AppsFlyer 点击归因全链路：钱埋在哪一跳里

做联盟、做买量的人，每天有几十万次点击从自己手里流过 AppsFlyer 的链接，但我见过的从业者里，能把「用户点了一下广告之后到底发生了什么」完整讲下来的，十个里不到一个。大多数人对这条链路的理解停留在「点了 → 装了 → AF 面板出数」，中间是黑盒。

问题是，你的钱和你的委屈，全都埋在这个黑盒里：掉归因、点损、CTIT 异常被判无效、上游说「我们这边没收到 click」——每一件事都发生在这几跳之间的某一跳。看不懂链路的人，出了问题只能干瞪眼；看得懂的人，抓一次包就知道锅在谁头上。

这篇文章就干一件事：把 AppsFlyer 点击归因的全链路，从用户手指碰到广告的那一毫秒，一跳一跳拆到归因结果回传，并告诉你每一跳你能观测什么、能排查什么。

一、先给你一张全链路地图

整条主链路一共八步：用户点击 → 渠道跳转 → AF 点击端点 → 商店 → 安装激活 → SDK 首启 → 归因判定 → 回传。先把这张时序图看一遍，后面每一节都是对图上某一跳的放大：

图1：AppsFlyer 点击归因全链路时序图——每一跳的关键参数与可观测点

如果嫌长，记住我常用的「四个包」心智模型：

包	发生了什么	谁发给谁
点击包	用户点广告，AF 收到一次 HTTPS GET	用户设备 → AF
跳转包	AF 用 302 把用户送去商店/App/落地页	AF → 用户设备
首开包	安装后首开，SDK 上报 install/session	App 内 SDK → AF
归因结果包	AF 匹配 click + 首开，出结果、发 postback	AF → 媒体/广告主

归因不是一个动作，是两条独立网络链路在 AF 服务端的会师。 点击链路走浏览器，上报链路走 App 内 SDK，两边任何一边断了，归因就没了。这是后面所有排障思路的总纲。

二、attribution link：URL 参数就是你的电子合同

先看一条比较完整的 AF 追踪链接（真实投放里的链接大致长这样）：

https://xxx.onelink.me/AbCd?pid=media_source_int&c=us_ios_campaign01
  &af_c_id=10086&af_adset=ret_users&af_ad=video_v3
  &af_siteid=pub_8821&clickid={click_id}
  &advertising_id={gaid}&af_click_lookback=7d
  &deep_link_value=promo

这一串参数不是装饰。pid 写的是谁，钱就结给谁；clickid 丢没丢，决定你月底能不能对上账。 我按「它替你回答什么问题」把参数分成六组，逐个拆。

第一组：钱归谁——归因维度参数

参数	含义	从业者视角
`pid`	media source，流量来源渠道	归因归谁，第一看它。集成渠道通常带 `_int` 后缀。pid 拼错一个字母，跑一个月都是白干
`c`	campaign 名称	面板按 campaign 拆数据的依据。注意它是「名字」，可以重复、可以中途改
`af_c_id`	campaign 的数字 ID	对账以它为准。上游中途改了 campaign 名，面板前后数据对不上——十有八九是你只看了 `c`，没看 `af_c_id`。名字会变，ID 不会
`af_adset` / `af_ad`（及 `_id` 变体）	广告组 / 素材维度	优化师定位哪条素材在跑量的抓手。拆得越细，事后越能自证
`af_prt`	代理机构标识	走 agency 投放时的归属维度，结算链条上多一方时必查

第二组：锅归谁——子渠道参数

参数	含义	从业者视角
`af_siteid`	publisher / 子渠道 ID	AF 反作弊按它评分，黑名单按它拉。整个 pid 被拉黑很少见，某个 af_siteid 被拉黑非常常见。你想按子渠道切掉垃圾流量，没有 af_siteid，你连该切哪个都不知道
`af_sub_siteid`	更细一级的子来源	联盟多层结构时的第二级定位
`af_sub1`~`af_sub5`	自由透传位	AF 不解析，原样存、原样吐回，随便你塞对账用的私货

做联盟的记住一句话：pid 决定钱给哪家公司，af_siteid 决定这家公司里谁背锅。 出了质量问题，AF 和广告主的刀都是按 af_siteid 落的。

第三组：对得上账——回执参数

参数	含义	从业者视角
`clickid`	渠道侧生成的点击唯一 ID	渠道把自己的点击 ID 塞进 AF 链接，AF 归因成功后在 postback 里原样吐回。渠道靠它把「AF 说的那个安装」对回「自己记的那次点击」，进而对回具体 publisher 和出价

