Learn what postbacks Singular can send in cases of rejected and suspicious installs.
If you are a Singular partner, we recommend checking out the Fraud Postbacks FAQ for Partners instead.
Learn more about Singular Fraud Prevention.
General Questions
Singular's attribution service can send automatic notifications to partners and customers about certain events. One category of postbacks is postbacks about fraud decisions.
The two types of fraud postbacks are:
- Rejection postback:
Rejection postbacks are sent when an install would be attributed to a certain touchpoint (such as a click from a certain ad network), but the touchpoint is rejected by Singular’s fraud prevention system. Rejection postbacks can be sent to the relevant ad network and/or the customer’s internal BI platform.
- Notification about a suspicious install:
Singular can notify customer’s internal BI systems when an install is attributed to a touchpoint that is marked as suspicious. In this case, the attribution decision is not changed, but Singular informs the customer about the install's suspicious status by adding the fraud decision reason to the install postback that is sent to the customer’s internal BI platform.
Fraud postbacks include the reason why the touchpoint was rejected or marked as suspicious. The decision reason is either:
- One of Singular’s built-in protection methods, such as “Blacklisted IPs” or “iOS Install Receipt Validation”.
- Or a custom rule the customer has set up.
Note: When sending a rejection postback to an ad network, the decision reason does not mention user-defined rules by name, in order not to expose the customer’s business logic. Instead, the reason is specified in general terms as “User-defined Rule”. The rule name appears only in postbacks sent to the customer’s internal BI platform.
Summary: Rejection Postbacks vs. Suspicious Touchpoint Notifications
| Fraud Decision | Attribution | Postback Type | Postback Sent To | Content of Decision Reason |
| Rejected | Install attribution is blocked | Rejection postback (separate postback) | Ad Network and/or Customer’s Internal BI |
For ad networks: “censored” decision reason (user-defined rules are not mentioned by name) For internal BI: full decision reason (name of built-in method or user-defined rule) |
| Suspicious | Install attribution is not affected | Decision reason added to install postback | Customer’s Internal BI | Full decision reason (name of built-in method or user-defined rule) |
Fraud postbacks are available to all customers of Singular’s Fraud Protection Engine.
These postbacks are enabled per app site.
To enable fraud postbacks:
- In the Singular platform, go to Attribution > Partner Configuration.
- Under the relevant ad network or internal BI, find the desired app site and click the pencil button (edit configuration).
- Select the Enable fraud postbacks checkbox and click Save.
Note: Fraud postbacks are currently only supported for some partners. Other networks will not show the fraud postbacks checkbox in the configuration window.
The following illustration shows a user’s timeline as it is examined by the fraud prevention system after an install event.
The attribution service has found two touchpoints associated with the install: Click 1 on an ad from Network A, and Click 2 on an ad from Network B. The fraud inspection rejects click 2 (the touchpoint closest to the install) and marks click 1 as suspicious.
In this case, the install is attributed to Network A for Click 1.
Singular sends the following postbacks:
| Postback | Sent To | Notes |
| Rejection Postback | To Network B | With censored reason for Reject decision |
| Rejection Postback | To Customer's Internal BI (regarding click 2) | With full reason for Reject decision |
| Install Postback | To Network A | |
| Install Postback | To Customer's Internal BI (regarding click 1) | With full reason for Suspicious decision |
Advanced Questions
Singular does not send a rejection postback if the fraud decision didn't affect the attribution decision. Postbacks are not sent for touchpoints other than the one the install would have been attributed to.
If a touchpoint closer to the install is judged to be valid or suspicious, and therefore the install is attributed to it, earlier touchpoints are still examined by the fraud prevention system. But even any of those earlier touchpoints are rejected, Singular does not send rejection postbacks for them.
Example:
In this example:
| Fraud Engine Results | Click 2 (Network B) - touchpoint closest to the install: Valid Click 1 (Network A): Rejected |
| Final attribution decision | The install is attributed to Network B for Click 2. |
Singular sends the following postbacks:
| Postback | Sent To |
| Install Postback | To Network B (regarding Click 2) |
| Install Postback | To customer's Internal BI (regarding Click 2) |
Rejection postbacks are only sent for one touchpoint per install - the touchpoint closest to the install).
Example:
In this example:
| Fraud Engine Results |
|
| Final attribution decision | The install is marked as organic. |
Singular sends the following postbacks:
| Postback | Sent To | Notes |
| Rejection Postback | To Network B (regarding Click 2) | With the censored reason for Reject decision |
| Rejection Postback | To Customer's Internal BI (regarding click 2) | With full reason for Reject decision |
| Install Postback | To Customer's Internal BI | Marking the source of the install as organic |
