Fraud Postbacks FAQ

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

What are fraud postbacks?

Singular's attribution service can send automatic notifications to partners and customers about certain events. One category of postbacks is postbacks about fraud decisions.

What types of fraud postbacks are there?

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.

What information do the postbacks include?

Fraud postbacks include the reason why the touchpoint was rejected or marked as suspicious. The decision reason is either:

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)
How do I enable fraud postbacks?

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.

image2.png

Note: Fraud postbacks are currently only supported for some partners. Other networks will not show the fraud postbacks checkbox in the configuration window.

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.

Screen_Shot_2019-05-06_at_17.55.58.png

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

Why do I not get postbacks on some rejections?

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:

Screen_Shot_2019-05-06_at_18.21.29.png

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)
What happens if a single install has more than one rejected touchpoint?

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

Example:

Screen_Shot_2019-05-06_at_17.59.03.png

In this example:

Fraud Engine Results
  • Click 2 (Network B) - touchpoint closest to the install: Rejected
  • Click 1 (Network A): Rejected
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
Was this article helpful?