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
Postback news
August 20, 2020: Postbacks available for rejected in-app events
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.
- AppsFlyer sends rejected events postbacks 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. |
| install_validation_rules | Rule name/s | ✓ | Installs are defined as invalid by the advertiser using user-defined validation rules. For example, the advertiser defines that they would like to promote their app only in the United States. Installs coming from outside of the United States, are considered invalid and are not attributed. |
| 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 |
To manage your rejected install postbacks contact your partner development manager or integrations@appsflyer.com. Specify as follows:
- The postback methods you want
- The URL of the additional endpoint if applicable
- Additional parameters to add to your current postback, specify the parameter name as you want like:
&reject_reason,&reject_sub-reasonand&reject_reason_value