At a glance: Integrated partners receive real-time postbacks of rejected installs and rejected in-app events due to fraud or non-compliance with targeting validation rules.
Rejected attribution postbacks relating to fraud and targeting rules
August 20, 2020: Postbacks available for rejected in-app events
- Fraud events: install and in-app events blocked by Protect360
- Non-compliant targeting events: installs and in-app events that don't comply with campaign targeting validation rules
- Rejected events: Fraud events and non-compliant targeting events
- Attribution corrected install: A hijacked install identified and blocked by Protect360 whose attribution is subsequently corrected and attributed to the genuine media source.
- Integrated partners get rejected event postbacks.
- 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:
- 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||Ruleset ID||✓||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||x||Installs coming from Site IDs 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 behaviour.|
|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||Ruleset ID or empty||✓||
Customer defined rule relating to:
|validation_hijacking||Ruleset ID||✓||Customer defined rule relating to CTIT|
|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|
To manage your rejected install postbacks contact your partner development manager or firstname.lastname@example.org. 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: