IAB Tech Lab recently published a 32 page technical document about the implementation of PAIR (Publisher Advertiser Identity Reconciliation).
I read this, so you don't have to...
1. What is PAIR?
PAIR was introduced by Google in 2022 to provide a privacy-first approach to identity resolution between advertisers and publishers. Google then donated this protocol to the IAB Tech Lab to make it a standard for all IAB members.
2. What do you need to know, for now?
If you are responsible for advertising & marketing in your company, whether as a standalone advertiser or publisher, you don’t need to take any action. The DSP/SSP you are using will implement this protocol into their solution. If you are using a CDP solution to manage your identity graph, you may consider adding a new type of identifier. I’m pretty sure that your CDP provider will also guide you regarding possible implementation.
3. How does it work?
The method is based on “commutative ciphers”. In this method, two parties have their own pair of encryption and decryption keys. They can encrypt/decrypt the data and it will still produce the original message. This property is particularly useful in scenarios where multiple parties need to securely share and access information without a predefined sequence.
Formulization: PAIR ID = function(raw identifier + advertiser key + publisher key)
You can imagine this process as a ‘multi-key safe,’ similar to the safe rooms in banks. Each advertiser X publisher combo will have a shared safe. To unlock the safe, both advertiser & publisher key must be insert to the key hole to open it.
Everyone has their own keys and they are unique.
Steps to produce PAIR ID
1. Each party generates a private key.
2. Each party loads the identifiers to the data clean room.
3. Data clean room generates the PAIR ID by using the formula in a safe environment.
4. Data clean room sends the PAIR ID to each party.
5. Data clean room shares the match rate with each party.
6. Each party can now use the PAIR ID to within their DSP/SSP to target the right audience.

Notes:
- It is the role of the data clean room and DSP/SSP to manage this complexity.
- Advertiser private key (Ka) and Publisher private key (Kp) remain constant for a certain time period.
- Data clean room aggregates match rates for each party. Publisher and advertiser will receive information on the percentage of their respective data sets that matched. For example, publisher will know that 50% of their data set matched and advertiser will know 30% of their data set matched for a specific matching operation.
- At the end of the operation, both parties will get their PAIR IDs next to the raw identifiers for the matching records.
4. My take as an end user and an expert
- It looks fundamentally and technically secure. You know, I have been very concerned about online privacy for a long time. Making PAIR a new standard for identity resolution and achieving mass adoption would give me and everyone who involved a bit of relief.
- However, the risk will always remain when any party’s DCR is compromised, and the key is leaked. But this factor is irrelevant to the PAIR protocol itself. They also mentioned this in the security considerations section.
- I would strongly suggest not loading raw identifiers to the DCR. SHA-256 them first and then load these IDs to the DCR. But of course, both parties (advertiser and publisher) must agree on this method first. Otherwise, the IDs won’t match.
5. What could be more?
Taking user privacy to the next level would occur if login providers like Google, Apple, or Meta decided not to share user email addresses directly with advertisers and publishers. Instead, they could generate random email addresses and link these newly generated addresses to the user’s real email address. I would love to see if that happens. However, this kind of sign-in/registration step with mobile numbers would be much harder to do compared to email addresses.