At a glance: Raw data reports describe installs and in-app events blocked by the Protect360 engine, as well as from manually added Validation Rules.
Related reading: Overview | Dashboards | Validation rules
关于Protect360原始数据报告
Raw data reports:
- Display data about:
- Clicks, installs, and in-app events identified as fraudulent by the Protect360 engine.
- Installs and in-app events identified via Validation Rules.
- Include the block reason for each click, install, or in-app event.
- Are used by advertisers to reconcile ad network accounts, for optimization, and to adjust attribution dashboards for post-attribution fraud.
- Report types and their availability by download, API, and Data Locker (S3 bucket) are described in the sections that follow.
Report types
| Report | 描述 |
|---|---|
| 安装 |
Reports include:
|
| 归因后-重新被判断为假量 |
Reports include installs attributed to a media source, but later found to be fraudulent. |
| Blocked in-app events |
Reports include in-app events from:
|
| Post-attribution in-app events |
Reports include in-app events:
|
| 点击 | Reports include blocked clicks with the block reasons. |
| 已拦截的激活回调 | Reports include copies of the rejection postbacks sent to media sources bringing blocked installs. |
Post-attribution reports
- Post-attribution raw data fraud reports have the same structure as the blocked fraud reports.
- 当前月份（按激活日期）的归因后拦截报告将继续更新，直到下个月的第七天（检测日期）才停止当前月份的归因后拦截报告更新。
- Post attribution raw data reports are limited to advertisers. Agencies need permissions enabled to access.
- 报告包含Protect360识别的归因后欺诈事件，并在一个报告中包含所有媒体渠道。
-
归因后原始数据拦截报告如下：
- 面板用户界面：在一个日历月内仅限于一种媒体渠道。
- Pull API：包含所有媒体平台 。（限制条件：仅适用于应用程序所有者）
Using post-attribution reports
- Select any combination of install/IAE and detect date ranges as needed.
-
For hijacked installs/IAEs, use the rejected_reason_value field to identify the valid contributor (media source), meaning the contributor that should have originally received attribution.
- The rejected_reason_value is populated with either contributor[1-3] or organic. Check the contributor[1-3] fields to view the contributor details and reconcile.
- If the contributor fields are not displayed in your report, they are available to be added from the Export data page.
- Take into consideration that Protect360 performs post-attribution detection during the calendar month of the install and up to the seventh day of the following month. This means, for example, that for installs in November, Protect360 checks for fraud up to December 7.
- 使用此Pull API的最佳做法如下：
- 假设您每天拉报表。
- 将安装日期范围设置为从当前日期回溯的60天。
- Set the detect-from/detect-to range to the day before the current day.
This means you will get the list of post-attribution frauds detected yesterday. If you didn't pull the report for a few days, adjust the detect date range, and pull the report.
Example
示例A ：在12月（安装日期）中，15个激活归因于example_media 。1月3日（检测日期），Protect360将example_media识别为欺诈者。结果，归因于example_media的15个激活在归因后拦截报告中被列为作弊，提供给应用所有者进一步采取措施。
Example B: During December, 15 installs are attributed to example_media. On January 9, Protect360 identifies example_media as a fraudster. In this case, no action is taken by Protect360 because the fraudster was identified after the month close on January 7.
Raw data availability by tool type
| Report | 数据新鲜度 | Pull API | 数据导出页面 | Data Locker |
|---|---|---|---|---|
| 安装 | 实时 | ✓ | ✓ | ✓ |
| Blocked in-app events | 实时 | ✓ | ✓ | ✓ |
| 点击 | 实时 | ✓ | ✓ | ✓ |
| 已拦截的激活回调 | 实时 | - | ✓ | - |
| 归因后-重新被判断为假量 |
每天UTC10:00 |
✓ |
✓ | ✓* |
| Post-attribution in-app events |
每天UTC10:00 |
✓ | ✓ | - |
|
*通过Data Locker获取报告的限制：
|
||||
获取原始数据报告
原始数据报告可通过下载，Pull API和Data Locker（S3存储）获得。您还可以授予合作伙伴访问报告的权限。
下载
下载：
- 在Protect360面板中，转到原始数据报告>已拦截或归因后
- 对于归因后报告，请选择媒体渠道和月份。
或
- 进入“ 数据导出”页面。
注意：从“数据导出”页面下载的报告，包含所有媒体平台。
Pull API
可用Pull API下载原始数据报告，请执行以下操作：
开始之前 ：
您需要一个Pull API 密钥（token）。从管理员那里获取密钥。
- 转到 对接 > API访问 。
打开“ Pull API”页面。 - 在Protect360欺诈报告部分中，选择必要的Pull API进行调用。
- 根据需要填充参数。下表列出了各项参数。
- 拉取报告。
| 参数 | 描述 | 格式 | 强制性的内容 |
|---|---|---|---|
| app_id | 在AppsFlyer中显示的 App ID | 字符串 | 是 |
| api_token | 可从仪表板检索到密钥。转到 对接 > API数据接口 。 只有帐户管理员才能检索API密钥。 | 字符串 | 是 |
| from |
日期范围的开始：
|
YYYY-MM-DD | 是 |
| 发挥 |
日期范围的结束：
|
YYYY-MM-DD | 是 |
| event_name |
[归因后欺诈的应用内事件：可选] 按应用内事件过滤筛选事件。将报告限制为特定事件。可以包含一个或多个事件。 用法示例： |
字符串 |
否
|
| additional_fields=rejected_reason_value |
[归因后欺诈的应用内事件：可选] rejected_reason_value displays the valid contributor (media source) for hijacked installs/in-app events. Populated with either contributor[1-3] or organic. |
字符串 |
否 |
| detect-from |
[归因后重新被判断为假量的安装：可选] 欺诈检测日期范围的开始。（默认是from. ）（用于归因后重新被判断为假量的安装。） （用于归因后重新被判断为假量的安装。） |
YYYY-MM-DD | 否 |
| detect-to |
[归因后重新被判断为假量的安装：可选] 欺诈检测日期范围的结束。（默认为to. ） |
YYYY-MM-DD | 否 |
Data Locker
Protect360报告结构
Protect360报告与其并行的“用户获取报告”字段具有相同的一般结构。
In addition to the regular raw data report fields, Protect360 reports have the following fields, as follows:
- 被拦截的原因
- 被拦截的子原因
- 被拦截原因值
- Blocked reason rule
Protect360拦截的原因
点击级别被拦截的原因
在点击层级，点击被拦截，在归因过程将忽略被拦截的点击。
| 被拦截的原因 | 描述 |
|---|---|
| ip_blacklist | 基于动态创建的列表（ 详细信息 ） |
| install_store_validation | 安装的Google Referrer值之间的差异 |
| invalid_fingerprint | 仅S2S点击：媒体源发送过来的无效参数（用于概率匹配） |
安装级别被拦截的原因
在安装级别，我们在安装时会使用足够的信息来确定以下两种之一：
- 假安装，意味着安装该应用的用户不是真实的人。在这种情况下，归因将被完全阻止。
- 归因劫持，用户是真实的，但广告互动却是虚假的。在这种情况下，虚假的广告互动被拦截，并且将归因被重新分配给第一个有效的贡献媒体渠道。
下表列出了可能的安装级别被拦截的原因：
| 被拦截的原因 | 被拦截的子原因 | 描述 |
|---|---|---|
| 机器人作弊 | fake_device_parameters | 在应用安装过程中，在与设备相关的参数中检测到非人为的行为 |
| 机器人作弊 | fake_install_parameters | 在应用安装过程中，在与安装相关的参数中检测到非人为的行为 |
| 机器人作弊 | bayesian_network | 贝叶斯网络识别欺诈模式 |
| validation_bots | invalid_device_parameters | 特定设备字段期望值不匹配-由客户定义 |
| validation_bots | validation_rules |
Rules where the outcome is blocked installs based on manually defined validation rule |
| 被拦截的原因 | 被拦截的子原因 | 描述 |
|---|---|---|
|
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 |
Rules where the outcome is blocked attribution based on manually defined validation rule |
群集级别被拦截的原因
当检测到欺诈行为时，会将欺诈源列入黑名单。由于以下原因，拦截了从该列入黑名单的源进行的安装：
- 假安装，意味着安装该应用的用户不是真实的人。在这种情况下，归因将被完全阻止。
- 归因劫持，用户是真实的，但广告互动却是虚假的。在这种情况下，虚假的广告互动被拦截，并且将归因被重新分配给第一个有效的贡献媒体渠道。
下表列出了可能的安装级别被拦截的原因：
| 被拦截的原因 | 被拦截的子原因 | 描述 |
|---|---|---|
| 机器人作弊 | timestamp_anomalies | 与归因点击时间和从设备收集的其他时间戳有关的异常 |
| bots, site_blacklist | device_emulators | 通过在虚拟环境中工作的自动脚本大规模生成的安装。 |
| site_blacklist | device_farms | 大量未知（新）设备 |
| behavioral_anomalies | behavioral_anomalies | 与普通应用程序用户行为模式相比，可疑的应用内行为 |
| 被拦截的原因 | 被拦截的子原因 | 描述 |
|---|---|---|
| ctit_anomalies, install_hijacking | ctit_anomalies | 每个应用程式标准的CTIT模式异常 |
| click_flood | click_flood | 在长时间的CTIT分布中，点击量异常高 |
| install_hijacking | click_clusters | 设备级恶意软件产生的点击 |
应用内事件级别被拦截的原因
可能出于以下原因拦截应用内事件：
- 最初的安装被确认为是虚假安装。
- 由于您定义的验证规则。
- 因为我们的算法检测到欺诈。
下表列出了可能的应用内级别拦截的原因。
| 被拦截的原因 | 被拦截的子原因 | 描述 |
|---|---|---|
| 从安装继承 | 从安装继承 | 根据安装或列入黑名单级别的原因，初始安装被标识为假量 |
| inapps_bots | fake_device_parameters | AppsFlyer算法检测欺诈 |
| in_app_store_validation | - | Receipt validation for in-app purchase fails. |
| validation_inapps | validation_rules |
Based on manually defined validation rule |