You may have seen Adjust’s latest announcement on our product updates feed: an upgrade to our systems that filters click injections even more effectively. This update is proven to stop more fraud from affecting client’s budgets (as much as 60% fraud based on click injection methodology, in fact).
But it took more than just us to make this happen. We worked with Google to share technology, data and insight that went into the creation of a new, effective filter, which enabled a new way to flush out fraud from the ecosystem.
With more collaboration like this, the industry can move forward to fight fraud in an effective way. This article is dedicated to showing just how to do it, and the results of the work we all put in. Read on for more.
How the industry re-discovered click injection
We asked Adjust’s Head of Fraud, Andreas Naumann, to tell us more about what led to the collaboration.
“Well, that is a pretty simple story. At the time we were seeing very, very short click-to-first-open times (also known as click-to-install_time, or CTIT). Of course, we knew something was wrong - but only understood then that somebody was pushing in a click at the right time, with high accuracy, to make this happen.”
“I thought it would be Click Injection, as I knew it from desktop web days - where software on your computer would listen to internet traffic, would find out that you're visiting a store site and then inject an affiliate link, so that they would get paid on whatever you order.”
“On mobile that’s also really easy to do, because you have a ton of software on your device that can simply do that. However, understanding the methods employed took a little more work.”
“I had a theory about the package_added broadcast, but I didn't have an idea yet of how an app would precisely exploit the system to make this happen. That's when we reached out to Google.”
“We sent them a huge package of data that showed what we were seeing. As Google wanted to deal with the exploit, they asked us what we would need to mitigate the problem in the meantime. To answer, we requested timestamps for when an install finished (before the broadcast gets triggered) and the time when the app download starts.”
“Google provided us with exactly that: the install begin time (defined as the time when the user clicked the download button in the Google Play Store), and the install finish time (which is available on the device). Since these two times mark the user interaction before a possible injection they would be perfect to use for accurate attribution (by removing attribution to clicks happening after these timestamps).”
"Google also began working on securing the exploits in future Android versions, but wanted to give attribution providers the chance to fix attribution manipulation in the meantime. This is because users wouldn’t necessarily have the most up-to-date version on their device.”
“For this, we needed the timestamps of the last user interaction before injection points. So, the timestamp of when the install finishes on the device before the broadcast, and the timestamp of when the user clicked the download button on the Play Store (which is before the content provider gets into action)."
“Fortunately, later the same year, Google came back with the documentation of a timestamp of when the app was installed. And a couple of months after that, on November 20th, 2017, Google changed from the broadcast for the referrer to the Referrer API, and released the API, which made the referrer (and the timestamp of when the user clicked the download button in the Play Store) available to the ecosystem as a whole.”
“Google even one-upped us on our own request, and gave us the timestamp of when the user has been redirected into the Play Store. With the secured referrer and both timestamps now freely available any app developer or MMP could now deterministically remove click injection from attribution."
Adjust’s new Click Injection filter
The update to Adjust’s Click Injection filter utilizes Google’s `install_begin` timestamp, which was made available in Google’s new Play Referrer API.
This update allows us to stop the Content Provider exploit by denying attribution of an install to sources that deliver a click between the ‘install_begin’ timestamp and the first open of an app by a user.
What success have we seen so far?
We’ve been testing the new filter with a select group of clients who were allowed access to the beta version, and the results have been encouraging.
Comparing the data from 30 days before the feature was deployed for the beta test, and for 30 days after, we see on average a 48% increase in engagements blocked daily by the new filter.
At its peak, the latest filter stopped nearly 14000 fraudulent installs in a single day. Over time, the updated filter prevented 159774 installs over thirty days, 46% more in total than the previous iteration.
In essence, the new filter has so far proven a capable upgrade, helping our clients to stop more mobile ad fraud from affecting their campaigns, and their bottom line.
For more on the current capabilities of the filter, click here to be taken to our product update. We’ll be returning with more data on the tool in an upcoming blog post, so if you want to keep informed, sign up to our mailing list below.