Protect360原始数据报告

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: OverviewDashboardsValidation 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

Protect 360 raw-data report types
Report 描述
安装

Reports include: 

  • Fake installs: Installs identified as fraudulent by the Protect360 engine. These are not attributed to a media source (they are marked as organic).
  • Hijacked installs: Real user installs where attribution is stolen, but Protect360 corrects the attribution.
    • In the Protect360 installs reports, the fraudulent media source is displayed.
    • In the regular installs raw data reports (non-organic and organic), the correct media source is displayed. 
  • Validation Rules: That either blocked the install or blocked the attribution. 
归因后-重新被判断为假量

Reports include installs attributed to a media source, but later found to be fraudulent.

Blocked in-app events

Reports include in-app events from:

  • Fake installs: IAEs are blocked.
  • Hijacked installs
    • In the Protect360 in-app events reports, the fraudulent media source is displayed.
    • In the regular in-app events raw data reports, the correct media source is displayed. 
  • In-app events: Identified as fraudulent independent of the original installs.
  • Validation Rules:
    • IAEs from a rule that blocked the install or blocked attribution.
    • IAEs from a rule that blocked the in-app event. 
Post-attribution in-app events

Reports include in-app events:

  • Identified post-attribution.
  • Of installs attributed to a media source, but later found to be fraudulent.
点击 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

Protect 360原始数据在不同工具类型的可用性
Report 数据新鲜度 Pull API 数据导出页面 Data Locker
安装 实时
Blocked in-app events 实时
点击 实时
已拦截的激活回调 实时 - -
归因后-重新被判断为假量

每天UTC10:00

✓*
Post-attribution in-app events

每天UTC10:00

-

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

  • 不支持代理透明化。这意味着代理带来的流量,不包含激活归因的媒体渠道名称。
  • 该报告具有相对于其他Data Locker报告的唯一字段集。此列无法更改。

获取原始数据报告

原始数据报告可通过下载,Pull API和Data Locker(S3存储)获得。您还可以授予合作伙伴访问报告的权限

下载

下载:

  • 在Protect360面板中,转到原始数据报告>已拦截归因后
    • 对于归因后报告,请选择媒体渠道和月份。

  • 进入“ 数据导出”页面。


    注意:从“数据导出”页面下载的报告,包含所有媒体平台。

Pull API

可用Pull API下载原始数据报告,请执行以下操作:

开始之前

您需要一个Pull API 密钥(token)。从管理员那里获取密钥。

  1. 转到 对接 > API访问
    打开“ Pull API”页面。
  2. 在Protect360欺诈报告部分中,选择必要的Pull API进行调用。
  3. 根据需要填充参数。下表列出了各项参数。
  4. 拉取报告。 
Pull API原始数据报告参数
参数 描述 格式 强制性的内容
app_id  在AppsFlyer中显示的 App ID 字符串
api_token 可从仪表板检索到密钥。转到 对接 > API数据接口只有帐户管理员才能检索API密钥。 字符串
from

日期范围的开始:

  • 对于激活,这是激活日期。
  • 对于应用内事件,这是事件发生的日期。
YYYY-MM-DD
发挥

日期范围的结束:

  • 对于激活,这是激活日期。
  • 对于应用内事件,这是事件发生的日期。
YYYY-MM-DD
event_name

[归因后欺诈的应用内事件:可选]

按应用内事件过滤筛选事件。将报告限制为特定事件。可以包含一个或多个事件。

用法示例: &event_name=af_purchase,af_login

字符串

 

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

Data Locker将 原始数据 写入AWS S3存储。

请参阅可用的Protect360报告列表

请参阅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

这篇文章有帮助吗?