Charles Shao
Go back

IDFA 之后的归因：MMP、SKAdNetwork 与 Postback 结算

–views

“我花在广告上的钱有一半是浪费的；麻烦在于，我不知道是哪一半。” —— John Wanamaker

到了移动 App 拉新这件事上，Wanamaker 那句老话有了一个更具体、也更扎心的版本：你今天花在 Facebook、Google、TikTok、某家 DSP 上的钱，各家后台都会告诉你”我给你带来了 X 次安装”——把它们加起来，往往比你真实的安装量还多。渠道各报各的、口径互不相认，你手里根本没有一份能对账的账本。

**MMP（Mobile Measurement Partner，移动测量合作伙伴）就是来当这份账本的中立第三方。**这篇会从工程视角讲清：MMP 到底怎么把一次安装追溯到具体的渠道 / 广告 / 创意，它的 SDK 在设备上采集了什么，数据怎么通过 Postback 实时回流到你的服务器，IDFA 崩塌之后 SKAdNetwork 如何补位，以及为什么最后你还需要一个 **SSOT（单一数据源）**来做统一结算。全程以 AppsFlyer 这个事实上的行业标准为例。

范围说明：本篇聚焦”安装之后、谁带来的”这条归因与结算链路。它上游的那套竞价生态——DSP / SSP / Ad Exchange 全景、Header Bidding 与 OpenRTB——以及端上广告怎么被渲染出来（App 广告 SDK 深挖），各有专文。隐私同意的上游约束见 IAB TCF 与 GPP、广告的地区合规。

TL;DR

Table of contents

Open Table of contents

1. 问题：移动世界里”这次安装从哪来”根本说不清

在网页时代，归因相对简单：cookie、referrer、URL 参数，链路基本连得起来。到了移动 App，事情断成了两截。

用户在媒体 App（比如刷 TikTok）里点了你的广告，然后被丢到应用商店，下载、安装、打开——这中间跨越了浏览器、商店、你的 App 三个彼此隔离的沙盒，没有一根天然的线把”那次点击”和”这次安装”缝在一起。

于是每个渠道只能各说各话：

这正是 MMP 存在的理由：引入一个所有渠道都接入、但不属于任何一个渠道的中立第三方，用统一规则去数每一次安装。

2. MMP 是什么：移动归因的中立第三方

MMP 坐在广告渠道和你的 App 中间，同时接两端：

MMP 拿着两端的数据做一次匹配，就还原出了”这次安装是谁带来的”。整条链路是这样的：

移动归因链路：① 用户在媒体 App 里点击广告，带设备标识/时间戳经 MMP tracking link 记录 → ② 跳转应用商店下载安装 → ③ App 首次启动，MMP SDK 上报设备信息与首启时间 → ④ MMP 做点击↔安装匹配（同设备、在归因窗口内）判定归因 → ⑤ 通过 Postback 把归因结果实时回传给广告主服务器与各广告渠道 图 1 —— 移动归因链路：点击 → 安装 → 首启上报 → MMP 匹配 → Postback 回传。

关键在于：MMP 是唯一一个同时看到”点击”和”安装”两端的角色。渠道只知道自己这侧的点击，你的 App 只知道自己被打开了——只有 MMP 把两端接起来，归因才成立。

MMP 归因数据里的核心字段（以 AppsFlyer 为例）：

字段含义
appsflyer_idMMP 为设备生成的唯一标识符（跨渠道稳定）。
advertising_id设备广告标识符（iOS 的 IDFA / Android 的 GAID）。
media_source广告渠道（如 facebook、googleadwords_int）。
campaign / adset / ad广告活动 / 广告组 / 创意的名称或 ID——归因的粒度就到这一层。
click_time用户点击广告的时间戳。
install_time应用安装完成的时间戳。
first_launch_time用户首次打开 App 的时间戳（SDK 上报的锚点）。
af_status归因状态：Organic / Non-organic / Re-engagement。
is_retargeting是否再营销流量。
is_first_launch是否首次启动。

3. 归因是怎么匹配的：确定性、概率与归因窗口

3.1 af_status：一次安装的三种命运

af_status 是归因数据里的核心分类字段：

值含义
Non-organic非自然——匹配到了某次广告互动，安装归给对应渠道。
Organic自然——没匹配到任何广告互动，视作用户自己搜到下载的。
Re-engagement再归因——已安装用户被再营销广告重新激活。

你付的钱只跟 Non-organic 有关；Organic 的量是白捡的，但也正因为白捡，它常常是渠道”抢归因”（把本属自然的量算到自己头上）的重灾区——后面 §7 会讲。

