Interoperable Private Attribution (IPA) Explained

When Meta and Mozilla team up to improve digital advertising, you should probably pay attention.

The two companies joined forces to create Interoperable Private Attribution or IPA, a framework for attribution measurement without tracking users.

Attribution measurement allows advertisers to gauge the performance of their ads in driving specific business goals. These goals, typically called conversions, could include a purchase, app install, or sign-up — outcomes that create actual business value.

Advertisers need to know if the money they spend on ads creates a measurable business impact. They want to know if users, who complete a conversion, viewed or clicked on an ad.

Advertisers learn if their advertising strategy works by attributing purchases or other goals to their ad spend.

Before we begin

I want to make a special thank you to Ben Savage for helping me understand IPA. Ben is a software engineer at Meta who helped create the IPA proposal.

I highly recommend checking out the excellent deck Ben produced that outlines IPA for a non-technical audience. You can view the full IPA overview here if you want to get down to the nitty-gritty technical details.

I believe the digital advertising industry should move away from cross-property data collection and toward solutions like IPA that do not require tracking individual users.

I also believe that bombarding users with consent agreements to gain their approval to track them is not an ideal solution. Consent banners annoy users, and most may not even understand what they give up.

We should move towards privacy by design advertising solutions that create a frictionless experience for users and do not require companies to share personally identifiable information.

Although, expecting the general public (and even those who work in digital advertising) to understand why solutions like IPA are more private is a tall ask.

I am not going to lie — IPA is a complex system. Without Ben's insight, I do not think I could write this post. But now that I understand the proposal better, it reaffirms my belief that we should move in this direction.

In this post, I hope to present the material in a way that will help others understand the concept and advocate for it and similar proposals

What is Interoperable Private Attribution?

Interoperable Private Attribution is a proposal that outlines a system for measuring advertising conversions without tracking individual users.

The dual Meta / Mozilla team behind the proposal approaches attribution using privacy by design principles, weaving together techniques that require minimal trust from the participants who choose to integrate with such a system.

IPA brings together disparate concepts from the deluge of proposals following the announcement by Google that they will deprecate third-party cookies. The team behind IPA cherry-picked the ideas with the most promise and has brought them together in a cohesive and impactful way.

The IPA proposal is especially notable given the unlikely duo behind the effort.

Mozilla, the team behind Firefox, has blocked third-party cookies by default in their browser since 2019. The privacy assurances behind Firefox remain a key differentiator from the most popular browser, Google Chrome.

Meta, a titan of advertising, raked in advertising revenue of $32.64 billion in Q4 2021 alone. The company has a vested interest in helping advertisers effectively measure the performance of their ads.

Why do we need Interoperable Private Attribution?

The days of wanton and unchecked user tracking are coming to a close. The well of cookies and device identifiers that allow digital advertising platforms to track a user across websites and apps is drying up.

Chrome aims to deprecate cookies in Chrome by 2023. Apple already effectively killed their iOS device identifier, and Google recently announced a two-year timetable to do the same with their Android device identifier, GAID.

Advertising platforms rely on these identifiers to tie together ad impressions, clicks, or other ad events with conversions.

Ad platforms log your identifier (device ID, cookie, or email address) when you view an ad. When you convert (purchase, install, etc.), the advertiser sends your identifier to an advertising platform to measure the intersection of those who viewed an ad and those who converted.

With no identifiers left, the digital advertising industry has tried to cling on by introducing universal identifier solutions like The Trade Desk Unified ID 2.0 or LiveRamp Authenticated Traffic Solution (ATS). Both products use email addresses as tracking identifiers.

These solutions face many challenges, including the scale of logged-in users, uptake by publishers, and techniques by Apple and other companies to curtail their usage. Google also made it clear that it will not implement any universal identifier solution.

So that leaves us with solutions that do not require sharing personal data like email and are private by design, solutions like Interoperable Private Attribution.

How does Interoperable Private Attribution work?

One thing to keep in mind is that Interoperable Private Attribution is still in the early phases of development. The proposal is now in the wild to gain feedback, iterate, and improve. So we will examine the proposal at a high level, and by the end of this section, you will have a working knowledge of the components and participants of IPA.

My first goal is to provide a quick overall summary of the main components of IPA and then review some novel details in the section following the overview.

To understand IPA, you must understand three distinct components:

1. Match keys

2. Event generation

3. Aggregate attribution measurement

Match Keys

Without cookies or device identifiers, advertising platforms will still need a key to tie ad events to conversions.

IPA proposes a match key to accomplish this task. A match key is a proposed write-only identifier that only a browser or operating system could read.

Any app or website that requires a user login can set a match key at the browser or operating system (OS) level. Participants leveraging IPA could then access (not read) a match key to use for attribution measurement.

