As the market celebrates Google switching to a referrer API, few people know what motivated Google to take this step.
The tech industry has several reasons to rejoice: this change allows for deeper insights into the user conversion funnel, secures the Google Play Store referrer and finally (and most importantly), the additional data provided allows for the complete eradication of click injections.
First stop: Click Injections
Since the common belief is that click injections are purely based on the Android package_added broadcast (which happens right after the app is installed), a lot of people are wondering why there’s additional data needed to get rid of click injections. The actual install timestamp (which Google made available with API 9 in December 2010) that is available to the app (and therefore the measurement SDKs inside it) is dated 20-2ms before the package_added broadcast, so it is sufficient to root out all click spam that is based on this method.
So why are we so excited to get the timestamp of when the user clicked the download button in the play store (install_begin timestamp)?
It’s because there is a second, lesser-known method to inject clicks, which works without the infamous (referrer) broadcast (called PACKAGE_ADDED). Fraudsters in this scenario subscribe to Google Play’s Downloads Content Provider, which holds the temporary data of app downloads. The perpetrators observe this database reactively: whenever the database does something, the fraudster will be notified, for example, every time there’s a new app download. By doing this, they can identify the app that is being downloaded. The click injections that follow this method will have a timestamp that lies before the actual install finished; therefore, there is a lot of excitement about a data point which proves the user made up their mind about installing/using an app, and lies definitively before the possibility to intercept that information. Any solution designed to protect advertisers will need to make use of both timestamps.
Second stop: Faked referrers
As outlined in a recent whitepaper by Checkpoint, there is malware out there that does not just use the content provider exploit click injection method, but also improves its chances of attribution by blocking Android’s referrer broadcast and substituting it with their own.
This means that the data point with the highest weight in the attribution waterfall - the trusted Google Play Store referrer - is no longer considered trustworthy by attribution companies and advertisers who build their own attribution software.
This threat explains the drastic (and much applauded) step by Google to switch to a secure API that only allows an app itself to request its own referrer information.
Third stop: Conversion funnel insights
For years now, the conversion funnel as indicated by timestamps of user interaction in mobile performance looked like this:
- Impression (underused)
- Install (in practice, the first open of the app)
- Any post-install events the advertiser sets up (e.g. first purchase)
With the data points made available by Google this year, the wealth of information available allows for much better analysis:
- Impression (still underused)
- Referrer redirect (user entered the Play Store)
- Install_begin_time (user clicks download button in Play Store)
- Install_finish_time (install finished on the device)
- First_open_time/ Install (tracking SDK initialized, old install timestamp)
- Any post installs events the advertiser sets up (e.g. first purchase)
With this funnel view it is now very easy to identify sources that lack proper latency, improvement potential in App Store optimization, sources of technical churn e.g. to big initial download size, etc.
We expect Apple to follow this trend of adding transparency and value to the advertising app developers.
Click injections are just one of the ways fraudsters can disrupt your campaigns. To learn more about the different types of fraud which exist in mobile advertising - and how to fight them - head on over to our mobile fraud guide.