Rejected attribution postbacks to integrated partners

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 


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


  • 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 for both install and rejected event postbacks, with additional parameters being:
    • Block reason
    • Reject sub-reason
    • Is-rejected
    • Reject reason value (when available). For example: reject_reason=site_blacklist&reject_reason_value="1123456"&is_rejected=1

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 names or empty

 Customer-defined rule.

validation_hijacking Rule names  Customer-defined rule.

Reject reasons for in-app events

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 be able to distinguish between postbacks for legitimate events and rejected postbacks, you must configure the rejected postback macros.
  • To enable rejected postbacks for Advance Privacy you must first append the following parameters to the Default postback:
    • is-rejected
    • blocked-reason
    • blocked-sub-reason
    • blocked-reason-value
  • When the parameters above are added to both the Default postback and the Advanced Privacy postback, rejected install/in-app event postbacks are enabled.