The Signal Landscape — Identifying Users

What the ecosystem actually knows about each user — and how it knows it.

By Luca Passani, @Scientia_CTO, June 2026

Note: this article assumes that you are familiar with multiple programmatic/ad tech concepts. If not, please make sure you read the previous installments.

The following bit of fiction is as silly as it gets, but bear with me for a little while.

Manhattan, New York City, 11:46 AM: Sloane Elizabeth Carver gets in a cab and pulls out her phone. She visits the Gotham Times. A few clicks later, she lands on an article in the Style and Fashion section.

Ashburn, Virginia, 11:47 AM: The TSD assessment panel is all reunited in room #12A, their eyes glued to the big screen in front of them. It’s a day like any other for TSD employees. They handle advertising campaigns the old-fashioned way: they let people assess each and every opportunity to pitch their customers’ products to consumers.

It’s approximately 11:47:23.441 AM when a bid request appears on the screen.  

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  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
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Daniel, the head honcho, initiates the usual round-table with a look at Jennifer.

“No GDPR and no US opt-out.” Jenny is the first to speak. “Great start.”

“We have the IDs. That’s very good. Looks like the identity graph has produced a good list of audience segments, too,” says Robert. 

“Wow! Look at that. We even have a direct campaign match. Perfect target for the House of Frada campaign,” Mike adds.

“Big time, Mike,” adds Karen. “Female, about 30, no kids, high income, interested in fashion. And a previous customer of House of Frada, no less.”

Everybody stops and looks at Daniel. After a brief moment of silence, the boss speaks:

“We absolutely want to take this opportunity. We should bid high. $22 CPM is fully justified,” is Daniel’s viewpoint, while Mike and Jenny nod in agreement. “Let’s do it!”

“Hold your horses,” interjects Jake.

“What now?” asks Daniel.

“According to my reference table here, we can get away with offering a lot less. If we offer $14, there’s a 90% chance that we still win the auction,” Jake explains.

“Fine,” says Daniel with a sigh. “You guys heard what bid-shader Jake said. $14 it is. Ship it!”

And this is a moment in the life of the bidder panel at The Shade Desk (TSD), a somewhat old-fashioned DSP. The panel’s job is done for now — until the next ding, when a new bid appears on the screen. The End.

If you’re wondering “what the heck did I just read?”, your reaction would be fully justified. Hopefully, though, you got the point. The fictional dialogue that unfolded among humans actually happens hundreds of thousands of times a second, each decision in less than 10 milliseconds, in the minds of computers in some data centers. Minus the drama, of course. As of June 2026, computers don’t have feelings. Yet.

Modern DSPs have the machinery to make decisions like that in real time, thanks to machine learning models trained to implement the logic our fictional panel illustrated. Bid shading included. Statistical machine learning models know that they can get away with lower bids than they are willing to pay. After all, their loyalty is to advertisers and their agencies, not the sell-side partners and their publishers.

The key insight from our fictional panel is this:

When identity is available, it trumps every other signal.

There’s not a lot to argue with here. This has been measured daily for as long as the industry has measured anything. Knowing the user and their shopping history is by far the most important data set to boost the efficacy of a campaign. After all, it’s pretty obvious if you think about it. Think of it this way: you’ve got enough budget to show 10 ads to sell a mountain bike. If you show them to 10 random people pulled from the pool of your 500 friends and acquaintances, your odds are slim. But what if you could target the 10 people in that pool who actually ride bikes regularly? In that case, your chances of selling that bike would go way up. That’s what identity does. It replaces guesswork with “intent”, i.e. a behavioral signal that shows purchase likelihood.

That’s what made DMPs so powerful during the wild west times I described in the previous article, and this is why the industry developed solutions that mimic the function of DMPs, without dependency on third-party cookies and — arguably — within the boundaries of different privacy regulations around the planet. These solutions deliver the personal data about each bid request that enables the functionality I described in the silly fictional piece at the beginning of this article. These solutions consist of components that interact with one another. Let’s start with the main one.

Introducing the identity graph