3.2 两种匹配方法：确定性优先，概率补充

MMP 判定”这次点击和这次安装是不是同一个人”，有两条路：

一句话记住原则：能确定就别猜，不能确定也别扔。

3.3 归因窗口：追溯多久算数

归因窗口（attribution window / lookback window）规定了”一次广告互动之后，多久之内的安装还能算到它头上”。这几个默认值直接决定了结算金额：

窗口类型默认值含义
点击归因窗口7 天点击后 7 天内安装，才归给这次点击。
展示归因窗口24 小时只看过（没点）广告后 24 小时内安装，才归给这次展示（VTA，View-Through Attribution）。
再归因窗口90 天已安装用户被再营销广告重新激活的判定窗口。

窗口越长，越多安装会被算成”非自然”、被算给渠道——你的花费也就越高。**这不是一个技术默认值，而是一个商务谈判点：**渠道希望窗口越长越好（多抢量），广告主则要按自己的真实转化周期把它收紧。

4. MMP SDK 到底在设备上采集了什么

归因只是 SDK 的起点。集成进 App 的 MMP SDK 会持续采集多个维度的数据，既服务归因，也服务后续的 ROAS 分析和防作弊。分类如下（以 AppsFlyer SDK 为例）：

设备与标识：appsflyer_id、idfa（需 ATT 授权）、gaid、device_model、os_version、device_brand、device_type、screen_resolution、device_language、device_timezone、network_type、carrier。

安装与来源：media_source、campaign、adset、ad、click_time、install_time、first_launch_time、is_first_launch、af_status。

应用内事件（in-app events）——归因之后真正衡量价值的部分：

字段含义示例
event_name事件名（如 purchase、af_level_achieved）。purchase
event_time事件发生时间戳。2026-07-01 12:40:00
event_value事件的值（如购买金额）。9.99
event_parameters附加参数（商品 ID、货币、支付方式等）。{"product_id":"12345","currency":"USD"}
event_revenue事件产生的收入。9.99

地理位置：country_code、city、region、latitude / longitude（需授权）。

深度链接（deep linking）：deep_link_url、deep_link_parameters、is_deferred_deep_link——延迟深度链接让新用户装完 App 后直接落到点击时那个具体页面。

防作弊：device_fingerprint、suspicious_activity——用于识别虚假流量（详见 §7）。

隐私相关：att_status（iOS 的 ATT 授权状态）、opt_out、data_deletion_request。

一段有代表性的采集数据长这样：

{
  "appsflyer_id": "12345678-1234-1234-1234-123456789012",
  "idfa": "A1B2C3D4-E5F6-...",
  "device_model": "iPhone 14 Pro",
  "os_version": "iOS 16.1",
  "media_source": "facebook",
  "campaign": "summer_sale_2026",
  "click_time": "2026-07-01 12:34:56",
  "install_time": "2026-07-01 12:35:10",
  "first_launch_time": "2026-07-01 12:35:30",
  "is_first_launch": true,
  "event_name": "purchase",
  "event_value": 9.99,
  "event_parameters": { "product_id": "12345", "currency": "USD" },
  "country_code": "SG",
  "att_status": "authorized"
}

采集越全，分析越深，但隐私红线越紧。这份数据里的每一个字段，在 GDPR / CPRA / PIPL 下都有明确的合规义务——见 §7 与 广告的地区合规。

5. Postback：数据怎么实时回流到你的服务器

采集在设备上，但数据要流出去才有用。Postback 就是 MMP 的实时数据出口：一旦发生归因或应用内事件，MMP 就把结构化数据实时推送（HTTP POST）到你指定的服务器和各广告渠道。

Postback 的字段按维度组织，覆盖归因、事件、设备、地理、隐私等。一份完整的 Postback 载荷示例：

{
  "appsflyer_id": "12345678-1234-1234-1234-123456789012",
  "advertising_id": "A1B2C3D4-E5F6-...",
  "media_source": "facebook",
  "campaign": "summer_sale_2026",
  "adset": "age_18_25_sg",
  "ad": "video_ad_12345",
  "click_time": "2026-07-01 12:34:56",
  "install_time": "2026-07-01 12:35:10",
  "af_status": "Non-organic",
  "event_name": "purchase",
  "event_time": "2026-07-01 12:40:00",
  "event_revenue": 9.99,
  "event_parameters": {
    "product_id": "12345",
    "currency": "USD",
    "payment_method": "credit_card"
  },
  "device_model": "iPhone 14 Pro",
  "os_version": "iOS 16.1",
  "country_code": "SG",
  "att_status": "authorized"
}

