How the campaign finds a user it already knows
By Luca Passani, @Scientia_CTO, July 2026

Note: this article assumes that you are familiar with multiple programmatic/ad tech concepts. If not, make sure you read the previous installments. At the very least, you should read the previous article on ID providers and identity graphs. That’s the foundation for audience activation, a complex topic that I will cover in this article and the next one. Here’s the itinerary. First, you’ll learn about the machinery the industry built to avoid passing users’ personal data in clear text that everyone can see: the data clean room. Then you’ll see how a clean-room match becomes a live campaign and who the main players are. By the end, House of Frada will have found Sloane at auction without anyone ever exchanging her email. This is called the deterministic path. In the next article, we’ll do it all again for the users nobody can identify — the probabilistic path.
The previous article showed how the programmatic machinery can add a unique (and “consented”) user ID to bid requests. In this installment, I’ll show how brands harness that foundational signal to target user segments or even specific users. Our example continues from the previous article: Sloane Elizabeth Carver, a fictional businesswoman from Manhattan (whose bid request we’ve already dissected) who happens to be a past customer of House of Frada, our fictional brand.
What follows is the same fictional bid request from the previous article. Much of it should be clear by now, but probably not everything.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BID REQUEST #7f3a9c2e ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ INVENTORY Publisher The Gotham Times Page gothamtimes.com/section/fashion Ad slot Leaderboard 970×250, above the fold Floor price $4.50 CPM Content tags Fashion, Style, Luxury USER UID2 token AgAAAeJ0uGcX7j3kL9mNpQrS8tUvW2xYz4B5C6D7E8F9G0H1I2J3K4L5M6N7O8P9Q0R RampID token YWJjMTIzNDU2Nzg5MGFiY2RlZmdoaWprbG1ub … dsU1RVVldYWVoxMjM0NTY3ODkw Year of birth 1996 (inferred) Gender Female (inferred) Location Manhattan, zip 10013 Privacy GDPR: not applicable | US privacy signal: not opted out AUDIENCE SEGMENTS (from identity graph) luxury_fashion_buyer confidence 0.96 ✓ household_income_180k+ confidence 0.88 ✓ manhattan_resident confidence 1.00 ✓ no_children_household confidence 0.82 ✓ in_market_accessories_30d confidence 0.79 ✓ frada_crm_match confidence 1.00 ✓ ← clean room output ACTIVE CAMPAIGNS MATCHED ┌─────────────────────────────────────────────┐ │ Strada by Frada — New Collection Launch │ │ Target: luxury_fashion + frada_crm_match │ │ Max bid: $22.00 CPM │ │ Budget remaining: $48,400 │ └─────────────────────────────────────────────┘ DEVICE Type Smartphone Make Apple Model iPhone 17 Pro OS iOS 26.5 Screen 402×874 px @3x resolution Connection T-Mobile Location SoHo, New York City ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
One aspect that you probably still find elusive is how the DSP knows all that information about Sloane. We know her full name because I mentioned her in the story, but the ad tech ecosystem doesn’t care about her name. Quite the opposite, in fact.
Note: ID providers, SSPs and DSPs are proactive in NOT WANTING to know (and store) a user’s real name, as this would go a long way in blowing the cover that “they don’t know your name; they just know it’s you”. This increases the distance between private companies and the most precious personal information a person has, the information that cannot be revoked and re-issued. This distance is safe to have in the age of personal data protection.
What the programmatic machine does care about is that this user is a luxury fashion buyer, with high income and lives in Manhattan. And now that House of Frada is running a campaign, they care even more that Sloane is a past Frada customer, which places her squarely within the audience they intend to activate.
Enter the Data Clean Room (DCR) — Matching a Campaign to Specific Users
House of Frada knows Sloane is a VIP customer. They have her name, email, purchase history and lifetime value. Legally and practically, though, they cannot simply send that data to a DSP. Privacy regulations don’t allow freely sharing customer lists, and DSPs don’t accept raw PII (Personally Identifiable Information) anyway. And even if they did, Sloane’s email address never appears in the bid request. The DSP would have no way to connect her CRM profile to the “anonymous” ID that travels with her as she browses the web.
Note: By now, it should be abundantly clear that personal information is “radioactive” for ad tech companies (or for any legal entity, for that matter). The right mental image is people with hazmat suits handling plutonium with extreme care. Any spillage could wreak havoc in a company’s reputation and cause heavy fines for the organization. I’ll illustrate GDPR, CCPA and their respective legal frameworks — i.e. the regulatory landscape around personal data — in a dedicated article later in the series.
The solution that works around the need to pass personal data among third-party companies is the data clean room (DCR). As the story goes, the term comes from real semiconductor clean rooms (the ultra-sterile rooms where computer chips are made). In those rooms, even a single speck of dust can ruin an entire batch of chips, so everything is strictly controlled to keep contaminants out. A data clean room borrows the same idea of strict boundary control, except here, what’s controlled is what’s allowed to leave. Raw personal data goes in, but it can’t come back out. The only thing permitted to cross the boundary is the agreed-upon result.
Data clean rooms support multiple use cases, but the most obvious is enabling two or more parties to match their data without either side exposing its raw customer lists to the other. Each party pushes their data through a slot. Inside the room, the data is matched and analyzed.
Example: Imagine an airline (say United) and a hotel franchise (say Marriott) want to run a joint marketing campaign to offer high-spending customers a promotion that’s too good to refuse. This would mean that one of the companies has to disclose their customer data to the other party, which is far from ideal and most likely illegal in many regions, unless they use a data clean room to discover where the data overlaps. The result is a (joint) audience that they can activate for advertising and marketing purposes.
Each party can see the match results and conclude that, say, 82,564 customer IDs are in both datasets. Importantly, neither party ever sees the other’s raw data.
The United & Marriott scenario is the symmetric use case — two brands finding their shared customers — and it’s good to help explain how DCR works. Our House of Frada’s situation is the one-sided variant: it isn’t matching against another advertiser’s list, but onboarding its own CRM to an identity partner, so the overlap gets written to the portable ID (say the RampID or UID2) already riding on Sloane’s bid request, which is what lets The Shade Desk (our fictional DSP introduced in the previous article) recognize her at auction (frada_crm_match confidence 1.00).
Glossary: Here’s an expression you may want to remember: Private Set Intersection, or PSI, is the cryptographic technique behind the two-party overlap: it returns the shared records without either side exposing its list. It’s one privacy-enhancing technology (PET) among several that a clean room uses.
PSI overlap vs. onboarding: United & Marriott is an example of PSI overlap, i.e. the match happens against a named counterpart. In our Frada case, that’s onboarding through an identity/activation partner like LiveRamp or TTD.
I’ll use some pseudodata to illustrate how the CRM match is achieved in our House of Frada example that involves an identity partner.
Frada’s CRM data
Frada has a big database with customer information in its CRM. This data never leaves Frada and looks something like this:
email first last lifetime last_order
value
sloane.carver@example.com Sloane Carver 14,200 2026-04-18
marcus.webb@outlook.com Marcus Webb 3,050 2026-02-02
This data gets transformed into something different before Frada (or its agency) sends it to the DCR.
Frada sends its data to the clean room
The data from Frada includes normalized, SHA-256-hashed emails plus a segment label. Of course, it does not contain names, nor raw addresses, nor any PII for that matter. Email address normalization (lowercasing and trimming) matters as Sloane.Carver@example.com and sloane.carver@example.com must hash identically or the match silently fails.
email_sha256 segment 9f2a7d…c14e frada_customers b1c8e4…77a0 frada_customers
Inside the room — partner resolves hashes (Frada never sees this)
The identity partner operates inside the room. It can resolve each hash against its identity graph to a RampID. Frada never sees this table; the partner never sends raw data back.
9f2a7d…c14e → YWJjMTIzNDU2Nzg5MG … oxMjM0NTY3ODkw (Sloane’s RampID) b1c8e4…77a0 → (no match, not part of the identity graph)
Output to House of Frada
The only information that Frada sees is a report with aggregate data: input count, matched count, match rate. Nothing per-person.
input: 42,318 matched: 31,902 (75.4%)
Out to the DSP: opaque segment, no PII
The clean room has produced what is needed for the activation and pushes the report down to The Shade Desk (the DSP): the segment is a list of opaque RampIDs labeled frada_crm_match. Importantly, no emails ever leave the DCR.
segment: frada_crm_match [ YWJj…NTY3ODkw, Zk9t…4WpQ, Q1p8…Lm3v, … ] // 31,902 members
i.e. a list of RampIDs.
Ready for the auction!
This closes the loop. As we learned in the previous article, when the auction happens, Sloane’s request already carries her RampID. TSD checks it against the segment Frada (or its agency) loaded in its system. Sloane’s bid requests are recognized and the system is authorized to bid as much as $22 CPM to reach her specifically.
A note about retargeting, the psychology behind it and frequency capping
What you’ve just watched has a household name: retargeting. The name might be new to you, but pretty much everyone experiences it daily. You look at tickets for a Lady Gaga concert once, and those tickets stalk you online for a month. The mechanism that enabled that was built on third-party cookies originally (the advertiser’s pixel on your browser, recognized across every site you visited). That machinery was built for a world of third-party cookies, and that world is shrinking. What Frada just did is retargeting rebuilt on the new rails — a consented customer list, a clean-room match, an identity token — narrower in reach but on much firmer ground.

