一
客户 BI / 业务后台 vs Adjust
4 项
BI / 业务后台
安装数
安装定义不同、时区/日期口径不一致、SDK未全量覆盖、去重逻辑不同，是最常见的四类原因。
根本原因
- 安装定义不同：Adjust的"安装"= 首次打开 App；客户后台可能是注册/激活/卸载重装等
- 时区/日期统计口径不一致（Adjust 默认 UTC）
- App 版本未全量集成 Adjust SDK，导致部分安装未被追踪
- 去重逻辑不同
排查清单
- 1对齐"安装"定义（首次打开 vs 注册/激活）
- 2确认双方统计时区一致（Adjust 默认 UTC）
- 3确认所有 App 版本均已集成 Adjust SDK
- 4确认去重逻辑一致
最常见原因：安装定义不同。建议先确认定义再排查其他项。
BI / 业务后台
事件数
事件触发定义不同、上报失败、唯一事件开关、拦截规则均可导致事件数差异。
根本原因
- 事件触发条件/定义不同
- 部分事件上报失败（SDK 未触发 / S2S 上报异常）
- Adjust 勾选了"唯一事件"，同一用户多次触发只算一次
- 事件被转化规则/事件规则拦截
排查清单
- 1确认事件触发条件定义一致
- 2检查 SDK 埋点是否正确
- 3检查 S2S 服务器上报是否成功
- 4后台确认"唯一事件"开关状态
- 5检查转化规则/事件规则是否在过滤数据
后台有事件但偏少 → 优先查唯一事件开关和拦截规则。
后台完全无事件 → 先查 SDK 埋点和上报。
后台完全无事件 → 先查 SDK 埋点和上报。
BI / 业务后台
事件收入
收入差异通常是事件数差异的延伸，建议先解决事件数问题。
根本原因
- 事件数本身有差异（先解决事件差异）
- 币种设置不一致
- 收入上报失败或被拦截
排查清单
- 1先确认事件数是否一致
- 2确认双方使用相同货币单位
- 3检查收入参数是否正确传入上报
Firebase / 其他
留存率
Adjust 使用严格 24h 制留存，Firebase 使用自然日，Adjust 留存数字通常偏低——这是正常现象。
根本原因
- Adjust：严格 24 小时制
用户 3 月 10 日 19:00 安装，D1 须在 3 月 11 日 19:00 ~ 3 月 12 日 19:00 之间打开才算 - Firebase / 其他：自然日制
只要在次日（同一日期范围内）打开即可 - 时区不一致也会导致同期群基准不同
排查清单
- 1向客户说明 Adjust 使用 24h 制，数字低于自然日统计属正常
- 2确认双方时区设置一致
正常现象，无需修复。24h 制更严格，能真实反映产品粘性，避免跨午夜使用被误计入次日留存。
二
媒体后台 vs Adjust（归因数据）
5 项
Meta (Facebook)
安装数
排重周期（Adjust 永久 vs FB 90天）、归因窗口、展示归因开关、记数逻辑，是四大核心差异来源。
根本原因（方法论差异）
- 排重周期：Adjust 永久排重 vs Facebook 90 天排重窗口——同一设备 90 天后重装，FB 重计，Adjust 不计
- 归因窗口：确认点击 7d / 展示 1d 是否已对齐
- 展示归因：Adjust 默认不开，FB 默认开——未开则 Adjust 数字低于 FB
- 记数逻辑：Adjust 将事件记录在激活日期；FB 记录在广告交互日期（点击/展示日期）
排查清单
- 1确认归因窗口：点击 7d，展示 1d（与 FB 一致）
- 2确认是否已开启展示归因
- 3确认数据分享回传配置正确
- 4确认是否启用 AEM 概率模型匹配（iOS 无 IDFA 设备）
- 5确认对比日期和时区一致
可对齐：归因窗口、展示归因开关。
本质差异（无法消除）：排重周期不同、记数逻辑不同。大部分差异属方法论，需向客户解释。
本质差异（无法消除）：排重周期不同、记数逻辑不同。大部分差异属方法论，需向客户解释。
Google Ads
安装数
GG 归因窗口默认 30 天，与 Adjust 默认 7 天差异大，建议先对齐窗口再比较数据。
根本原因
- 排重周期：Adjust 永久排重 vs GG Firebase 卸载重装重新计算
- 归因窗口：GG 点击 30d（Adjust 默认 7d），窗口差异大导致数字差异明显
- 展示归因：Adjust 默认不开，GG 默认开
- 数据来源：Adjust 后台"安装（渠道）"取自 GG Ads API 的 conversions 接口，非 first-open
排查清单
- 1确认归因窗口：点击 30d，展示 1d（与 GG 对齐）
- 2确认是否开启展示归因
- 3确认是否启用 ICM 概率模型匹配
- 4确认数据分享回传配置正确
- 5确认对比日期和时区一致
注意：GG 归因窗口默认 30d，与 Adjust 默认 7d 差异大，这是最常见的数字偏差来源。建议先对齐窗口再比较数据。
TikTok
安装数
TikTok 使用 Audience Reporting API 的 real_time_conversion 指标，与安装归因口径存在差异。
根本原因
- 排重/归因窗口与 Adjust 存在差异（点击 7d，展示 1d）
- TikTok 使用 Audience Reporting API 的 real_time_conversion 指标，与安装归因有出入
排查清单
- 1确认归因窗口：点击 7d，展示 1d
- 2确认是否开启展示归因
- 3确认是否启用概率模型匹配
- 4确认数据分享回传配置正确
TikTok API 指标差异：Adjust 用 real_time_conversion 作为渠道安装数，与 TT 后台展示的数字口径可能不同，属正常现象。
Apple Search Ads
安装数
ASA 归因依赖 AdServices.framework，未接入则 ASA 安装无法被 Adjust 追踪。归因窗口为点击 30d。
根本原因
- iOS ATT 限制：无 IDFA 设备走 SKAN，数据有延迟且聚合
- 归因窗口：点击 30d，展示 1d
- AdServices.framework 未集成，导致 ASA 归因缺失
排查清单
- 1确认已添加 AdServices.framework
- 2确认归因窗口：点击 30d，展示 1d
- 3对比指标定义（ATT/SKAN 指标需区分）
- 4对比日期和时区是否一致
各平台通用
事件数 / 收入
事件/收入差异通常是安装差异的延伸，建议先对齐安装数。
根本原因
- 安装数本身有差异（延伸问题）
- 事件未正确回传给媒体平台
- 回传事件未映射
- 币种不一致（收入类）
排查清单
- 1先确认安装数是否一致
- 2确认已开启事件回传
- 3确认回传事件已正确映射
- 4收入：确认币种一致，已回传收入事件
三
App Store / Google Play Store vs Adjust
2 项
App Store / GP
安装数（系统性）
8 大系统性差异原因，均属正常现象，无法消除。Adjust 与应用商店数据统计口径根本不同，不可直接对比。
8 大根本原因（均属正常现象，无需修复）
- 下载 ≠ 安装：商店统计下载；Adjust 统计首次打开，部分用户下载后未打开
- 时间/时区：商店记录下载时间；Adjust 记录首次打开时间（UTC），用户可能几天前下载今天才打开
- 用户维度 vs 设备维度：商店按账号去重（同账号多设备=1次）；Adjust 按设备计算
- SDK 接入时间：上线后才接 Adjust SDK，老用户更新后被重新计为安装，持续数周后回落
- iOS 隐私授权：App Store 只统计同意分享数据给 Apple 的 iOS 8+ 用户（opt-in only）
- Google Play Service：无 GPS 设备的安装不被 GP 统计，但 Adjust 会统计
- 防作弊逻辑不同：GP 与 Adjust 识别假量的标准不同，导致被拒绝的安装数不同
- 归因逻辑不同：GP 自然量/非自然量是 GP 自己的归因，与 Adjust 的 Last-Click 归因逻辑完全不同
建议操作
- 1明确"安装"定义后选择统一口径
- 2不建议直接将商店数据与 Adjust 数据对比
- 3若差异异常偏大，检查 SDK 版本覆盖情况
告知客户：Adjust 与应用商店数据统计口径根本不同，不可直接对比。这不是数据错误，是统计方法的本质差异。
Google Play
卸载数
Adjust 卸载统计有延迟（最长 1 周），且须以追踪到安装为前提，与 GP 口径不同。
根本原因
- Adjust 统计卸载的前提：已追踪到该设备的安装（首次打开）；GP 基于下载
- Adjust 通过每日静默推送判断卸载，延迟最长 1 周；同一设备多次卸载只统计一次
排查清单
- 1确认双方卸载统计前提是否一致
- 2告知客户 Adjust 卸载数据有延迟（最长 1 周），属正常
四
SKAdNetwork (SKAN) vs Adjust
1 项
iOS SKAN
转化值 / 安装数
SKAN 是 Apple 隐私框架，数据有延迟（≥24h）、隐私阈值（>100安装/天/campaign）、仅聚合报表，与 Adjust 实时归因本质不同。
根本原因
- 数据延迟：SKAN 回传至少延迟 24 小时
- 隐私阈值：单个 campaign 每天安装 <100 时，Apple 不返回数据
- 数据聚合：SKAN 只有聚合报表，无法下钻到设备级别
- 转化值配置：后台转化值未正确配置会导致转化值丢失
排查清单
- 1确认渠道账户关联完成且未过期（FB/Google/Twitter）
- 2后台指标选择"Total Installs(SKAN)"
- 3确认 App 已接入 StoreKit.framework
- 4后台已验证 App ID
- 5检查后台转化值配置
- 6确认流量满足隐私阈值（单 campaign/天 >100 安装）
- 7告知客户 SKAN 数据有延迟，不能与实时数据直接对比
SKAN vs 可交付（Adjust）核心对比：
归因来源：SKAN = Apple 归因；可交付 = Adjust 归因
数据延迟：SKAN ≥ 24h；可交付 = 实时
数据精度：SKAN = 聚合（无设备级）；可交付 = 设备级
用户识别：SKAN 无；可交付用 adid 排重
归因来源：SKAN = Apple 归因；可交付 = Adjust 归因
数据延迟：SKAN ≥ 24h；可交付 = 实时
数据精度：SKAN = 聚合（无设备级）；可交付 = 设备级
用户识别：SKAN 无；可交付用 adid 排重
五
Adjust 后台数据异常（内部问题排查）
4 项
Adjust 后台
安装数为 0 / 异常偏低
最常见原因：误用 Sandbox 环境。确认环境是第一步。
根本原因
- 筛选条件错误：环境选了 Sandbox 而非 Production
- App 版本未集成 Adjust SDK
- SDK 初始化失败
排查清单
- 1首先确认后台环境筛选为"生产环境(Production)"而非 Sandbox
- 2确认时间范围和时区筛选正确
- 3确认 App Store 版本已集成 Adjust SDK
- 4输出 Verbose log 确认 SDK 初始化成功
Adjust 后台
事件数异常
确认埋点、上报、拦截规则三个方向。
根本原因
- 事件未正确埋点（SDK 未触发）
- S2S 服务器上报异常
- 被转化规则/事件规则拦截
排查清单
- 1确认环境/时间筛选正确
- 2确认事件埋点逻辑正确
- 3检查转化规则和事件规则
- 4输出 Verbose log 查看事件上报日志
Adjust 后台
订阅事件/收入异常
订阅监测不是默认开启的，需额外配置。未配置则后台不会有订阅数据。
根本原因
- SDK 未集成订阅监测模块
- 未关联 App Store Connect 凭证或 Google 服务账户
- 未设置商店通知
排查清单
- 1确认 SDK 已集成订阅监测
- 2在后台关联 App Store Connect 凭证(iOS) / Google 服务账户(Android)
- 3配置 App Store 或 Google Play 的商店通知
- 4确认环境/时间筛选正确
Adjust 后台
点击/展示数异常
确认数据源筛选和渠道账户关联状态。
根本原因
- 数据源筛选错误（渠道/归因来源未正确选择）
- 渠道账户关联未完成或已过期
排查清单
- 1确认数据源筛选（渠道/归因来源）
- 2检查渠道账户关联状态，确认账户未过期
六
原始数据回调（Raw Data Postback）异常
1 项
原始数据回调
安装/事件/收入回调
先确认 Adjust 后台是否有数据，再检查回传配置和 IP 白名单。聚合广告收入不支持原始回调。
根本原因
- Adjust 后台本身无数据（回调自然为空）
- 服务器回传/云储存配置错误
- 客户服务器 IP 白名单未放行 Adjust IP
- 聚合广告收入不支持广告收入回调（产品限制）
排查清单
- 1先确认 Adjust 后台是否有对应数据
→ 有数据：检查回传 URL 和服务器配置
→ 无数据：先排查数据本身 - 2确认 Adjust IP 已加入白名单
- 3确认服务器回传/云储存配置正确
注意：聚合广告收入（如 AdMob 等广告变现）不支持原始回调，这是产品限制，非配置问题。
七
广告聚合平台 vs Adjust（广告收入）
1 项
广告聚合平台
广告收入
广告变现收入需单独对接（SDK/API），与事件收入不同，需确认对接方式是否成功。
根本原因
- Ad Revenue SDK/API 未正确集成
- 后台广告收入来源筛选器设置不正确
- 统计日期和时区不一致
排查清单
- 1确认 Ad Revenue 已通过 SDK 或 API 正确对接
- 2检查 Adjust 后台数据配置项中的广告收入来源筛选器
- 3确认对比日期和时区一致
八
概念补充说明（供客户参考）
2 项
再归因
Reattribution
非活跃用户（超过设定天数未打开）通过新广告来源重新打开 App，与卸载无关。会影响渠道数据分布。
概念说明
- 定义：非活跃用户（超过设定的非活跃天数阈值，默认 10 天未打开）通过新的广告来源重新打开 App = 产生一次再归因
- 注意：与卸载无关，无需卸载重装
- 示例：用户从渠道 A 安装，10 天后未打开（变为非活跃），点击渠道 B 广告进来 → 产生渠道 B 的再归因，后续事件计入渠道 B
- 配置入口：后台 > 所有设置 > 归因 > 再归因（可设置非活跃用户定义天数 + 再归因归因窗口）
再归因会影响渠道数据分布。若某渠道事件数异常增加，需检查是否有大量再归因发生。
归因来源
动态 vs 第一
两种模式口径不同，不要混用后对比数据：第一=初始安装来源；动态=当前归因来源（含再归因）。
概念说明
- 第一 (First)：用户首次安装时的归因渠道，查看用户最初从哪里来
- 动态 (Dynamic)：用户当前的归因来源，含安装+再归因，用于分析召回广告效果
- 动态模式：0d 同期群大小 = 安装数 + 再归因数（Organic 不含再归因）
- 第一模式：每个渠道下（含 Organic）都可能有再归因
使用建议
- ✓分析新用户获取效果 → 用"第一"
- ✓分析召回/再营销效果 → 用"动态"
- !两种模式口径不同，不要混用后对比数据
🔍
未找到匹配结果
尝试其他关键词或切换筛选条件