When it comes to fraud in mobile marketing we think it’s important to understand which vulnerabilities each fraud technique abuses, how it works, what are its consequences, and how it can be detected. 

In the subject of attribution manipulation we’ll focus on two opposing types of fraud that both revolve around the abuse of the way attribution technically works (i.e, by faking attributed installs by taking over organic or other paid installs).

Click spamming is a technique that abuses the last touch attribution model in order to “steal the credit” for an install. The most commonly used attribution model is ‘last touch’, in which the latest UA partner who was attributed with a click on the ad that preceded the install will be attributed with the install, assuming the attribution window is still open. In short, the last click on an ad before the install will be credited for the install. 

Click spamming happens at the time of an ad impression. It can be an in-app banner ad or a pixel “ad” on a webpage. Once there’s an impression, the ones conducting the fraud trigger a series of clicks (20 or even 30 clicks), as if there were multiple ads being displayed to a single user and all of them were clicked. This process is called ad stacking. 

In the next stage of the process, the app store opens. Since the ad wasn’t originally clicked by the user, this happens in the background without the user’s knowledge, and all of these clicks are registered for future attribution purposes, but there’s no install, yet. 

Click spamming works on assumption, and targets click to apps who are likely to be installed organically by large groups of users (apps who have a buzz around them, new services, apps that new devices tend to install, and more). 

What happens eventually is that users install after the ad was ‘clicked’, and the spammer gets attributed for the install. It’s guesswork, but imagine the probability of running 20 to 30 different clicks (for popular apps) per a single impression. You’re bound to ‘win’ some installs. 

Click spamming hurts almost all sides involved in the ad serving process – the advertiser, legitimate UA partners (ad networks and DSPs), and the users. 

If your app is the targeted app (i.e, you’re it’s advertiser), it means you end up paying for your organic installs. One of the most infamous cases where a company claimed they’ve been paying for organic installs is Uber, in the case of Uber vs. Fetch. 

Fetch was Uber’s ad agency, which means they hired and handled the ad networks that ran Uber’s paid ad campaigns. Uber claimed that Fetch hired ad networks who used click spamming, resulting in Uber paying, both Fetch and the ad networks, for installs that were attributed to the ad networks, but in reality originated in organic installs. 

Fetch, on the other hand, claimed they work tirelessly to minimize fraudulent activity and that Uber’s invoices went unpaid for months.

While there seems to be some additional tension between these two companies, click spamming is a well-known issue in the industry, one any UA and Growth manager should be aware of. 

According to a report by AppsFlyer, $20.3B in ad spend was exposed to app install fraud in the first half of 2019 with 22.6% of non-organic app installs globally are currently identified as fraudulent. 

An app store ranking is decided based on multiple factors that differ between the stores. One of the deciding factors is the ratio between store visits to installs, if the conversion rate is lowered over time (i.e, a lot of users open the store but only a few download the app) the store’s ranking will decrease. If your app is subject to click spamming this means that even your store ranking will be negatively affected.  

The second party to get hurt by this technique is the trusted UA partners. A partner that ran an honest, fraud-free campaign might have been losing it’s view-through attribution window (an impression that preceded the install) to click spammers. 

View-through attribution windows are significantly shorter so as to only be counted when they can actually be considered to have led to an install. If a click occurs while a view attribution is still open the click “wins” the attribution (even if the impression occurred closer to the install). This means that even if the impression from the trusted ad network led to the install, the click (that occurred without the user’s knowledge or intention) will be attributed for the install. 

For some users, data plans are billed by usage (instead of a monthly package). This means that in devices that are subject to click spamming, the increase in data usage will be costly since opening the app store for 20 clicks per ad takes a fair amount of data usage, for people whose data is a limited resource, click spamming can lead to a lot of frustration, as it can’t be easily ascertained that it even occurred.

There are a couple of KPIs that should be tracked and monitored to rule out click spamming. 

In click spamming, the conversion rate (click to install) will be low, and in many cases extremely low (0.01%-0.05%) since there will be a whole lot of clicks but a relatively minuscule amount of installs. In past occurrences where we helped our partnered advertisers detect click spamming, we saw examples like ~2,000,000 clicks and ~300 installs (0.015%), and the conversion rates were sometimes even lower.  

