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 

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

 Important!

  • In order to be able to distinguish between postbacks for legitimate events and rejected postbacks, you must configure the rejected postback macros (such as &reject_reason&reject_sub-reason,  &is-rejected, and &reject_reason_value).

  • To enable rejected install/event postbacks, contact integrations@appsflyer.com.
Was this article helpful?