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
- Reject reason value (when available). For example:
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||✓||
|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:
- When the parameters above are added to both the Default postback and the Advanced Privacy postback, rejected install/in-app event postbacks are enabled.