The CTIT (click time to install) will be longer. There are benchmark CTIT to compare to, but our recommendation is to take them with a grain of salt. Benchmarks vary between apps, and the best thing to do is to compare it with other campaigns for your own app if you can.

And lastly, in click spamming, as soon as a new click spamming ‘source’ is added to your buying, you’ll see a decline in your organic installs, because, at the bottom line, those are the installs that click spamming targets and hurts the most. 

A LAT environment makes fraudsters’ life easier, since attribution tracking relies on fingerprinting, instead of relying on device IDs, rendering it probabilistic as opposed to deterministic. If click spamming is executed on a device with LAT enabled, anyone on the same IP address who organically installed the app will end up attributing the fraudster with an additional install. 

The lack of a deviceID in a LAT environment makes it harder to track the connection between a click and an install. Having a lot of devices on the same IP address and tracking an already popular app, means it might have just been installed organically by a different device than the one with the open click attribution window. 

Without click spamming, fingerprinting is estimated to be 98% accurate when the time between the click to the install is 10 min or less, but as time passes the likelihood that the click and install actually originated from the same device, decreases. 

“As the time between click and conversion increases, fingerprint attribution becomes increasingly inaccurate. After three hours, accuracy drops by 85%. At the 24-hour mark, it drops to 50%; and beyond that, fingerprint attribution is more likely wrong than right.”

Grant Simmons, VP @ Kochava Foundry, “Your Attribution May Be More Wrong Than Right

Keeping in mind the inaccuracy in fingerprinting (especially the longer the CTIT is) and adding click spamming, means UA managers need to be especially careful and monitor their LAT sources, always suspect inflated click volumes, and have a minimal understanding of how those sources generate these clicks. 

As an advertiser, a good precaution would be to limit your fingerprinting attribution window to decrease the chances of click spamming in a LAT environment. Granted, this is hard to detect, but if your UA partner runs both LAT and non-LAT in-app campaigns and in both cases can’t provide you with device IDs, it should raise your suspicion and lead to further questioning, as there are very little (if any) legitimate reasons to not use deterministic attribution where it’s available. 

Click hijacking differs from click spamming significantly. It can only occur in-app, the hijacker has to have it’s code natively on the device (either through an app or an SDK), and it’s much more targeted in its nature. While click spamming is about sending massive amounts of clicks for different apps hoping to catch a few, click hijacking is very specific and hijacks already-clicked ads. 

Once the infected user clicks the app store button to install an app (whether he got there organically or through a paid click), the fraudster recognizes it, checks if he has access to a campaign promoting the app that’s about to be installed, and hijacks the click, resulting in the fraudster being attributed with the install. 

The vulnerability that’s taken advantage of in click hijacking occurs much earlier compared to click spamming and comes from the core – the app stores. When a new app is submitted to the app store it must go through a review process/ approving new apps to be added to the store.

So far, some fraudsters were able to pass this barrier on both platforms, but in an ideal world, more thorough testing would be done at this stage, and hopefully all, apps containing malicious software would be detected and banned. 

One by one, several different aspects of the advertiser’s UA efforts are affected. First, click hijacking hurts the app developer in a very clear and deliberate way, similarly to click spamming, organic installs are written off as paid installs which means the advertiser is paying for something he already owns., but there’s more to it. It completely obstructs setting the app’s marketing KPIs. The fraudsters’ results might look good on paper, but it won’t represent actual performance, and will simultaneously hurt other partners’ performance. 

If other UA partners are targeting relevant users for your app, but are not successfully converting them (since those installs are being hijacked), their performance report is off as well. Their campaigns are underperforming, their CAC (customer acquisition costs) are higher, and they’ll try to optimize and improve while running on false, manipulated data. 

This leaves advertisers confused. The fraudulent campaign will thrive while the non-fraudulent will underperform (since those installs are hijacked). If the underperforming campaigns are paused, the fraudulent campaign will see a decline as well (since the performance of the hijacked campaign is directly reliant on the work of other campaigns), but might still not clear the air and reveal the hijackers. 

Whether or not it’s done consciously, the ‘host’ app (which enables click hijacking) gains from this fraud. As many installs are generated for the ad placements inside it, as the hijackers usually only trigger their malicious code in some percentage ratio of all impressions (something like 1/10 or 1/15 impressions is hijacked, for example), it can still be labeled by legitimate bidders as a prime ad placement for user acquisition, which means it would get higher CPM bids for its inventory. 

