Singular Fraud Prevention

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.

See Advanced Android Fraud Protection for more information.

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.

Hyper-Engagement

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 thats 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.

The Fraud Detection Process

1. Logging Touchpoints

Touchpoints include end-user events such as:

  • Clicks
  • Impressions (view-through)
  • Self-Attribution Network touchpoints (from Facebook, AdWords, Twitter, and Snapchat)
  • Google Play Install Referrer and additional special touchpoints.
2. Logging the Install

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 the Touchpoints and the Install

Singular’s Fraud Prevention Engine receives the install event information as well as each of the touchpoints.

The engine inspects each touchpoint based on the activated fraud protection methods and custom rules, and decides if the touchpoint is:

  • Valid: The touchpoint is legitimate and the install can be attributed to it.
  • Suspicious: The touchpoint can be used for attribution but the attribution will be marked as suspicious and appear in the suspicious reports.
  • Rejected: The touchpoint can not be used for attribution and will appear in rejected reports.

The engine also inspects the install itself: in some cases, the actual install may be rejected, for example if it comes from a blacklisted IP.

4. Final Attribution Decision

Singular’s tracker makes the final attribution decision, which is one of the following:

  • The install is attributed to a touchpoint (the highest-priority touchpoint that was not rejected).
  • If there were no touchpoints associated with the install, or if all touchpoints were rejected by the Fraud Prevention Engine, the install is marked as organic.
  • If the install itself is rejected, it is marked as Untrusted (see Untrusted Installs below).

Example: Rejected Click

In this example, Click 2 is the highest-priority touchpoint for attribution (as it is the click closest to the install) but it is rejected by the Fraud Prevention Engine.

Attribution decision: The install is attributed to the first click, which was found to be valid.

Example: All Clicks are Rejected

In this example, all the touchpoints associated with the install (Click 1 and Click 2) are rejected.

Attribution decision: The install is marked as Organic.

Untrusted Installs

As mentioned above, the Fraud Prevention Engine may occasionally reject the install itself - for example, if the install comes from a blacklisted IP. In these cases, the attribution decision is Untrusted. This is because rejected installs are characteristic of bot activity, and we do not want to have them pollute the Organic installs numbers. Your fraud reports will count organic installs and untrusted installs separately, allowing you to track bot activity.

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. Rejection postbacks can be sent to the relevant ad network and/or the customer’s internal BI platform.
  • 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. The install is still attributed to the touchpoint, 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.

See Fraud Postbacks for more information.

Was this article helpful?
0 out of 0 found this helpful