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

1. Click validation requires an almost-impossible level of adoption to to be effective across all channels.
2. There are better tools to fight click injection/spamming, ad fraud, and fake users.
3. 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.

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.

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:

1. 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.
2. 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.