Postback 有两个方向，别混淆：

除了 Postback（推），MMP 通常还提供另外两种取数方式：

方式形态用途
Postback（S2S 回传）MMP 主动推实时、逐事件；喂渠道优化、触发你自己的实时逻辑。
Pull API你主动拉周期性批量拉明细报表，做离线分析、补数、对账。
Dashboard人看MMP 后台看聚合报表、渠道对比、ROAS。

6. IDFA 之后：ATT、SKAdNetwork 与概率归因

上面讲的确定性归因，全都建立在”能拿到设备广告 ID”这个前提上。2021 年 iOS 14.5 的 ATT（App Tracking Transparency）把这个前提抽掉了。

ATT 要求 App 在访问 IDFA 前必须弹窗征得用户同意。真实世界里同意率长期在低位徘徊，结果是 iOS 端的 IDFA 覆盖率大幅坍塌——确定性归因在 iOS 上大面积失效。行业的应对是三条腿走路：

IDFA 之后的三种归因路径对比：① 确定性归因——用 IDFA/GAID 精确匹配，最可信，但 iOS ATT 后覆盖坍塌；② 概率归因——设备指纹+时间戳+行为，覆盖广但不精确，Apple 政策收紧；③ SKAdNetwork——Apple 官方框架，无需设备 ID、隐私保护，但数据聚合、延迟、无用户级明细、转化值位数有限 图 2 —— IDFA 之后的三条归因路径：确定性、概率、SKAdNetwork（SKAN）各有取舍。

这三者是互补而非替代关系：MMP 的现代职责，就是把确定性、概率、SKAN 三路信号融合成一份尽量完整的图景。而正因为口径这么多、来源这么杂，你最终更需要一个统一的对账层——这就引出了 SSOT。

7. SSOT：为什么你需要一个”单一数据源”

SSOT（Single Source of Truth，单一数据源）是 MMP 的最终价值主张：不是简单地把各渠道数据堆在一起，而是用统一的技术规则 + 隐私架构，输出一份所有人都认的账本。

7.1 它解决什么：去重与统一口径

回到 §1 那个”180 > 150”的困局。SSOT 的核心动作是跨渠道去重 + 按统一优先级分配归因：

SSOT 跨渠道去重对比：无 SSOT 时——用户先点 Facebook 广告又点 Google 广告后安装，两个渠道各自计数 1 次安装（重复计数、总量虚高）；同一设备 24 小时内多次广告展示，各媒体各记多次有效曝光。有 SSOT 时——按统一规则（如最后点击优先）仅归因 Google 1 次；多次展示仅记 1 次有效展示。输出：一份去重后、可对账的统一安装账本 图 3 —— SSOT 用统一规则去重：把”各渠道各报各的”收敛成一份可对账的账本。

场景无 SSOTSSOT 处理结果
用户点了 FB 广告，又点 Google 广告后安装FB 和 Google 各记 1 次安装仅归因 Google（最后点击优先）
同一设备 24h 内收到多次广告展示各媒体可能各记多次有效曝光仅记 1 次有效展示

统一的归因规则包括：一致的点击 / 展示窗口期、一致的去重优先级（如 last-click）、一致的防作弊过滤逻辑。所有渠道在同一把尺子下被衡量，ROAS 才有横向可比性。

7.2 顺带解决的：防作弊

因为 SSOT 同时握着所有渠道的原始明细，它天然是防作弊（反 IVT）的最佳位置：

7.3 顺带解决的：隐私合规

SSOT 通过三层机制平衡数据效用与隐私：

  1. 数据最小化：不收原始 IP、精确 GPS，敏感标识做哈希处理。
  2. 聚合优先：报告层给分群数据（“25–34 岁女性”）而非个体数据。
  3. 合规适配：自动遵循 GDPR / CPRA / PIPL 等区域法规；对 iOS 用户启用 SKAdNetwork（无需设备 ID）。

关键结论：SSOT 不是数据聚合器，而是数据价值链的重构者——它把碎片化、口径不一、隐私风险高的多源数据，收敛成一份可审计、可解释、法律安全的营销账本。

8. 生产实战：那些真正会咬你的取舍

速查表

延伸阅读

先看同系列里和本篇相邻的几篇：

再是一手资料：

附录：术语表

–views
Share this post on:
Share this post via WhatsApp Share this post on Facebook Share this post on X Share this post via Telegram Share this post on Pinterest Share this post via email
Previous Post
时序数据库 InfluxDB 深挖 · 数据模型、TSM 存储引擎与降采样保留
Next Post
冷启动：程序化栈每一层都在解同一个问题