Protect360原始数据报告

高阶付费
推荐用于
营销人员
最近更新：

概要：您可以通过Protect360原始数据报告查看被Protect360引擎拦截的激活和应用内事件，以及根据您手动添加的验证规则（Validation Rules）拦截的流量。

Protect360原始数据报告简介

原始数据报告：

  • 呈现以下数据：
    • 由Protect360引擎识别为假量的点击、激活和应用内事件。
    • 根据验证规则拦截的激活和应用内事件。 
  • 报告中包含每个点击、激活或应用内事件的拦截原因。
  • 广告主可以使用这些报告与广告平台核对流量，从而进行相关优化，并根据归因后识别的假量调整归因面板。
  • 如果您启用了AppsFlyer的汇总层级高级隐私保护（AAP）功能，报告中的部分字段可能受限或不可用。
  • 报告类型及其可用性在各类数据传输方式中有所不同，分为下载、API和Data Locker（S3存储桶）几种，具体请见下文说明。
  • 历史原始数据报告最多保留90天，具体取决于数据传输方式以及原始数据来源。

注意

由于原始数据会受到数据隐私方面的限制，因此原始数据报告中会出现空值字段，比如助攻渠道字段的值可能为空。

报告类型

Protect360原始数据报告分为以下几类：

报告 说明
激活假量

这类报告中包含以下信息： 

  • 虚假激活（Fake installs）：由Protect360引擎识别为假量的激活。只有Protect360的面板及原始数据会包含这些激活，AppsFlyer的任何其他面板和原始数据中都不会出现相关信息。
  • 被劫持的激活（Hijacked installs）：这些激活来自真实用户，其激活归因遭到窃取，但由Protect360纠正了归因结果。
  • 验证规则（Validation Rules）：根据验证规则拦截的激活或归因（由Protect360纠正归因结果）。 
归因后判定为假量的激活

这类报告中包含归因到某个渠道后被识别为假量的激活。Protect360会纠正其归因结果。
已拦截的应用内事件

这类报告中包含以下信息：

  • 由虚假激活产生的应用内事件
  • 被识别为假量的应用内事件（与相关初始激活的判定结果无关）
  • 验证规则（Validation Rules）：
    • 根据验证规则被拦截的激活或归因所产生的应用内事件
    • 根据验证规则被拦截的应用内事件 
归因后识别为假量的应用内事件

这类报告中的应用内事件：

  • 在归因后被识别为假量
  • 由归因后被识别为假量的激活所产生
点击 这类报告中包含被拦截的激活及其拦截原因。
已拦截的激活回传 如果某个渠道带来的激活被拦截，我们会向其发送被拦截的数据回传。这类报告中即包含这些回传信息。

归因后识别的假量报告

  • 归因后识别为假量的原始数据报告与已拦截的假量报告具有相同的结构。
  • 当前月份（按激活日期计算）的归因后假量报告到次月七日（即检测日期）之前会持续更新。
  • 归因后的原始数据报告仅对广告主开放。代理如需访问该数据，需要广告主为其授权。
  • 该报告中包含在归因后被Protect360识别出来的假量，覆盖所有相关的媒体渠道。请注意：如果在指定日期范围内没有出现归因后被识别的假量，则该报告为空。

  • 归因后原始数据拦截报告如下：

    • 后台面板：每个日历月内限一个媒体渠道。
    • Pull API：包含所有媒体平台 。限制条件：仅对广告主（应用所有者）开放。

归因后报告的使用方式

  • 根据实际需要选择一种激活/IAE组合以及检测日期范围。
  • 请注意：Protect360会在激活发生当月到次月7日之间检测归因后的假量。比如，对于在11月内发生的激活，Protect360会一直检测到12月7日。 
  • Pull API的最佳使用方法如下：
    • 假设您拉取报告的频率为每天一次。 
    • 将激活日期范围设置为60天前-当天。
    • 将“detect-from/detect-to”的范围设置为当天的前一天。
      这样，您就能获得前一天的归因后假量报告。如果您已有数天没有拉取该报告，请根据实际情况调整检测日期范围，然后拉取报告。

示例

示例A：在12月发生的激活中，有15个激活被归因到example_media。Protect360在1月3日（检测日期）将example_media识别为作弊平台。这时，归因到example_media的15个激活就会出现在归因后识别的假量报告中，以便广告主后续采取相应措施。

示例B：在12月发生的激活中，有12个激活被归因到example_media。Protect360在1月9日将example_media识别为作弊平台。在这种情况下，Protect360不会采取任何措施，因为检测出作弊的日期在1月7日之后，这时上个月的归因后假量检测已经结束。

分数据传输方式的原始数据可用性

各种数据传输工具中的Protect 360原始数据可用性

报告 数据时效性 Pull API 导出数据页面 Data Locker
激活假量 实时 ✓ ✓ ✓*
已拦截的应用内事件 实时 ✓ ✓ ✓
点击 实时 ✓ ✓ ✓
已拦截的激活回传 实时 - ✓ -
归因后判定为假量的激活

