Yonatan Komornik, Author at Singular

Can click validation solve the problem of app install fraud? (Big hint: no!)

Recently, we’ve seen some noise about click validation, claiming that this will solve the mobile app install industry’s problem with fake users. Sadly, this is far from true.

In fact, there are far better tools to fight fake users, and click validation is one of the worst. Read on to learn why.

TL;DR

Click validation requires an almost-impossible level of adoption to to be effective across all channels.
There are better tools to fight click injection/spamming, ad fraud, and fake users.
Click validation is not useless, but there are more effective options and better ways to spend time and energy.

Click validation: what it is and how it works

In a recent white paper, a competitor claimed that a leading cause of fraud (I would call it an enabler, not a cause) in the industry is that there’s no proof of actual user engagement when a click is reported to an MMP. The white paper also claims that server-to-server clicks remove some of the data and make it harder to spot fraud.

Fraud is a significant problem. Get Singular’s recent fraud prevention report.

These things are definitely true. And their purpose with click validation is to solve these problems by introducing a new mechanism.

Here’s how it would work:

When an ad network serves an ad it would also fire an “Impression Proof” callback to the mobile measurement partner (MMP). Each impression will get a unique ID and the proof will be authenticated by the MMP in some way.
When the user clicks the ad, the click callback would also include that impression ID.
Validation would be performed by doing the following:
- Make sure an impression with matching ID and parameters (for example, device ID) was provided beforehand.
- Make sure the impression didn’t cause too many clicks.
- Optionally, do further statistical analysis to look at the time between the impression and the click, and potentially other parameters.

The claim: Click validation done this way would make app install fraud impossible … or at least very costly to do.

Let’s analyze different properties of the proposed click validation mechanism to spot its strengths and weaknesses.

Let’s start with the big one: Adoption

First, let’s look at ad networks. Pretty clearly, effective click validation requires support on the ad-serving side.

Let’s assume for a moment that click validation is in fact a silver bullet for fighting fraud in the mobile advertising space. Even if that’s true, it would still require all networks and affiliates to implement the feature.

Unfortunately, that’s next to impossible, unless this becomes a standard in the industry.

Findings from Singular’s 2019 mobile attribution fraud prevention report

Fact is, any given MMP’s weight and reach are limited and they would likely only be able to enlist a few quality ad networks who are already actively fighting fraud to work with them. That’s great … except that it means that customers are left open to fraud by all of the other networks in the industry. And if that’s the case, then all MMPs would need to work together to create a standard around click validation.

That alone would force the majority of clean ad networks to implement the solution.

Since this is not currently the case, marketers need to ask themselves what do they stand to gain by leveraging click validation. Currently, it probably only means that they can trust those networks which they already trust a little bit more. That’s not huge value.

Secondly, what about affiliates?

One big hole that click validation fail to address is affiliates and sub ad networks. There’s no solution for cases where the party serving the ads is not the actual network integrated with the MMP. And that would create a unique — and potentially dangerous — situation where these affiliates would actually be trusted just like the network itself (given keys and data).

Or, their impressions would not be verifiable at all, creating a data black hole.

What about click spamming? Can click validation stop it?

The white paper claims that click spamming would now be impossible as “the attackers cannot control the ad serving process.”

This is a big assumption about the parts some networks and affiliates play in some app install fraud. Singular has found more than one case where the ad-serving entity’s SDK was the one to include click injection and spamming code. In addition, these fraudsters had API endpoints supplying tracking links upon request to specific devices, apps, and other parameters.

Additionally, fraudsters do not need to control the actual ad-serving process. Often, they can just rely on the existing process by creating clicks for ads that are served but are not shown or not clicked.

The white paper then also claims that “Click spamming would be made impossible by the same principle, requiring an unviable amount of corresponding impressions with realistic click-through-rates (CTR).”

Here, there are two possible cases:

