In this series, we debunk some of the myths which help convince marketers they don't have a fraudulent app install problem.

In the first instalment, Gary Danks looked at misconceptions over in-app performance, click volumes and scale. In the second, Hannah Graham delved into the various chinks in the supply chain – the regions, the networks and finally the publishers themselves.

In this third part, we review the flaws in current methods of app install fraud prevention, and uncover why they are leaving advertisers unknowingly vulnerable.

Myth #1: I’ve got several fraud rules in place to manage app install fraud across our campaigns. I don’t need to worry.

For some time now, advertisers have been working to reduce the number of fraudulent app installs occurring across their campaigns, by implementing probabilistic rules. For example, disputing all installs from publisher with an install rate over 10%, or disputing all installs from a publisher with a click-to-install rate of under 0.05%.

Of course, by not paying for installs that break these publisher-based rules, some fraudulent installs will be caught – and, better yet, not paid for. However, without using advanced data sets to analyse each individual install, these rules will only ever catch a fraction of fraudulent installs.

This is because these rules make broad assumptions about publishers and apply a one-size fits all approach to fraud detection. With many sub-publisher IDs encompassing multiple sources, advertisers utilising broad publisher-based rules can actually end up blocking genuine and valuable traffic.

By applying a deterministic approach to app install fraud analysis, Machine has increased the volume of fraudulent installs detected across campaigns by an average of 70% versus a traditional publisher-based rule methodology.  

Myth #2: I dispute any install that delivers with a click-to-install time of under 15 seconds. Click Injection isn’t a concern for me.

For many of the advertisers that we speak to, a click-to-install time below 15 seconds (or sometimes even 10 seconds) is deemed too fast, and a sign of click injection or install hijacking. We fully agree – 10-15 seconds is definitely too fast for a legitimate install to take place. However, when we ask whether an advertiser has run tests to determine what the quickest possible speed to actually download their app is, the answer is almost always no.

Having carried out many of these tests at Machine, using different-sized apps across a variety of devices and connection speeds, we have found that it is not possible to click on an ad, go to the app store, download and install the app, and open it in less than 30 seconds as an absolute minimum – and often much more time is needed.

It’s for reasons like this that rule-based app install fraud detection is not a reliable approach, even when looking at installs on an individual basis.
 

Myth #3: I’m buying on a CPA/CPE – I don’t have to worry about fraudulent app installs because I only pay for completed in-app events.

This is one of the most common misconceptions among marketers running app install campaigns. It’s understandable – why should you worry about fraudulent installs when you’re only paying for those that convert?

Unfortunately, paying out only on a post-install conversion basis does not provide any protection for advertisers’ marketing budgets, as conversion events can be fraudulently generated as easily as the installs themselves. There are plenty of ways for the fraudsters to do this.

Via attribution theft – whether utilising click stuffing or click injection – fraudulent sources can effectively steal attribution for organic installs and then get paid out on the inevitable in-app events, driven by genuine users who would have downloaded and used the app of their own accord.

Install farms are constantly evolving and becoming more sophisticated, with a stronger focus on driving post-install events, in a bid to appear more genuine in their user patterns.

And finally, there’s bot delivery, whereby programmes will not only imitate app install delivery, but go on to mimic app opens and usage on a regular basis in order to fake the converting event and mimic a valuable app user.