每天UTC时间10:00更新

✓

 ✓ ✓*
归因后识别为假量的应用内事件

每天UTC时间10:00更新

 ✓ ✓ -

*通过Data Locker获取报告的限制：

  • 不支持代理数据透明化。也就是说，代理流量中不包含带来激活的媒体渠道的名称。 
  • 该报告中有一组专属字段，是其他Data Locker报告中所没有的，且这组字段无法更改。 
  • 激活报告中不包含再营销数据，只有归因后识别的激活假量报告中会呈现该信息。 

获取原始数据报告

您可以通过下载、Pull API和Data Locker（S3存储桶）获取原始数据报告，也可以向渠道开放报告访问权限。

下载

Protect360原始数据报告的下载方式如下：

  1. 在Protect360面板中点击原始数据报告 > 实时或归因后。
    • 对于归因后识别的假量报告，需要选择媒体渠道和月份。
  2. 选择并下载Protect360与验证规则报告。

或

  1. 从AppsFlyer面板进入导出数据。 
  2. 选择并下载Protect360与验证规则报告。

请注意：从导出数据页面中下载的报告包含所有媒体渠道。

Pull API

通过Pull API下载原始数据报告的操作方法如下：

前期准备：

您需要一个Pull API token，请让相关账户的管理员为您提供该token。 

  1. 进入报告 > API数据接口。
    界面会打开Pull API页面。
  2. 在Protect360假量报告部分中选择所需的Pull API。
  3. 根据需要填充参数。下表列出了各项参数。
  4. 拉取报告。  

Pull API原始数据报告参数

参数 说明 格式 是否必须发送
app_id  在AppsFlyer中显示的 App ID 字符串 是
api_token 如需获取该token，请在报告 > API数据接口 中查看。仅帐户管理员可获取该API token。 字符串 是
from

日期范围起始时间：

  • 在激活记录中指激活日期。
  • 在应用内事件记录中指事件发生日期。
 YYYY-MM-DD 是
to

日期范围结束时间：

  • 在激活记录中指激活日期。
  • 在应用内事件记录中指事件发生日期。
 YYYY-MM-DD 是
event_name

【可选】适用于归因后识别的应用内事件假量

按应用内事件筛选数据，让报告仅呈现特定的事件，  其中可包含一个或多个事件。

示例：&event_name=af_purchase,af_login

 字符串

否

 
additional_fields=rejected_reason_value

【可选】适用于归因后识别的应用内事件假量

rejected_reason_value字段用于说明被劫持的激活/应用内事件的实际助攻渠道，可能出现的值为contributor[1-3]或者organic。

 字符串

否
detect-from

【可选】适用于归因后识别的激活假量

假量检测日期范围的起始时间（默认为from）。

 YYYY-MM-DD 否
detect-to

【可选】适用于归因后识别的激活假量

假量检测日期范围的结束时间（默认为to）。

 YYYY-MM-DD 否

Data Locker

即使用Data Locker将原始数据写入AWS S3存储桶。

另请参阅Protect360可用报告列表。

以及Data Locker配置说明。

Protect360报告结构

Protect360报告的总体结构与用户获取报告一致。

除了常规的原始数据报告字段，Protect360报告还包含再营销和拦截原因字段，具体如下：

拦截原因（Blocked reason）

点击层级的拦截原因

在点击层级，点击被拦截，在归因过程将忽略被拦截的点击。

拦截原因（Blocked reason） 说明
ip_blacklist 根据动态黑名单（了解详情）进行拦截
invalid_fingerprint 仅适用于S2S点击：媒体渠道发送的参数无效（用于概率匹配）
click_capping 检测到该广告平台的点击作弊率极高。详情请见此文档。
click_signing 点击中的签名未通过验证。详情请见此处说明。
input_validation 媒体渠道名称无效

激活层级的拦截原因

我们在激活发生时根据充分信息判断该流量为假量，具体分为以下两种：

  • 虚假激活，即激活相关应用的用户并非真实存在。这时，该激活的归因会完全被拦截。
  • 归因劫持，即用户真实存在但广告交互是伪造的。这时我们会拦截虚假的广告交互，并将该激活重新归因到最初的真实助攻平台。

下表列出了可能出现的激活层级拦截原因：

激活层级：适用于虚假激活的拦截原因

拦截原因（Blocked reason） 详细拦截原因 （Blocked sub reason） 说明
bots fake_device_parameters 在应用激活过程中，通过与设备相关的参数检测到非人类行为。
bots fake_install_parameters 在应用激活过程中，通过与激活相关的参数检测到非人类行为。
bots bayesian_network 通过贝叶斯网络识别的作弊规律
install_store_validation -

未通过Apple App Store的激活验证
validation_bots invalid_device_parameters 特定设备字段出现反常值，具体由客户定义
validation_bots validation_rules

由于广告主自定义的验证规则而被拦截的激活
bots ai_layer