Imagine you walk into a hotel. You use your credit card at the front desk, connect your phone to the Wi-Fi, order room service from the restaurant, and scan your key card to get into the gym. Each of those interactions goes into a different system. But the hotel knows they’re all you because they share a common thread: your room number.

An identity graph does the same thing for your digital life. You check your email on your laptop (cookie A). You scroll Instagram on your phone (device ID B). You buy something on Amazon while logged into your account (email hash C). You watch YouTube on your smart TV (CTV ID D). To an advertiser, those look like four different people. An identity graph connects the dots and says, “Actually, this is the same human being”. Technically, grouping the different IDs is a process called “stitching”, short for stitching different identity signals together. There are two main types of stitching: Deterministic (when they know it’s you) and Probabilistic (when they can guess with reasonable certainty). 

Deterministic Matching (The “Gold Standard”) vs. Probabilistic Matching (The “Informed Guess”)

Deterministic matching relies on an exact, verified match. You log into the same email address on your laptop (Cookie A) and your tablet (Cookie E). The graph shows the same hashed email (HEM) attached to two different cookies and says, “These are 100% the same person”.

Probabilistic matching uses statistical models to infer a match when no login is available. Your Phone (Device ID B) and your CTV (CTV ID D) are always on the same Wi-Fi at 8:00 PM, share similar GPS coordinates, and have similar usage patterns. The algorithm estimates a 95% probability that they belong to the same household.

Figure: How fragmented IDs resolve to one anonymous profile.

These are the address labels that let you recognize someone across “touchpoints”, i.e. the point where a customer interacts with your brand:

• Hashed emails and phone numbers.
• Mobile ad IDs (IDFA on Apple, GAID on Android).
• Cookies and device IDs.
• Loyalty program numbers.
• IP addresses.

The identity graph’s job is to say: “ID 88273-X” is connected to all of these identifiers. That’s stitching in action.

Commercial Identity Providers

There are many commercial identity providers, but I’ll focus on the three main ones, which account for the bulk of the market (walled gardens aside). Many other identity graphs exist, but are typically more specialized. 

• RampID (formerly LiveRamp IdentityLink).
  • The OG. Built on hashed emails. Massive footprint in CPG (Consumer Packaged Goods). RampID is a people-based ID built to outlive third-party cookies.
• UID2, short for Unified ID 2.0 (The Trade Desk).
  • Email-based ID. Biggest adoption outside Walled Gardens. TTD open-sourced it (which arguably makes it auditable by everyone).
• ID5 (both the product and the company name).
  • Identity graph + probabilistic ID. Focused on browser signals, privacy-safe matching. Huge with publishers in Europe.

Despite using similar math, each player starts from a different place when reconciling the IDs.

LiveRamp (RampID) starts with offline data (names, addresses, phone numbers). They can resolve offline PII (Personally Identifiable Information, for example “John Smith” vs “J. Smith” at the same address) into a single ID using public records and proprietary data. When you log into a site using an email linked to that offline record, LiveRamp deterministically stitches your online device IDs to that offline person. This is extremely accurate for people-based marketing in the US, but relies heavily on PII, which is harder to use in the EU due to GDPR. The whole privacy issue will be explained in depth in the next installment of this series.

UID2 relies on authenticated logins (email addresses) as its primary deterministic anchor. When a publisher asks you to log in (or provide an email), the system hashes that email (turns it into a string of characters, HEM) and generates a UID2 Token. That token is passed from the website to the ad exchange. If you use the same email to log into a news site on your laptop and a shopping app on your phone, both devices generate the same UID2 token. The graph reconciles them instantly. This approach is sort of clean and arguably privacy-safe, but only works where users are logged in.

ID5 focuses on creating a shared “map” of relationships (an identity graph) that many companies can use, combining both methods. They ingest consented signals from a vast network of publishers and partners (such as hashed email addresses, IP addresses, and device IDs). If Partner A sees Device X with Email Hash 1, and Partner B sees Device Y with Email Hash 1, ID5’s graph connects Device X and Y. They use AI to evaluate “privacy-safe signals” (like device attributes and behavioral patterns) to probabilistically link devices where deterministic links are missing. ID5 has good reach in the open web (especially in Europe) because it doesn’t rely solely on logins, but on aggregated network data.

