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
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
| Report | Description |
|---|---|
| Installs |
Reports include:
|
| 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:
|
| Post-attribution in-app events |
Reports include in-app events:
|
| 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] media source/partner 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
| 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:
|
||||
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.
- Go to Integration > API Access.
The Pull API page opens. - In the Protect360 fraud reports section, select the necessary Pull API call.
- Populate the parameters as required. The table that follows lists the parameters.
- Pull the report.
| 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:
|
YYYY-MM-DD | Yes |
| to |
End of the date range:
|
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: |
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.
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 | Discrepancy between Google Referrer values of the install |
| invalid_fingerprint | S2S clicks only: Invalid parameters are sent by the source (for Probabilistic matching) |
| click_capping | Extremely high rates of click fraud are detected from that ad network. Learn more |
| click_signing | Signature on the click is not validated. Learn more |
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:
| Blocked reason | Blocked sub reason | Description |
|---|---|---|
| bots | fake_device_parameters | Non-human behavior detected in device-related parameters during the app installation process |
| bots | fake_install_parameters | Non-human behavior detected in install-related parameters during the 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 |
| 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:
| 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 |
| 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.
| 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 |