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.
-
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. |
| ai_layer | N/A | x | AI models are utilized to analyze vast amounts of data points, enhancing detection capabilities for identifying fraudulent device and installation activities. |
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 |
Important!
- 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-rejectedblocked-reasonblocked-sub-reasonblocked-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.