What The Google AdID Means For Ad Tech

"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.

Where Google doesn't have an identity, but does have a third-party cookie (typically in the ad.doubleclick.net domain), it will evaluate the quality of that cookie and, when it meets a minimal threshold of quality, use that ID as the unique identifier to be hashed. You may ask which criteria make a given cookie high-quality or low-quality? Good question.

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.

All I have to offer is speculation as well, and my speculation is that Google AdID is merely a Chrome feature, which they're doing because they feel the need to eliminate 3rd party cookies like Safari and soon Firefox as well. I don't think they're offering an AdID for the entire Web ecosystem.

First off, they are already leveraging publisher 1st party and 3rd party cookies (see https://support.google.com/dfp_premium/answer/177282?hl=en), and have very strong Google 1st party cookie coverage, so they're not exactly suffering there. Secondly, any effort beyond that would be a significant policy hurdle for them ... minimally necessitating an update to all publisher's privacy policies. Within Chrome, they have their own ToS and privacy policy with the consumer, which bypasses all of that headache.

Can't wait to see the ToS for 3rd parties to be able to use the AdID. I suspect in order for a party to use the AdID, they will pretty much need to accept it as their primary key, won't be able to associate it to any other ID, and perhaps won't be able to use any other ID -- creating a dependency on AdID.

Is there any aspect of ad tech that you don't spend an enormous amount of time pondering? Good summary and interesting possibilities. Here's what I see...

The DoubleClick cookie powers Google's ad ecosystem and portability of data today. They need a replacement for two key reasons: 3rd party cookies are in danger from changing browsers policies, and the fragmented world created by mobile devices and their app based internet interactions.

What you propose works well for the first case. Replace the 3rd party cookie with a persistent identity driven off of Chrome, Google+, Gmail, etc. The second case is harder to solve. You suggest statistical identification or leaving this user / usage pool out without an identifier. But this is where Apple and iOS throw a big monkey wrench into the works. The iPhone / iPad app universe is too big to ignore, so Google would have to do device recognition based on a probabilistic model and bridge that from app to web and web to app and device to device. That requires analysis of behavior plus a deep persistent presence on the phone to enable persistent opt-out. If Google starts massive scale behavior analysis, across devices, without opt-IN, the privacy advocates, the FCC, Germany, and every state Attorney General out there will be certain to object. Apple's own IFA is insufficient for a whole host of reasons. And partnership between Apple and Google on this isn't conceivable.

Which suggests that Google will be most successful in the environments within their control: Chrome and Android, and browsers where they can reinforce identify, along the lines you suggest. But they won't be able to solve for cross device identity outside of their ecosystem, and iOS (apps at least) will remain a big black hole for them. That leaves a big space for bridging technologies or an open source effort that brings the big parties to the table and solve this problem in a meaningful way that enables great privacy and a whole host of business models. I heard some talk earlier this week about an OpenStatID project. I'd love to see that catch on and get some traction before Facebook, Apple, and Google take complete control of my identity and the internet.

And shouldn't someone weigh in on the anti-competetive implications of all of this? Ballmer can't be the only one.

Some solid speculation here Ari. However, I would hesitate to assume that Google taking the reins of a product like this is a positive thing for the industry and consumers overall. Any cookieless identification technology should be evaluated on the basis of 3 primary pillars;

Privacy for the consumer (how does this obfuscate user data, is there control and permission)
Performance for the advertisier (does it work everywhere, all the time, what is the latency)
Protection for data owners (can they fully control their own data, is it being aggregated without permission)

There is a clear need for an independent driver in audience identification, so whilst it's great that Google are validating the space, we should work towards an industry standard not controlled by a major player, with vested interests in ignoring the work of DNT, privacy and industry groups.