For eight articles, the bid request has been something that happens to you.
The browser fills in the device. The CMP fills in the consent string. The supply chain fills in itself, hop by hop. You configure it all, you control much of it, but you do not author it. It is a stack of facts about the impression, reported up through the pipe.
This part is the exception.
user.dataandcontent.dataare the only fields in the entire request that you write yourself. Not the browser, not the SSP, not some vendor's script. You. They are the publisher's own line in a machine-readable auction: Here is who I think this reader is, here is what this page is about, and here is what I am willing to tell you about it.
And here comes the uncomfortable part. Most publishers leave those fields empty. And those who do not often make the opposite mistake: They take their very best audience signal and shout it out to every single bidder in the open auction – for free.
That is the most expensive free thing a publisher does. This article is about doing it deliberately instead – and then about turning that one self-authored field into an actual product, because that is where the money is.
Last time I argued that the trust layer – ads.txt, sellers.json, schain – is really the publisher deciding what to reveal about itself: who owns this inventory, who manages it, who may sell it. Part 9 is exactly the same instinct, pointed one step outward.
Last time: what you reveal about who you are. This time: what you reveal about who is reading. Same discipline. Higher stakes. Because in 2026, what you choose to put in these fields is not a nice-to-have enrichment. It is the last durable signal you own.
Four terms, quickly:
*The Data and Segment objects are tiny – two nested objects, reused in two places. That is the whole surprise of this layer: The mechanism is small. The strategy is not.
Here is the backbone of the entire article. When a publisher writes data into the bid request, it fills one of three fields – and they are not the same. They answer three different questions, and they carry three very different privacy weights.
user.eids – "Do I even know who this is?" The heaviest field in the request, because it is an actual identifier. Logged-in users only, which in practice is a minority of your traffic.user.data (with segtax) – "What is this reader like?" A cohort, not a person. "Interested in home renovation", not "this exact human". Behind the consent gate, but lighter than identity.site.content.data (with segtax) – "What are they here for?" About the page, not the person. The lightest weight of all – and, as we will see, the one that survives everything.
Here are all three in one and the same request:
{
"user": {
"eids": [
{ "source": "id5-sync.com", "uids": [ { "id": "ID5*..." } ] }
],
"data": [
{ "name": "stepnetwork.dk", "ext": { "segtax": 4 }, "segment": [ { "id": "44" } ] }
]
},
"site": {
"content": {
"data": [
{ "name": "stepnetwork.dk", "ext": { "segtax": 7 }, "segment": [ { "id": "687" } ] }
]
}
}
}
Three fields. eids is identity (part 4). The segtax: 4 block is an audience cohort. The segtax: 7 block is context. Note that eids now sits at the top level of user – it was promoted from user.ext.eids to core in OpenRTB 2.6, exactly the ext-to-spec promotion I hammered on in part 7.
Visualization generated with claude.ai
The design principle worth holding on to: They can be separated. A privacy-conscious publisher can reveal audience without revealing identity. You can tell a buyer "this reader looks like a home improver" without telling them who the reader is. The spec actively warns against mixing the two. Data is "what they are like, in aggregate". eids is "exactly who". Publisher data strategy is the decision about which of the three you attach – to whom and under what consent.
There is a name for the privacy-safe version of the audience field: Seller-Defined Audiences (SDA). IAB Tech Lab released it in February 2022, and the idea is elegant. Now that cookies and mobile IDs are disappearing, let the seller – the publisher – define a cohort on its own servers, map it to a standard taxonomy node and only send the anonymized node number along in the request. No cookie, no cross-context identifier, no leaked person. Just: "node 44, from the Audience Taxonomy".
It runs on exactly the mechanism above, with two conventions: audience SDA goes in user.data with segtax: 4; context SDA goes in content.data with segtax: 7. And now for the honest part, because here I have to be direct.
SDA has struggled. It is a genuine chicken-and-egg problem: Buyers say there is not enough of it to bid on, publishers do not invest because buyers do not bid, and as long as third-party cookies clung on, no one was forced to care. (Not the first time we have had those problems with something new, lol)
Buyers are also suspicious of the black box – they cannot see how you built a cohort, and you have every reason to exaggerate the label. In December 2024, citing weak adoption, IAB Tech Lab repositioned SDA under a new banner: "Curated Audiences".
So the plumbing is stable and widely installed. The branded product has been renamed twice. Both are true, and the gap between them is the most interesting thing about this entire area.
Here is the part almost every "what is in the bid request" walkthrough skips – and it is the hinge the whole strategy swings on.
You do not have to reveal the same data to every bidder.
Most people picture the bid request as one broadcast: You assemble it, you fire it off, everyone sees the same thing. That is the default, and it is a choice most publishers make by accident. But Prebid gives you a scalpel. You can author different data for different bidders on the very same impression.
Client-side it is called setBidderConfig:
// Afslør en premium first-party-kohorte KUN til de to partnere, der har licens til den
pbjs.setBidderConfig({
bidders: ['adform', 'appnexus'],
config: { ortb2: { user: { data: [
{ name: "stepnetwork.dk", ext: { segtax: 4 }, segment: [{ id: "44" }] }
] } } }
});
Those two bidders get the cohort. Everyone else gets the request without it. Server-side there is an allow-list that does the same job. And there is a module whose sole purpose is the "do not leak this" valve, stripping identity and seller-defined segments from the requests you do not want them in.
Why does any of this matter? Because of one hard fact about the open auction:
Bidstream data leaks whether or not anyone buys.
Your audience signal goes out with every request. A buyer who loses the auction – or who never intended to bid – still receives it, reads it and can keep it. For every impression a buyer actually pays for, it can harvest data on hundreds of page views it paid nothing for. Brian O'Kelley has the phrasing I keep coming back to: Data is fallout, not oil. It is a byproduct publishers give away – not an asset they get paid for.
That redefines the whole task. If your best first-party cohort goes to twelve bidders in the open auction, you have handed your audience to twelve companies and been paid by at most one. So the sell-side answer is not "send more data along". It is matching the container to the value:
Visualization generated with claude.ai
At STEP Network we author user.data and content.data for 100+ Danish publishers, and deciding who sees what is a real part of the job. A housing section on boligsiden.dk is contextual, so it goes out broadly. A logged-in reader on one of our Jysk Fynske Medier titles is an audience cohort, and it only goes to the partners licensed for it. Same auction. Different data. Deliberately.
That is the difference between a publisher and a leaky pipe: the permission list. But permission management is only the discipline. The real lever is what you put in the controlled containers – and that is where data stops being a field and becomes a product.
Filling user.data with a raw signal is the price of admission. The publishers who pull ahead do something more deliberate, and it boils down to three moves.
Move 1: Productize the data. Do not broadcast raw signals – package them into a small set of standardized, weighted, genuinely buyable segments. That is the thinking behind our own audience product, OMNISEG: one solution blending six data types (contextual, first-party, third-party, IP, deterministic and probabilistic) and automatically weighting the one performing best for the campaign. The point is not the six inputs. It is that the buyer never touches them. They buy one clean audience, and the messy multi-source blending happens underneath. There is craft hiding in there too: The internal source prioritization flips depending on the segment. For an interest segment, we trust behavioral and contextual signals first; for a demographic segment, we trust deterministic, registered data first. The buyer sees none of it. They want one segment that works – not your data pipeline.
Simplicity is the product, not a compromise. A commodity impression on the open market cannot offer that with data of the same quality.
Move 2: Anchor it on a CDP. Here is the point most people miss: A segment is only as durable as the identifier it rides on. Build a beautiful first-party cohort, activate it naively, and the ad server quietly translates your first-party ID into its third-party ID further down the chain – where Safari, Firefox and now Chrome kill it on sight. You did the hard work and handed it straight to the browser's block list.
A CDP – a customer data platform: one unified first-party profile with one ID – is what stops that. You keep the first-party ID yourself, and you activate the segment on your own ID through first-party hooks – e.g. Google's Publisher Provided IDs, where you send your own ID with the request and Google matches your populated segments to it, instead of issuing a third-party ID that dies in two of the three major browsers. Everyone is busy collecting first-party data right now; reportedly over 70% of brands and publishers are expanding their first-party datasets, nearly twice as many as two years ago. Collection was never the hard part. Activating it durably is. Your audience strategy is only as strong as your identity backbone.
Move 3: Combine it with the advertiser's data in a clean room. A clean room is a neutral, locked environment where two parties match data and only get an aggregated result out – without either seeing the other's raw records. The most valuable audience is not just yours or the advertiser's – it is the overlap, and the trick is computing that overlap without either side handing over raw personal data. The advertiser hashes its customer emails, you match them against your profiles inside the clean room, and what comes out is a set of anonymized labels driving an always-on campaign. No one sends a raw email list anywhere.
The reason I count this as strategy and not just engineering: What usually kills clean rooms is fragmentation, not the technology. Every media house builds its own, every advertiser faces a new spec and a new legal contract, and the friction smothers it all. The solution is to standardize it. In Denmark, that is what the DAMA Cleanroom Framework does – one shared legal agreement, one file format, one label taxonomy, adopted by STEP Network, JP/Politikens Hus, Berlingske and TV2. Competitors standardizing the plumbing precisely so they can compete on the segments instead of the SFTP setup. As DAMA puts it, it moves the competition up the value chain: from technical friction to actual value creation. And there is real room here – retail media is a ~$70 billion market in 2026, and yet fewer than half of media networks offer a clean room at all.
Three moves, one direction: Stop treating your data as a field to fill in, and start treating it as a product to build.
Here is the commercial payoff, and it is the whole reason the strategy matters.
Data plus inventory, packaged together, is something a buyer can only get from you. An impression on the open market is a commodity – the same slot a thousand other sites sell into the same auction. That same impression with your productized audience attached, durably activated, is differentiated supply. And differentiated supply is what earns a direct or curated deal instead of an open auction race to the bottom.
The market has already voted. More than two thirds of open exchange spend – over $100 billion a year – now flows through curated private marketplaces rather than the pure open auction. The open market is no longer where the money is. Buyers increasingly want to transact against a publisher's unique data, directly, cutting out the chain of intermediaries and fees between them and the source. It is the same instinct behind every "buy direct" push in the market right now, just seen from the sell side: fewer hops, more value, a relationship instead of a race.
This is the alternative to the "easy path" – dumping everything into AdX and the open market and letting the auction turn you into a commodity. Take the easy path, and you are a price taker. Build the unique thing, and buyers come to you.
I will keep it honest, because otherwise the finale would not be mine. Curation can just move the tax – swapping an open market fee for a curator's fee and leaving the publisher with the same net amount, a fair critique I raised myself back in the curation debates. And it raises a genuinely unresolved question: Once your audience is curated at the SSP, who owns it – you or the curator?
My answer is the thread running through all three moves above: You own it by owning the stack. Build the audience product, the identity backbone and the clean room yourself – or co-own them as shared publisher infrastructure like DAMA – and the margin and the audience relationship stay on the sell side.
The catch, and I will not pretend it does not exist, is that this is expensive, and not every publisher can do it alone – which is exactly why the shared-infrastructure route matters. But that is a bigger conversation, and honestly a topic for its very own article.
Strip away the JSON, and this is a short list of commercial decisions any publisher can act on:
The rule of thumb I will leave you with: If you reveal it to everyone for free, you do not have a data strategy – you have a data leak. The fields are free. Deciding what to build and who gets to read it is the whole job.
One last look over the horizon, because that is where this layer stops being plumbing and becomes the point itself.
In an agentic world, AI buying agents will not crawl the open auction impression by impression. They will discover inventory by reading a publisher's structured description of its audience and its content – and then negotiate directly. When that happens, your declared data stops being a targeting signal and becomes your storefront. And notice – everything in the strategy above is the human-scale dress rehearsal for exactly that. A productized segment catalog is a store shelf. A CDP is what makes it activatable. A standardized clean room framework is the trust layer the agents will need. Curating into direct deals is the destination.
The standards are real and very new. AdCP (Ad Context Protocol), launched in October 2025 and built on Anthropic's MCP, is the control layer – how agents discover inventory, negotiate terms and execute. On the data side, IAB Tech Lab has gathered its work under an umbrella it calls AAMP, with Agentic Audiences – the standard formerly known as UCP, donated by LiveRamp – as the layer for exchanging identity and context signals. Remarkably, IAB Tech Lab and the AdCP camp are not singing from the same hymn sheet, which tells you how early and how contested all of this is.
And that is the honest caveat to end on. We have been here before. OpenRTB 3.0 was also supposed to be the future, and the market never migrated. SDA has been repositioned twice and still lacks buy-side demand. Whether agentic discovery becomes the market or stalls like 3.0 is genuinely up for debate – standards only matter when the market ratifies them.
But the instruction to publishers is identical either way: Build the product, own the backbone, decide what you reveal. It holds whether the reader at the other end is a DSP today or an agent tomorrow.
The data layer is the one part of the bid request you do not inherit – you write it yourself. Three fields, three questions: identity (user.eids – do I know who this is?), audience (user.data – what are they like?) and context (content.data – what are they here for?). In a world without a universal ID and with a dead Privacy Sandbox, what you choose to put in those fields is your addressability.
But authoring the data is only the beginning. The advantage lies in what you build on top: Productize your signals into buyable segments, anchor them on a CDP so they survive the browser, combine them with advertiser data in a clean room, and package the result into direct deals that pull buyers away from the open commodity market. Reveal context broadly, identity and premium cohorts narrowly, and the crown jewels only in paid, controlled containers – and own the stack so the value stays yours. The publishers who win the next phase will not be the ones who send the most data along. It will be the ones who deliberately decide what to build, what to reveal, and to whom.
That was the series. Nine parts on what is actually hiding in a bid request – and this final one on what you choose to say back.
Let us help you get the most out of your display campaigns.