clickid 是整条结算闭环的钥匙，也是最经典的事故现场：宏没替换。链接里的 {click_id} 本该在下发时被渠道系统替换成真实值，结果原样字面量打到了 AF——面板上点击照记、安装照归，但 postback 回来全是 {click_id} 这个字符串，渠道侧一条都对不上，钱结不下去。拿到链接先跑一条测试点击，看 clickid 有没有被替换成真值，这个习惯每月能救你一次。

第四组：证明是谁——设备参数

参数	含义	从业者视角
`advertising_id`	Android 的 GAID	确定性匹配的核心信号。点击带了 GAID，首开 SDK 又报同一个 GAID，两边精确相等，直接判归因
`idfa`	iOS 广告标识	同上，但 ATT 拒绝授权时拿到的是全 0，等于没传
`af_ip` / `af_ua` / `af_model` / `af_os_version`	真实设备的 IP、UA、机型、系统版本	S2S 点击必带（下文第四节细讲）。不带的话 AF 看到的是你服务器的 IP 和 UA，概率匹配直接废掉

设备参数的常见死法和 clickid 一样：宏没替换、传了空值、iOS 传了全 0 的 IDFA。这些点击不会报错，AF 照单全收——只是安静地从「确定性匹配」降级到「概率匹配」，你的归因率悄悄掉一截，面板上什么提示都没有。

第五组：按什么规则算——窗口与模式参数

参数	含义	从业者视角
`af_click_lookback`	点击归因窗口，默认 7 天，可配 1d~30d，链接上可覆写	窗口多长，直接决定多少安装能算你的。上游给你的链接如果偷偷写了 `1d`，你 7 天心智下的预估安装量直接砍掉一大块
`af_viewthrough_lookback`	展示（view-through）归因窗口，默认 24 小时	跑展示归因的渠道才关心，但要知道它和点击窗口是两套
`is_retargeting`	再营销标记	为 `true` 时走 retargeting 归因逻辑，和拉新归因分开算

第六组：体验与钱数

参数	含义	从业者视角
`deep_link_value` / `deep_link_sub1`	深链目标与附加参数	决定唤起 App 后落到哪个页面，转化率的隐形杠杆
`af_cost_model` / `af_cost_value` / `af_cost_currency`	成本模型、金额、币种	面板里的 ROI/ROAS 从这来。不传成本，面板只有收入没有回本

对联盟从业者来说，这条 URL 就是你的电子合同：每个参数都在替你回答一个结算问题——pid 和 af_prt 回答「钱给谁」，af_siteid 回答「锅归谁」，clickid 回答「账怎么对」，advertising_id 和 af_ip/af_ua 回答「归因凭什么成立」，af_click_lookback 回答「按什么规则算」。所以拿到上游 offer 链接的第一件事，不是急着跑量，而是把参数逐个核一遍——宏替换了没有、pid 对不对、窗口是几天、clickid 会不会吐回来。合同都没看就签字画押，出了纠纷怪不了别人。

三、点击的那一秒：一跳一跳拆开看

用户手指点下去之后，网络上真实发生的事，比你想象的要多。先摆一个分层的底子——一次 HTTPS 点击请求，自下而上要穿过整个协议栈：

应用层: HTTP GET / 302 / 200
安全层: TLS 握手与加密
传输层: TCP 三次握手
网络层: IP 路由
链路层: Wi-Fi / 4G / 5G

下面每一层都可能出事，而且每一层的「出事」长得都不一样。带着这个分层意识往下看。

第一跳：设备 → AF 点击域名

DNS 解析：xxx.onelink.me 解析成 IP；
TCP 三次握手：SYN → SYN-ACK → ACK；
TLS 握手：ClientHello → ServerHello/Certificate → Finished，通常是 TLS 1.2 或 1.3；
HTTP 请求：这才是 AF 真正「看到」点击的时刻——

GET /AbCd?pid=media_source_int&c=us_ios_campaign01&... HTTP/1.1
Host: xxx.onelink.me
User-Agent: ...
Referer: ...

AF 在这一步记录 click 日志：点击时间、IP、UA、全部 link 参数、设备类型、国家地区、referrer 上下文。注意，你的设备指纹在这一毫秒就已经被采集完了——不止 IP 和 UA，还包括 TLS 握手层的 ClientHello 特征：cipher suites 列表、extensions 及其顺序、ALPN，也就是 JA3 一类的指纹。