AppsFlyer利用AI模型分析海量数据点，针对作弊设备和作弊激活提升假量识别能力

激活层级：适用于归因劫持的拦截原因

拦截原因（Blocked reason） 详细拦截原因 （Blocked sub reason） 说明

ctit_anomalies

short_ctit

由于CTIT过短而导致激活被拦截，具体由Protect360判定

install_hijacking

referrer_hijack

根据GooglePlay API和AppsFlyer SDK参数被拦截的归因劫持

install_hijacking

integration_temporarily_blocked

由于渠道（pid）作弊率过高且所有流量中均存在明显异常，因而导致激活被拦截

validation_hijacking

short_ctit

由于CTIT过短而导致激活被拦截，具体由客户定义

validation_hijacking

empty_site_id

由于未填充子渠道（site） ID，导致激活被拦截。

validation_hijacking

validation_rules

由于广告主自定义的验证规则而被拦截的归因

聚类层级的拦截原因

AppsFlyer检测到有规律的作弊行为时，会将作弊平台加入黑名单。来自该平台的激活会被拦截，拦截原因分为以下两种：

  • 虚假激活，即激活相关应用的用户并非真实存在。这时，该激活的归因会完全被拦截。
  • 归因劫持，即用户真实存在但广告交互是伪造的。这时我们会拦截虚假的广告交互，并将该激活重新归因到最初的真实助攻平台。

下表列出了可能出现的激活层级拦截原因：

聚类层级：适用于虚假激活的拦截原因

拦截原因（Blocked reason） 详细拦截原因 （Blocked sub reason） 说明
bots timestamp_anomalies 归因链路中的激活时间或从相关设备收集的其他时间戳出现异常
bots, site_blacklist device_emulators 通过虚拟环境中的自动化脚本大批量生成的激活
site_blacklist device_farms 未知（新）设备占比过高
behavioral_anomalies behavioral_anomalies 有异于普通应用用户行为模式的可疑应用内行为

聚类层级：适用于归因劫持的拦截原因

拦截原因（Blocked reason） 详细拦截原因 （Blocked sub reason） 说明
ctit_anomalies, install_hijacking ctit_anomalies 根据相关应用的CTIT标准判定CTIT模式异常
click_flood click_flood 在CTIT的长期分布趋势中出现点击量异常激增
install_hijacking click_clusters 由设备层级的恶意软件生成的点击

应用内事件层级的拦截原因

应用内事件可能会由于以下原因被拦截：

  • 相关的初始激活被判定为虚假激活。
  • 根据您定义的验证规则进行拦截。
  • 我们的算法检测到作弊行为。 

下表列出了可能出现的应用内事件拦截原因。

应用内事件层级的拦截原因

拦截原因（Blocked reason） 详细拦截原因 （Blocked sub reason） 说明
Inherits from install Inherits from install 初始激活在激活层级被判定为虚假激活，或根据黑名单被拦截。
inapps_bots fake_device_parameters AppsFlyer算法检测到作弊行为
in_app_store_validation - 未通过相关应用内购买的收据验证 
validation_inapps validation_rules

根据广告主自定义的验证规则判定

再营销

Protect360原始数据中包含由再营销广告代带来的激活和应用打开（session）假量（分别记录为再归因和再互动假量）。这些数据会通过event name（事件名称）和retargeting conversion type（再营销转化类型）字段来呈现，可能出现的字段值为：

  • Install（即激活。该字段值适用于事件名称，但不会出现在再营销转化类型中）
  • Re-attribution（再归因）
  • Re-engagement（再互动）
  • Reinstall（重装激活）

Protect360再营销原始数据中包含实时拦截以及归因后识别的假量，具体如下：

报告  导出数据 Pull API Data Locker
激活假量 ✓* ✓* -
归因后判定为假量的激活 ✓ ✓ ✓
*再互动数据不可用

被劫持的激活归因更正

对于被劫持的激活，AppsFlyer会拦截其归因，即阻止该激活被归因到作弊平台，并将其归因到最后一个触达用户的真实助攻渠道。

AppsFlyer会使用rejected_reason_value字段来标记激活劫持场景中的真实助攻渠道（即原本应获得激活归因的助攻渠道）。

  • rejected_reason_value字段中可能出现的值为contributor[1-3]或organic。您可以通过contributor[1-3] 渠道字段查看助攻渠道的详细信息并核算流量。
  • 如果您的报告中未出现助攻渠道字段（contributor），可以通过导出数据页面添加。

请注意：在激活劫持场景中，如果激活被实时拦截，则AppsFlyer面板和报告中也会显示正确的归因结果，而不是仅仅在Protect360中呈现该信息。但如果在归因后被识别为激活劫持，则正确的归因结果仅显示在Protect360原始数据中。

特点与局限性

特点 说明
应用内事件报告

应用内事件报告中不包含助攻渠道字段，该字段仅在激活报告中呈现。
空值 由于原始数据会受到数据隐私方面的限制，因此原始数据报告中会出现空值字段，比如助攻渠道字段的值可能为空。