The core of the Singular Fraud Prevention Engine is built from two parts:
- Singular Protection Methods
Singular Detection & Preventions methods can be activated by a press of a button (see Managing the Singular Protection Methods). These methods are built and refined by our fraud experts and protect against the most common types of fraud.
- User Defined Rules
Singular supports the creation of user defined custom rules that can be leveraged by users to address their specific needs.
Each touchpoint is checked against all of the configured User Defined Rules & Singular Protection Methods, and marked as:
- Whitelisted - any touchpoint that matches a whitelisting rule will be considered valid and no other rule will be evaluated on it.
- Rejected - any touchpoint matching this rule/method will be rejected.
- Suspicious - any touchpoint matching this rule/method will still be considered valid for attribution but will also be marked as suspicious.
Decision is based on the first matching rule and so the order of evaluation is important. Whitelist rules are evaluated first to make sure any whitelisted touchpoint is not rejected, then rejection rules are evaluated and finally suspicious rules are evaluated.
Singular Protection Methods
Singular has done extensive research into fraud to detect and implement the most useful and actionable fraud prevention methods in the market. One of the results of that research is the calculated effectiveness of each of the different methods in the market today:
Taken from Singular’s 2017 Fraud Index
Based on these results we have chosen and tuned the most effective methods and have made them easily accessible in the UI. We fine-tuned the methods based on the collective information from Singular’s clients to achieve the best results while minimizing the false-positive rate.
The pre-defined methods Singular employ are:
The method is triggered when a touchpoint’s IP address matches a blacklisted IP range.
Singular maintains a list of blacklisted IPs that updates continuously, the list contains IP addresses of:
- 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.
This method triggers in the case of impossible travel - i.e if an end-user moved at impossible speeds from the click location to the install location.
For example, if an end-user clicks an Ad and two hours afterwards Singular receives an install-event from 10K kilometers away.
In many cases click spamming and click injection creates an influx of clicks from the same source. The Hyper-Engagement method detects this influx and takes action to reject clicks coming from the same source.
Click Injection attacks are performed by detecting an installation and firing a fake-click. Since the click is fired as the app finished installing - it will often result in an abnormally short Time-to-Install (TTI).
This methods detects the cases of abnormally short TTIs.
Managing the Singular Protection Methods
The methods can be found under “Settings” in the “Fraud Prevention” menu:
Once entered, the following should appear:
Each of the methods has an action associated with it, and that action dictates what happens when the method is triggered. Changing the action and Saving would affect the Fraud Engine immediately. The actions are:
- Do Nothing - method is disabled and will not affect the attribution decision or reporting.
- Mark as Suspicious - method flags touchpoints as suspicious, but doesn’t affect attribution decision.
- Reject - methods actively rejects touchpoints and prevents CPI & CPA billing postbacks.
User Defined Rules
Advanced use-cases might require more granular control over the fraud decision making, for that purpose Singular has implement the User Defined Custom Rules. These rules can be leveraged by the user for user-specific fraud prevention purposes.
The User Defined Rules screen can be accessed by pressing Rules in the Fraud Prevention menu:
Once the “Create New Rule” button is pressed a new rule form is presented and the rule can be edited and saved.
Each one of the fields controls a different aspect of the rule and can be edited by the user. Additionally the name of the user who last updated the rule and the last update time are shown.
The rule name is used to identify the rule and would also show in the “Reason” dimension in the fraud reporting if it was triggered.
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:
- 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.
- Operator - the operator defines the relation between the field and the values.
- 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, can be set to get less than number of seconds or greater than number of days.
- Duplicate Clicks - The number from clicks from the same Ad Network.
- Click Country - Originating country of the touchpoint (based of IP address)
- Install Country - Originating country of the install (based of IP address)
- Campaign Name - The name of the touchpoint’s campaign.
- Attribution Method - The method used for attribution: strong identifier or fingerprint.
Rule Action & Status
Actions dictate what happens when the rule’s conditions match a touchpoint. The different possible actions are:
- Whitelist - any touchpoint that matches a whitelisting rule will be considered valid and no other rule will be evaluated on it.
- Reject - any touchpoint matching this rule will be rejected.
- 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 quickly turn rules on or off.