Google’s Message To The Ad Industry: We Won’t Build Our Own Third-Party Cookie Alternatives (And We Don’t Want You To Either)

Google has said that it won’t use alternative methods to track users online once it ends support for third-party cookies in Chrome – and that it disapproves of using email as an alternative identifier for ad tracking.

Google said in a blog post on Wednesday that it won’t use alternative methods to track users online once it ends support for third-party cookies in Chrome – and that it disapproves of using email as an alternative identifier for ad tracking.

In other words, Google is stating for the record that it will not cook up any voodoo tracking magic of its own and that all of its web products will be driven by the privacy-preserving APIs currently in development within the Privacy Sandbox, including FLoC-based cohorts.

The direct implications of Google’s announcement are not immediately clear. Will Google’s pledge not to use or support user-level identifiers for third-party ads in its products only apply to DV360, Google Campaign Manager and Google’s demand partners – or could this also apply to YouTube? The latter is unlikely but, if so, that would be major.

But while the dust settles, Google’s statement does appear to answer one of the biggest open questions that has come up during meetings of the Improving Web Advertising Business Group (IWABG) at the World Wide Web Consortium, which is whether Google plans to, forgive the cliche, eat its own dog food when it comes down to actually applying Privacy Sandbox proposals.

There’s been a great deal of skepticism on that point, especially among ad tech companies that believe Google is aggressively pushing through a series of good-enough-for-thee-but-not-for-me pseudo-solutions that likely won’t deliver as promised.

For example, almost every meeting of the IWABG since late January has included debate over how Google was able to use FLoCs to deliver 95% of conversions per dollar spent when compared to cookie-based advertising, as Google has claimed it was able to do.

There still hasn’t been a clear explanation of the math behind the claim or confirmation of whether 95% is only the best-possible outcome as opposed to the median that advertisers can expect with FLoCs. It also appears that performance was good during testing at least in part because Google seems to have relied on cookie-based learning to train the model – data that won’t be available when third-party cookies go away.

IWABG member companies, including Criteo, are calling for Google to share a detailed paper on exactly how it conducted its FLoC tests. They’re still waiting.

One thing that’s clear, though, is that Google is strongly pushing FLoCs or cohort-based IDs as a replacement for individual IDs. FLoC is one of the most developed proposals in the Privacy Sandbox, and Chrome is making it available for developer testing this month and for public testing in Google ads in Q2.

But what about industry identity initiatives, namely Unified ID 2.0?

The Trade Desk, which spearheaded UID 2.0, has been adding partners at a rapid clip and busily gearing up to make the ID generally available at some point during the first half of 2021. The Partnership for Responsible Addressable Media is currently reviewing the UID 2.0 code, and Prebid has signed on the independent operator to implement the identifier.

Google, however, is not a fan.

In its blog post, Google took the opportunity to throw a little shade – perhaps even a grenade – in the direction of industry identity initiatives being developing outside the auspices of the W3C.

Although Google’s director of product management for ads privacy and trust, David Temkin, who authored the post, didn’t mention Unified ID 2.0 by name, he didn’t have to.

Regarding what he referred to as “PII graphs based on people’s email addresses,” Temkin writes that Google doesn’t “believe these solutions will meet rising consumer expectations for privacy, nor will they stand up to rapidly evolving regulatory restrictions, and therefore aren’t a sustainable long-term investment.”

One could argue that it doesn’t necessarily matter what Google believes, at least in this one regard. If people willingly share their email address and give permission for it to be used as a first-party identifier, what power does a browser or platform have to deny a user’s consent, as long as it’s informed and freely given?

Then again, there is some precedent. Apple has said that hashed emails and phone numbers collected elsewhere cannot be used as a replacement for app tracking on iOS 14, regardless of whether they were collected with consent.

Developers will only be able to get permission to use identifiers for ad tracking on iOS 14 devices if they’re collected through Apple’s own AppTrackingTransparent framework.

Would Chrome institute a similar policy? The question is “would” rather than “could,” because Google could disallow hashing as an encryption method, but whether it would do so, with antitrust complaints flying in from every direction, is another matter altogether.

Perhaps the bigger challenge email-based industry initiatives face, at least in the near-term, is scale.

Although Criteo is busily working to develop a consumer-facing single sign-on user interface for publishers as part of UID 2.0, there’s just no easy way to get people who are accustomed to web browsing with no strings attached to suddenly start coughing up their email address.

There does seem to be one thing Google and the ad industry agree on, and that’s the importance of first-party data.

Temkin ends his blog post by declaring that “first-party relationships are vital” and that Google “will continue to support first-party relationships on our ad platforms for partners, in which they have direct connections with their own customers.”

… but just not email addresses collected  by publishers with consent, I guess.

Enjoying this content?

Sign up to be an AdExchanger Member today and get unlimited access to articles like this, plus proprietary data and research, conference discounts, on-demand access to event content, and more!

Join Today!

 

Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>