Learn what postbacks Singular can send to partners in case an attribution decision is changed by Singular's Fraud Prevention Suite. For general information about the Suite, see Singular Fraud Prevention.
If you are a Singular customer, read the Fraud Postbacks guide for customers instead. It contains more information that you need to know.
In this article:
What are Fraud Postbacks?
Fraud postbacks are automatic real-time notifications sent by Singular's attribution solution when the attribution of a certain conversion is affected by a decision made by Singular's Fraud Prevention Suite.
Fraud postbacks are available to every customer of Singular's Fraud Prevention Suite. The customer can enable or disable fraud postbacks per app per ad network.
To learn more about Singular's anti-fraud tools, see Singular Fraud Prevention.
When do Singular Partners Receive Fraud Postbacks?
Partners can receive fraud postbacks in case of a rejection decision - meaning, when an app install would have been attributed to a certain touchpoint (click or view), but the touchpoint is rejected by Singular's Fraud Prevention Suite.
Note: As mentioned above, Singular only sends fraud postbacks to partners if the customer has enabled this functionality for the specific app and partner.
What Information Do Fraud Postbacks Include?
Fraud postbacks include the reason why the touchpoint was rejected.
The rejection reason can be either one of Singular's built-in Fraud Protection Methods (see details in the table below), or a custom rule defined by the customer.
|"Android Install Validation"||Android Install Validation is a proprietary, deterministic method developed by Singular to protect customers from fake install attacks on Android devices. If an attribution fails Android Install Validation, it means Singular does not think the install was really carried out by a real Google Play user.|
|"iOS Install Receipt Validation"||Singular evaluated the install using the receipt that Apple provides for each app installed on an iOS device through iTunes, and found that the install was not carried out by a real user on a real device.|
|"Android Click Injection"||The touchpoint (impression or click) was found to be part of a click injection attack.|
|"Android Organic Poaching"||The install was found to be defined as organic by the Google Play store (not associated with any ad click), and therefore the click associated with the install is identified as an organic poaching attempt.|
|"Time-to-Install (TTI) Outliers"||This attribution was rejected on the basis of the Time-to-Install (TTI) - the time between the click and the install - which is one way to identify a "click injection" attack.|
|"Geo-Bleed"||Singular detected a distance between the click location and the install location that was impossible for a real end-user to travel in the time that passed between the click and the install.|
|"Hyper-Engagement"||Singular detected an influx of clicks from the same source, which is an identifier of click spamming or click injection attacks.|
|"Blacklisted IP"||Singular detected activity from a known suspicious IP range.|
|"User-Defined Rule"||The touchpoint was rejected based on a custom rule defined by the customer.|
What Do I Need to Do to Receive Postbacks?
If you want to start receiving fraud postbacks from Singular, please contact the Singular support team and give us the following details:
- An API endpoint to post postbacks to (it can be the same endpoint that you use to receive install postbacks);
- The parameter in which to place the rejection reason.
1. Only One Rejection Postback per Install
Rejection postbacks are only sent for one touchpoint per install - the touchpoint closest to the install. The Fraud Prevention Suite may reject other touchpoints associated with the same install, but no postbacks will be sent for those.
In this example, Singular found two clicks associated with the install. The Fraud Prevention Suite has examined the two clicks and has rejected them both.
Final attribution decision: The install is marked as organic.
Fraud postbacks: Singular sends a rejection postback to Network B for Click 2.
2. No Fraud Postbacks if the Fraud Decision Didn’t Affect the Attribution
Rejection postbacks are not sent for touchpoints other than the one the install would have been attributed to.
If the touchpoint that is closest to the install is judged to be valid (or marked as suspicious but not rejected), and therefore the install is attributed to it, earlier touchpoints are still evaluated by the fraud prevention system. However, regardless of the result of the evaluation, no rejection postbacks will be sent for any of those earlier touchpoints.
In this example, Singular found two clicks associated with the install. The Fraud Prevention Suite has examined the two clicks with the following results:
- Click 2 (Network B) - the touchpoint closest to the install - valid
- Click 1 (Network A) - rejected
Final attribution decision: The install is attributed to Network B for Click 2.
Fraud postbacks: No fraud postbacks are sent, because the rejection of Click 1 didn't affect the attribution decision.