Link to the original source 

Being careful not to draw too much from Google’s latest announcement, we do see five conclusions:

Conclusion #1: No magic Google solution

Since Google will not use alternate IDs, this rules out the usage of Google Login IDs for cross-site advertising purposes. During 2020 this has been a hard-to-kill myth, despite obvious anti-trust arguments. Many have assumed that publishers and advertisers will move inventory and spend to Google platforms based on a belief that Google will launch a magic solution using Logins.

Conclusion #2: Not the death of first-party IDs

First reactions proclaimed the death of unified ID solutions, but that’s a hasty conclusion. Certainly, Google’s support would have fueled faster adoption, but with most publishers running header bidding and multiple SSPs or direct DSP/PMP integrations, it doesn’t really change much. Accordingly, we read that Google acknowledges its products will have a disadvantage.

Already many publishers are deploying first-party ID solutions, despite not being supported by Google. This makes Google less competitive against other SSPs and DSPs due to its continued lack of support, and strengthens those supporting and funding these IDs. The outlook of not competing against Google Logins is very welcomed news.

The question now remaining is how Google might fight such IDs – and the app store and Chrome is where Google can look at restrictions. In the app store, it is possible for Google to impose rules, like Apple, on whether apps can use Identifiers for advertising purposes without explicit consent. It’s possible because Google ultimately controls what apps are in the store, whereas a ’technical filter’ of server-to-server ID transmission is technically inconceivable. A similar option doesn’t apply to the open internet where neither Apple nor Google would likely ban a website like Facebook in their browsers if utilizing IDs for advertising. Browsers do not control server-to-server data being passed from websites to SSPs/DSPs. There doesn’t seem a way for Google to ’turn off’ ID solutions.

Conclusion #3: This does not make Google evil

Let’s state the obvious: Google is likely on the right side of history with its decision! It is not in consumers’ interests to have their email addresses hashed and transmitted across the adtech landscape ­– an opinion likely to be shared by regulators as well. From a mid-to-long-term perspective, consumers having privacy concerns about Google poses a large existential threat to them.

With these mounting privacy concerns potentially hurting Google’s main search engine product, it’s a sensible strategy for Google to disengage from cross-site tracking and for Chrome to follow its main competitors in blocking third-party cookies. It would seem reasonable for Google’s left hand to follow the right hand, and not have DV360 introduce alternative IDs for tracking and advertising, so we do not see that conclusions can be made to say there is any evil behind Google’s announcement.

However, it should be mentioned the industry has been vocal with complaints about Google’s Privacy Sandbox approach. It is perceived as driven almost entirely by Google, with little-to-no industry input factored in, with limited transparency and with preferential early access by Google’s own platforms.

Conclusion #4: This is a blow to DV360

In Google’s words, other vendors will offer something that Google’s ad products will not. DV360 especially is disadvantaged in comparison with competitors. To illustrate that, let’s compare DV360 with the Adform stack, one of the vendors starting Privacy Sandbox implementation and trials. Being an early mover, Adform supports all major first-party cookie and unified IDs, such as ID5, TTD, LiveRamp and Britepool, which are affected by the announcement.