首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >AF 判假量后,如何判断是不是代理、VPN 或机房流量?

AF 判假量后,如何判断是不是代理、VPN 或机房流量?

原创
作者头像
用户12585837
修改于 2026-10-29 10:47:57
修改于 2026-10-29 10:47:57
1030
举报

声明:本文为 AdTech 出海投放技术实践总结,文中提及数据源仅为行业通用技术调研参考,不构成采购推荐。 前置说明:AF 即 AppsFlyer,是出海广告常用的归因平台。AF 本身会输出 fraud 标记(假量判定),但 AF 的欺诈标签不会直接告诉你这条流量是机房、VPN 还是住宅代理。很多投放同学遇到 AF 判假之后,卡在一个问题:这个假量到底是 IP 层面的匿名流量,还是归因劫持、模拟器、脚本行为类作弊?需要我们把 AF 日志拉出来,结合外部数据二次归因分析。

本文适合投放风控、后端、数据同学,承接前面几篇关于 IP 库、虚假流量识别的内容,同样适配腾讯云开发者社区发布规范。

一、先理清核心边界:AF 欺诈标签 ≠ 代理 / VPN / 机房

AppsFlyer 的欺诈判定是多维度综合判定,它的 Fraud Reason 常见包含几大类:

  1. IP 相关风险(IP 匿名、代理、机房)
  2. 设备异常(模拟器、云手机、设备篡改)
  3. 时序异常(点击晚于激活、时间异常)
  4. 归因劫持、点击注入
  5. 行为异常、短时间高频转化等

重点:AF 返回的欺诈原因只能作为参考,AF 不会直接给出「VPN / Datacenter / Residential Proxy」这类细分标签。 也就是说:AF 标记这条是假量,我们需要把 AF 原始日志和外部 IP 情报数据做关联 JOIN,才能区分它属于哪一类。 同时注意:AF 识别为欺诈的流量,也有可能 IP 本身是正常住宅 IP(比如模拟器跑在家庭宽带、人工点击农场);反过来,机房 / VPN 流量也不一定会被 AF 直接标记为假。

二、第一步:拿到 AF 可用于分析的关键字段

从 AF Raw Data(原始日志、API 导出、S3 / 云存储同步日志)中,优先提取这些字段:

  • ip:用户访问 IP(核心关联字段)
  • country, region:AF 基于自身 IP 库解析的地域
  • device_id, advertising_id:设备标识
  • click_time, install_time, event_time:时间戳,用来校验时序作弊
  • fraud, fraud_reason:AF 欺诈标记、欺诈原因
  • media_source, campaign, sub_channel:渠道信息,用于聚合分析
  • user_agent:UA,辅助判断终端类型

一个容易踩坑的细节:AF 内部使用独立 IP 解析库,它的地域判定口径,和你自己采购的 MaxMind、Digital Element、IPinfo 口径可能不一致,对账时要区分两套来源。

三、第二步:用 IP 字段对接 IP 情报库,打网络类型标签

拿日志里的ip作为 key,调用或者离线匹配商用 IP 库,给每一条 AF 欺诈流量打上标签,这是区分机房 / VPN / 代理最核心一步。 可使用的数据源(前面文章提到的行业常用方案):

  • MaxMind GeoIP2 + Anonymous IP Database:标记 Datacenter、VPN、Tor、匿名代理,和很多归因链路对齐;
  • IPinfo:区分机房、住宅、移动,同时提供专门的住宅代理标签;
  • IP2Proxy:分类标签直接是 VPN / DC Proxy / Residential Proxy / Tor;
  • Digital Element:品牌程序化审计场景认可度高,网络类型标签适合用于审计对账。

期望输出标签一般包含:

  1. network_type:datacenter / residential / mobile / business
  2. anonymous_category:vpn / dc_proxy / residential_proxy / tor / none

匹配之后就可以做第一层分类:

  • network_type = datacenter → 机房流量
  • anonymous_category = vpn → VPN 流量
  • anonymous_category = dc_proxy → 机房代理
  • anonymous_category = residential_proxy → 旋转住宅代理、SDK 代理(高隐蔽类型)
  • anonymous_category = tor → Tor 匿名流量

重要工程规范: AF 自己的 country 不要直接覆盖,单独存一套你自己 IP 库解析的 country、风险标签,两个来源分开存储,方便对比口径差异,避免对账纠纷。比如很多场景下,AF 判定为美国,而你的 IP 库识别是机房代理出口。

局限性提醒

IP 库只能拿到 IP 侧静态标签。存在两种情况:

  1. IP 标签是正常 residential,但 AF 依然判假:大概率不是 VPN / 机房,而是模拟器、群控、归因劫持、脚本行为作弊、人工农场;
  2. IP 标记住宅代理:这是最难治理的一类,IP 层面看起来是正常家庭 IP,AF 经常靠设备、时序、跨渠道关联识别出来。

四、第三步:结合 fraud_reason 交叉验证,判断是不是 IP 类作弊

