Google drew a line in the sand on March 3rd, when it said it wouldn’t build or support cross-site identifiers. But single-site identifiers, specific to an individual publisher, are fair game – and something Google wants to encourage.
To that end, Google is dusting off an old/new ID type: the publisher provided identifier (PPID) in Google Ad Manager.
The PPID has been around for years, but until now was only used for direct deals. With third-party cookies going away and cross-site email apparently data-non-grata in Google-run auctions, the product holds new appeal.
To expand the use of PPIDs, they need to work programmatically. So Google Ad Manager is building tech that will allow publishers to share the PPID – either selectively or universally – with advertisers in all programmatic deal types, including the open auction. With this new PPID tech in place, publishers will be able to surface their first-party data programmatically for buyers, as long as they use Google as their intermediary.
The company outlined the approach in a blog post today.
Google is already doing early tests with publishers using the PPID. In the coming months, before third-party cookies are dropped from Chrome, it plans to add more features that will collectively offer a solid alternative to the cross-site trackers that are prevalent today.
The PPID’s technical setup works like this: the publisher will create a unique ID for users, based on a first-party cookie or a log-in ID. Then it will put that ID into Google Ad Manager, and choose who it wants to share that data with. Google will hash that ID and pass it through to buyers.
Buyers won’t know that PPID 123 is a sports fan in an open auction. But as they observe the ID in bid requests, they may notice that the user ID goes to a sports site frequently, for example, and deduce that a buyer is a good fit for an ad campaign.
Could a publisher slot in the Unified ID as its PPID? Not really. In order to meet Google Ad Manager’s contract terms, the ID would have to be unique to an individual publisher – which would defeat the whole point of a universal ID like the Unified ID.
What about small publishers?
Creating PPIDs requires resources small publishers can’t readily deploy. First-party data is generally considered most valuable at big publishers, where audiences are larger (a bigger pond for advertisers to fish in). Google says it plans to address that issue by automating parts of the PPID process for small publishers, but that process is in its very early stages.
Encrypted data passing
What if a publisher wants to signal to a buyer in a bid request that a user is likely to appeal to them – but wants to keep that information secret?
Google is creating an encrypted signal that a publisher could pass in the bid request, which is also in the very early stages of being built. Imagine a PMP with a lock and key. So if a buyer wants to sync its customer data with a publisher, for example, and then create a pool of customers and lookalikes it wants to target, a publisher could signal the presence of one of those users with an encrypted bid request. Or they could communicate anything they like. Google can’t read it and won’t know what the two parties are sharing with each other.
Update: While PPIDs can’t include cross-site identifiers like the unified ID 2.0, those identifiers could be slotted in via encrypted signals, according to a spokesperson for the UID.
These new tools are together designed to help publishers use their first-party data – a fulfillment of Google’s goal – stated last week – to “deepen our support for solutions that build on these direct relationships between consumers and the brands and publishers they engage with.”
In the new post-cookie world, signals like the PPID could be passed alongside other information in the Privacy Sandbox, like a user’s FLoC (and hey, the universal ID too). As the industry races to simulates the targeting and measurement it once enjoyed with third-party cookies, next year, it’ll be a brand-new bidstream.
