At a glance: Integrated partners get postbacks of rejected installs and in-app events due to fraud or non-compliance with validation rules.
Rejected attribution postbacks relating to fraud and validation rules
Terminology:
- Fraud events: install and in-app events blocked by Protect360
- Non-compliant events: installs and in-app events that don't comply with validation rules
- Rejected events: Fraud events and non-compliant validation rule events
- Attribution corrected install: A hijacked install identified and blocked, whose attribution is subsequently corrected and attributed to the genuine media source.
Postbacks
- Integrated partners get rejected event postbacks in real-time.
- There are no fraud event postbacks for in-app events of attribution corrected installs.
- Rejected event postbacks are sent to the endpoint specified by the partner. Partners select from one of the following:
- Single endpoint for both install and rejected event postbacks with additional parameters being:
- Block reason
- Reject sub-reason
- Reject reason value (when available). For example:
reject_reason=site_blacklist&reject_reason_value="1123456"
- Dedicated endpoint for rejected event postbacks: Endpoint having a unique structure. This includes the previously mentioned parameters and any other available parameters.
- Single endpoint for both install and rejected event postbacks with additional parameters being:
The following table lists the reject reason, reject reason value, and an explanation of the reject reason:
| Reject reason | Reject reason value | User can configure | Explanation |
|---|---|---|---|
| ctit_anomalies | The measured click to install time in seconds | x | CTIT anomalies are attributed clicks that have been blocked based on unreasonable CTIT (click to install time). |
| store_install_validation | N/A | x | Installs that failed validation from the App Store |
| site_blacklist | Site ID | x | Installs coming from Site IDs that AppsFlyer blocked due to a high density of fraudulent activity. Determined by our internal algorithms. |
| bots | N/A | x | Blocked install attempts made by Bots |
| click_flood | Site ID or empty | x | Installs coming from clusters blocked by AppsFlyer due to a large number of installs with a high CTIT and low conversion rate. |
| behavioral_anomalies | N/A | x | Behavioral anomalies being install fraud blocked due to inconsistent and abnormal post-install behavior. |
| install_hijacking | N/A | x | Install hijacking being attributed clicks blocked based on unreasonable click and install time, based on Google Play Server-Side API. |
| validation_bots | Rule name/s or empty | ✓ |
Customer-defined rule. |
| validation_hijacking | Rule name/s | ✓ | Customer-defined rule. |
| Reject reason | Reject reason value | Explanation |
|---|---|---|
| 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 requested or manually defined validation rule |
| validation_inapps | invalid_event_value | Based on requested or manually defined validation rule |
| validation_inapps | Rule name/s | Based on manually-defined rules |
Important!
-
In order to be able to distinguish between postbacks for legitimate events and rejected postbacks, you must configure the rejected postback macros (such as
&reject_reason,&reject_sub-reason,&is-rejected, and&reject_reason_value). - To enable rejected install/event postbacks, contact AppsFlyer via the partner assistant widget.