Configuring User-Defined Fraud Rules

Learn how to create user-defined rules for fraud detection and prevention.

For information about Singular's built-in fraud protection methods, see Configuring Fraud Settings.

 

In addition to the fraud protection methods developed by Singular, you can also create your own custom rules to prevent types of fraud that are specific to your apps.

Creating a Rule

To create a user-defined rule:

  1. Go to Fraud Prevention > Rules.
  2. Select Create New Rule and fill out the rule form.

Rule Name

Identifies the rule and also shows up in the Reason dimension in the fraud report if it is triggered.

Rule Conditions

mceclip7.png

Conditions define the cases in which a rule will be triggered. Multiple conditions can be set for each rule, and all of them need to apply for the rule to trigger on a touchpoint.

Each condition is built from three parts:

  1. Field: the field that is being evaluated based on the touchpoint and install. For example, if the field is Source - the condition will be based on the source (Ad Network) of the touchpoint.
  2. Operator: the operator defines the relation between the field and the values.
  3. Values: the values used on the right side of the operator for the condition.

The possible fields are:

Source The touchpoint’s source name.
App The installed app.
Publisher The touchpoint’s publisher ID.
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.
Duplicate Clicks The number of clicks from the same ad network.
Click Country Originating country of the touchpoint (based on IP address).
Install Country Originating country of the install (based on IP address).
Campaign Name The name of the touchpoint’s campaign.
Attribution Method The method used for attribution: deterministic (using a device identifier) or probabilistic (see the Probabilistic Attribution FAQ).
Receipt Validation Is the supplied install receipt for iOS valid (see iOS Install Receipt Validation).
Click to Install Distance The distance (based on IP geolocation) in kilometers the device has moved from the click event to the install event.
Click to Install Speed The speed (based on IP geolocation) in kilometer per hour in which the device has moved from the click event to the install event.
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.
App version The version of the app (see version comparison for more details).
OS version The version of the OS (see version comparison for more details).
OS The device's OS (Android/iOS).
Touchpoint type The touchpoint's type (Click/Impression).

Rule Action & Status

Actions dictate what happens when the rule’s conditions match a touchpoint. The different possible actions are:

  1. Whitelist: any touchpoint that matches a whitelisting rule will be considered valid and no other rule will be evaluated on it.
  2. Reject: any touchpoint matching this rule will be rejected.
  3. Mark as Suspicious: any touchpoint matching this rule will still be considered valid for attribution but will also be marked as suspicious.

The rule status can be used to turn rules on or off quickly.

Versions Comparison

Generally, version names have a structure to them. We check to see that the versions that are entered adhere to that structure.

  • The structure is as follows: Positive numbers separated by dots.
  • After the digits, a “-” followed by one of the following suffixes:
    • alpha
    • beta
    • rc-x
    • dev

Valid Examples:

  • 2.3.5
  • 2.4.5.6
  • 3.4-alpha
  • 4.5-rc3

Invalid Examples:

  • 2.3-master
  • 3.4Alpha
  • Alpha
Was this article helpful?