So far, I’ve covered the identity graph’s “who layer”.

Traits, Behaviors, Attributes: the “what layer” and the “do layer”

The identification part (stitching IDs together) is just the infrastructure. The actual data about the person and what that person does give the graph its value (also, this is what makes privacy advocates nervous). Commercial identity graphs can store thousands of data points per profile.

As you can imagine, the graph doesn’t generate this data autonomously. It pulls from multiple sources and links them to the profile. This is the same kind of data we encountered in the previous chapter when talking about DMPs:

• First-party data: What a company knows about you directly — your purchase history, your login behavior, your email engagement. This is the most reliable and the least controversial.

• Second-party data: Another company’s first-party data that they share or trade. For example, an airline shares frequent flyer data with a hotel chain.

• Third-party data: Data brokers aggregating information from public records, surveys, loyalty programs, and other sources. This is where things get fuzzy. These brokers pull from a wide mix of public and private sources — voter registration rolls, motor vehicle records, warranty card submissions, magazine subscriptions, and various financial and digital behaviors. The precise origins are often opaque, and the consumer whose data is being traded has no way of knowing what is in their file or how it got there. This approach is largely impossible in the EU, where such aggressive data aggregation runs directly into GDPR’s restrictions on processing personal data without a lawful basis.

Figure: Traits and behaviors associated with one anonymous profile.

The graph’s power comes from linking all these sources to a single pseudo-anonymous ID.

Note on deterministic vs. probabilistic: Identity graph vendors market themselves as deterministic because that sounds more accurate. And it’s true — when a user logs in with an email address, the match is often deterministic. What they don’t advertise, though, is that the traits and behaviors attached to that ID are almost always probabilistic. The graph may know with certainty that this ID is the same person across devices. But does that person own a dog? Are they in-market for a car? Do they have a graduate degree? These are inferences — statistical outputs, not facts. Even the most deterministic identity graph is built on a foundation of probabilistic guesses about who that person actually is. The ‘deterministic’ label applies to the stitching. Arguably, the ‘probabilistic’ reality applies to everything else.

What the Graph Does NOT Typically Store

Most commercial identity graphs do not store directly identifiable information such as your full name, physical address, or Social Security number. They operate on pseudonymous identifiers (hashed emails, anonymized IDs). In our initial example, Sloane Elizabeth Carver’s name does not show up anywhere in the bid request. This is not a coincidence. It’s the industry’s primary privacy defense: “We don’t know who you are, we just know it’s you”.

Identity Graph, Walled Gardens and the Advent of Retail Media

So far, I have focused on commercial identity graphs that serve the open web — ID5, LiveRamp, UID2. But the most powerful identity graphs are not for sale. They are owned by the walled gardens. Google, Meta, and Amazon did not need to build identity graphs in response to cookie deprecation. They already had them. Every logged-in user, every search query, every purchase, every video watched constitutes a firehose of signals they don’t need to buy from a third party. That first-party data, collected with every interaction, is the raw material for identity graphs that dwarf anything available to the open web. This is the confirmation, if one ever was needed, that user identity trumps any other signal when it’s present.

Amazon was relatively late to the Ad Tech game compared to Google and Meta, which is why its example is the most instructive. We witnessed an e-commerce website spawn a very successful programmatic ad business (Amazon Ads). A user shops on Amazon.com (e-commerce), watches Thursday Night Football on Prime Video (CTV), listens to a podcast on Audible (audio), and asks Alexa to set a timer (smart home). All of these activities are tied to the same Amazon account. The identity graph connecting them is not a product that Amazon sells. It is the engine of their advertising business. Amazon Publisher Services is an SSP, while Amazon DSP is the name of Amazon Ads DSP. Both companies sit under the Amazon Ads umbrella, but they are run as separate, independent entities. Amazon’s ad revenue in 2024 was approximately $60 billion. To put that in perspective, that is roughly the size of the entire open web programmatic market we have been dissecting in this series. And Amazon achieved it with a fraction of the complexity.