拿到 IP 标签后,搭配 AF 的 fraud_reason 组合判断,给大家一个对照逻辑:

  1. IP 标签 = datacenter / DC 代理 + AF 欺诈原因包含 suspicious_ip /anonymous_ip → 高度确认:机房流量、机房代理作弊
  2. IP 标签 = VPN + AF 标记 IP 匿名风险 → 高度确认:VPN 流量(注意:VPN 不全是作弊,企业远程办公 VPN 也会命中,需要再看行为)
  3. IP 标签 = residential_proxy + AF 欺诈标记 → 旋转住宅代理 / SDK 代理(这类 IP 在 IP 库基础地理标签是住宅,只有专项代理库才能识别)
  4. IP 标签 = residential(正常住宅 IP),AF 欺诈原因是 click_after_install / attribution hijack → 不是机房 / VPN / 代理,是归因劫持、后点击作弊
  5. IP 标签 = residential,欺诈原因是 emulator / device_suspicious → 模拟器、云手机群控,IP 本身是正常家庭宽带 / 移动网
  6. IP 标签正常,欺诈原因是 high_frequency、异常事件密度 → 脚本刷行为、人工点击农场

一句话总结:如果 AF 欺诈原因和 IP 无关,就算 IP 是机房,也只是叠加特征,根因不是代理 / VPN;反之 IP 是正常住宅,也不能排除住宅代理作弊,要看专项代理标签。

五、第四步:补充其他信号,进一步确认(可选,适合自建风控)

如果你们有落地页 SDK、前端埋点,还可以把 AF 日志和自有风控日志通过advertising_id关联,增加佐证:

  1. JA3 指纹、设备指纹:同一个 IP 短时间大量设备指纹,机房脚本特征;
  2. 地理一致性:设备时区、语言、GPS 位置和 IP 国家冲突,VPN 强佐证;
  3. IP velocity:这个 IP / 设备 ID 在短时间跨国家切换,典型代理轮换;
  4. 大盘聚合:这个 sub_source 下,AF 假量中机房 / VPN 占比持续远高于其他渠道,渠道风险实锤。

六、落地分析流程(可直接给数据同学做 SQL 逻辑参考)

  1. 同步 AF 原始欺诈日志到数仓;
  2. 拿日志 ip 批量离线匹配 IP 情报库,挂载 network_type、anonymous_category、ip_country;
  3. 关联 fraud_reason,打一级分类标签:
    • ip_fraud_type:机房 / VPN / DC 代理 / 住宅代理 / Tor / 非 IP 类欺诈
  4. 按 media_source、campaign、sub_channel 聚合,统计每个渠道假量里,机房、VPN、住宅代理的占比;
  5. 输出报表:区分【IP 匿名类假量】和【设备 / 归因劫持类假量】,给投放决策。

简易 SQL 思路(伪代码)

代码语言:javascript
复制
SELECT
  af.media_source,
  af.fraud_reason,
  ip.network_type,
  ip.anonymous_category,
  COUNT(*) AS fraud_cnt
FROM af_fraud_log af
LEFT JOIN ip_info_mapping ip ON af.ip = ip.ip
WHERE af.fraud = true
GROUP BY 1,2,3,4

七、常见误区

  1. 误区:AF 标了假量,就代表是 VPN / 机房流量 纠正:大量假量是劫持、模拟器、篡改设备 ID,IP 完全正常。
  2. 误区:AF 的 country 就是 IP 真实类型 纠正:AF 内部 IP 库和外部商业库口径不同,不要拿 AF 的地域去判断是否是代理。
  3. 误区:只要标记 VPN 就全部扣量 纠正:VPN 包含企业员工远程办公、海外员工合规访问,优先统计占比、做渠道评级,不要一刀切。
  4. 误区:普通 IP 库能识别住宅代理 纠正:MaxMind 基础匿名库对旋转住宅代理识别偏弱,想要抓这类,需要搭配 IPinfo 或者 Spur 这类专项代理情报。
  5. 误区:在线实时用 AF 回调去同步查 IP 库 纠正:AF 回调链路延迟敏感,一般是离线 T+1 批量分析,不建议在回传链路同步调用 IP 服务。

八、产出结果怎么用在投放侧

  • 如果假量主要是机房、DC 代理:渠道直接要求媒体清理机房出口流量,或者 Pre-bid 增加机房 IP 过滤;
  • 如果假量以住宅代理为主:单纯 IP 黑名单效果很差,需要在 AF 之外叠加设备指纹、行为风控,重点审计 sub 渠道;
  • 如果大部分假量是归因劫持、点击晚于激活:问题不在 IP,需要调整归因窗口、增加点击鉴权、约束媒体点击回传逻辑;
  • 如果 VPN 占比高:评估是否为目标市场企业用户,判断是误伤还是恶意 VPN 刷量。

结语

AppsFlyer 的欺诈标记是一个综合判定结果,它本身不会拆分出机房、VPN、住宅代理标签。标准分析路径是:拉取 AF 欺诈原始日志,以 IP 为 Key 关联 IP 情报库,拿到网络类型与匿名分类标签,再结合 fraud_reason 交叉验证,区分是 IP 匿名类作弊,还是设备、归因劫持类作弊。 这套分析方式,既能定位假量来源,也能在和媒体对账时提供可审计的证据,区分不同作弊类型,针对性调整过滤策略。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 一、先理清核心边界:AF 欺诈标签 ≠ 代理 / VPN / 机房
  • 二、第一步:拿到 AF 可用于分析的关键字段
  • 三、第二步:用 IP 字段对接 IP 情报库,打网络类型标签
    • 局限性提醒
  • 四、第三步:结合 fraud_reason 交叉验证,判断是不是 IP 类作弊
  • 五、第四步:补充其他信号,进一步确认(可选,适合自建风控)
  • 六、落地分析流程(可直接给数据同学做 SQL 逻辑参考)
    • 简易 SQL 思路(伪代码)
  • 七、常见误区
  • 八、产出结果怎么用在投放侧
  • 结语
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档