Figure: Retargeting illustrated (with a little help from ChatGPT).
Retargeting works because of psychological principles like the mere-exposure effect and recency bias. When someone visits a site or views a product, their brain already has some familiarity and interest. Seeing the ad again later keeps the product top-of-mind, reduces friction, and gently nudges them back toward conversion (often using subtle urgency or FOMO). However, too much repetition creates ad fatigue — people get annoyed, ignore the ads, or develop negative feelings toward the brand. Frequency caps solve this by limiting how many times the same person sees a specific ad within a set time period (say, three times a day or ten times a week). They strike the right balance: enough exposure to drive recall and action, without crossing into irritation. Good frequency capping improves both performance and brand perception.
Note: Whether retargeting is service or stalking is a question we’ll take on seriously in the privacy article, later in the series.
Let’s appreciate the following aspects before we move on:
- Hashed email is not anonymous. Under GDPR a SHA-256 email is pseudonymous personal data, and the RampID is persistent and linkable too. You may see the term “anonymized” thrown around casually. While it’s true that no raw PII crosses the boundary and neither side sees the other’s list, that’s not anonymity, but rather a privacy claim that serves the purposes of the industry. This might look like nitpicking, but it’s not. Appreciating the finer points of privacy regulations helps you make sense of why things are the way they are in programmatic.
- A brand’s CRM segment is a buy-side secret, and it’s not broadcast. frada_crm_match is not blasted into the open bidstream; that would leak Frada’s customer list to every competing bidder. It’s resolved inside the buying DSP. The mock bid request that the TSD people saw on the screen in our little fiction is what a DSP sees after its own resolution, not what the SSP sent to everyone.
- The agency is often the real actor. In practice, the agency/trading desk holds the DSP seat and runs the onboarding on Frada’s behalf. When I wrote “Frada or its agency”, that clarification is doing significant work, as the agency is often the one pushing the buttons.
The Devil in the Details
The walk-through above may have conveyed the idea that clean rooms are all cool and dandy. In practice a handful of details decide whether a match is worth doing at all.
A clean room only lights up the overlap between two datasets, and that overlap is rarely as big as anyone hopes. Real-world match rates commonly land between 40% and 70%, depending on how good each side’s identifiers are and where the users live.
Note: You may wonder where the 40–70% range comes from, and the honest answer is: from triangulating sources that don’t fully agree. Published benchmarks put typical CRM onboarding at 40–60% and clean hashed-email lists at 60–80%. Meanwhile, LiveRamp’s own site advertises a 99.5% match rate. How do you reconcile 40% with 99.5%? You don’t — they measure different things. One number counts how many records match into the vendor’s identity graph on complete PII; the other counts how many of your hashed emails resolve to users you can actually reach. Every player defines “match rate” the way that makes its own machinery look best. An Italian idiom goes “tirare l’acqua al proprio mulino” (“everyone pulls water toward their own mill”). Keep the expression in mind: it describes half the numbers in this industry, including a few in this article.
Sloane’s 75.4% sits on the healthy side of that range, and Marcus — who resolved to no match in our example above — is not an anomaly but the normal case. A weak match rate throws no error. It just silently shrinks the audience you can actually activate. Match rate is the clean room’s answer to the addressability question from the last article: of all the people you want to reach, how many can the machinery actually find?
“Raw data can’t leave” is only half the guarantee. The other half is that the results can’t be reverse-engineered back to individuals. Clean rooms enforce this with minimum-cohort thresholds — a query has to touch enough users that no single person can be singled out (often tens of users, though the exact floor varies by platform) — and sometimes by adding statistical noise to the output.
Note: chances are you know the term cohort from school, business, or Covid news (“age cohort”). If not, replace mentally with ‘group’ for a reasonable approximation. The term is widely used in advertising.
An aggregate can leak an individual even when no raw record ever crosses the boundary. If that sounds theoretical, consider the famous result that ZIP code, gender and date of birth alone are enough to uniquely identify the vast majority of the US population (87% according to this study). Aggregates leak more than intuition suggests.
Note: Delving deeper into other PETs (privacy enhancing techniques) such as K-anonymity and statistical noise would bring us to the wrong side of the 80-20 equation. The core takeaway is to prevent reverse-engineering the data in ways that may make users identifiable.
Note: Not everything sold as a “clean room” is actually one. Plenty of offerings wearing the label are ordinary data sharing with a contract stapled on top. The line that matters is whether privacy is enforced by technology — the operator itself cannot see the raw data — or merely promised in an agreement you have to trust. Only the first kind is doing what the name implies.
Note: Even technology-enforced DCRs might have loopholes: the room can prove that nothing leaked, not that what went in was genuine. A counterparty could feed the room a dictionary of every plausible identifier instead of a real customer list and profile your entire dataset rather than a genuine overlap.
Note: clean rooms don’t launder consent. A match is only lawful if the data going in had a lawful basis to begin with. The room governs what leaves; it does not retroactively manufacture permission that was never given. The legitimacy of graphs built on hashed-emails is under regulatory scrutiny.
An idea that I certainly don’t want to convey is that clean rooms are turnkey solutions. A clean-room match means SQL, data engineering and, increasingly, both parties sitting in the same cloud. This is enterprise-class brand and agency territory, i.e. not infrastructure that a mid-tier publisher can spin up on a Tuesday afternoon.
In addition to keeping one’s data private, DCRs support a variety of marketing, technology and legal use cases around the purpose of the matched data, how the data is shared, against which ID should the match happen, who has access to it, how long the data is retained and how it is disposed after the agreed use. Specifically to marketing use cases, customer activation and co-marketing opportunities are only two of them. Other examples are customer insights, customer experience improvement, campaign planning, attribution.
This explains the great variety of solutions on the market which I’ll get to shortly.
Clean Rooms and Walled Gardens
If I asked you to reply off the top of your head whether Walled Gardens need clean rooms, you might instinctively say No. But if I gave you a moment, you’d probably realize that, while an advertiser may leverage Meta, Google and Amazon for audience activation, it’s not okay with sharing its customers’ data with them. This is why those tech giants also offer sophisticated clean rooms to advertisers.
Of course, I’m not implying the walled-garden clean room is the same tool as what Frada used in our fictional example. A garden clean room matches against the garden’s own graph and lets nothing user-level out, so you can’t onboard to a RampID and ship it to an independent DSP.
I’ll provide a longish list of major DCRs on the market. Skim it if you’re short on time and come back to it when a vendor name crosses your desk. As a minimum, be aware that DCRs come in three families worth knowing. When someone mentions a data clean room, chances are that it falls into one of the following three categories.
- Independent (“neutral”) DCRs. Our Frada example implies the use of one such clean room. I’ll mention the main industry player shortly, but be aware that the “independent” and “neutral” adjectives might be misplaced for some of the big players. I’ll say more about a series of acquisitions that challenge this characterization shortly.
- Walled-garden DCRs — These came first. Each lets an advertiser query campaign performance against the platform’s own user data without ever seeing it — but only against that platform’s properties. Useful inside the garden, useless outside it.
- Cloud / infrastructure DCRs — If both parties already store their data in the same cloud, no files move at all — you just open a window between two databases. This “warehouse-native” model is the dominant one as of 2026.
What follows is an overview of the major Data Clean Rooms on the market.
Independent DCRs
These are the clean rooms that connect your CRM to the open web, i.e. the kind Frada would use to onboard Sloane’s RampID without exposing her email.
- LiveRamp Clean Room — The one with RampID baked in: it resolves hashed PII to a RampID inside the room, which is exactly the onboarding step in our fictional example. It began as Habu, an independent — until LiveRamp bought it in 2024. Which is where “neutral” starts to wobble: the clean room and the identity it resolves to are now the same company. In May 2026, Publicis (a major agency “holdco”) agreed to acquire LiveRamp. You may recall a reference to this acquisition in this article. This was a major event I’ll comment on shortly.
Note: Holdco = holding company. In advertising, this shorthand industry jargon identifies one of six or seven giant parent companies that own hundreds of agencies and dominate the industry (presented in a previous article). Global brands sign Master Service Agreements with the holdco, not each agency. Finance, legal and tech stacks often sit at holdco level. So “holdco rates”, “holdco terms”, “holdco clean room” are real operational things. - InfoSum — For years InfoSum embodied the purest expression of the idea — the data never moves, each party’s records stay in their own “bunker”, and only the overlap is computed. Widely considered the last genuinely independent clean room, until WPP’s GroupM acquired it in April 2025. So the two standard-bearers for independence (LiveRamp and InfoSum) now sit inside their respective agency holdcos. More about this shortly.
- Decentriq — Still independent, and built on the strict version of the privacy guarantee: confidential computing. Instead of relying on software rules, data enters the room encrypted and is processed inside a hardware-isolated enclave (a Trusted Execution Environment or TEE) that is completely blind to everyone, including Decentriq itself. It is the ultimate reference for a critical distinction: privacy enforced by immutable hardware, not by a legal contract you just have to hope the operator follows.
- Optable — An independent “publisher-leaning” clean room. With Optable, a publisher can build an identity graph that mixes both known IDs (emails or alternative IDs) and anonymous behavioral events (for example, “users who read the fashion section 5 times a week”). This means the publisher can pack that anonymous traffic into valuable targetable segments for advertisers, rather than letting unauthenticated inventory go to waste. An additional killer feature for publishers are Flash Nodes, which function as lightweight PSI (Private Set Intersection) environments. They allow publishers to instantly invite an advertiser to match data for a campaign without forcing that advertiser to sign a contract or endure a heavy-duty corporate DCR onboarding process. Native integration with ad servers like GAM is the final piece that hooks it directly into the sell-side’s daily workflow.
The implications of LiveRamp and InfoSum’s acquisitions on neutrality
In this article, I presented LiveRamp’s (agreed) acquisition by Publicis as a big deal. At the time, we still didn’t have the background to properly explain the implications. We do now. InfoSum’s acquisition by WPP one year prior falls in the same category. “Independent” and “neutral” are two foundational properties on which DCRs build their reputation. As those companies are acquired by entities with their own demand-side interests (the holdcos), those labels are increasingly contested.
RampID is not Publicis’s private tool. It is shared infrastructure — one of the three identity standards the open web leans on, wired into tens of thousands of publisher domains and used across the industry by advertisers and agencies alike, Publicis’s rivals included. That is exactly the problem. Publicis is not a neutral party. It is a buyer — an agency group that spends its clients’ media budgets, and one that already owns Epsilon and Lotame (DMP/Identity Graph).
When a massive advertising holding company buys that clean room, neutrality evaporates. Imagine you are the CMO of BMW, and your agency is Omnicom. If you want to match your customer data against a media partner using infrastructure owned by Publicis, you have a problem. You are being asked to hand your most sacred, first-party customer list into a system controlled by a direct competitor’s agency, i.e. the very people whose day job is helping Mercedes-Benz take market share from you. This is not a small issue; it’s a massive structural problem.
Nobody has to actually steal or misuse your data for this to be a disaster; the underlying incentives have completely shifted. The moment the entity that owns the toll road also owns a fleet of cars competing for the exact same passengers, “neutrality” is no longer a feature of the system; it’s a promise you have to take on faith.
To be clear, both companies have publicly pledged that LiveRamp will run at arm’s length after the close (no preferential pricing, no insider deals, everything by contract), and no wrongdoing has been shown. But it is the same shape we saw elsewhere in this series: Google owning the ad server that gets last look, an SSP that also curates its own supply (quietly shifting from basic traffic shaping to running its own higher-margin private brokerages). Once a single player owns the neutral layer and bids on one side of it, “neutral” stops being a property of the system and becomes a claim you take on trust.
Walled Garden DCRs
- Google Ads Data Hub (ADH) — Query Google and YouTube event-level data against your own, get aggregates back, and export nothing user-level. Built on BigQuery. The textbook “useful inside the garden, useless outside it” case.
- Amazon Marketing Cloud (AMC) — Same shape for Amazon’s shopping and media signals, with one detail that makes our point for us: you can build an audience, but you can only activate it through Amazon DSP — Amazon built that linkage specifically for its own DSP and won’t open it to third-party DSPs. There’s no path to ship an AMC-built segment to an outside DSP like The Shade Desk, which is precisely why Frada’s open-web match can’t happen here.
- Meta Advanced Analytics — Meta’s environment for querying campaign data against Meta’s signals. Newer and more limited than ADH or AMC — still access-gated as of 2026 — and, like the others, bounded by its own properties.
- Retail media clean rooms — I already mentioned how major retailers (Walmart, CVS and others) leveraged their data to build identity graphs and enter the programmatic arena directly. It’s a walled-garden play on their first-party purchase data similar to the one by tech giants.
Cloud / infrastructure DCRs
- Snowflake Data Clean Rooms — Snowflake was originally created as a Data Warehouse system. When third-party cookies began to crumble and global privacy regulations tightened, the advertising industry panicked. Marketers needed a way to match customer lists against publisher audiences without either side seeing the underlying raw data. Snowflake realized they didn’t need to build a clean room from scratch; they just needed to let two companies query data inside their secure vault without ever moving it. If both parties are on Snowflake, the data never travels, never replicates, and never leaves company walls; and the match happens exactly where the data already sits. By embedding identity partners like LiveRamp directly into their system as native apps (the next brilliant idea), Snowflake let brands translate raw customer data into portable ad signals instantly. One additional brilliant idea was acquiring Samooha, a startup that specialized in building visually pleasant, no-code, point-and-click UI templates natively on top of Snowflake.
- AWS Clean Rooms — Amazon Web Services’ equivalent for data already sitting in AWS. Worth not confusing with AMC: this is neutral cloud infrastructure, not Amazon’s advertising garden.
- Databricks Clean Rooms — Snowflake’s direct competitor. Rather than forcing parties into the same proprietary cloud sandbox, Databricks leans into multi-cloud flexibility, allowing a brand on AWS to securely run a match against a publisher on Azure without moving or replicating a single file. It is heavily code-centric and designed around shared Spark notebooks, making it the weapon of choice for heavy-duty data scientists and engineers who want to build advanced, custom AI and lookalike models right where the raw data lives.
Conclusions
Everything in this article worked because Sloane logged in. Most people don’t. And that’s where the probabilistic side of the audience activation machinery kicks in. In the next article, I will run the same bid request through a universe where Sloane is not logged in, but the programmatic crowd still wants to do something with her bid requests. We will meet the machinery that bets instead of knowing.