Amazon is not alone. Walmart has built Walmart Connect, its retail media network, on top of its massive first-party data set — purchase history from hundreds of millions of in-store and online shoppers. Walmart’s ad business is smaller (estimated at $5 billion annually) but is growing fast as advertisers seek access to Walmart’s shopping data. The same logic applies to Target (Roundel), CVS (CVS Media Exchange), Home Depot (Orange Apron Media), and Uber (Uber Advertising). Each of these companies sits on a mountain of first-party data about what people buy, where they go, and how they behave. Each has realized that this data is more valuable as an advertising asset than as a private record of transactions.

The term for this phenomenon is retail media. What makes retail media strategically important is not just its size — it is its efficiency. When a brand advertises on Amazon or Walmart, they are not guessing. They know that the person who sees the ad has an account, a payment method, and a purchase history. The conversion path is shorter. The attribution is clearer. The waste is lower.

This efficiency is the mirror image of the open web’s problem, which I already mentioned in previous articles. The open web has spent years building identity graphs, clean rooms, and consent infrastructure to answer the question: “Is this impression actually a real person who might buy something?” Amazon and Walmart do not need to ask that question. They already know the answer.

At this point, we understand a lot about how Sloane’s data ended up in the bid request we saw at the beginning, but not everything. One thing we do not understand is the privacy flags, but connecting the dots there will be easy, and I’ll do the connection in a moment. What requires deeper explanation is how The Shade Desk (our fictional DSP) connected Sloane’s bid request to the House of Frada campaign targeting Sloane specifically.

Collecting User Consent

If you read the article that explained the Consent Management Platforms (CMPs), you have probably already connected the dots by yourself. At some point, Sloane must have clicked on the CMP dialog box and consented to the use of her personal information for ad targeting. That choice reverberated in all bid requests that The Gotham Times (our fictional publisher) sent to its demand partners.

The consent string in a bid request doesn’t just say “Yes” or “No”. It encodes which legal framework applies. The CMP captures that distinction and stamps every bid request accordingly.

Note: I will cover US and EU privacy regulations in depth in the near future. Stay tuned. 

For EU users under GDPR, the CMP generates a TCF (Transparency and Consent Framework) string — a dense, encoded payload that lists exactly which vendors are permitted to process data and for what purposes. A DSP receiving a bid request reads that string and instantly knows whether it can use the user’s data for targeting, share it with measurement partners, require explicit consent, and so on.

For a US user, the logic may flip depending on which state privacy law applies. California has arguably the most stringent regime, but tracking is generally okay unless they’ve clicked “Do Not Sell My Data”. Virginia, Colorado, Connecticut, and others have adopted similar laws over the last few years. The CMP captures that distinction and stamps every bid request accordingly.

Privacy: GDPR: not applicable | US privacy signal: not opted out — i.e. the line we saw in our bid request — tells the entire downstream ecosystem which rules to play by. Under GDPR, the TCF consent string is the lock, and the DSP’s vendor registration is the key. No key, no bid. In Sloane’s case, it’s all pretty straightforward. Sloane clicked on “I agree” and all the bid requests generated during her browsing session will be marked as “consented”.

Identifying the User

I’m going to show you how publishers identify users and how that identity is passed to demand partners in a privacy-conscious way. To do this, you should know about an essential tool of the trade that lets you look at the plumbing of programmatic auctions as they happen in your browser.

Prebid.org has released and maintains a Chrome browser extension called Professor Prebid. This is a key tool for AdOps that need to test and troubleshoot Prebid.js installations. When you open a page that uses Prebid.js, it automatically detects the Prebid instance and provides a detailed view of your ad-units, bids, auctions and configuration. It lets you inspect auctions in real time, see which bidders responded, override CPMs, and check consent/ID module settings.

Figure: Professor Prebid add-on for Chrome in action on the Boston Globe website. 

Professor Prebid allows everyone to see which modules a publisher relies on to solicit bids from SSPs and perform other functions, such as user identification.

If you use Professor Prebid to look at which identity providers are used by the Boston Globe, you’ll get the complete list. You’ll recognize the three main players I presented earlier, along with a long list of more specialized ones.

