The tools Kochava uses to identify fraud are part of the Fraud Console, which is comprised of a comprehensive Global Fraud Blocklist and reports. The Global Fraud Blocklist consists of three components: network/site IDs, IP addresses and device IDs that have been flagged by our algorithms. It 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 blocklist. In this post, I’ll explain the different levels and views we use to mitigate fraud in real time and how to enable the Blocklist.
Blocklisted sites
Three separate criteria can land a network’s site ID on the Global Fraud Blocklist: 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 Blocklist is much higher than what is used for reports in the Fraud Console which flag statistical anomalies for marketers to investigate.
MTTI Outliers: 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 Blocklist we are more stringent. For a specific site ID to be blocklisted, 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 blocklist an additional deviation from the norm. Preload and self-attributing networks (SANs) are excluded from our algorithms.
The criteria for blocklisting sites is as follows:
- 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
An earlier post I wrote explored MTTI fraud in detail.
Ad stacking: As with MTTI, we’re more stringent with the blocklist than what we report in the Fraud Console. We set a minimum click threshold for stacked clicks. Anything beyond that threshold is blocklisted. In my previous post, I 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 blocklisting a site ID.
Blocklisted 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.
Blocklisted device IDs
Device IDs are placed on the Global Fraud Blocklist if they have an exorbitant click volume. When adding a device to the Blocklist 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 blocklisted. A device may be reported on an individual app’s fraud report from Kochava but not blocklisted. For more information, read my previous post about devices with high click volume.
Devices, where we’ve observed an invalid purchase receipt, are also added to the Global Fraud Blocklist. There are two primary methods for generating false receipts to spoof the verification from iTunes or the Google Play Store:
- A hijacked device with malicious code on it pretends to be the App Store
- “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 Blocklist
Marketers can begin using the Global Fraud Blocklist by contacting their Client Success Manager for the service. From that point on, marketers are in control of how they use the Blocklist.
There are two ways to enable the list:
- Navigate to Fraud Console (under Account Options) select to apply the Blocklist to your entire account or to specific apps in the account
- 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 Blocklist 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 Blocklist is a necessary step to protect ad spend and run effective campaigns with legitimate impressions, clicks, installs and post-install events.
In case you missed them, read also Parts 1, 2, 3 and 4 of the Fraud Abatement Series.
About the Author
Grant Simmons is the Director of Client Analytics at Kochava and leads the team in analyzing campaign performance and business value assessments. He is the former head of Retail Analytics at Oracle Data Cloud where he worked with over 1,500 retail directors, VPs, CMOs and agencies to develop individualized test-and-learn strategies.
For more information about the Kochava Fraud Console, Contact Us.
