Table of Contents

PAIR is a new identity solution from Google that allows publishers and advertisers (using Google's buying platform, DV360) to match first-party data to deliver personalized ads. Google announced PAIR in a blog post outlining the concept last week.

PAIR stands for Publisher Advertiser Identity Reconciliation, and as far as ad tech acronyms go, it's not half bad.

The abbreviation accurately describes the goal of the solution since it allows publishers and advertisers to pair together to reconcile their respective first-party data. The result enables the advertiser to deliver personalized ads using DV360 without cookies or device IDs.

PAIR is similar to universal ID solutions like The Trade Desk's Unified ID 2.0 in that participants convert email addresses into encrypted identifiers. Also, like email-based universal identifiers, publishers and advertisers can use Google PAIR to deliver personalized ads across all devices.

However, PAIR has a few essential qualities that separate it from other universal identifier solutions.

First, the most obvious difference is that PAIR is only a solution for Google's DSP, Display & Video 360 (DV360). While other solutions are DSP-agnostic, PAIR is a solution by Google for Google. Although, Publishers can use PAIR from any SSP integrated with DV360.

But one of the most notable aspects of PAIR is that it eliminates any chance of data leakage or unauthorized parties creating profiles based on a publisher's data.

Publishers face the threat of data leakage whenever they share traditional identifiers like device IDs or IP addresses in bid requests, but that threat persists with some universal identifier solutions.

If a DSP or advertiser can extract any identifier that is useable across other publisher inventory, they can build audience segments based on increasingly valuable publisher first-party data sets.

Publishers may not want to allow anybody the opportunity to target their first-party data elsewhere. PAIR nullifies this threat and ensures unauthorized parties cannot siphon off precious first-party publisher data.

So PAIR can universally work across all devices, but its universal nature ends there because an identifier generated with PAIR has no use outside a single publisher/advertiser relationship. This unique attribute of PAIR is how Google prevents data leakage.

But how does it work?

How does PAIR work?

Google did not provide exact technical detail about how PAIR works in their blog post, but they did outline the process in broad strokes.

A publisher must first establish a relationship with an advertiser they want to pair with on PAIR. Once a publisher and advertiser pair up, Google will create three different encryption keys:

  1. Advertiser key
  2. Publisher key
  3. A shared key between the two parties

Google then requires each party to encrypt their first-party data three times over (once for each key). The thrice—encrypted data ensures there is no way for anybody to determine the original raw PII behind the encrypted values. From Google:

These keys are unique for every advertiser-publisher relationship and ensure there is no way for any one party to reverse-encrypt or identify users.

Since the publisher and advertiser uniquely encrypt the data for their specific relationship, that data is not useable outside the context of the business arrangement. So Google or the advertiser cannot take publisher identifiers and target them elsewhere.

But where does all this encrypting occur? Google highlights clean rooms as a potential but not necessarily required location to encrypt and reconcile publisher and advertiser data.

"Clean room" is a loaded term these days, but to understand PAIR, you only need to know that a clean room is a third-party platform that takes in raw PII data and outputs secure encrypted data to a publisher, advertiser, and DV360.

Google has partnered with several clean-room providers like Habu, InfoSum, and LiveRamp to encrypt and upload data. So clean rooms can handle the technical requirements behind PAIR and also guarantee that publishers and advertisers only ever share encrypted (not raw PII) data with Google DV360.

Google says that "advertisers and publishers can use clean rooms." So presumably, publishers and advertisers can forego working with a clean room if they want to handle the heavy technical lifting or possibly allow DV360 to do it if they don't mind sharing their data with Google (not clear from the post). But the clean room partnerships seem to offer a more seamless integration approach.

Regardless of the integration path, publishers and advertisers need to encrypt email addresses into useable identifiers (let's call them PAIR IDs). Publishers must upload their PAIR IDs to their SSP and include them in bid requests to DV360. Advertisers must upload their PAIR IDs to DV360 so the DSP can match publisher PAIR IDs in bid requests to uploaded first-party advertiser data.

Publishers would have the option to include PAIR IDs in ORTB bid requests to DV360 on any programmatic deals for an advertiser where they want to enable audience targeting. Publishers would have to share the PAIR IDs encrypted explicitly for that advertiser since the encryption keys vary for every unique relationship.

Why did Google create PAIR?

PAIR jumps on the first-party data bandwagon and adds another tool for advertisers to deliver data-activated campaigns without sharing sensitive raw user data. PAIR can also facilitate audience-driven advertising without passively-collected identifiers like cookies, device IDs, and IP addresses.

Google had initially appeared to go all in on its Privacy Sandbox initiative — which focuses on ad-serving technologies that don't require exchanging user identifiers. But now, Google has slowly shown a willingness to allow other solutions as long as they adhere to its concept of privacy.

They introduced encrypted signals allowing Google publishers to pass universal identifiers in ORTB bid requests, announced support of Seller-Defined Audiences, and now they are introducing PAIR, which can work with any SSP.

Google controls the world's most used web browser, mobile operating system, and gigantic portions of the digital advertising economy with Google Ad Manager and DV360. Owning all sides of the digital media equation gives Google enormous advantages, especially when they don't integrate with competing platforms.

So PAIR can be one of an increasing amount of examples Google can point to when regulators cry foul on Google's outsized influence on digital media and the ad tech ecosystem. Google can also tout that rather than restricting PAIR to only Google publishers, any SSP can integrate the solution to help their publishers monetize their inventory.

Google may also have altruistic intent to preserve user privacy since PAIR enables a method to deliver personalized advertising with consent-driven first-party data. PAIR and the other solutions mentioned above move us closer to a world of personalized advertising based on opted-in first-party data or privacy-by-design solutions.

Google may want to deprecate cookies in Chrome and device IDs in Android to bolster its strategic advantages of owning massive amounts of first-party data. But many consider personalized advertising based on those two passively collected signals a blight that requires eradication.

Will Apple allow PAIR on iOS?

One big question mark with PAIR is if it fits within Apple's definition of "tracking." If an iOS user asks an app not to track them, then Apple policy dictates that an app owner cannot link any user data collected from an app with data collected from other companies.

Google seems to think that PAIR does not amount to tracking:

PAIR will protect trust in your brand because it doesn’t allow for tracking people across the web, which we don’t believe meets user’s privacy expectations. Instead, users will only be shown ads from the advertisers and publishers with whom they have direct relationships, giving them more control of the ads they see.

But Apple may not agree. Here is the exact language from Apple:

Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies' apps, websites, or offline properties for targeted advertising or advertising measurement purposes.

Since Google designed PAIR to link first-party data collected by a publisher with first-party data from an advertiser, I'd say this is a clear violation of the above policy.

But will Apple soften its stance if publishers and advertisers gathered explicit consent on both sides? I wouldn't hold your breath.

PAIR and Android Privacy Sandbox

Google announced the Privacy Sandbox on Android to:

limit sharing of user data with third parties and operate without cross-app identifiers, including advertising ID.

They did not indicate if they will remove Android device identifiers altogether or if they will implement some Apple ATT-like prompt to limit their usage.

If Google asks users if they want to permit tracking with each Android app, will they still allow PAIR if the user opts out? Or will they only limit access to the Android device ID?

You have to think that PAIR will be permitted on Android in most cases and offer one way to deliver personalized ads as long as the publisher and advertiser gather consent during data collection. So this will be one point to pay attention to as we loom closer to the deadline outlined in Google's promise to:

support existing ads platform features for at least two years.

Google PAIR is yet another tool for publishers and advertisers to consider when evaluating next-generation identity and audience targeting solutions. Even though PAIR is a DV360-specific solution, Google's DSP wields enough market power to catapult PAIR to the top of the list for those prioritizing alternative identity solutions.

Photo by Austin Kehmeier on Unsplash

Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Ad Tech Explained.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.