• amxIdSystem — AMX RTB’s first-party ID, stored client-side and attached to bid requests for AMX-related demand.
• connectIdSystem — Yahoo ConnectID, an email-based, login/first-party identity from Yahoo’s identity graph.
• criteoIdSystem — Criteo’s user ID, used to improve match rates and addressability for Criteo demand.
• fabrickIdSystem — Neustar (now TransUnion) Fabrick ID, an identity-graph ID built from a hashed email plus an API key.
• hadronIdSystem — Audigent’s Hadron ID, which resolves a user ID and ties it to Audigent’s audience/data segments (curation).
• id5IdSystem — ID5’s shared, encrypted universal ID designed to work in cookieless and low-consent environments.
• identityLinkIdSystem — LiveRamp’s IdentityLink/RampID. Identity derived from authenticated (logged-in) traffic.
• liveIntentIdSystem — LiveIntent’s email-based identity (nonID), built largely from newsletter/email engagement.

Figure: the ID providers that are programmatically accessed when a user visits the Boston Globe’s page

• pairIdSystem — Google PAIR (Publisher Advertiser Identity Reconciliation), a privacy-preserving, clean-room-based matching protocol where publishers manage the IDs.
• pubProvidedIdSystem — Publisher-Provided ID, which lets a publisher inject its own first-party user IDs directly into the bid stream.
• sharedIdSystem — Prebid’s own open, first-party shared ID, generated and stored by the publisher.
• uid2IdSystem — Unified ID 2.0, The Trade Desk’s open-source deterministic ID based on hashed/encrypted email or phone.
• unifiedIdSystem — The original Unified ID from The Trade Desk, the cookie-based predecessor to UID2. Likely a stale config, as this was superseded by UID2.

Figure: User IDs by the different ID providers are added to the bid requests (user.ext.eids) that fan out to all Boston Globe’s demand partners 

That’s a lot of IDs. Publishers deploy multiple identity providers because no single one works for every user, context, or geography. The more IDs a publisher carries, the more buyers can recognize a given user, which means fewer unaddressable impressions. The industry has a name for this property: addressability, i.e. the share of your audience the machinery can actually recognize and therefore aim a campaign at. Better addressability is what ultimately supports better monetization.

Note: These ID modules are a two-way exchange. As they resolve a user into their own identifier, the vendors that phone home also log which site the user is on and when. Repeated across every publisher running the same module, this becomes a cross-site browsing history. But the module is only the smaller half: the real collection happens once that stable ID is attached to the bid request and broadcast to dozens of SSPs and DSPs, each of which can record it. The whole point of these IDs is to be persistent across sites, which is exactly what lets the entire bidstream — not just the issuing vendor — reconstruct who a user is and where they’ve been.

At this point, you might (incorrectly) assume that installing the ID provider module is all it takes. In reality, things are more complicated than that, and installing the module is only part of the solution. The module isn’t a detective that figures out who you are automagically. Rather, it’s the cashier who reads the card you already have. And if you never signed up, the cashier has nothing to read.

How does the ID provider know who Sloane is? Here’s the part that had me confused for a while: the Prebid module doesn’t figure it out. It can’t. Identity isn’t discovered at auction time — it’s established earlier, the moment a user logs into the publisher for the first time. Think of a store loyalty card. The first time you shop, you hand over your email address, and they issue you a membership number. You keep the card in your wallet. From then on, every visit, you flash it at the register and they recognize you — not because the register is clever, but because you’re carrying a number they minted earlier. And because that number is tied to your account, not to the store, you get recognized at every branch of the chain.

UID2 works the same way. When Sloane logged into the Gotham Times, the publisher hashed her email and, behind the scenes, exchanged it for a UID2 token — her member number. That token gets stored in the publisher’s own first-party storage (allowed, because it’s the publisher’s own site, not a third-party cookie). The Prebid module’s entire job, later, is to pull that token out of the wallet and flash it at the bid stream. It’s the cashier, not the detective.

