Protect360 raw data reports

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

About Protect360 raw data reports

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 Description
Installs

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. 
Post-attribution installs

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.
Clicks Reports include blocked clicks with the block reasons.
Blocked install postbacks 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.
  • 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 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. 
  • 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. 

Raw data availability by tool type

Protect 360 raw-data availability by tool type
Report Data freshness Pull API Export Data page Data Locker
Installs Real-time
Blocked in-app events Real-time
Clicks Real-time
Blocked install postbacks Real-time - -
Post-attribution installs

Daily 10:00 UTC

✓*
Post-attribution in-app events

Daily 10:00 UTC

-

* 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=rejected_reason_value

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

rejected_reason_value displays the valid contributor (media source) for hijacked installs/in-app events. Populated with either contributor[1-3] 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

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_device_parameters Specific device fields expectation mismatch - defined by the customer
validation_bots validation_rules

Rules where the outcome is blocked installs based on manually defined validation rule

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 

validation_hijacking

validation_rules

Rules where the outcome is blocked attribution based on manually defined validation rule

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
in_app_store_validation - Receipt validation for in-app purchase fails. 
validation_inapps validation_rules

Based on manually defined validation rule

Was this article helpful?