Third-party cookies are going away and Google is restricting ID sharing. What does this mean for Google’s suite of advertising IDs and the advertisers and publishers that rely on them for monetization?
It’s one of the most consequential questions for the world of online advertising, but nobody has a clear answer.
Google operates two different identity spaces.
The first is the logged-in universe of Google users, who could be signed into platforms such as Maps, Gmail, Search, Chrome or YouTube. While Google might query against these identifiers and send back aggregated data, these logged-in IDs are not available outside of Google.
The second identity space houses an ID that third-party ad tech and ad servers can use. The mobile version of the former DoubleClick ID, associated with Google Play, is the Google Advertising ID (GAID).
In desktop, the ID once called the DoubleClick ID will – by Q3 this year – exist only in Google’s cloud-based analytics service Ads Data Hub (ADH), where it is either called the UserID, if it’s used by a brand, or a PartnerID, if it’s used by an intermediary like an agency or data company.
While there’s no functional difference in how the UserID or PartnerID can be applied, the PartnerID is encrypted differently, so vendors or agencies can use it for their clients, but can’t connect it to other data sets, even in ADH. For instance, vendors with access to multiple brands’ data sets could theoretically gain insights for themselves by comparing IDs across those brands. The PartnerID keeps that from happening.
How do these IDs work together?
ADH, which has been in beta since 2017, is focused on measurement use cases.
Marketers lose the user-level transparency they used to have with the DoubleClick ID, but the benefit is that within ADH the UserIDs are enriched by Google’s first-party data.
Every marketer and agency buyer understood the DoubleClick ID, said Matt Fiskness, chief solutions officer for Adswerve, a Google marketing platform services provider. “Relearning how that ID works now can be one of the most confusing things to navigate a customer through.”
During its heyday, the DoubleClick ID was widely available and could be used for both targeting and measurement. It offered user-level insights, and the results could be exported. Its use case today is much more limited.
Click on image to enlarge.
Historically, a campaign may get 10,000 cookie-based DoubleClick IDs from people who engaged with or saw the ad on a site or app – indicating they may be on-target customers. Those 10,000 DoubleClick IDs could then be retargeted elsewhere or measured alongside campaigns run by Flashtalking or The Trade Desk.
But the cookie-based DoubleClick IDs are fleeting – they disappear when someone resets cookies, and are already gone for Safari or Firefox browser users. And those IDs don’t connect well to first-party CRM data, since cookies aren’t attached to known individuals.
The UserIDs in ADH can’t be taken out of the Google system like DoubleClick IDs, but within the Google Cloud they are anchored by actual human profiles built from Google’s logged-in universe, meaning there’s richer data.
So a campaign won’t get 10,000 cookie-based DoubleClick IDs, but the advertiser is able to query the data for more sophisticated insights, like if the brand wants to know if it’s reaching audiences in Chicago and Boston who read sports news sites or recently searched for sports tickets.
The new IDs aren’t retargetable like DoubleClick IDs – they exist only in ADH and for campaign measurement – but they’re more insightful and sync more effectively with the brand’s first-party data (as long as the data is housed on the Google Cloud), said Hugo Loriot, partner at the ad analytics consultancy fifty-five.
In Q3 this year, the new Google ID policy will go into effect worldwide, as it already has in the E.U. to comply with GDPR, and marketers will only have the ADH UserIDs to work with. The former DoubleClick ID will no longer exist outside of ADH.
The problems and possibilities with ADH
There are advantages that come with the lack of ID transparency in ADH.
Identity data is stronger within ADH, since those IDs are attached to the deterministic Google user graph, instead of just cookies, according to one holding company data exec. But to take advantage, marketers need first-party data sets integrated with ADH as well.
“And getting data into ADH is a huge challenge,” she said.
For instance, brands can’t just onboard and match a list of email addresses or other IDs with Google’s identity graph, as they might with LiveRamp or Epsilon, Loriot said.
Google must first confirm how that data was obtained, before matching it against its own ID graph in ADH.
Brands must load their identity data and integrate their ad server with BigQuery, the Google Cloud data warehouse. Google’s first-party data sits in BigQuery as well, which means Google IDs and the brand’s ID data can be analyzed together without sacrificing privacy (since ADH doesn’t return user-level data, only aggregated insights). Once the brand’s data is in BigQuery, it can start re-identifying users from its list when they click an ad or visit the site.
But that’s a huge challenge for CPG brands or companies that sell exclusively through outside retailers, like cosmetics and some clothing companies, Loriot said, because people don’t click on their ads or visit their sites.
A candy brand’s email list might theoretically match well with YouTube’s signed-in user base, but the brand needs to get people to visit its site, click on an ad or re-establish first-party data in some way, say through a customer data partnership with a drug store chain, to use those IDs in ADH.
Google has started testing LiveRamp to help bridge its logged-in user data and the cookie-based ad server data in ADH, according to sources.
LiveRamp’s IdentityLink is digital advertising’s most-used deterministic ID, meaning the profiles are built on identifiable data like email and home addresses, not cookies. Google’s logged-in user graph is tied to email too, since that’s how most people sign in to its apps and services.
