Learn the details of Singular's fraud detection and prevention process, including what happens when a certain touchpoint is rejected, what happens when touchpoints are marked as suspicious, and which types of postbacks are sent with each different fraud decision.

Fraud Detection Steps

1. Logging all touchpoints

Touchpoints include end-user events such as clicks, impressions (view-through), Self-Attributed Network touchpoints (from networks such as Facebook, AdWords, and Twitter), and additional special touchpoints such as Google Play Install Referrer information.

2. Logging the install event

When the app is first opened, an install event is triggered and sent to Singular’s servers. Singular logs the install and gathers all matching touchpoints.

3. Evaluating all the attribution candidates

The Fraud Detection Engine assembles a list of all the attribution candidates and evaluates each one based on all the fraud prevention methods and the custom fraud rules.

For example, here is an install with two associated touchpoints:

In this example, the attribution candidates are:

• Network B (for Click 2)
• Network A (for Click 1)
• Organic

The Fraud Prevention Engine may reject any touchpoint for fraud. It may also reject the organic option - if the install itself is found to be fake. For example, the Engine may reject the organic install option if the install event comes from a blacklisted IP that is associated with bot activity.

Depending on your fraud settings, some touchpoints may not be rejected but only marked as suspicious. These touchpoints are still valid candidates for attribution, but you will be able to see in your reports that they were marked as suspicious, for your further investigation.

4. Making the final attribution decision

Singular’s attribution mechanism goes over the attribution options in order of best to worst, and attributes the install to the best option that has not been rejected by the Fraud Prevention Engine.

If all options have been rejected for fraud (including the option of it being an organic install), the install is marked as Untrusted.

5. Updating the reports and sending postbacks

For "Rejected" Decisions:

If the attribution decision was influenced by the Fraud Prevention Engine - meaning, if the best attribution candidate was rejected - Singular’s attribution mechanism:

1. Adds a rejection to the rejection report
2. Sends a rejection postback (if rejection postbacks have been configured - see Fraud Postbacks).

If the Fraud Prevention Engine didn’t change the attribution decision, no fraud postback is sent. For example, the Engine might have rejected a lower-priority click. This is not counted as a rejection for the purposes of rejection reports and fraud postbacks.

For "Suspicious" Decisions:

Touchpoints that were marked as "suspicious" by the Fraud Prevention Engine are still valid candidates for attribution. If Singular's attribution mechanism selects one such touchpoint as the final attribution decision, it:

1. Adds a suspicious install to the suspicious report.
2. Adds a parameter to the install postback sent to the customer's internal BI (if such postbacks have been configured - see Fraud Postbacks). The parameter includes the reason for the suspicious decision.

Untrusted installs are also marked as suspicious and will appear in the suspicious report.

Examples: Fraud Decisions and Their Impact

Let’s look at some simple cases of attribution decisions affected by fraud evaluation results.

Example 1: Rejected Click

1. Fraud detection process: In this example, the Fraud Prevention Engine went over all the touchpoints and decided to reject Click 2 for fraud.
2. Attribution logic: The attribution mechanism has to choose between the following attribution candidates:
   • Network B (for Click 2)
   • Network A (for Click 1)
   • Organic

   If no fraud evaluation existed, Click 2 would be the best option for attribution, as it is the click closest to the install. However, Click 2 is rejected, so the next-best option is chosen.

3. Attribution Decision: The install is attributed to Network A (for Click 1).
4. Reports: Singular adds a rejection for Network B to the rejection reports.
5. Postbacks: Singular sends Network B a rejection postback.

Example 2: All Clicks are Rejected

1. Fraud detection process: In this example, the Fraud Prevention Engine went over all the touchpoints and rejected both click 1 and click 2 for fraud.
2. Attribution logic: The attribution mechanism has to choose between the following attribution candidates:
   • Network B (for Click 2)
   • Network A (for Click 1)
   • Organic
3. Attribution decision: Since all clicks are rejected, the install is marked as Organic.
4. Reports: Singular adds a rejection for Network B to the rejection reports.
5. Postbacks: Singular sends Network B a rejection postback.

Example 3: Even the “Organic” Option is Rejected (Untrusted Install)

1. Fraud detection process: In this example, the Fraud Prevention Engine went over all the touchpoints and rejected both click 1 and click 2 for fraud. The Engine also rejected the install event itself as fake.
2. Attribution logic: The attribution mechanism has to choose between the following attribution candidates:
   • Network B (for Click 2)
   • Network A (for Click 1)
   • Organic
3. Attribution decision: Since all clicks are rejected, and the Organic option is rejected as well (because the install event was found to be fake), the install is attributed to Untrusted.
4. Reports: 
   • Singular adds a rejection for Network B to the rejection reports
   • Singular adds a suspicious install to the suspicious reports, attributed to Untrusted.
5. Postbacks: Singular sends Network B a rejection postback.