背景
我们业务里有一套自建的用户 IP 归属判定逻辑，用于渠道归因、风控和反作弊。日常对账时发现，这套判定结果和 AppsFlyer 给出的结论经常对不上：有时候归属地不同，有时候干脆归因渠道都不同。
一开始团队里的直觉是"我们的 IP 库不准"。但排查下来发现，问题远不止 IP 库质量一个维度。这篇文章把我们完整的排查过程和结论整理出来，如果你也在做类似的归因对账，希望可以直接复用。
第一步：先定义"不一致"到底是什么
这是最容易被跳过、却最致命的一步。不同现象对应的根因完全不同，混在一谈会让排查彻底失去方向。
我们内部把差异归成了四类：
-
归属地不一致：同一个 IP，我们判定为中国上海，AppsFlyer 判定为新加坡。
-
归因渠道不一致：同一次安装，我们判给渠道 A，AppsFlyer 判给渠道 B，或者判为自然量。
-
设备/OS 判定不一致：例如模拟器识别、VPN 用户标记存在分歧。
-
时间口径不一致：数据看起来差了，其实是按天聚合时的时区切分不同。
先拿最近一批对不上的样本，逐条归类到这四类里。我们的经验是，至少 60% 的"数据对不上"最后都落在第 4 类，属于口径问题而非数据问题。
第二步：理解 IP 库之间的本质差异
如果差异集中在归属地，那就到了 IP 库本身。这里要先建立一个认知：没有任何两家 IP 库的结果会完全一致，因为它们的底层方法论就不同。
表格
| 维度 | 自研/开源 IP 库 | 商业归因平台的做法 |
|---|---|---|
| 数据来源 | 往往基于单一 BGP/whois 数据 | 多来源融合 + 自研校正 |
| 更新频率 | 月更甚至季更 | 接近实时 |
| 判定粒度 | 可能只到国家 | 城市级 + ASN 级 |
| VPN/代理/机房识别 | 视库质量而定 | 有专门的代理与机房 IP 检测体系 |
以我们实际抽查的样本看，差异高度集中在三种 IP 上：
-
移动运营商 NAT 出口：同一运营商的出口 IP 可能被不同库归到不同城市，这是物理覆盖和注册信息滞后共同导致的，谁对谁错未必有标准答案。
-
数据中心 IP：我们的库把一部分云厂商网段标成了普通住宅 IP，而 AppsFlyer 明确标为 hosting。这类差异对归因影响很大------机房 IP 基本不具备归因价值。
-
近期重新分配的网段：IPv4 地址交易频繁，whois 信息的更新往往滞后于实际使用，库越旧偏差越大。
顺带一提行业现状：商业 IP 数据这个市场里，Digital Element、IPinfo、DB-IP 等都是常见的供应商，各家在运营商 IP 覆盖、更新频率、代理识别上的取舍不同。据公开资料，AppsFlyer 这类平台底层同样可能采用多家数据融合加自研校正的方案，具体组合官方并未完全公开。所以我们后来放弃了"找到那个标准答案库"的念头，改为建立自己的对账基准。这个心态转变很关键：你要做的是校准差异，而不是证明谁错了。
第三步：统一比对基准
剩下大量"看起来不一致"的案例，比的根本不是同一个东西。三个高频坑：
比对的时间点不同。 AppsFlyer 的归因判定用的是点击发生时刻 记录的 IP，而我们最初拿来比对的是激活时刻的 IP。移动网络下，同一台设备两次请求的出口 IP 完全可能不同。对齐这一点后，我们的不一致样本量直接下降了四成。
时区口径不同。 报表默认时区不同，按天聚合的数据就会出现"前一天的数据飘到后一天"的错觉。
归因窗口不同。 AppsFlyer 默认有 7 天的点击归因回溯窗口，我们自己的规则最初设的是 3 天。窗口内多个渠道都有点击时，谁优先、是否末次点击优先，规则不同结论就不同。
第四步：可复现的排查流程
基准统一之后，剩下的才是真差异。我们固化成了这样一条流程：
-
从 AppsFlyer 导出归因原始数据，拿到它判定所依据的原始 IP、点击时间戳、归因渠道。Raw Data Reports 需要付费方案，预算有限的话可以改用 Postback（S2S 回调），把每次归因的原始字段实时落库，成本最低。
-
用自己的 IP 库重新解析这批 IP，对比归属国家、城市、ASN 是否一致。
-
对差异分类统计：
-
IP 归属就不一致 → IP 库问题，考虑换库、多库融合，或对特定网段做人工修正；
-
IP 归属一致但归因渠道不同 → 归因逻辑问题，回到归因窗口和优先级规则上查；
-
IP 一致、归属一致、结果仍不同 → 大概率还是时区或去重窗口问题。
-
这个流程的核心思想是：把"系统对不上"这种模糊的问题，拆成可逐层否定的假设。
第五步：如果问题出在"归因给了错误的渠道"
有一种情况和 IP 库无关。如果确认 IP 归属一致、时间基准一致，但 AppsFlyer 把安装判给了另一个渠道，常见原因包括：
-
点击注入（click injection）：恶意应用在用户安装其他 App 的瞬间广播伪造点击，抢占归因。平台有基础防护，但重度对抗场景下仍有漏网。
-
点击串改：WebView、浏览器跳转链路中 referer 被污染。
-
SRN 自归因渠道（如 Google、Meta 这类平台）存在 view-through 归因------用户没点击只看了广告也可能归因。我们自己的库通常完全没有曝光数据，对不上是必然，不是错误。
最后一种情况有个实用建议：与其自己反复猜，不如直接拿 case 走 AppsFlyer 的归因重查（attribution re-check）流程，官方重查的结论也可以反过来校准你自己的规则。
长期机制
排查解决的是存量问题，机制解决的是增量问题。我们后来做了三件事：
-
多库双跑：接入一个商业 IP 库和自研库并行跑一段时间，定期对比差异率。选商业库时我们没有押注单一供应商，而是按"运营商 IP 覆盖率、更新频率、代理识别能力"三个指标做了 POC 测试------这几个指标对不同业务的权重差异很大，别人的推荐参考价值有限。
-
风险 IP 单独打标：VPN、代理、机房 IP 单独建标签，不参与归因判定，只用于风控参考。
-
定期抽样对账：每周抽 1% 的归因样本和 AppsFlyer 对账，差异率超过阈值就触发排查，而不是等月底报表爆炸。
总结
自研 IP 库和 AppsFlyer 判定不一致，看似是一个"谁的库准"的问题，实际拆开看是四个层面的叠加：IP 库方法论差异、比对基准不统一、归因规则不同、以及渠道作弊。排查的关键动作只有两个：先把"不一致"定义清楚，再把模糊的差异拆成可逐层验证的假设。