排查目录
安装数和渠道后台对不上
安装数和商店后台、或自己的BI对不上
为什么安装都归到了自然量（organic）
广告变现收入对不上
内购收入对不上
留存、ROAS、LTV和别处算出来不一样
今天的数据缺了一块
速查：最高频的三个原因
Meta：AMM条款未签署，数据可见性会受到限制
Google Ads：转化动作未设为Primary，会放大Tracked Installs 和 Reported Installs的差异
广告变现收入：混淆Ad Mediation与Ad Network两种收入口径
开始查之前，把比较条件完全对齐
同一个App、同一个平台、同一个日期范围；
两边使用同一个时区（Tenjin看板统一使用UTC+0）；
同一层级和同一组筛选条件：App、Channel、Campaign、Country等不能一边有筛选、一边没有。
01 安装数和渠道后台对不上
Tenjin看板上这两个指标含义完全不同：
指标
含义
Tracked Installs
（追踪激活）
Tenjin自己追踪并归因到的安装
Reported Installs
（报告激活）
广告渠道API返回的安装，我们原样展示，方便你并排对照
以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重复计数。
02 安装数和商店后台、或自己的BI对不上
Tenjin记录的不是商店下载，而是SDK在设备上第一次成功上报的app open。首次app open记为安装，之后的app open记为会话（session）。
用户在商店点了下载但从来没打开过App，Tenjin里没有这次安装。
SDK未正常运行时，Tenjin不会收到数据。
原始数据里的acquired_at是这次首次打开的时间，不是商店下载时间。所有同期群指标都以它为锚点。
如果你的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名称和平台
具体的时间区间
涉及哪个渠道
已完成的配置步骤
对比方包含完整信息和相同筛选条件的截图
有任何疑问，欢迎联系我们（Tenjinbd）。
Tenjin
小红书官方账号
（打开小红书App扫码关注）
Tenjin
官方视频号