The attacker does NOT control the ad-serving process
In this case, creating a realistic CTR would indeed be harder for the fraudsters. But in such a case it would actually be easier to just compare the number of impressions reported by the network and the number of clicks reported by the tracker.
The attacker DOES control the ad-serving process
In this case it would be pretty easy for the attacker to create a realistic CTR as they would just game the impressions.

Realistically, there are better tools for the job.

Click spamming is usually used to poach organic users, claiming credit for installs that would have happened anyways. Singular provides Organic Poaching Prevention on Android which renders click spamming campaigns ineffective. (Plus many other fraud prevention tools on both Android and iOS.)

Conversion rate (CVR) is also a great tool for spotting click spamming at scale. Marketers don’t really need super-fancy mechanisms for stopping high-scale click spamming attacks. A simple look at conversion rates can and should be enough. Any source with less than 1% CVR should probably not be trusted.

Finally, as stated previously, comparing network data to MMP data can also help in spotting these cases. (And, by the way, Singular makes this extremely easy by putting all of the data in one place!)

And click injection … can click validation stop that?

Well, let’s start this section by assuming that click injection is still a problem. (It’s solved.)

The white paper claims that click injection is done by listening to “app install broadcasts and firing the click in between the broadcast and install completion.” It continues by claiming that “logically it’s impossible that the user was served a matching ad and clicked it within the same second that the app install was broadcasted.”

This assumption about how click injection works has been invalid for more than two years now.

Fraudsters have long ago found better methods than relying on the install broadcast and can now spot installs before they happen or at the same time the user presses the install button and the app starts to download. In both cases, that means that most of the time, attackers will have ample time to “serve” a new fake impression and then report a click.

Again, there are better tools for the job. Click injection is a problem that is present only on Android, where it’s solved by utilizing other mechanisms such as Google Play Referrer and its timestamps. (And yes, Singular does so very, very effectively.)

So, can click validation solve the problem of fake installs and fake users?

The white paper says that “spoofed users would require spoofed impressions for their clicks, either dramatically increasing the amount of data to be fabricated, or making it downright impossible to perform – as the attackers cannot control the ad serving process.”

Sadly, this is not true even if you assume that the fraudsters are not controlling the ad serving.

In fact, fraudsters can just serve ads and fake installs when they see an ad matching their faked “inventory.” In addition, they can also learn how to query ad-serving entities and make them serve them matching ads.

I’ve personally seen this happen before … even on the biggest Tier 1 networks.

So no, click validation cannot stop fake user attacks. And, to be clear, it’s pretentious to claim that it can. Once again, there are better tools for the job. Many tools, in fact.

Ready to go deeper?

Here are three ways to go deeper and get started on the process of eliminating fraud — and fake users — from your app install campaigns.

1. To learn more about those better tools, please refer to our recent blog post to read about the different methods and their pros/cons.

2. And, check out a short report with data from customers using Singular’s Fraud Prevention solution.

3. Even better? Get a demo of the solution first-hand.

Fixing a $13B problem: How Singular is killing app install fraud

You probably saw the news that we released last week: deterministic Android app install validation. This, along with a number of other improvements we’ve recently made, is a massive industry breakthrough that is completely game-changing for many of our clients.

Some of them are now saving massive amounts of money:

“Singular’s updated Fraud Prevention suite is the most powerful mobile app install fraud prevention I’ve seen,” says Channy Lim, Head of BI Department at Com2uS, maker of the hit mobile game Summoners War. “This will save us literally hundreds of thousands of dollars every month, and lead us to make more effective marketing decisions.”

The news is exciting, but I wanted to dive a little deeper.

I would like to share a little more detail about how app install fraud works, the problems with existing methods of finding it, and what we doing differently at Singular.

How app install fraud works

One of the ways fraudsters steal billions of advertisers’ dollars annually is app install fraud. Or, to put it another way: fake installs.

App install fraud is a collection of fraud methods that create fake mobile users and app installs. As opposed to attribution manipulation fraud, which steals credit for existing legitimate app installs, app install fraudsters take matters into their own hands and create app installs out of thin air.

