At a glance: Integrated partners can receive real-time postbacks of rejected installs.
Rejected install (due to fraud) postbacks
Integrated partners can receive postbacks about blocked installs due to fraud using one of the following methods:
- AppsFlyer can add additional parameters to the install postback. The additional parameters are Reject reason, Reject sub-reason, and Reject reason value (when available). For example:
- Create a new endpoint (a postback URL), dedicated to rejected installs, with a different structure. This includes the previously mentioned parameters and any other available parameters.
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 high CTIT and low conversion rate.|
|behavioral_anomalies||N/A||x||Behavioral anomalies are install fraud installs, blocked due to inconsistent and abnormal post-install behavior.|
|install_hijacking||N/A||x||Install hijacking are attributed clicks blocked based on unreasonable click and install time based on the 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|
- AppsFlyer does not send postbacks for in-app events of rejected installs.
- If the install was fraud due to hijacking, and we did "attribution correction" (meaning it was correctly attributed), then postbacks on following in-app events will be sent.
If you are integrated with AppsFlyer and want to start receiving postbacks on rejected installs, contact your Partner Development Manager or firstname.lastname@example.org. Specify which of the two methods mentioned suits you.
If you want to add new parameters to your current postback, specify the parameter name as you would like to receive it such as,
If you want to add a new endpoint, send the new URL together with all relevant parameters to your Partner Development Manager or to email@example.com.