Prevent Mobile Ad Fraud
The Fraud Console is a powerful, comprehensive suite of mobile ad fraud detection and abatement tools, including fraud detection analytics and the Global Fraud Blacklist. These tools give marketers the ability to monitor their traffic and eliminate mobile ad fraud.
The summary reports are a visualization of abnormal, potentially fraudulent activity from across a marketer’s apps. The charts are interactive—marketers can click on a portion of a chart to further explore the data and see a prioritized list of networks responsible for the activity in question.
Fraud detection analytics
The Fraud Console includes 13 reports that leverage statistical methodologies and pattern identification to flag all identifiable fraudulent tactics present in the ecosystem.
1. High Click Volume IP Addresses
Many customers currently focus on install rates, but high click volumes for IP addresses obscure campaign outcomes. Abnormally high click-to-install ratios raise a flag that fraud may be present. This can also be a leading indicator of issues with server-to-server click feeds. Either way, there is a problem to be solved.
2. High Click Volume Devices
A high volume of clicks from a single device is not typical user behavior and is a strong indicator of click injections from bots or hijacked devices. As with IP addresses with large click volumes, Kochava identifies these device IDs for abatement.
3. Mean-time-to-install (MTTI) Outliers
MTTI is the average time between the click and install and varies by app and network. For example, map apps have a very low MTTI—users download when they need to get somewhere. Games tend to have a higher MTTI—users download with the intention of playing, but it may take days before they launch the app. When MTTI varies greatly for a specific source—either too short or long—this indicates that something is askew.
5. Geographic Click / Install Delta
The vast majority of installs happen within close proximity to the attributed click. Kochava identifies statistically significant variances between the location of the click and that of the install. These variances may be indicators for fraud.
4. Time-to-install (TTI) Outliers
Time to install (TTI) is an important indicator of install validity. The time between click and install depends on physical factors (network speed, size of app binary, etc.) and behavioral ones (incentivized installs typically happen within a short time). Determine the mean TTI for your app on a given network and sub-publisher as a baseline from which to measure. The TTI Outliers view indicates potentially fraudulent traffic based on the baseline TTI and shows abnormally fast installs.
6. Platform Click / Install Mismatch
When ads are repeatedly served to the wrong platform, there’s a problem. If ads for an iOS app are generating clicks on non-iOS devices, this may indicate that bot farms are generating fraudulent traffic. It may also show poorly targeted traffic.
7. Multi-Hash Attribution Matches
Networks and publishers often hash device IDs to provide a level of privacy. However, when IDs are hashed multiple times, it is an indication of rebrokered traffic. If this is done transparently, it is of no concern. But if the traffic is purported to be exclusive, this may indicate fraudulent behavior.
8. Ad Stacking Clicks
This tactic is one of the easier forms of fraud to detect at the network/site level. This report indicates when multiple ads were clicked at the same time from the same device. Multiple timestamps strongly suggests click/impression stuffing or viewability fraud.
9. Anonymous Installs
If sites use anonymous proxies, VPNs and TOR exit nodes to hide their identity, Kochava blacklists them. Transactions should be transparent and a site taking measures to hide its identity is not trustworthy.
10. Non-Verified Install Receipts
For installs originating from the iTunes Store, Kochava receives an install receipt that can be independently verified. In cases where the installs are not able to be verified, Kochava surfaces these as fraudulent.
11. Non-Verified Purchase Receipts
Kochava receives purchase receipts for both iOS and Android purchases. Kochava validates these purchases against their respective store servers. Similar to Install Receipt verification Kochava surfaces unverifiable purchases as fraudulent.
12. Click Flooding
This type of mobile ad fraud occurs when a network or sub-publisher floods its channels with clicks until a user installs. Because of the frequency of clicks, the network/sub-publisher illegitimately receives attribution. This type of fraud is detected when clicks outnumber campaign installs. The view shows those networks and sub-publishers with an unusually high click-to-install ratio.
13. TTI Distribution
For most campaigns, the majority of installs occur within the first few days of launch and then trail off as the campaign continues. The TTI Distribution view shows the number of installs that occurred within a five-day window of the click or impression and also outside of it. This visualization highlights cases where there is an increase in installs with time, which is typically considered abnormal behavior.
Click fraud monitoring
Marketers can use the reports to take action with their partner networks and resolve any discrepancies. The Fraud Console reports focus only on fraudulent activity within the apps associated with the Kochava account. Enable the Global Fraud Blacklist for real-time fraud abatement against an aggregated list of all known fraudulent entities.
SDK Spoofing Protection
Fraudsters attempt to infiltrate all aspects of an ad campaign, including using SDK spoofing to try and send fake installs, purchases and other activity as if it’s being sent from the real app. It can be difficult to identify SDK spoofing without digging into campaign data, and even then relies on the fraudster making a mistake. SDK Install and Event Authentication, by Kochava circumvents this issue by validating that all traffic is actually sent from the SDK, rather than waiting for the fraudster to make a mistake. By using this tool, any spoofed installs and events are immediately detected by the Kochava system.
Marketers have two options in how to use SDK Install and Event Authentication:
- Strict: drops all unverifiable traffic, regardless of SDK version
- Lenient: drops unverifiable traffic for eligible SDK versions (Android 3.2.0, iOS 3.3.0, Windows 3.0.1 versions or greater)
Dropped installs and events are never recorded or attributed to paid media. This means you won’t have to worry about paying for fabricated conversions.
Activate the Global Fraud Blacklist
The Kochava Global Fraud Blacklist is a dynamic list of device IDs, IP addresses and network/site IDs curated from across the Kochava customer base. These are entities that have been flagged as repeat offenders of fraudulent activity.
Marketers can implement the Blacklist at the account, app or tracker level. At the tracker level, the Blacklist may be selectively enabled for IP addresses, device IDs, network/site IDs, or any combination of these. Marketers can also add device IDs, IP addresses and network/sites to their own account-level Blacklist directly from their account’s Fraud Console.
The Global Fraud Blacklist aggregates bad actors from across all Kochava traffic. Once enabled, Blacklisted entities are automatically excluded from attribution for any account, app or tracker for which it is enabled. Real-time fraud abatement with the Global Fraud Blacklist eliminates time-consuming chargeback conversations for marketers and costly make-goods for networks.
Fraud Abatement Series
Grant Simmons is Director of Client Analytics at Kochava. He is our resident expert on mobile ad fraud detection, and leads his team in analyzing campaign performance and business value assessments. Below is an in-depth series by him explaining the major types of fraud.
Part 1: Detecting Fraud by Counting Clicks
If marketers only focus on install rates, they’re missing the action behind the scenes. Fraudsters can employ a number of tactics to win attribution, resulting in an exorbitant number of clicks per install and wasted ad spend. Read More.
Part 2: Devices With High Click Volumes and Fraudulent Traffic
Devices that output a high number of clicks are likely the product of a bot or hijacked device. The fraud report for this tactic flags abnormally high click volumes, but marketers should also have their own baselines for acceptable volumes. Read More.
Part 3: The Fraud Behind Install Metrics
The time from click to install varies according to a campaign. However, abnormal patterns require further investigation. Differences in MTTI and TTI may show evidence of unwanted incentivized traffic or are indicative of poorer quality users. Read More.
Part 4: Ad Stacking
Ad stacking is a fraud technique where multiple ads are layered on top of each other in a single ad placement – with only the top ad being visible. If a user clicks on the visible ad, a click is registered for all ads in the stack. Read More.
Part 5: The Global Fraud Blacklist
The Global Fraud Blacklist acts as a firewall for campaign traffic. It is a dynamic list comprised of known fraudulent device IDs, IP addresses and network/site IDs. These are entities that are repeat offenders of fraudulent activity or exceed established thresholds outside of normal activity. Read More.
Detecting Fraud by Counting Clicks
Many, if not most, marketers run campaigns based on install rates. It’s proof that a user was obtained and that marketing efforts were successful. However, Kochava sees all user traffic, and the number of clicks per attributed install doesn’t always add up. While the reasons may differ—be it an error or bad actors—it’s unwanted traffic. Detecting fraud by looking at click-to-install rates is one part of fraud abatement among connected devices.
Our algorithms frequently flag an inordinate number of clicks per install, which increase your ad spend and skew a campaign’s true outcome. Over the next several weeks, we will explore several scenarios, and show marketers and networks how to interpret our fraud reports.
The following table details the click-to-install (CTI) rate across multiple networks for an entertainment app during the month of January:
We use CTI instead of conversion rate (CVR) because it’s easier to see the difference between 1,000 and 10,000 clicks than between 0.001 and 0.0001. What’s a reasonable response rate for a network’s traffic? In other words, how many clicks are reasonable for an install?
When we think of a campaign, we envision a creative ad unit with a call to action that hooks the viewer’s interest. Ideally, the user clicks an ad unit, visits the App Store, and installs the target app. If this was the reality across the advertising space, we’d see CTIs with ranges between 1 and 10—not in the thousands.
When an install occurs, the average CTI rate is close to 2.5. This varies by vertical: Social apps are a bit higher, gaming apps are lower. But the average across all apps doesn’t have a huge range; it is closer to two to three clicks per install. This likely fits with your own experience. Think of the last app you installed. Perhaps you clicked on an ad, visited the App Store, left and saw another ad later which compelled you to finally install (for a total of two ad clicks). You didn’t click 9,000 ads before installing.
High click volumes: What’s going on here?
Why are we seeing such high click volumes relative to installs? Are these user-driven clicks, or something else? Are they forced redirects? We’ve all likely been on our phones or tablets when we’re suddenly in the App Store with no reasonable explanation as to how we got there—it just happened.
Are these self-clicking ads or recorded impressions?
There are several reasons why click fraud monitoring is advantageous. The first reason for high click volumes could be self-clicking ads. Envision a video app that programmatically sends click activity in the background of the video, unbeknownst to the viewer. The second could be that the clicks being recorded are actually impressions. The latter may be the scariest scenario because it effectively takes the lowest intent of an advertising function (an impression that may engage the user) and calls it the highest intent ad function (a click, where the user engaged with it).
This last scenario becomes particularly problematic when it comes to web inventory because web ad units generally do not pass a device ID to match with an install, so a fingerprint match is used instead. The match is a combination of IP address and User Agent (device type, OS, version, etc.). If the ecosystem is flooded with spurious clicks, and the fingerprint attribution window is long, we can see a scenario where one user’s “click” can be credited to another user’s install.
For instance, let’s say the fingerprint attribution window is seven days. Over the course of a week, how many different IPs do we connect with? There are different IPs for home, work, commuting, the gym, restaurants, etc. Regarding the user agent, there aren’t many distinct UA combinations. An iPhone 6 with the latest OS update makes up a large population of mobile users. When one user with a relatively common profile connects to an IP address, where many other iPhone 6’s are connected, we start to see the attribution fallacy that encourages click flooding activity across the digital ad space. If a user clicks on an ad on his device, someone else may install it, and the network gets credited with that install—even though none of it was casual. The user never actually “clicked” an ad, and the actual user who installed is not tied to a paid marketing effort.
Here’s the point: If a network can get enough clicks flooding the ecosystem, they will pick up installs they didn’t drive.
What’s the big deal about attribution? Those installs happened—what’s there to cry about?
THE WRONG PARTY IS BEING CREDITED!
The game really becomes who can blanket the ad space with the most reported clicks. Forget about viewability. In many cases, the user doesn’t know there was an ad but took some action that generated a click in the background. And by blanketing the ad space with non-user-driven clicks, networks and sub-publishers are getting credit for installs that would happen anyway or are being driven by another source.
What should I do about attribution fraud?
If you’re a marketer, establish a baseline mean clicks to install (MCTI) so you know what to expect from your campaigns. Once you have a ballpark figure, leverage the Kochava Fraud Console which contains a comprehensive Global Fraud Blacklist for you to run with Traffic Verifier. From then on, all device IDs, IP addresses and network/site IDs on the Blacklist will be excluded in real time.
Also in Traffic Verifier, set frequency/volume caps for impressions and clicks. Any activity beyond the threshold is considered unverified traffic for you to decide whether to attribute or not.
Couple frequency caps with Alerting to know when a threshold is surpassed. Marketers can set up Alerts for a number of metrics and receive notification (email, SMS, Slack, voicemail) when a cap is reached in real time. Bad actors have many tactics, but Kochava tools keep marketers in control of their traffic.
Devices With High Click Volumes and Fraudulent Traffic
Our industry is increasingly wary of fraudulent traffic, but the use of fraud abatement tools is beginning to pay off. The Association of National Advertisers (ANA) recently released their latest findings on fraud, which actually showed a decline. Currently, they estimate that losses can reach $6.5 billion this year, down 10% from the $7.2 billion estimated for 2016. The results show an industry taking a stand against fraud yet the reality is that it is ever present.
“Despite the proliferation of mobile fraud detection mechanisms, bots continue to become more sophisticated and evasive,” said Michael Tiffany, CEO at White Ops, who performed the study on behalf of the ANA. He goes on to say, “as these declines are relatively modest, it’s critical that those affected by this threat remain vigilant.”
When reviewing Kochava fraud reports, network/site IDs with high click volumes are a surefire bet for fraud. Fighting click fraud requires close analysis of these because at first glance, the clicks may appear legit. Previously, we asked the question, “How many clicks are reasonable from a source of traffic?” We looked at site IDs with remarkably high click volumes and described what the fraudulent tactic might be behind them. Here, we’ll again look at unreasonably high click volumes but at the device level.
The following table details the top four Android device IDs by click count for an entertainment app during January. This marketer ran a campaign on over 10 networks during that month, and while most Android device IDs (ADID) had fewer than five clicks per install, some were remarkably higher:
- ADID 1: 61,221 clicks were reported during the timeframe. When we look at the network and sub-publisher breakdown, we see it all coming from one network and a single site ID.
- ADID 2: 48,327 clicks from the same network but two separate site IDs.
- ADID 3: 33,611 clicks from two separate networks but two separate site IDs.
- ADID 4: 23,037 clicks from two different networks than ADIDs 1 through 3 and two site IDs.
From this interpretation, we can make a couple of assumptions: Each ADID had unreasonably high click volume for the period, and the clicks were not user-driven. We often see this across multiple days for the same device.
What’s going on here? Where’s the fraudulent traffic?
For the devices listed above, we suspected the clicks were either generated from automated bots or hijacked devices. The bot was likely an emulator running on a remote service. If it was a physical device, it likely had behind-the-scenes malware installed that spawned clicks without the owner’s knowledge.
Note that in the fraudulent scenario no real ad or human is present. Instead, a hijacked device is programmatically spawning clicks back to an endpoint. This is probably not fraudulent activity focused on the marketer but rather the network itself (and likely not intentionally). Each of these devices can only install an app once, so if the marketer is paying some form of CPI (cost per install) pricing. A device bombarding clicks in hopes of driving installs has no monetary upside.
However, networks constantly seek new sources of traffic and are always on the hunt for new sub-publishers. The monetary arrangement between the network and sub-pub is likely different than between the network and marketer. And, the sub-pub may be selling traffic at a low CPM (cost per mille impressions), whereas the marketer is buying on a CPI model. The network pockets the difference.
We see the network’s challenge. As a marketer’s appetite for new installs grows, so must the network’s ability to satisfy it. Networks are constantly on the hunt for new traffic sources, and perhaps a sub-publisher promises lots of volume at a reasonable price—the network has to try it. However, malicious activity is generating the traffic.
In the example above, it’s possible the same bad actor is involved across all the networks and sites. We oftentimes see multiple networks and sites at the device level (like ADIDs 3 and 4), where multiple bad actors may be spread out over several networks. However, it could also be the same bad actor making the same traffic promises to multiple networks.
What can we do about click fraud?
Luckily, this tactic is easy to catch as the outliers are easy to spot. When we see tens of thousands of clicks at the device level, the remedy is obvious. Block that device, and let the marketer know. The less extreme examples are tougher to flag. Again, how many clicks per device is reasonable when it comes to advertising? 10? 100?
To deter click fraud, we allow marketers to cap the number of clicks at the device level. Where they set the cap depends on the app and campaign. There’s no magic number. However, marketers can determine a plausible baseline for their app and campaign because different user audiences will have different numbers of normal click volumes. And, in reference back to that BI article, be careful with cheap inventory as the risk for fraudulent traffic increases. Fraudsters may change bots and devices but they can’t hide their tactics. Detect mobile click fraud through high click volumes.
The Fraud Behind Install Metrics
We’ve detailed how the click:install ratio can be used to identify sketchy traffic. Here, we’ll look at install metrics, specifically the time difference between the user click and the install event, to illustrate some interesting fraud tactics.
Before we begin, however, ask yourself, “How much time is reasonable between clicking an ad and installing an app?” Or more importantly, “How fast is too fast?” To determine what’s reasonable, you need to know your audience’s behavior based on past campaigns. Some app campaigns may have faster click-to-install times than others.
Next, let’s lay some groundwork. There are several touchpoints in the chain of events from impression to launch. The user sees an ad, clicks on it, is redirected to the app store, downloads the app (generally around 45 MB) and launches (installs and opens) the app. This series of actions “wakes up” the Kochava SDK to begin recording post-install events. When we talk about time to install (TTI), we’re talking about the time difference between the click event and the first launch of the app.
We detect fast TTI outliers in a few different ways. The entire site ID (sub-publisher) may be driving traffic much differently than the parent network as a whole. We flag this as a mean-time-to-install (MTTI) outlier. However, the entirety of a site ID’s attributed installs may have a spread from short TTIs to long. In this case, the entire site ID isn’t problematic in terms of MTTI, but it may be flagged as a TTI outlier.
We need to dig a bit deeper to see what’s behind those outliers.
Within the attribution space, marketers and networks struggle to identify appropriate attribution windows because the answer changes from app to app. What remains consistent is the argument that mobile advertising creates interest and action where we expect the distribution of installs to be closer in time to the click event. However, sometimes we see the opposite, and install events increase the further they get from the attributed click. A flat or inverted distribution of installs from the click may indicate fraudulent traffic sources as well.
Let’s walk through a scenario for MTTI, TTI and flat/inverted separately.
Mean-time-to-install (MTTI) outliers
The chart below shows the distribution of site IDs in terms of average MTTI for a month’s worth of click and install data. In total, there were 139 site IDs within a network’s campaign trafficking ads for the month. We also see that generally, they have a normal MTTI distribution around 18 hours.
On the far left-hand side of the graph, there are three site IDs that have an MTTI under 30 minutes. There is something obviously different about those three sites relative to the network traffic as a whole. Within the Fraud Console, we flag site IDs greater than 2.5 standard deviations from the mean as potential sources of unrequested incentivized traffic. Incentivized sources of traffic benefit the user, such that their only interest in the advertised app is to get something for free, elsewhere. For instance, “Install this app and get 30 more gold coins for the game you’re playing,” is an example of incentivized traffic.
This doesn’t mean that all fast installs are fraudulent. If sites are incentivized, a quick check of post-install events will show whether the traffic is incentivized or something else. For example, an app has a registration event that entails the user submitting an email address and verifying via a separate link. If we look at 7 days from the install, the average across all traffic with this registration event is 15%. In this case, traffic from the three questionable site IDs has an average 1% of installs with the registration event. Not only is the click-to-install time much different than the average, so is the quality of the installs. This is clear evidence of incentivized traffic.
Conversely, sites with fast MTTI may look too good to be true in terms of install quality (when looking at post-install event usage). In this case, the site may be injecting clicks in order to win organic installs. We’ve seen this particularly in Android campaigns, where the fraudster is able to identify an imminent install and programmatically injects a “click” to win attribution.
As mentioned earlier, the entirety of a traffic source may not be a statistical outlier per se, but we may still detect fraudulent behavior. Let’s look at an example dataset of clicks and installs from a specific network of a finance app (Android) during December of 2016.
The table below details several different points:
- Installs are evenly stratified into TTI deciles: fastest 10%, next 10%, etc., in average minutes for each grouping of 10%
- Installs are broken out by device or Fingerprint matches (a proxy for in-device inventory vs. web inventory)
- Within each decile, a percentage of those installs with a specific post-install event (in this case, a sign-up event) is used as a way to measure install quality
- Device matches make up 7% of total installs for this network, and the MTTI through the 90th percentile is 315 hours
- For Fingerprint matches (the bulk of installs for this network), the MTTI through the 90th percentile is 7 minutes
- The time disparity indicates that the tactics/traffic from Fingerprints is significantly different than that from device inventory
Within the Fingerprint match table, look at the TTI increase from the 70th to the 90th percentile. In the course of 5,014 installs, the TTI increased 37 times, indicating the tactic/traffic is different even within the Fingerprint inventory.
Now let’s look at the fastest 10% of installs on Fingerprint-matched traffic. Again, the user clicks on an ad, is sent to the app store, downloads (in this case a 48 MB app) and launches it, but 5,577 users do so in 15 seconds? Let’s dig in a bit more.
Across all traffic sources, 12% of installs have the sign-up event. Let’s look at quality by TTI decile:
Device Match – TTI & Quality
This table shows that device-matched inventory is generally above average quality (although again, device inventory only made up 7% of the network’s total attributed installs). With the device-matched inventory, installs past the 80th percentile drop below the average quality (24 days). There is some room to narrow the attribution window for device matches, as the quality appears to decrease with longer TTI.
Fingerprint matches here show the opposite trend: The faster the install, the poorer the quality. In summary, the Fingerprint matches tend to be low quality and unreasonably fast.
In one month, there were 54,000 attributed Fingerprint-matched installs from this network; 20,095 installs occurred in under 30 seconds (37% of networks total install volume); 10,000 occurred in under 10 seconds:
Once we look at the network’s traffic by site IDs, we see that the percentage of traffic under 30 seconds varies:
We see here that all the attributed installs weren’t unreasonably fast–-only a portion were. In this case, these sites wouldn’t be flagged as MTTI outliers.
Conversely, we see instances where the quality for unreasonably fast installs tends to be on par with that of organic (unattributed) traffic. Here’s an example:
The installs again happened close to the reported click, but the quality was remarkably close to the average. The fastest 10% of installs occurred in under 13 seconds, and even the slowest installs (90th percentile) happened in under 3.5 minutes.
In this case, the questionable sites may have picked up a signal that an install was inbound, and the site essentially poached the organic traffic. This article details how that happens on Android traffic, but we have also seen it with device-match traffic sources for iOS.
Regardless, the time between the click and the event is unreasonably fast. It may warrant taking a closer look at the sites driving the installs and/or comparing TTI against your organic installs.
Flat/inverted install distribution
So far, we’ve looked at the click-to-install relationship outliers which appear unreasonably fast. Can the opposite be true, where the click-to-install relationship takes unreasonably long?
The graph below shows the click TTI distribution for a social app on iOS during the month of Dec. 16 through Jan. 17. Specifically, the chart details the time difference between the attributed click and the install for all networks during the period (27 networks, 2.7 million attributed installs):
From this table, we infer that:
- 79% of installs occurred the same day as the click
- 11% likely installed the day after the click
- After 6 days, users were 0.70% as likely to install as they were on the day of the click
Overall, we would call this a typical distribution. The user sees an ad, becomes interested and takes action within a predictable time frame.
However, the following chart details a single site ID during the same time frame. This site ID was flagged because it showed an inordinate volume that, from a quality perspective, looked like unattributed (organic) traffic. This site accounted for 72,000 installs (approximately 3% of the total installs for this period):
As you can see, the distribution is inverted: The user was 50% MORE likely to install 6 days after the click as they were on the day of. While there is no smoking gun here, the delayed TTI is a red flag for two reasons:
1. If the goal of advertising is to create an inflection in behavior, the delay indicates that’s not happening, particularly when compared to other site IDs. Marketers shouldn’t be serving ads on those sites.
2. This sub-publisher may be timing injected clicks to game attribution either by sniping installs or stuffing clicks. The publisher is flooding the advertising space with clicks to lay claim to organic installs or installs actually driven by other networks.
What should you do?
MTTI is part of the Fraud Console, and repeat offenders across multiple apps are flagged, blacklisted and excluded from future campaigns.TTI intra-site is also included in the Fraud Console.
What this all boils down to is how to make sense of our fraud reports. Our algorithms identify a normal distribution for your app and flag the outliers for you to analyze more closely. We’re providing a closer look into click-to-install behavior so that you can have an informed conversation with a network should they contain suspicious installs.
Part 4: Ad Stacking
Ad stacking is a fraud technique where multiple ads are layered on top of each other in a single ad placement. While only the top ad is visible, if a user clicks on the visible ad, a click is registered for all ads in the stack.
Kochava is unique in the ecosystem because we see billions of ad impressions for a variety of ad campaigns across thousands of publishers, networks and exchanges, all in real time. Our fraud algorithms detect and report cases where multiple clicks are registered at the exact same date timestamp for a given ad placement. The following table and graph detail this behavior for a gaming app during the month of January:
When we look specifically at the site IDs, we see that there is one main offender (Site_OEP) with 698,000 ads that shared the same date timestamp, and there are 164,000 instances of stacking (at an average of 4.3 clicks for different apps per ad unit). Overall, there were relatively few installs (97).
What’s going on here?
There are several reasons fraudsters employ the ad stacking tactic:
- Click stuffing: Once the user clicks on the visible ad, the click is registered for all the ads stacked behind it. If the fraudster is strategic, they may stack ads for similar apps, meaning apps the user is likely to install in the future. If they can register a click for what the user may eventually install, they stand a chance of receiving attribution for it. This type of fraud focuses on scamming the marketer by gaming attribution.
- Impression stuffing: We discussed earlier about high click-to-install rates. If an impression is sent to a click endpoint, it is registered as a click even though a user never clicked. The scam is twofold: First, no actual click took place; and second, the scam sends multiple “clicks” en masse against multiple apps with the intent of 1.) Gaming attribution (scamming the marketer) and 2.) Delivering bogus impressions (scamming the network).
- Viewability fraud: In addition, if impressions are stacked, all the impressions stacked within the ad container may be reported as “viewed.” In this instance, fraudsters are scamming viewability metrics as well.
Prevent Ad Stacking with the Fraud Console
Luckily, ad stacking is a relatively easy fraudulent tactic to catch and is one of the fundamental fraud behaviors we surface in our Fraud Console. The Fraud Console surfaces 11 indicators of fraud. Any site ID, device ID, or IP address flagged in the advertiser’s Fraud Console can easily be added to their Account Blacklist to abate fraud in real-time.
In addition, sites that execute this tactic across multiple marketers are automatically added to the Global Fraud Blacklist. The list is dynamically updated with new entities added if they regularly participate in fraudulent activity. Networks and publishers may work to remove themselves from the list by demonstrating aggressive anti-fraud processes and solutions.
Part 5: The Global Fraud Blacklist
The tools Kochava uses to identify fraud are part of the Fraud Console, which is comprised of a comprehensive Global Fraud Blacklist and reports.
The Global Fraud Blacklist consists of three components: network/site IDs, IP addresses and device IDs that have been flagged by our algorithms. The Global Fraud Blacklist acts in real-time and dynamically updates as new fraudulent entities are identified across all Kochava traffic. In addition, customers can add their own site IDs, IP addresses and device IDs directly from their account’s Fraud Console to curate their own account level Blacklist. In this post, we’ll explain the different levels and views we use to mitigate fraud in real time and how to enable the Blacklist.
Three separate criteria can land a network’s site ID on the Global Fraud Blacklist: MTTI outliers, ad stacking and invalid install receipts. Each entity must surpass an established threshold to be considered fraudulent. The threshold required to land a site ID, IP address or device ID on the Blacklist is much higher than what is used for reports in the Fraud Console which flag statistical anomalies for marketers to investigate.
With mean-time-to-install (MTTI), our Fraud Console will highlight any outliers that are 2.5 standard deviations from the network mean time for a given app. However, for the Blacklist we are more stringent. For a specific site ID to be blacklisted, we look at a rolling timeframe where the behavior was observed against multiple apps and exceeded a volume floor on the minimum number of installs reported for the outlier site. We only Blacklist an additional deviation from the norm. Preload and self-attributing networks (SANs) are excluded from our algorithms.
- Significant statistical outlier (more of an outlier than what’s reported in the Fraud Console)
- Behavior must be observed on multiple apps
- Rolling time window
- Minimum volume of 50+ installs
Part 3 explored MTTI fraud in detail.
As with MTTI, we’re more stringent with the Blacklist than what we report in the Fraud Console. We set a minimum click threshold for stacked clicks. Anything beyond that threshold is blacklisted. In Part 4, we discussed ad stacking in detail.
Invalid install receipt:
For installs originating from the iTunes or the Google Play Store, we receive a receipt that an installation occurred. In the cases when the App Store returns a non-verified install receipt, we deem the install fraudulent as reported by the site. Again, we set a minimum on the number of unverified receipts to warrant blacklisting a site ID.
Blacklisted IP addresses
We flag instances of anonymized IP addresses including proxies, VPNs and TOR exit nodes. These are sites purposefully trying to mask their traffic source.
Bad actors take steps to obscure their true IP address using proxies or VPNs (Virtual Private Networks) to circumvent geolocation restrictions; both are used in botnet traffic.
TOR or “The Onion Router” is a process by which web traffic is routed through a byzantine maze of encrypted relays with the purpose of anonymizing traffic. A TOR exit node is the gateway where encrypted traffic hits the internet. Legitimate traffic sources should not mask the sources of their traffic.
Blacklisted device IDs
Device IDs are placed on the Global Fraud Blacklist if they have an exorbitant click volume. When adding a device to the Blacklist because of click volume, it must surpass a threshold of clicks within a 24-hour period.
Not all devices with high click volumes are automatically blacklisted. A device may be reported on an individual app’s fraud report from Kochava but not blacklisted. For more information, read Part 2 about devices with high click volume.
Devices where we’ve observed an invalid purchase receipt are also added to the Global Fraud Blacklist. There are two primary methods for generating false receipts to spoof the verification from iTunes or the Google Play Store:
1. A hijacked device with malicious code on it pretends to be the App Store
2. “Man-in-the-middle” attacks where the malicious code sits between the device and the App Store
In both instances, a false receipt is generated and sent back to the device. The app accepts the receipt as a legitimate transaction, but there is no record of the transaction from the respective App Store.
Enabling the Global Fraud Blacklist
Marketers can begin using the Global Fraud Blacklist by contacting their account manager for the service. From that point on, marketers are in control of how they use the Blacklist.
There are two ways to enable the list:
1. Navigate to Fraud Console (under Account Options) select to apply the Blacklist to your entire account or to specific apps in the account
2. At the tracker level (under Campaign Manager and Traffic Verification), you can select to apply the list by IP, site, device ID or all three in addition to other criteria to verify the traffic delivered by networks
Marketers can also customize their Blacklist by adding their own list of fraudulent device IDs, site IDs and IP addresses they’ve encountered to the list in the Fraud Console.
With the Fraud Console, marketers have a powerful suite of preventative tools to eliminate fraudulent activity from their traffic. Because fraud is evident in most app traffic, employing the real-time Global Fraud Blacklist is a necessary step to protect ad spend and run effective campaigns with legitimate impressions, clicks, installs and post-install events.