In click hijacking, your CR will appear to be high (since these users are prequalified), while the CTIT would be low (since the hijacker is attributed with the click right before the install occurs). If your attribution platform offers some form of user journey tracking you’ll notice the fraudulent company constantly popping up between other UA partners and their installs. 

A famous case of a malicious SDK is the Chinese company Mintegral that allegedly disguised itself as a tool to help app developers and advertisers monetize their apps ‘effectively’ with ads. It was discovered that the SDK allegedly had malicious code within it that worked to steal potential revenue from other ad networks. 

Mintergal made it harder to detect their alleged fraudulent activity. Instead of supposedly hijacking the attribution of all the clicks, they would only hijack one out of ten, making it seem like an ordinary ad network activity. 

Another case that was made famous back in 2018, named two Chinese companies – Cheetah Mobile and Kika Tech. In the article published by Buzzfeed, it was claimed that these companies used their SDK across different, self-owned, wildly-popular apps in order to perform click hijacking. 

Their activity was discovered by Kochava’s attribution platform. 

If you have cause to suspect click spamming or hijacking from a new UA partner, take a better look at your campaigns’ ad placements. Both of these attribution manipulations tend to use ‘hardcoded placements’. 

If your data indicates a few repeating well-performing placements over long periods of time, it might be hardcoded and fraudulent. In reality, many new ad placements are created on a daily basis as new apps are released, and you should expect a healthy dynamic nature in the placements that are prominent for your UA campaigns in the in-app ecosystem. In some cases, in click spamming, the ad placement will indicate an app that doesn’t even run ads, so double-check for that as well.

Monitoring your campaigns under falsely calculated CAC is a problem in and of itself, but the issue is much bigger when it involves investors, people outside your organization, operating under false assumptions regarding the app’s growth potential. 

When your app’s paid acquisition data consists of many organic users falsely claimed as acquired ones, your costs seem lower than they actually are, and funds raised under these assumptions won’t pay themselves back over time, as the growth potential of the product itself isn’t what it seems to be.

This means that if you’ve raised capital, your app grew, your team grew, and your acquisition investments grew as well, but in the end, the expected results weren’t delivered and the investment was deemed to be a failure. 

In the worst-case scenario, this will result in new hires being laid off, shrinking teams back down, losing not only the funding, but the trust of the investors, which will also lead to negative public coverage, and more. 

An app with actual potential can still be a victim of mobile fraud, and though it had everything it needed to become a success, the mishandling of UA in the early stages of the app could’ve hurt in an irreparable way. 

• Due Diligence – ask your UA partners the hard questions – how they target, ask to learn more about how their SDK works, and their ad units, and get familiar with their process. In this day and age offering transparency is basic and DSPs should be able to make their information accessible to the advertiser. Not getting definite, clear answers should raise a flag. 

• Adjust Your KPIs – make sure your organization is setting the right KPIs for the UA campaign. Some organizations are still focusing on volume instead of quality (i.e install volume vs. active and engaged users, depositors, etc’.) By focusing solely on volume and not testing the quality of the users, you essentially attract possible fraudulent activity to your app and hurt the overall performance of your app (getting a lot of new users who open once and never come back means lower retention rates.) 

• Monitoring and Tracking – Keeping track of your user base, shifts in the percentage of organic and paid users, shifts in overall app performance, etc’ can serve as great indicators of malicious activity. In both click spamming and click hijacking you’ll see a decline in organic installs. Though a more substantial hit in organic installs will most likely be detectable in click spamming. 

Since these are attribution-related manipulations there are two key partners who can help avoid, prevent, track, and recognize the fraudulent activity. 

Different attribution platforms offer different tools to track fraud and notice abnormalities in the data. Taking the time and choosing the right attribution platform for your app can help with the early detection of fraud. 

Choosing a trusted and reliable DSP. Our glossary entry choosing a DSP covers the different types of DSPs and which mobile growth opportunities they offer. Adjust also wrote extensively about choosing a DSP. 

As we’ve mentioned before, as we steer further from ad networks and transition to programmatic and ML-based campaigns, transparency is a basic expectation from a UA partner.