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:

Singular sends the following postbacks:

Rejection postbacks are only sent for one touchpoint per install - the touchpoint closest to the install).

Example:

In this example:

Singular sends the following postbacks:

The Android Install Validation fraud rule is triggered if:

• There is a problem with the licensing response from Google Play
• OR if a licensing response hasn't been sent for the device at all.

The reason it works this way is that otherwise, fraudsters could just omit the Google Play licensing check and avoid detection.

If you haven't implemented Google Play licensing support in the SDK in your app, the rule is just triggered whenever there is an Android install sourced from Google Play.

We suggest:

1. Turning of the rule until you implement the proper code in your app.
2. After implementing the code, create a custom fraud rule to apply Android Install Validation only to versions of the app that support it.

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.

Summary: Rejection Postbacks vs. Suspicious Touchpoint Notifications

Fraud postbacks are available to all customers of Singular’s Fraud Protection Engine.

These postbacks are enabled per app site.

To enable fraud postbacks:

1. In the Singular platform, go to Attribution > Partner Configuration.
2. Under the relevant ad network or internal BI, find the desired app site and click the pencil button (edit configuration).
3. Select the Enable fraud postbacks checkbox and click Save.

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: