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.
Note: If you are a Singular customer, read the Fraud Postbacks guide for customers instead. It contains more information that you need to know.
Troubleshooting
Singular lets advertisers define custom fraud rules to deal with specific fraud attacks on their apps and campaigns. For example, advertisers can set up blacklists of IPs associated with click-spamming attacks. Advertisers can even create a rule that is based on Singular's default fraud detection methods, but combines or limits them in some way to fit the specific attacks being made on that partner.
See Rule Conditions for more details on how advertisers can set up custom rules.
When an install is rejected due to a custom rule, the postback sent to the partner only says "User-Defined Rule" for the rejection reason. This is meant to protect the advertiser's privacy. If you need more details, try asking the advertiser to share their custom rule logic.
Singular allows advertisers to set up fraud rules to have some installs marked as "suspicious" for internal testing purposes.
Suspicious installs are considered legitimate attributed installs and the partner gets awarded the install normally - including receiving an install postback.
No fraud postback is sent to the partner for suspicious installs.
Only the advertiser can know (by looking at their special fraud reports) if an install was marked as suspicious.
| Singular Fraud Decision for an Install | Final Attribution |
Postback Sent to the Partner |
| Valid | Install is attributed to the partner | Install postback |
| Suspicious | Install is attributed to the partner | Install postback |
| Rejected | Install is attributed to a different partner or marked as "organic" | Fraud postback |
FAQ
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.
Partners can receive fraud postbacks when an install is rejected - meaning that 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.
No. Partners only receive fraud postbacks for rejected installs. Rejected installs are installs that would have been attributed to the partner, but the click/view was found to be fraudulent (based on a default Singular fraud detection method or a custom rule set up by the advertiser).
A rejected install is attributed to a different partner or marked as "organic," and no install postback is sent to the original partner.
Singular allows advertisers to set up fraud rules to have some installs marked as "suspicious" for internal testing purposes. Suspicious installs are considered legitimate attributed installs and the partner gets awarded the install normally - including receiving an install postback.
No fraud postback is sent to the partner for suspicious installs.
Only the advertiser can know (by looking at their fraud reports) if an install was marked as suspicious.
| Singular Fraud Decision for an Install | Final Attribution |
Postback Sent to the Partner |
| Valid | Install is attributed to the partner | Install postback |
| Suspicious | Install is attributed to the partner | Install postback |
| Rejected | Install is attributed to a different partner or marked as "organic" | Fraud postback |
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.
| Rejection Reason | Meaning |
| "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 based on 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. |
To start receiving fraud postbacks from Singular, 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.
Example:
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.
Example:
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.