干货分享｜数据对不上，先别慌

以 Tracked Installs 为准。这是 Tenjin 作为第三方独立归因的结果，也是计费和出报表的口径。*自因渠道 30% 以内的差异属于预期范围。

差异超出预期范围时，按以下顺序排查：

• Google Ads：如果 Tenjin 的 First Open 转化动作设成 Secondary（次要）、Firebase 设为主要转化事件，会显著放大 reported install 和 tracked install 的差异。改成 Primary 后，差异会逐步收敛。

• Meta：确认 AMM 条款已签署。若未达到最低流量门槛且未在 Meta Events Manager 接受 AMM（Advanced Mobile Measurement）条款，Meta 会套用严格的隐私阈值，低于阈值的 campaign 数据会被 API 遮蔽。在投放开始前完成 AMM 签署。

• 回传开关：渠道后台显示安装为 0 时，确认 Tenjin 侧该渠道的回传开关已开启。ON 表示回传已开启；OFF 表示未开启。

  

• Callback Health：绿色 100% 表示过去一天的回传全部成功送达；黄色或红色表示部分回传被渠道拒绝；没有颜色和百分比表示该事件过去一天未被触发。

• 渠道 SDK：确认 App 是否同时在用渠道的 SDK 发送安装事件。两套 SDK 同时上报会导致渠道侧的 Reported 重复计数。

Tenjin 记录的不是商店下载，而是 SDK 在设备上第一次成功上报的 app open。首次 app open 记为安装，之后的 app open 记为会话（session）。

• 用户在商店点了下载但从来没打开过 App，Tenjin 里没有这次安装。

• SDK 未正常运行时，Tenjin 不会收到数据。

• 原始数据里的 acquired_at 是这次首次打开的时间，不是商店下载时间。所有同期群指标都以它为锚点。

和自己的 BI 比，还要看两边的主键是不是一回事。Tenjin 按设备算：每一次安装会生成一个新的安装 ID（AIID，Analytics Installation ID），我们再用设备标识（Android 的 GAID、iOS 上已授权 ATT 的 IDFA）去查这台设备以前的安装记录，尽量把老用户认回来。如果能识别到老用户重装，我们会继承原来的归因。不产生新转化、不重复计费、不重复回传给渠道。

如果你的 BI 是按账号 ID 去重的，一个用户在三台设备上登同一个游戏账号，你算一个人，我们算三个。

03 为什么安装都归到了自然量（organic）

一个安装被记成自然量，只意味着一件事：在归因窗口内，没有找到任何能匹配上这台设备的广告互动。

这不代表这个用户真的是自然来的。如果大部分安装都归到了自然量，按顺序检查归因链路：

• 确认投放渠道已在看板中完成授权配置。

• 确认自归因渠道的安装回传已开启。

• 确认广告点击已进入 Tenjin。非自归因渠道可在看板的 campaign 详情页检查点击数；如果点击为 0，检查追踪链接的宏映射。

04 广告变现收入对不上

Tenjin 看板上的广告变现收入分为两种，计算机制不同，不应期待两者完全一致

指标		含义
Ad Mediation 收入 来自聚合平台 SDK，展示级		聚合平台在每次展示后发出展示级收入信号（ILRD），Tenjin 的 SDK 监听它。每条信号都带用户标识，所以能绑定到具体用户，再逐层汇总到买量的 campaign、渠道和 App
Ad Network 收入 来自变现渠道 API，结算级		Tenjin 调各变现渠道的报表 API，拉 App 和日期级别的实际结算总额，再按各买量渠道贡献的会话数占比分摊下去

结论：计算 ROAS 和优化买量渠道时，使用 Ad Mediation。

两者产生差异的常见原因包括：计算逻辑不同、ILRD 出价属于聚合平台估算值、时区不同，以及 API 报表延迟或事后修正。

• Ad Mediation 为 0 或明显偏低：确认 Tenjin 的聚合平台 SDK 监听插件已正确安装。

• Ad Network 为 0 或明显偏低：确认每一个变现渠道都已单独添加并授权，只添加聚合平台的发布商账号并不够。

05 内购收入对不上

• 确认 SDK 集成状态表中的「Valid Purchase Event」为绿色。未显示绿色，表示 Tenjin 没有收到通过校验的内购事件。

• 需要逐笔对账时，使用 Raw Data Exporter 导出 purchase 事件。purchase_state 字段会显示交易的校验结果，例如缺少收据、商店校验失败或重复提交。这是定位内购差异最直接的方法。

• 如需跳过收据验证，可在 App - edit - "Accept unvalidated purchases"中调整。

06 留存、ROAS、LTV 和别处算出来不一样

第一，先确认你比的是「哪天发生的」还是「哪天来的人」

类型		说明
同期群（cohort）指标		指标名里带 N-Day 的都是，例如 N-Day IAP LTV、N-Day Retention Rate、N-Day Ad ROAS。全部按获取日期（也就是安装日）分组
日常指标		不带 N-Day 的，例如 Spend、Tracked Installs、Ad Revenue。按事件发生当天统计

「7 月 1 日的收入」和「7 月 1 日安装的用户在之后 24h 带来的收入」是两个不同的统计口径。

第二，确认你用的是哪种同期群算法

路径是 My Account→Manage User→Cohort Strategy。

算法		怎么切 Day N
UTC（绝对）		Day 1 从用户安装之后的第一个 UTC 零点开始，所以 Day 0 是安装当天那段不完整的时间。
Relative（相对，默认）		从每个用户自己的安装时刻起算，每 24 小时算一天。0 到 24 小时是 Day 0，25 到 48 小时是 Day 1。适合看用户真实的行为节奏

同一批用户在两种算法下的留存率和 ROAS 必然是不同的数字。

07 今天的数据缺了一块

来自 Tenjin SDK 收集的事件几乎实时，来自渠道 API 拉取的数据有若干延迟：

延迟	包括哪些
基本实时	Tracked Installs、SDK 上报的各类事件（自定义事件、内购等）
每 2 到 3 小时	Spend、Reported Installs/Clicks/Impressions，以及变现里的 Ad Revenue（Ad Network）

都查过了，还是对不上

完成以上检查后仍然没有头绪吗？没问题，我们帮你排查！请一次性提供以下信息：

第 1 天和第 7 天留存 App 名称和平台

具体的时间区间

涉及哪个渠道

已完成的配置步骤

对比方包含完整信息和相同筛选条件的截图

Tenjin

小红书官方账号

（打开小红书 App 扫码关注）

Tenjin

官方视频号