There are multiple ways to perform fake installs fraud, and naturally, some are better than others.

The simplest and most low-tech way is a device farm. You get a bunch of devices, click a lot of tracking links, install a lot of apps, then open them, delete them, and reset each device’s Advertising ID (Android) or IDFA (iOS). Rinse and repeat regularly, and you’re collecting ad dollars.

But there are far more complex and advanced ways to perform fake installs that generate a lot more money far quicker.

One of the other ways fraudsters scale up their device farm operation is to use emulators and bots instead of real devices and real human beings who use the devices. This can be done in the cloud, and potentially on multiple servers in multiple locations, to try to look authentic.

One of the most notable techniques leveraged by smarter fraudsters is SDK spoofing.

Mobile marketers place software (an SDK) from a Mobile Measurement Partner (MMP) in their apps to monitor and measure the results of their marketing. In SDK spoofing, no app is ever actually installed … but an install is being reported to the MMP and potentially other analytics providers by faking the SDK’s traffic. This can be done by technically advanced fraudsters who understand how communication with the measurement service works and how to emulate that communication.

This is far more scalable than running a device farm, because once they have done the initial work, they can create a script to run on servers around the globe. That creates fake installs on fake devices. Alternatively, they can write code that can run on legitimate users’ devices anywhere, reporting installations of apps that have never been installed: fake installs on real devices.

Another example comes in the form of malware, where malicious apps install and run legitimate apps on real users’ devices. This happened for example with the Viking Horde malware. In such cases the user is real and the app is real but the install itself is fraudulent.

As fraudsters become more advanced they tap more and more into the power of the high-tech fake install techniques, and for good reasons. These attacks are highly scalable and hard to find, therefore netting the fraudsters huge amounts of money.

Detecting and preventing fake installs is hard

There are multiple ways to detect fake installs. The problem is that many are unreliable, inaccurate, and most importantly, ineffective.

SDK Message Hashing
Since SDK spoofing aims to fake an MMP’s SDK traffic, MMPs (including Singular) protect each message sent from the SDK. That’s typically done via hashing: taking the data from the message, a secret key that is different for each app, and combining them to create a blob of data that can be verified on the MMP’s backend.

The problem is that the secret is not so secret, as apps that run on users’ devices can create these hashes, so SDK fraudsters can extract the secret and algorithm from the publicly available app binary. At times they don’t even need to reverse engineer the algorithm since the SDK is open source.

Abnormal numbers of new devices
One interesting statistical technique to fight fake install fraud is to look for a high percentage of brand-new or never-before-seen devices coming from specific ad networks or publishers. When you see abnormally high ratios, it’s generally clear that something fishy is happening.

The problem however, is that fraudsters sometimes leverage existing devices or mingle their fake traffic with traffic from real devices, making it harder to spot anomalies.

Abnormal retention rate or other KPIs
Marketers can sometimes identify fraud by seeing abnormal rates of retention, in-app purchases, or other KPIs. For example, if your average retention is 15% on D14, but installs from a particular campaign, publisher, or network show a 1% retention rate, it’s clear that there’s something that deserves further investigation.

But Singular research shows that fraudsters have learned to fake retention and post install events/purchases.

For example, Singular uncovered a case of extremely sophisticated SDK spoofing campaign on iOS that fools most fraud prevention solutions in the industry. The fraudsters not only generated seemingly legitimate app installs but they also continued to send post-install events, in essence faking real users’ activity. They have even tried reporting in-app purchases, and while doing so reported revenue receipts for these fake purchases.

Sensor data and user behavioral analysis
Sensor data based solutions take post-install fake user detection one step further. These solutions try to detect abnormal devices or users by looking at non-marketing data points such as device movements (via a smartphone’s accelerometer and/or gyroscope), battery data, and user-screen interaction.

How?

Simple: sensor data for real devices should look different than simulators that don’t move.

The challenge is that this can be faked as well as shown in the huge “We Purchase Apps” scandal revealed in October 2018. In this massive ad fraud campaign the perpetrators bought real apps, studied the usage patterns of their real users, and then created fake users coming from those same apps.

