点击去哪了?AppsFlyer 点损机制全拆解

做渠道对接的人,几乎都经历过这样的对账现场:自己后台明明发出了 100 万个点击,AppsFlyer(下称 AF)后台只记录了 60 万,40% 的点击就这么"人间蒸发"了。渠道说我点击都发了,广告主说我只认 MMP 的数,月底结算一谈就崩。这 40% 去哪了?是 AF 吞了,还是你自己链路漏了?更要命的是——你连"该去问谁"都说不清。

这篇文章把点损(点击损耗)这件事从头到尾拆开:点击在哪些环节被丢弃、被去重、被判无效;每一类损耗大概是什么量级;掉量时你和 AF 各自的后台会呈现什么数字;以及怎么一步步排查、怎么在对账桌上举证。全文只讲正当的排查与对账,不讲任何"怎么把假量混过去"——那条路的尽头是扣款和封号。

先给一个基本认知:点损不是一个 bug,而是一条漏斗。点击从用户设备出发,到最终被 AF 记录并参与归因,中间要过五道关,每一道都会掉量:

前两段是工程问题,后三段是风控与规则问题。90% 的人只盯着 AF 骂,却没意识到:行业里点损高达 50% 的案例,多数根子是自己的转发架构设计错误,而不是 AF 黑箱。把这条漏斗画出来,大概长这样:

图1:AF 点损漏斗——100% 点击如何一路漏成 60%

下面按漏斗从上到下,一层一层拆。每一类点损都回答三个问题:量级多大?双方各自看到什么数字?怎么排查、怎么举证?

一、网络层折损:点击死在半路上

发生了什么。用户点了广告,一次完整的跳转要走 DNS 解析 → TCP 三次握手 → TLS 握手 → HTTP 请求 → 302 重定向,每一环都可能超时或被重置。弱网、DNS 污染、运营商劫持、TLS 证书链在老设备上校验失败——点击在到达 AF 域名之前就死了,AF 那边连尸体都没有。

**量级。**成熟市场、单跳直连的链路,这类纯网络折损通常在 1%~5%;东南亚、拉美、非洲等弱网市场可以到 5%~10%。这是物理层面的税,谁都免不掉,只能压缩。

**双方各看到什么。**你的 tracker 日志里有这次点击(你已经返回了 302),但 AF 的点击报表和 raw data 里完全没有这条记录。特征是:损耗率与 geo、运营商、时段强相关,与媒体源、siteid 弱相关——按国家拆开看,弱网国家明显更高,就是网络折损的签名。

**怎么排查。**在目标国家用真机(或干净的住宅网络出口)实际点一遍链路,用抓包工具看四件事:DNS 是否解析成功、TCP 是否 SYN 超时或被 RST、TLS 握手是否报 handshake_failure / certificate 类错误、HTTP 是否拿到 302 且 Location 正确。再统计你自己 tracker 上"返回 302 后,下一跳是否真的被请求"——如果你在 302 的 Location 里挂了自己可观测的中间点,断点在哪一跳一目了然。

**谈判口径。**这部分损耗举证不到 AF 头上,也不该由你全背——对账时把它按 geo 拆成明细,作为"链路物理折损"单列,和商务约定一个双方认可的折损容忍线(比如 5%),超出部分再进入排查流程。

二、重定向断链:每多一跳,多埋一颗雷

**发生了什么。**很多流量团队的点击路径是:

publisher → 自有 tracker → redirect → 又一层 tracker → AF

每多一跳,就是一次全新的 DNS + TCP + TLS + HTTP。三跳就是三次完整握手,任何一跳超时、Location 拼错、返回 4xx/5xx、中间服务限流,点击就断在半路。更隐蔽的是:多层跳转还会污染参数——上游带的设备信息在某一跳被截断或转码丢失,点击就算到了 AF 也是残废。

量级。经验值是每多一跳,额外增加 2%~5% 的折损;三跳以上的链路,仅断链一项总折损就轻松超过 10%。移动端弱网下用户的耐心只有 3~5 秒,跳转链每长一秒,中途关掉页面的用户就多一批。

**双方各看到什么。**典型不对称:你的第一跳 tracker 记录了 100%,第二跳只剩 96%,AF 只剩 90%——逐跳递减。而如果你只在第一跳记日志,你会觉得"我发了 100%,AF 只收 90%",把锅全甩给 AF。

**怎么排查。**核心动作一个:逐跳埋日志,做逐跳对数。每一跳记录进量和出量(成功返回 302 的量),两跳之间的差值就是这一跳的断链率。抓包时沿着 302 链一路跟下去,重点看哪一跳的 Location 有问题、哪一跳响应时间超过 2 秒、哪一跳偶发 5xx。治理方向也只有一个:砍跳数,能一跳直达 AF 就不要三跳,中间每一层 tracker 都要回答"你存在的必要性是什么"。