Learn what postbacks Singular can send in cases of rejected and suspicious installs.
- Types of Fraud Postbacks
- Decision Reasons
- Example: How Both Postbacks are Used in a Single Install
- How to Enable Fraud Postbacks
- Advanced: Limitations and More Examples
In addition to sending install attribution postbacks to the relevant ad networks, Singular can also send postbacks about fraud decisions.
Types of Fraud Postbacks
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.
Decision Reasons
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.
The following table summarizes the differences between fraud postbacks and 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) |
Example: How Both Postbacks are Used in a Single Install
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 |
How to Enable Fraud Postbacks
Fraud postbacks are available to customers of Singular’s fraud prevention service.
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.
Advanced: Limitations and More Examples
The following additional limitations apply:
Only One Rejection Postback per Install
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 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 |
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 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) |
