Protect360 raw data reports

At a glance: Protect360 raw data reports describe blocked and identified fraudulent events.

Related reading: OverviewDashboardsValidation rules

About Protect360 raw data reports

  • Raw data reports are divided as follows:
    • Blocked reports: Installs, clicks, and in-app events of users whose attribution was blocked and not attributed to any media source at all. 
    • Post-attribution reports:
      • Installs attributed to a media source, but later found to be fraudulent. 
      • In-app events of installs identified as fraud after being attributed to a media source.
      • In-app events judged to be fraudulent without regard to the install itself.
  • Advertisers use these reports to reconcile ad network accounts, for optimization, and to adjust attribution dashboards for post-attribution fraud.  
  • Raw-data is available by download, API, and Data Locker (S3 bucket) as described in the table that follows.
Protect 360 raw-data availability by tool type
Report topic Data freshness Description Pull API Export Data page Data Locker
Installs Real-time Blocked installs with the block reason
In-app events Real-time In-app events performed by blocked users
Clicks Real-time Clicks performed by blocked users
Blocked install postbacks Real-time Postback to the media source of blocked installs - -
Post-attribution installs

Daily 10:00 UTC

Installs identified as fraudulent post-attribution. 

The report can be optionally filtered by the detection date as described in the section that follows. 

✓*
Post-attribution in-app events fraud

Daily 10:00 UTC

  • In-app events performed by installs identified as fraudulent.
  • Any other in-app event judged as fraudulent irrespective of the install.

The report can be optionally filtered by in-app event type as described in the parameters table that follows. 

-

* Limitations to report via Data Locker:

  • Agency transparency not supported. Meaning that agency driven traffic does not contain the name of the media source sending the install. 
  • The report has a unique set of fields relative to other data locker reports. This list can't be changed. 

Getting raw data reports

Raw data reports are available by download, Pull API, and Data Locker (S3 bucket). You can also give partners access to reports.

Download

To download:

  • In the Protect360 dashboard, go to Raw data reports > Blocked or Post-attribution.
    • For post-attribution reports, select the media source and month.

OR

  • Go to the Export Data page. 
    Note: Reports downloaded from the Export Data page contain all media sources.

Pull API

To download raw data reports available by Pull API:

Before you begin:

You need a Pull API token. Get the token from the admin

  1. Go to Integration > API Access.
    The Pull API page opens.
  2. In the Protect360 fraud reports section, select the necessary Pull API call.
  3. Populate the parameters as required. The table that follows lists the parameters.
  4. Pull the report. 
Pull API raw data report parameters
Parameter Description Format Mandatory
app_id  App ID as it appears in AppsFlyer String Yes
api_token Retrieve the key from the Dashboard. Go to Integration > API Access. Only the account admin can retrieve the API token. String Yes
from

Start of the date range:

  • For installs, this is the install date.
  • For in-app events, this is the date of the event.
YYYY-MM-DD Yes
to

End of the date range:

  • For installs, this is the install date.
  • For in-app events, this is the date of the event.
YYYY-MM-DD Yes
event_name

[Optional for Post-attribution in-app events fraud]

Filter events by in-app event. Limit the report to specific events.  One or more events can be included.

Example usage: &event_name=af_purchase,af_login

String

No

 

additional_fields=blocked_reason_rule

[Optional for Post-attribution in-app events fraud]

blocked_reason_rule displays the valid contributor (media source) for hijacked installs/in-app events. Populated with either contributor[1-5] or organic.

String

No

detect-from

[Optional for Post-attribution installs]

Start of the fraud detect date range. (Default is from.) (Used in Post-attribution install fraud.) (Used in Post-attribution install fraud.)

YYYY-MM-DD No
detect-to

[Optional for Post-attribution installs]

End of the fraud detection date range. (Default is to.)

YYYY-MM-DD No

Data Locker

Data Locker writes raw-data to an AWS S3 bucket.

See list of available Protect360 reports

See Data Locker configuration instructions

Post-attribution reports

About post-attribution reports

  • Post-attribution raw data fraud reports have the same structure as the blocked fraud reports.
  • The current month (by install date) post-attribution report continues to be updated until the seventh day of the following month (detection date). 
  • Post attribution raw data reports are limited to advertisers. Agencies need permissions enabled to access.
  • Reports contain post-attribution fraud events identified by Protect360 and include all media sources in a single report.
  • Post-attribution raw data fraud reports are available as follows:

    • Dashboard user interface: limited to one media source during one calendar month.
    • Pull API: contains all media sources. (Limitation: Available to app owners only.)

