Real-time app install ad fraud prevention: is it working?
The phrase “real-time” is widely used in the mobile ads' ecosystem. However, it’s not always used properly in the mobile ad fraud detection framework.
It does make sense when we talk about an anti-fraud solution working on RTB (real-time bidding) traffic purchases. In this case, it’s necessary to define almost instantly whether a potential ad impression corresponding to an ad request is fraudulent or not. Considering the present state of technology and standards behind RTB, a long and thorough review of received traffic is unlikely to provide a satisfactory outcome.
But in the app install ad fraud sphere, the phrase “real-time prevention” may turn out a fancy word without much meaning behind it. In reality, the application of real-time solutions in app install fraud identification usually reveals more drawbacks than advantages. Let’s have a closer look at this statement.
No install - no problem
First, we should define which anti-fraud solutions are able to prevent fraudulent installs and which are not. Although SDK-integrated solutions are theoretically capable of rejecting a potential fraudulent install, such an approach is not always effective.
From the surface “fraud prevention” option looks attractive for user acquisition managers:
1. SDK-integrated solutions appear to be reliable in terms of their traffic evaluation.
2. Publishers are forced to agree with the results of such solutions a priori.
3. If the install is not attributed, it doesn’t appear in the reports. This means there is no need for additional negotiations with publishers on the subject of fraud rejects (and these are often unpleasant negotiations).
Based on these points, SDK-integrated anti-fraud solutions usually present “fraud prevention” as one of their main advantages, while third-party anti-fraud solutions are labeled as a meager “fraud detection.”
However, you cannot run with the hare and hunt with the hounds. So let’s see what else is hidden behind the fraud prevention approach.
The four critical drawbacks of real-time app install ad fraud prevention
1. While real-time analytics is the industry’s generally accepted standard, it doesn’t always work for anti-fraud solutions. The traditional rules-based solutions have to show an attributed install in the dashboard and reports during the first five minutes, which means that the system has only a couple of minutes to make a decision whether an install is fraudulent or not. Such an insufficient time for analysis makes the results much less accurate, which leads to the critical distortion of ROI (Return on Investment) and ROAS (Return on Ad Spend) metrics.
2. The second drawback follows logically from the first. The nature of app install ad fraud is completely different from the RTB impression-based ad fraud. For the maximum accuracy and completeness in app install ad fraud identification, thorough analysis of install clusters in multiple measurement planes is mandatory. And this task becomes impossible for traditional anti-fraud solutions due to the above-mentioned limited time for decision-making, along with an applied rule-based model of fraud identification. So such tools, despite their positioning based on “fraud prevention,” build their anti-fraud solutions on rules which react to every single install. An example of such a solution, which checks every install by a set of rules, might be the following:
a) The given install has a different version in the app store, which differs from the actual installed version. The rules-based solution may consider this as a clear sign of app install fraud, however, this is not necessarily the case.
b) The given install has a TTI (time-to-install) less than 30 seconds. As a rule, this is a sign of fraud for rules-based anti-fraud solutions; however, such a conclusion is always questionable. TTI windows can be very short in many cases without being a fraudulent install (e.g. re-targeting, etc.).
But applying only the conversion analysis to every single install can be extremely inaccurate. Let’s take, for instance, an install with a TTI of 8 hours: can we conclude with certainty that we are dealing with fraud? No, we can’t, since it might be both, a non-fraudulent install and modified click spam.
Or let’s take an install without any post-install activity: here we also can’t make a definitive conclusion, since it might be either a non-fraudulent install, bots or device farms.
3. Another drawback of a “preventive” approach is the irreversibility of its decision. If a decision is made, then it can’t be changed. This problem also prevents the traditional anti-fraud solution from providing a retrospective analysis, which can be extremely helpful in the identification of “shredded traffic” - a tactic of fraudsters designed to hide any sign of fraud.
4. The inability to conduct post-install events analysis. This is one of the most critical flaws of fraud prevention. Precisely the analysis of post-install metrics helps to distinguish a significant volume of different fraud types. As a result, with the fraud prevention approach clients can get a huge number of false positive and false negative decisions in two different ways:
a) Clients get very low completeness of fraud detection (recall). It means that with 10,000 fraudulent installs, the traditional anti-fraud solution will reject about 1,000 fraudulent installs (and will approve 9,000 remaining installs). Along with this, the accuracy (precision) will be quite high. However, in such a format only the most obvious fraud types can be identified, potentially detecting a very small share of the real fraud volume.
b) Clients get a very low accuracy (precision) and an average level of the completeness (recall). That is, out of 10,000 fraudulent installs, the traditional anti-fraud solution will reject about 3,000 fraudulent installs (and will approve 7,000 remaining fraudulent installs). And, at the same time, 3,000 non-fraudulent installs will be also rejected (6,000 - total number of rejected installs). In the given scenario, with a higher level of fraud protection, the true picture of ROI-efficiency during traffic purchases is distorted.
"Real-time" means that anti-fraud solution has only a couple of minutes to make a decision whether install is fraudulent or not. Such an insufficient time for analysis makes the results much less accurate, which leads to the critical distortion of ROI and ROAS metrics
How Scalarr solves these issues
1. Scalarr analyzes fraud both on the level of each install and on the level of install cohorts.
2. The decision model is based on machine learning by applying thousands of data points, hundreds of features and numerous relationships between them.
3. The existing working scheme with publishers tolerates a 48-72 hour lag in feedback regarding traffic approval, which gives an opportunity to collect a certain volume of installs and therefore show more complete and accurate results.
4. Scalarr applies personally trained decision models for every app to significantly increase the overall protection level since fraudsters are not able to use all individual metrics and features of every specific app or game.
5. We are currently developing ensemble/cascade fraud identification models, which will soon allow staggered delivery of fraud analysis results. This will further accelerate the feedback and optimization of advertising campaigns for user acquisition managers.
6. The team of customer success managers conducts all negotiations with publishers on controversial issues of rejects almost completely independently, freeing up time for mobile marketers.
Thus, Scalarr clients can get completeness and accuracy (up to 97%) of fraud identification several times higher than those of traditional anti-fraud solutions. At the same time, Scalarr’s system requires minimal input from user acquisition managers, so they can focus on more important tasks.
As we discovered above, the idea of “real-time app install ad fraud prevention” is usually presented incorrectly, since only SDK-integrated solutions are technically able to reject perceived fraudulent installs. However, such the real-time prevention approach often features a high rate of false positive and false negative errors and makes it impossible to conduct a throughout analysis of post-install events.
The general principle of “mixes” grounds on the conscious use of several various types of fraud to get over the known protection measures of fraud ...
Fraud is an adaptive crime, so it needs special methods of intelligent data analysis to detect and prevent it