“Data-Driven Thinking” is written by members of the media community and contains fresh ideas on the digital revolution in media.
Today’s column is written by Ari Paparo, SVP, product management at Bazaarvoice. From 2004-2010, Paparo was an executive with Google’s DoubleClick unit.
There is a lot of news coverage and blog analysis responding to a USA Today report about the rumors from Google that they want to replace the Web cookie with their own unique identifier (the poorly named AdID) and that they may allow certain partners to have access to this system. I have no firsthand information about this project but I have plenty of speculation on how it might work and the implications on others within the ecosystem.
How It Might Work
If I were Google, my goals for creating a new ID would be:
- Take advantage of first-party identity through the Google login (Android, Gmail, etc), while obfuscating the ID so it couldn’t be traced back to an individual’s phone or mail account;
- Cover as close to 100% of users as possible on any device;
- Support cross-device persistence;
- Support a persistent opt-out;
- Avoid the problems with cookie deletion, where IDs get reset all the time and opt-outs get deleted as well.
Based on these requirements, here’s how I think it might work:
Where Google has a first-party identity, it will create a hashed ID unique to each partner it works with. The hash is the important part since this will protect the privacy of the Google user as well as prevent partners from sharing information about users without Google’s permission or using Google systems. More on this later.
Consider two cookies, one which was set an hour ago and was seen a single time vs. a second cookie set a year ago and which has consistently seen ads as recently as today. The first cookie is much more likely to be the result of a user who clears cookies frequently, or an “incognito” session of the browser, whereas the second cookie is very likely to be a real user, with the caveat that it still might be a shared computer or other outlier. It is pretty straightforward to develop a cookie-quality algorithm that can separate the wheat from the chaff, and hopefully this is part of Google’s plan.
Where the user does not have a cookie or has a bad cookie, there are two options: Google could statistically estimate the uniqueness of the user, or it could not provide an ID.
One of my guesses, above, about the goal of this program is that Google will want this ID to have very large coverage of impressions in order to be a viable replacement for the cookie, so I think it will try to offer a statistical method to fill in the gaps. What this means in practice is there will be a system that takes all the information about the impression, including timestamp, browser header, IP address, unreliable cookie, etc. and attempt to assign a persistent ID to the user such that the next time that user is seen the same ID can be used.
Finally, opt-out. The traditional problem with opt-out is that for a user to opt out they need a unique identifier that lets you know they don’t want to be tracked, which is a circular problem.
With Google’s AdID, however, the opt-out should be much more persistent. If you read the three paragraphs above about how the ID will be calculated and instead think about how an opt-out can be operated, you see that this opt-out is much more likely to persist than the traditional method, especially since the majority of consumers will be able to associate their opt-out with a Google login. This is also interesting because the Google opt-out will persist across devices and to its entire partner ecosystem, thus potentially being much more effective than DNT or other methods.
What Are The Implications?
The implications of a Google AdID are very different depending on where you stand in the Google ad-tech stack. If you are an agency or publisher using DFA or DFP, respectively, the Google AdID sounds like very good news, since it could enable cross-device tracking and targeting, clean up opt-out and cookie-deletion issues and, in all likelihood, increase the targetable universe of users significantly as compared to the current third-party cookie norm.
If you are a third-party ad-tech vendor, RTB participant with your own cookie space or anyone else who transacts a lot of business with the Google ad-tech stack, but at an arm’s length, things are not as rosy.
To start with, you’re now competing with a company that simply has better identity tools than you do, and it will be very difficult — unless you’re Facebook or Twitter — to match the amount of identity Google can bring to the table. The implications are that your retargeting doesn’t yield as much as Google’s, your reach isn’t as accurate as Google’s, your fraud detection isn’t as good as Google’s. You get the picture.
Now, consider the scenario where Google allows partners to use the AdID but puts conditions on the usage. These conditions could very well sound logical and forthright, but could actually prevent other companies from enjoying the business model flexibility that Google reserves for itself.
Let me give you a real example of a business practice that Google currently enforces. Google requires all participants in AdX and in AdSense to certify their ad servers and have their domains whitelisted for each. But they do not allow the same domain to be whitelisted for both, claiming that this would allow for data leakage between the systems. Sounds reasonable. But the implication is that no outside ad server that is a platform for running on AdSense can seamlessly let their clients bid on AdX. This restriction means that the combination of DFA and Invite is the only integrated buy-side solution allowed to exist in the marketplace.
A real-world example of how AdID could be restricted is around data portability between systems. I mentioned above that Google will likely hash the ID, and that they will use a different hash for each client or partner. There’s a big implication for this design: Various clients reliant on the AdID will not be able to share data without going through a Google system or translating the IDs into a common domain, adding a ton of friction.
This is not unfounded speculation, since Google does exactly this on the raw log files offered to DFA and DFP clients, a significant change in policy from the old DoubleClick systems. To use a real-world example, suppose a DFA client was reliant on AdID, then wanted to pass its log files to a third-party DSP to model and target ads on AdX. If the ID is hashed differently between the DFA logs and the DSP’s AdX integration this won’t work and the client will have to manually drop pixels.
The apocalyptic scenario, which I personally don’t think will happen but will include for completeness, is that Google could only offer the AdID to partners that abided by restrictive economic terms of service, such as providing their clients fully transparent reporting on margins. While this seems like an overreach, we shouldn’t forget that Facebook actually enforces such as policy on its ad system right now, in the name of transparency and fairness.
Conclusion
As I stated at the top, this article is entirely speculative. I might have gotten some or all of my assumptions wrong, and it wouldn’t be the first time. But, there are two assertions that I’ll stand behind: Google creating an AdID based on first-party data is a very big positive for customers within their ecosystem. And it is very likely a very big negative for companies that are competitive, but reliant, on their ecosystem.
Follow Ari Paparo (@aripap), Bazaarvoice (@bazaarvoice) and AdExchanger (@adexchanger) on Twitter.
