Understanding Singular Fraud Prevention

Learn how Singular's Fraud Prevention Engine works, the difference between pre-defined protection methods and custom fraud rules, and the steps in the fraud detection process.

To learn about your fraud analytics and reports, see the Fraud Reporting and Fraud Data FAQ.


Singular’s Fraud Prevention Engine actively protects your marketing efforts using a mixture of out-of-the-box detection methods and custom user-defined rules to prevent attribution fraud.

The Fraud Prevention Engine evaluates installs before finalizing the attribution or reporting it to the partner, thus preventing excessive billing for CPI/CPA campaigns.

Fraud Protection Methods

Singular has conducted extensive research into attribution fraud to detect and implement the most useful and actionable fraud prevention methods in the market. The methods are fine-tuned based on the collective information from Singular’s clients to achieve the best results while minimizing false positives.

The customer can activate or deactivate each method separately. When activating a method, the customer can choose whether touchpoints that trigger this method should be Rejected (declared as unsuitable for attribution) or just marked as Suspicious for later follow-up.

  For more information about activating fraud protection methods, see Configuring Fraud Settings.

Fake Installs Protection Methods

While other types of attribution fraud rely on stealing the credit for legitimate app installs, install fraud is based on the creation of fake installs and fake users for the purpose of getting the installs attributed.


NEW: Android Install Validation

To tackle install fraud on Android, Singular has developed Android Install Validation - a proprietary, deterministic method of evaluating an install and making sure it is legitimate. Android Install Validation detects and prevents all known forms of fake install attacks at a significantly higher level of accuracy than any tools developed previously.

  See Advanced Android Fraud Protection for more information.

iOS Install Receipt Validation

Apple provides a receipt for each app installed on an iOS device through iTunes. The receipt can be used to verify that the app has been installed by a real user on a real device. Receipt verification is a multi-step process:

  1. Making sure that a receipt exists.
  2. Verifying the authenticity of the receipt by checking Apple’s digital signature.
  3. Validating the receipt by matching the receipt’s details to the current installation (for example comparing the app’s longname).
  4. Ensuring that the receipt hasn’t been used for another install (so that fraudsters wouldn’t re-use the same receipt on multiple installations/devices).

Note: Singular performs receipt validation only on devices with iOS 7.0 or higher and only when the app includes a Singular SDK of version 8.2 or higher.

Attribution Manipulation Protection Methods

NEW: Android Click Injection Protection

In click injection, the fraudster detects an app install by a real user and creates a fake click (or impression) in order to hijack the install attribution.

To protect against click injection, Singular’s new detection method uses Google Play Referrer values and timestamps to identify impressions and clicks that occur after users were directed to the Play Store or initialized an install.

  See Advanced Android Fraud Protection for more information.

New: Android Organic Poaching Protection

In Organic Poaching, a fraudster claims credit for an app install that is, in fact, organic and should not be attributed to any source.

Singular’s new protection method detects signals from the Google Play Store that an app install is organic (not associated with any ad clicks). Any clicks associated with this install can then be identified as an organic poaching attempt.

  For more information, see Advanced Android Fraud Protection.

Time-to-Install (TTI) Outliers Detection

“Click injection” attacks involve detecting an installation and firing a fake click. They can often be detected by looking at the Time-to-Install (TTI) - the time between the click and the install. The click is fired right as the app finished installing, so it often results in an abnormally short TTI.

Geo-Bleed Detection

Singular detects a distance between the click location and the install location that was impossible for a real end-user to travel in the time that passed between the click and the install. For example, if an end-user clicks an ad, and two hours later there is an install event from 10,000 km away, this is probably a fraudulent install.


Attacks such as click spamming and click injections create an influx of clicks from the same source. Singular detects the suspicious activity and can reject clicks coming from the same source.

General Protection Methods

Blacklisted IPs

Singular detects touchpoints coming from known suspicious IP ranges, which include:

  • Cloud Service Providers and Data Centers
  • Proxy and IP anonymization services
  • TOR exit points
  • High-risk IPs: IPs that have been spotted doing fraudulent or other abusive activity on the internet.

Singular maintains a regularly updated list of these IP ranges.

User-Defined Rules

In addition to the fraud protection methods developed by Singular, customers can create custom rules to prevent types of fraud that are specific to that customer’s apps.

For example, a customer may want to reject clicks where the publisher is a certain problematic publisher and the Time to Install (time between click and install) is under a certain number of seconds.

  For more information, see Configuring User-Defined Fraud Rules.

[NEW] Click Flooding Protection

In addition to the protection methods and custom rules, Singular uses click flooding protection as an additional level of defense against fraudsters who use fake clicks. Click flooding protection is activated automatically when Singular detects a click flooding attack. For more information, see the Click Flooding Protection FAQ.

The Fraud Detection Process

The fraud detection process comprises the following 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 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.


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.

Fraud Reporting

Singular’s fraud reporting tools allow you to track Fraud Prevention Engine decisions and analyze fraudulent activity related to each of your apps.

  See Fraud Prevention: Reporting for more information about the available reports and how to use them.

Fraud Postbacks

Singular can send automated postbacks about fraud decisions to the relevant ad network and/or to the customer’s internal BI platform.

There are two types of fraud postbacks:

  • Rejection postback: Sent when an install would be attributed to a certain touchpoint, but the touchpoint is rejected by Singular’s fraud prevention system.
  • Notification about a suspicious install: Sent to the customer’s internal BI systems when an install is attributed to a touchpoint that is marked as suspicious.

  See Fraud Postbacks for more information.

Best Practices for Using Singular Fraud Prevention

Use “Mark as Suspicious” Before Enabling “Reject”

Singular's fraud prevention tools - including both the default method and any custom rules - may run into edge cases and produce unwanted behavior in the form of false positives or false negatives. When you activate new methods or rules without testing them, they may affect your ongoing marketing campaigns or impact your volume unexpectedly.

This is why we recommend testing new methods and rules by setting them to "Mark as Suspicious" rather than "Reject". Monitor the performance of the methods/rules for a while, using the suspicious report, and make sure they work as expected.

Once you're satisfied with the methods/rules, promote them to "Reject" so that they prevent Singular from sending billing postbacks and help keep down your CPI/CPA charges.

Leverage Custom Rules

Every vertical and application runs into its own unique fraud cases. We always recommend creating custom rules to help Singular's fraud prevention system protect you in your specific use-cases. For example:

  • Whitelist partners that are guaranteed to not fraud you, e.g., internal cross-promo.
  • Reject installs that don’t match your campaign’s targeting options.

Leverage Singular’s Alerts

Sometimes the best way to catch fraud is to look at KPIs. You can set alerts on specific KPIs to be notified when a source or a publisher suddenly performs extremely well or extremely poorly. These abnormalities may indicate fraud which you can then fight using custom rules.

Was this article helpful?