如何验证 Appsflyer、Adjust或Branch.io 这样的移动测量平台（MMP）的安装和应用内事件数据？

如果我不确定像Adjust或Appsflyer这样的MMP，是否正确记录了应用的所有安装和应用内事件，并希望确认它们是否被 100% 记录下来，怎么办？这种情况尤其会在初创公司，没有部署完善的用户分析系统时发生，确认数据的逻辑，是找到一个有 “100%” Install 数据的可信数据源。我会推荐使用 Firebase 作为数据源来进行对比，所有的 MMP 都提供了事件 API（如Appsflyer 的 Push API）或 Callbacks（如Adjust），允许你访问原始事件数据流，我们拿到原始数据来与 Firebase 进行对比。

Firebase的“first_open”事件与MMP的“install”事件之间的数据差异

Firebase 的 first_open = MMP 的 install + reinstall

通常，Firebase的 first_open 事件数量会比 MMP 的 install 事件多，因为 first_open 事件会在你的应用首次启动时触发（无论是首次在设备上安装，还是在同一设备上删除后重新安装）。这与 MMP 不同，Adjust 或 Appsflyer 有一个“重新归因窗口”的设置，默认设置为 90 天。

The re-attribution window starts when the app is first installed. During the window duration, reinstalls can't be attributed as new installs. Reinstalls are ignored unless they are a result of a user engaging with a retargeting campaign. This is referred to as a re-attribution. Learn More

re-attribution window Appsflyer — Appsflyer 再归因窗口期设置

Firebase first_open 事件的 previous_first_open_count 参数

Firebase 的 first_open 事件是自动收集的事件，并且有一个事件参数 previous_first_open，它表示，在设备级别上，应用被安装和首次启动的次数，如果是全新安装，previous_first_open_count = 0，并且随着设备删除应用并重新安装的次数增加。因此，first_open（其中 previous_first_open_count = 0）的数量将更接近 MMP 的 install 数据。

当 iOS 设备没有获得 ATT 同意，即没有允许苹果 iOS 14应用跟踪提示时，previous_first_open_count 会发生什么？

尽管 Firebase 因为没有获得 ATT 同意而无法访问 IDFA，但 Firebase 仍然可以获取 IDFV，这是来自同一发布者/供应商的单一设备标识符，因此 previous_first_open_count 仍然可以适用于所有 iOS设备。通过下面的 SQL，你可以看到在 BigQuery 中按 previous_first_open_count 和按操作系统分组的 first_open 事件数量。

SELECT
  device.operating_system AS os,
  event_params.value.int_value AS previous_first_open_count,
  COUNT(*) AS count_of_events
FROM
  `your_project.your_dataset.events_*`, /*replace with your project id and dataset */
  UNNEST(event_params) AS event_params
WHERE
  event_name = 'first_open'
  AND event_params.key = 'previous_first_open_count'
GROUP BY
  os, previous_first_open_count
ORDER BY
  os, previous_first_open_count

你将得到像这样的样本结果

使用 ADID 和IDFV 作为标识符，来验证 MMP 的安装事件，与 Firebase 的 first_open 事件进行交叉比较

从Firebase的first_open事件中提取 ADID 和 IDFV

Firebase 事件中的 ADID 存储为 advertising_id， IDFV 存储为 vendor_id，两者都是设备列的参数，参考 [GA4] BigQuery Export schema. 因此，通过下面的SQL，你可以提取带有 advertising_id、IDFV 和 previous_first_open_count 的 first_open 事件，按日期和时间戳。

SELECT
  event_name,
  device.operating_system,
  device.advertising_id,
  device.vendor_id,
  TIMESTAMP_MICROS(event_timestamp) AS event_timestamp,
  DATE(TIMESTAMP_MICROS(event_timestamp)) AS event_date,
  device.mobile_brand_name,
  (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'previous_first_open_count') AS previous_first_open_count
FROM
  `your_project.your_dataset.events_*`,  /* replace with your project id */
WHERE
  event_name = 'first_open'
  AND (DATE(TIMESTAMP_MICROS(event_timestamp))  = '2023-12-03' or DATE(TIMESTAMP_MICROS(event_timestamp))  = '2023-12-04')  /*set time period*/
ORDER BY
  event_timestamp

你可以编辑特定日期范围的时间限制，并将结果保存到谷歌表格以进行进一步比较。

export ADID&IDFV_first_open to google sheet

从MMP访问安装原始数据

这里我列出了从 Appsflyer 和 Adjust 导出安装原始数据的示例

从 Appsflyer 导出安装回传数据

Appsflyer 提供了“报告”部分下的“原始数据导出”，你可以选择回传中的安装，只需记住：

对于iOS和Android，你需要在每个应用下分别导出。
Appsflyer上的时间持续性遵循你自己的时区设置，但Firebase安装数据时间戳是 UTC+0，所以你可能需要匹配时区。

另一种方法是使用 Appsflyer Push API 来记录安装数据，与 Adjust Callback 类似。

从Adjust导出安装回传数据

Adjust 在仪表板上没有原始数据导出功能，所以如果你想导出原始安装数据，可以联系你的账户经理并指定日期范围，账户经理将为你导出。或者，我们可以使用 Adjust Callback 功能手动记录安装数据，只是你无法从回调中访问历史数据。你可以使用 make.com 创建一个简单的 webhook 来接收来自 Adjust 的回调，并将其保存到Google sheet 中，不需要编写任何代码，只需几次简单的点击即可完成。配置 Adjust 安装回调时，记得添加“User Data”部分的参数，这样 ADID 和 IDFV 就会包含在回调中。

webhook for adjust install callback from make.com

通过比较 ADID 和 IDFV 与 Firebase 的 first_open 事件来验证 MMP 的 Install 数据

现在你有了同一时间段内的 first_open 事件和 Install 事件，你可以在 Google sheet 中使用简单的 vlookup 功能来找出哪些 ADID 或 IDFV 缺失，并提供给开发人员以进一步定位问题。

用 Firebase 的 "first_open" 事件来验证 Appsflyer/ Adjust 的 Install 数据