Rejected attribution postbacks to integrated partners

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 

Postback news

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: 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.

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:

  • Customer user ID
  • App version
validation_hijacking Ruleset ID  Customer defined rule relating to CTIT
Reject reasons
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
Reject reasons for in-app events

 To manage your rejected install postbacks contact your partner development manager or 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-reason and &reject_reason_value
Was this article helpful?