The usefulness of match keys increases with reach and cross-device usage. With this in mind, someone leveraging a system like IPA would want to rely on services with vast user bases across many different devices like Google, Facebook, or Twitter.

These services can store a match key in a browser / OS and allow anyone to use that key to perform conversion measurement (without anyone ever able to read the key) with IPA.

For IPA to work, browsers and operating systems must adopt the concept of a match key. They must provide an API for a website or app to:

• Write a match key to a browser / OS

• Fetch a match key to include in an IPA event (without revealing the actual key)

A browser or operating system cannot ever reveal a match key since doing so would violate the privacy by design principles laid out in IPA. However, they need to provide a mechanism to include it in an outgoing IPA event (more on that below).

So assuming an app or web service with a large user base, like Google, was interested in making something like this work, it could write a match key to the browser. The browser would store the mapping of a URL to a match key:

In this example, a browser ties a match key to a user's Google login, but any other service could also be a match key provider and store a match key. If iOS supported IPA, and the same user logs into a Google app on an iPhone, iOS could privately store a match key in the operating system. Apple could make the match key available for IPA but never reveal the actual value to anyone using it.

A match key may sound like a UID2 or a universal ID at this point, but the other components of IPA are what set it apart. Keep reading to find out how.

Event Generation

Browsers and operating systems would also need to implement a new API to allow apps & websites (or the ad tech vendors working with them) to generate two types of events: source and trigger events.

Source events

Source events include impressions, clicks, ad opportunities, or any other relevant metric used when measuring ad delivery.

Trigger events

Trigger events are conversion events like purchases, app installs, or sign-ups. Any action a business wants to drive through advertising.

The event generation API would return a standardized event that includes one or more encrypted match keys (corresponding to the match-key providers a developer specifies in the API call).

A website or app would generate and send the event to a server (most likely an ad tech vendor) whenever the event they want to track occurs — similar to any real-time tracking call made today.

Aggregate Attribution Measurement

Now comes the fun and innovative part. To measure attribution, whoever collects the trigger and source events will bundle them up and periodically make a query to a set of semi-trusted servers to receive aggregated attribution results.

Browsers and operating systems would need to identify a set of companies or non-profit groups they trust to operate these semi-trusted servers. Developers would be able to choose two of these companies from this menu.

When generating IPA events, the data would be encrypted towards the two entities the developer chose. The browsers and the operating systems cannot run the servers themselves since they would have all the user data and the encryption keys to unlock it.

Now you may be asking: "But wait! Then a semi-trusted server could see a match key!" That would be true, except this is where a key innovation of IPA comes into play, a concept called MPC.

Interoperable Private Attribution employs a concept called multi-party computation (MPC). Stay with me here because this might be the most complicated part of the summary section, but very important nonetheless.

MPC is a method of cryptography that allows multiple parties in a single system to protect inputs (in this case, match keys) from each other. IPA uses an MPC model to ensure that both servers must turn malicious and collude to decrypt a match key and reveal a user's identifier.

The ultimate goal is to ensure user privacy even if one server turned malicious, but the proposal has open questions to answer to achieve that.

One of the key cryptography concepts used in the IPA proposal is homomorphic encryption. This technology allows one semi-trusted server to scramble the match key while it is still encrypted. This way, neither semi-trusted server ever has a chance to see the original value of the match key. The first one only saw encrypted values, and when the second one decrypts it, it has already been scrambled.

Through the “multiparty computation”, the two helpers would match up source and trigger events that originated from the same person (without knowing who that person was). They would then produce aggregated results, like counts of attributed events, or sums of attributed conversion values.

Ad tech vendors wanting to receive aggregated attribution results will need to enter a business agreement with two companies offering semi-trusted IPA servers. In a model similar to Amazon EC2 - they would need to pay for the compute they use to produce an aggregated report.

The IPA proposal would support two kinds of queries.

Ad Networks and publishers would run “source fanout queries” to count how many conversions (triggers) resulted from a set of source events.

Ad buyers would run “trigger fanout queries” to do the opposite, to count how many conversions (triggers) were attributable to each channel where they buy ads.

Neither type of query would ever reveal data about individual users.

IPA Deep Dive

An IPA Deep Dive may sound like a cleverly named beer (I had to sneak one IPA joke in here), but this is going to be a little different.

The summary you just read is a massively simplified version of Interoperable Private Attribution. It is like saying Golf is a game where you put a ball in a cup without going over any other details.

My goal for the prior section was to describe the main components of IPA and how it worked at the highest level so that anyone not interested in the more technical details could walk away with conversational working knowledge of the proposal if they skipped this next section.

I highly recommend that you continue reading this next section to learn about other novel concepts of IPA, but if the details are not your thing, skip this section.

Double Encryption and Blinding

Before any source or trigger events are sent to the MPC, they are double encrypted — once for each trusted server. A single semi-trusted server could not read a match key with its lone decryption key.

