In addition to the pre-existing fraud protection methods offered by Singular, you can also create your own custom rules to protect yourself from specific types of attacks that tend to target your apps.
You define rules by picking specific attributes of the install and its relevant touchpoint(s) and specifying when these attributes may hint at fraud. For a full guide to creating custom rules, see How to Set Up Singular Fraud Protection: Custom Rules.
List of Attributes
Field |
Description |
Android Click Injection Detected | Whether a click injection attack was detected. 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. Singular uses Google Play Referrer values and timestamps to detect impressions and clicks that occur after users were directed to the Play Store or initialized an install. |
Android Install Validation | Whether the app install has been validated by Singular using our special tools for testing Android installs. Android Install Validation is one of Singular's out-of-the-box fraud protection methods, which you can enable or disable, but you can also use it inside a custom rule if you want to limit/refine it and combine it with other conditions. |
Android Organic Poaching Detected | Whether an "organic poaching" attack has been detected (an attack in which a fraudster tries to claim credit for an install that is actually organic). Singular’s 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. Note: This protection method may trigger high percentages if a network sends clicks instead of impressions. Customers can prevent this by using custom rules to apply Organic Poaching prevention only to relevant sources. |
App | The installed app. |
App version | The version of the app (see version comparison for more details). |
Attribution Method | The method used for attribution: deterministic (strong ID) or probabilistic (based on device characteristics, available on Android only). |
Campaign Name | The name of the advertising campaign. |
Click Country | Originating country of the touchpoint (based on IP address). |
Click to Install Distance | The distance (in km) between the IP geolocation of the click event and the IP geolocation of the install event. A long distance may indicate fraud. |
Click to Install Time |
The time between the click event and the install event. |
Click to Install Speed | The speed (in km/h) in which the device has theoretically moved from the click event to the install event (based on dividing "click to install distance" by "click to install time"). If the speed is unrealistically high, it may indicate fraud. |
Duplicate Clicks | The number of clicks related to this install that originated from the same ad network. Multiple clicks may indicate fraud. |
Install Country | The originating country of the install (based on IP address). This is useful if you are targeted by fraudsters from a specific country. |
Install Source | Android apps can query the package name that initiated their installation. The package name is different if the app was installed through a different store or an APK. |
Integration Type |
Whether it's an SDK or S2S integration. |
OS | The device's OS (Android/iOS). |
OS version | The version of the OS (see version comparison for more details). |
Publisher | The touchpoint’s publisher ID. |
Singular SDK Version |
The version of the Singular SDK integrated into your app. |
Source | The ad network that the touchpoint came from. |
Time to Install | The time from click to install. Both very short and very long periods can indicate fraudulent activity. Can be set to a maximum number of seconds or a minimum number of days. |
Touchpoint type | Click or impression. |
Receipt Validation | Is the supplied install receipt for iOS valid? (see the In-App Purchase Validation FAQ). |
Versions Comparison
Version names have a structure and we check to see that the versions that are entered adhere to that structure:
- Positive numbers separated by dots.
- After the digits, a dash (“-”)followed by one of the following: alpha, beta, rc-x, or dev.
Valid Examples:
- 2.3.5
- 2.4.5.6
- 3.4-alpha
- 4.5-rc3
Invalid Examples:
- 2.3-master
- 3.4Alpha
- Alpha