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 

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.

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 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
validation_inapps Rule name/s Based on manually-defined rules
Reject reasons for in-app events

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