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 are divided as follows:
- Blocked reports: Installs, clicks, and in-app events of users whose install/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.
| 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 | Blocked in-app events with the block reason | ✓ | ✓ | ✓ |
| 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 |
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:
|
|||||
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.
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 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. - 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:
| 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 |
| 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 |
| 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 |
| validation_inapps | validation_rules |
Based on manually defined validation rule |