Also, each server uses a technique called blinding. After decrypting one layer of encryption, a trusted server applies a random value (blinding factor) to the output before passing it to the second trusted server. The second server decrypts the blinded output of the first server and applies its own blinding factor, resulting in a double-blinded match key.

Two double-blinded match keys from the same person would now match up, while the double-blinding ensures that neither server could ever know the value of the original match key.

But since the double-blinded match keys between source and trigger events match up, the semi-trusted servers can perform attribution and sum up the conversion value across all the attributed trigger events. Source events from ads bought across different ad networks would even match up, enabling advanced capabilities like cross-publisher attribution.

Differential Privacy

Differential privacy is a system used to reveal information from a dataset without identifying individuals in that dataset. Differential privacy involves introducing noise (random data) to outputs to make it impossible to determine data about a specific person.

IPA would use differential privacy to prevent attacks from actors trying to determine individual identity.

Imagine that a social media platform called SocialApp has logged-in users, and they assign emails alongside IPA source events that they collect.

SocialApp sends 100 source events and 50 trigger events to the MPC and receives 20 conversions, let's say a purchase from a bidet DTC brand. If SocialApp sends another query and removes one source event, but then receives 19 conversions, that provides them valuable information.

Since SocialApp has a first-party logged-in email stored alongside each source event, they can now know that the email associated with the one removed source event bought a bidet. They could then place that email in a privacy-intruding buttwasher enthusiast audience segment.

To prevent this, IPA proposes adding random amounts of noise. The noise would ensure that the sum of conversions would change with each query to the MPC. So in our example, SocialApp would receive conversion sums within a random range. So in the first 100 source query, they could receive a conversion sum with a +/- random noise of 5, altering the output trigger value to somewhere between 15 - 25.

With IPA, the amount of noise does not change with larger batches of events sent to the MPC since it would be more challenging to identify an individual in a large data set. So the larger the batch of events you send, the better quality of aggregated results you receive.

Privacy Budget

Our friend SocialApp could still keep issuing requests over and over to where they could hone in on the actual conversion sum, even with noise introduced. If they averaged out the conversion results they received, they could probably guess the actual value. That is why IPA presents the concept of a privacy budget.

Entities submitting requests to the MPC would be allotted a privacy budget within a 7-day window. With each request, they would specify how much of their budget they want to spend. The more budget they spend, the less noise the MPC output would contain.

So you could choose to blow your weekly privacy budget into a single query to get super accurate results, or you could spread it out over the week to get more frequent but less accurate results. Either way, the privacy budget would ensure that you could not zero in on a person by gaming the system.

IPA Adoption

Congrats for making it through the deep dive, or if you skipped it, hello again. Interoperable Private Attribution brings together multiple novel concepts to deliver attribution measurement at the highest privacy standards.

The complexity of IPA is daunting and will require buy-in from major browsers (looking at you Google) and operating systems (now I'm looking at you Apple).

The good news is that both Apple and Google are on board with the privacy by design approach to digital advertising.

Whether for marketing (Apple) or fear of regulatory scrutiny (Google), both of these tech behemoths have rejected the notion of universal or any freely available tracking identifier and have committed to designing targeting and measurement systems that do not require pervasive tracking.

Google has their Privacy Sandbox, and Apple released their flavor of attribution tracking, SKAdNetwork.

IPA vs. SKAD

If you want to learn about SKAdNetwork, check out this article I wrote about it. It is a system designed by Apple to provide app install conversion reporting without tracking users.

Unlike SKAD, IPA offers some unique advantages:

• Available cross-device (not iOS-only)

• Conversion signals are not time delayed

• No campaign limits

The proposal does not lock IPA into any one specific environment. Conversion measurement can occur cross-device without tracking.

SKAD also time delays conversion signals 24-48 hours to prevent bad actors from correlating specific users to a conversion. IPA does not require this since apps or websites can generate and log conversion events on demand and then immediately call the MPC for an aggregated attribution report.

SKAD also imposes limits on the amount of information available in a conversion event. Because of these limitations, Facebook limits advertisers to 9 campaigns when using SKAD. Apple does this to mitigate using any information to pinpoint a user.

Interoperable Private Attribution faces big hurdles ahead. To provide its full promised value, each major browser and mobile operating system would need to adopt it.

We know Mozilla is down for it, so Firefox and its 4.18% market share is a start. But bringing on Apple (iOS & Safari) and Google (Chrome & Android) is imperative to cover most of the digital advertising ecosystem. Without the two juggernauts of tech, IPA is DOA.

Subscribe to the Ad Tech Explained Newsletter

Ad Tech Explained provides explainers, insights, and analysis on the latest trends in advertising technology.

Photo by Kelvin Ang on Unsplash