One of the biggest targets of this campaign was none other than Google itself, the company who has probably put the most effort into profiling real user activities and protecting advertisers from fake user emulation.

And more …
There are multiple other methods, each of which has its strengths and weaknesses.

The problem with post-install fraud determination

While post-install methods do an important job of raising the bar against fraud they have some inherent caveats that stop them from being effective fraud prevention tools.

1: Statistical (in)significance
Post-install methods are statistical tools that work by looking at groups of installs and checking if one or more of these groups exhibit anomalous activities. Usually these groups would be installs coming from the same publisher. For example, when looking for new devices it’s unsurprising to see a legitimate user with a new device, as new devices are constantly being sold to consumers.

However, for a publisher driving thousands of installs, seeing 95% of those installs from new devices should be highly suspicious. Fraudsters have figured out that they can’t be so blatant, and so they take action and hide. Some drive their traffic from many different publisher IDs and even networks to keep numbers low; some mix their fraudulent installs with legitimate installs to make the anomaly less apparent.

Utilizing such techniques allows fraudsters to avoid detection by making the anomalies statistically less significant, making it a lot harder to distinguish legitimates traffic from fake traffic and so making it harder to stop the fraudulent activities without incurring high false positives.

2) Post postback friction
As the name suggests, post install methods only come into effect after an install has happened, and might be processed days or weeks after the install. That also means that they are evaluated after an install postback is sent to the media source, which means after conversion and billing notification in CPI campaigns.

The result is that the media source will charge for the now-known-to-be fraudulent conversion … unless a process of reconciliation is done. This process is often manual, messy, and a cause of great friction between ad networks and advertisers.

3) Non-optimized optimization
Ad networks often perform real-time optimizations based on initial success analytics: evidence of conversions such as app installs. Now, however, those optimizations will be skewed by fraudulent activities.

In effect, having been rewarded by fraud, they will now optimize for MORE fraud.

As an example, if publisher A drives more installs than publisher B for some advertisers, the network might prefer to prioritize publisher A over publisher B and send more ads its way. Now imagine publisher A is actually driving fake installs which are not prevented in real time (as happens in post-install detection). The network will funnel more budget to A over B.

Even if those fraudulent installs are detected post-install and reimbursed, the damage has already been done and goals will not be met because of the optimization changes and budget shift.

Singular’s solution: deterministic pre-attribution fraud decisions

Singular strives to have no false positives. We want to clearly identify fraud at a granular level. So Singular’s fraud results apply to actual individual installs, devices, and users, not blanket-level sources or publishers (although we can – and do – block those too).

We also want to find fraud as conversions or installs happen.

Anything less will suffer from the problems outlined above.

When we took time out earlier this year to consider everything, it was clear that we needed a different approach here. We needed something that would work in real time — install-time — and have an extremely low false-positive rate while still maintaining effectiveness.

To meet these requirements, we decided to disregard everything we thought we knew about ad fraud and look for something new. As we reported publicly last week, after an exhaustive search we found what we believed would be a high-quality deterministic fake install detection method that works at install time.

The new method we discovered depends on signals from the install device that allow us to verify that a user exists, they truly installed the app from the store, and they haven’t installed the app an unreasonable number of times (sorry-not-sorry, fraudsters who “install” an app on a phone hundreds or thousands of times).

Of course, once we found this method, we knew we needed to validate that it works as expected at scale, in the real world, on thousands of ad networks. To do so we tested with some of the most successful mobile publishers on the planet. And we validated our results against post-install metrics.

The actual implementation of our new fraud prevention method proved to have a tremendous effect on some of our customers, eliminating their fake install problem. (Find more about it in our report.)

In a later blog post we will share some more details about our findings, but it’s safe to say that we were blown away by the scale of the fraudulent activity we’ve found, and as more and more customers utilize the feature, the numbers are only going to grow.

Interested in learning more? Schedule a demo to go even deeper.