Using post-attribution reports

  • Select any combination of install/IAE and detect date ranges as needed.
  • For hijacked installs/IAEs, use the blocked_reason_rule field to identify the valid contributor (media source), meaning the contributor that should have originally received attribution.
    The blocked_reason_rule is populated with either contributor[1-5] or organic. Check the contributor[1-5] fields to view the contributor details and reconcile.
  • 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. 
  • The best practice for using this Pull API is as follows:
    • Assume you pull the report on a daily basis. 
    • Set the install date range to 60 days looking back from the current day.
    • 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

Example A: During December (install date) 15 installs are attributed to example_media. On January 3 (detection date), Protect360 identifies example_media as a fraudster. As a result, the 15 installs attributed to example_media are listed as fraudulent in the post-attribution fraud report for further action by the app owner. 

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. 

Protect360 report structure

Protect360 reports have the same general structure as their parallel user acquisition reports fields.

In addition to the regular raw data report fields, Protect360 reports have the following fields, as follows:

  • Blocked reason
  • Blocked sub-reason
  • Blocked reason value
  • Blocked reason rule

Protect360 blocked reasons

Click level blocked reasons

At the click level, clicks are blocked, and the attribution process ignores them.

Blocked reason Description
ip_blacklist Based on a dynamically created list (details)
install_store_validation The discrepancy between Google Referrer values of the install
invalid_fingerprint S2S clicks only: invalid parameters sent by the source (for Probabilistic matching)

Install level blocked reasons

At the install level, we identify enough info at the time of install to determine either:

  • A fake install, meaning the user installing the app is not a real person. In this case, the attribution is completely blocked.
  • Attribution hijacking, where the user is real but the engagement is falsified. In this case, the fraudulent engagement is blocked and attribution is re-assigned to the first valid contributing ad-network.

The following tables list possible install level blocked reasons:

Install level: Fake install block reasons
Blocked reason Blocked sub reason Description
bots fake_device_parameters Non-human behavior detected in device-related parameters during app installation process
bots fake_install_parameters Non-human behavior detected in install-related parameters during app installation process
bots bayesian_network Bayesian network identification of fraudulent patterns
validation_bots invalid_sdk Installs with outdated or unused SDK versions - defined by the customer
validation_bots invalid_device_parameters Specific device fields expectation mismatch - defined by the customer
validation_bots invalid_app_version Installs with outdated or unused app versions - defined by the customer
Install level: Attribution hijacking block reasons
Blocked reason Blocked sub reason Description

ctit_anomalies

short_ctit

Install blocked due to short CTIT: Protect360 defined

install_hijacking

referrer_hijack

Blocked hijacking attempt based on GooglePlay API and AppsFlyer SDK parameters

install_hijacking

integration_temporarily_blocked

Install blocked because the partner (pid) has extremely high fraud rates and significant anomalies in all their traffic

validation_hijacking

short_ctit

Install blocked due to short CTIT: Customer defined

validation_hijacking

empty_site_id

Install blocked due to unpopulated site ID. Rule implementation is phased 

Cluster level blocked reasons

When a pattern of fraud is detected, the fraud source is denylisted. Installs from this denylisted source are blocked either because of:

  • A fake install, meaning the user installing the app is not a real person. In this case, the attribution is completely blocked.
  • Attribution hijacking, where the user is real but the engagement is falsified. In this case, the fraudulent engagement is blocked and attribution is re-assigned to the first valid contributing ad-network.

The following tables list possible cluster level blocked reasons:

Cluster level: Fake install block reasons
Blocked reason Blocked sub reason Description
bots timestamp_anomalies Anomalies related to attribution flow click times and other timestamps collected from the device
bots, site_blacklist device_emulators Installs generated on a large scale by automatic scripts working in virtual environments
site_blacklist device_farms High rates of unknown (new) devices
behavioral_anomalies behavioral_anomalies Suspicious in-app behavior compared to common app user behavior pattern
Cluster level: Attribution hijacking block reasons
Blocked reason Blocked sub reason Description
ctit_anomalies, install_hijacking ctit_anomalies Abnormal CTIT pattern per app standards
click_flood click_flood Abnormally high click volume across long CTIT distribution
install_hijacking click_clusters Clicks generated by a device-level malware

In-app level blocked reasons

In-app events can be blocked for the following reasons:

  • The initial install was identified as fake.
  • Because of a defined validation rule.
  • Because our algorithm detects fraud. 

The following table lists possible in-app level blocked reasons.

In-app level block reasons
Blocked reason Blocked sub reason Description
Inherits from install Inherits from install Initial install identified as fake based on install or denylisted level reason
inapps_bots fake_device_parameters AppsFlyer algorithm detects fraud
validation_inapps invalid_event_name Based on a requested or manually defined validation rule
validation_inapps invalid_event_source Based on a requested or manually defined validation rule
validation_inapps invalid_event_value Based on a requested or manually defined validation rule
Was this article helpful?