Which means the module only carries an identity if one was issued. No login, no email, no token — nothing to flash. The system sees the most engaged, signed-in users perfectly, but not the anonymous reader at all. The login, it turns out, is the new cookie.

Note: This is why the cookieless world quietly became the login world, and why publishers have been growing increasingly desperate to get you to register, sign in and accept the newsletter. No login, no email, no token. The identity layer runs on authenticated traffic.

Note: The third-party cookie became the symbol of online tracking, so the industry’s move away from it was treated as progress by privacy advocates. But the cookie was the easiest tracker to block and the only one that politely expired. Today, we have deterministic, email-based identity stitched across our devices, which is way more durable and far less visible.

Note: No single “ID” wins on every axis — each trades strengths for weaknesses, which is why publishers often deploy several at once. RampID has unmatched offline-to-online reach in the US and deep CPG relationships (Consumer Packaged Goods, companies like P&G, Unilever, Nestlé), but it leans on PII-heavy matching that runs into trouble under GDPR and thins out outside the US. UID2 is open, deterministic, and clean when it fires — but it fires only for logged-in users, so it has nothing to say about the anonymous visitor. ID5 reaches further into the open web and is strong in Europe precisely because it doesn’t depend on logins and relies more on probabilistic linking. They also differ in how much they still rely on third-party cookies versus cookieless signals like hashed email IDs — UID2 and ID5 were built for the cookieless world, while older approaches still carry “cookie baggage”. In general, these IDs only work when they can actually recognize a user, and that might happen less often than sales pitches suggest. While IDs recognize logged-in subscribers, repeat shoppers and authenticated readers, they go blind on incognito browsers, first-time visitors, and users in “thin coverage” countries, i.e. all traffic that is, in practice, unaddressable. Depending on the publisher, that could mean a good chunk of their traffic. 

SSPs and the IDs

By now, I should have convinced you that the Rube Goldberg machine has a way to identify users, and that a pseudo-anonymous, unique set of user identifiers piggybacks on bid requests. You are probably (correctly) guessing that DSPs are ultimately in charge of acting on that information on behalf of agencies and their customers. This is exactly what I’ll illustrate in the next installment, but before we go there, I’ll spend a few words on the role of SSPs here, as you might assume that SSPs are simply passing that information untouched to the DSPs. This is not always the case, and things are slightly more complicated than simply including or not including the IDs. The mere fact that an ID is available in the stream is valuable information for the SSP, even without knowing who the ID refers to.

For a lot of what the SSP does, mere presence is enough. The SSP can see that a request carries a UID2, or a RampID, or no ID at all, and that alone is a useful signal. It can route on it — sending ID-bearing requests toward buyers known to value them — and it can use the token as an opaque key to count how often it has seen the same user, without ever knowing the user is Sloane. None of that requires decoding anything.

Turning the token into meaning is a different matter. To attach an audience to the request — to say not just “this is some user” but “this is a luxury-auto in-market shopper” — the SSP has to resolve the ID against a segment store, and that requires being an authorized participant in that ID’s ecosystem, or partnering with one. It’s not a free-for-all: a UID2 token, for instance, is encrypted (and rotated) precisely so that the many intermediaries a request passes through can’t quietly read it. Only parties inside this “trust framework” can.

What the SSP does with these signals is the subject of a later installment on traffic shaping and curation, i.e. shaping its traffic to send buyers only what they’re likely to want, packaging resolved audiences into curated deals, deciding which requests even reach which DSP. For now, the simpler thing to hold on to is this: the IDs don’t just ride along in the bid request. They start steering it.

Conclusion

By now, you should be convinced that the programmatic machine knows who we are, and our identity travels from the publisher to the DSPs with each bid request. But knowing who someone is is one thing. Using that knowledge to target them is another. The next step is to see how this knowledge is leveraged on the demand side for audience activation, i.e. how brands take a group of people they intend to target and actually “turn them on” in the ad ecosystem so they can reach them. Effectively, the big picture reproduces what DMPs delivered back in the Wild West, just one decade ago! A plethora of players who know how to navigate the whole privacy regulatory framework can collectively deliver the same function.