Part 0 of 9: Programmatic auctions from a bird's-eye view

In programmatic advertising, the bid request is often treated as a technical detail – a JSON payload that only developers and SSPs need to care about.

That is a mistake.

A bid request is not just a message. It is the commercial definition of an ad opportunity. Every auction. Every decision to bid or pass. Every CPM. It all starts with the bid request.

That is why this 9-part series (yep, 9 parts) will look at bid requests from both a commercial perspective (how buyers value inventory) and a technical perspective (the ad tech running behind the scenes when campaigns meet publisher inventory). Given my background, the ad tech perspective will take up most of this series 🤓

First, let's get the terminology straight

Before we go deep, it helps to establish some key terms:

Bid request – The message sent before any bids exist. It describes the ad opportunity and asks buyers to respond. Sent by the publisher.
Bid – A single price offer on a specific ad opportunity. Sent by the buyer.
Auction – The process that compares multiple bids on the same ad opportunity and selects a winner. Takes place at the publisher.
Impression – When a creative (the actual ad file) is downloaded and rendered on the user's device (i.e. the ad was actually delivered and displayed).
Ad unit – The position on the page defined by the publisher where an impression can take place. Also called an ad slot or placement.
Media types – The permitted ad formats for an impression (banner, video, native, audio).
Banner – Image or HTML ads that (often) render in fixed-size placements.
Video – Ads shown before (pre-roll), during (mid-roll), after (post-roll) or alongside other content (including in-stream and out-stream).
Native – Ads defined by assets and layout rules rather than fixed sizes, designed to match the surrounding content.
Header bidding – An auction where multiple buyers bid simultaneously before the ad server makes its decision. Runs in the browser's header.
Prebid – An open source framework for header bidding, used to run auctions and communicate with buyers.
Client-side / Server-side – Whether the auction runs in the user's browser or is passed on to an external auction server such as Prebid Server. Also called C2S and S2S.
OpenRTB – Open Real-Time Bidding: The most widespread industry standard defining how bid requests and bid responses are structured.
SSP / DSP – Supply-Side Platforms sell inventory; Demand-Side Platforms buy it.
Consent – The legal permissions a user grants (or declines) for data processing and ad personalization – typically encoded via frameworks like TCF.
TCF – Transparency & Consent Framework: The industry standard in the EU that standardizes how consent is collected and passed along in the bid request.

These terms make up the shared vocabulary of programmatic seen from a technical perspective. With that baseline in place, we can zoom out.

So what is a bid request, really?

At the highest level, a bid request is a structured description of a single ad opportunity, sent from the publisher's stack to potential buyers with one simple question:

"Here is an ad opportunity – do you want to buy it, and at what price?"

Everything in the bid request exists to help the buyer answer exactly that question.

The five questions every bid request must answer

Whether you use Prebid, OpenRTB, client-side or server-side header bidding, every modern bid request tries to answer five fundamental questions:

What is being sold? Is it a banner, a video or a native placement? Which sizes, formats and constraints apply?
Where is it being sold? Which site, app or environment does this impression live in? What is the context?
Who might be seeing the ad? What do we know about the user via identity solutions, first-party data or contextual signals?
Under what rules may it be sold? Which privacy legislation applies? What consent has been given (or not given)?
How should the auction be run? How much time is available? Who runs the auction? Client-side or server-side?

If a bid request cannot answer one of these 5 questions clearly, bidders will either bid conservatively or not at all.

Why bid requests look "complicated"

If you have ever looked at a real bid request (example from jv.dk), it probably felt overwhelming: nested objects, extensions, IDs, consent strings and supply chain paths.

That complexity exists because a bid request must balance three opposing concerns:

Standardization: Buyers and sellers need a common language (OpenRTB).
Flexibility: Every publisher, format and market is different.
Regulation & trust: Privacy legislation, identity loss and supply chain transparency all have to be encoded in real time.

The result is not pretty, but it is deliberate. And yes – sometimes it is genuinely annoying to work with.

Why this matters (even if you do not write code)

Whether you work in publishing, monetization, ad operations, sales, product or ad tech, the bid request is what determines:

How buyers value your inventory
Which demand can participate
How identity and consent affect your yield
Why two impressions that look "identical" can monetize completely differently

If you do not understand what goes into your bid requests, you do not have full control over your revenue.

What the series will cover

In the coming articles I take the bid request apart, one major component at a time – published weekly over the next 9 weeks:

Each article focuses on why a given part exists – not just what it looks like.

Next: Part 1 of 9: The auction & the control layer →

First, let's get the terminology straight

Before we go deep, it helps to establish some key terms:

Bid request – The message sent before any bids exist. It describes the ad opportunity and asks buyers to respond. Sent by the publisher.
Bid – A single price offer on a specific ad opportunity. Sent by the buyer.
Auction – The process that compares multiple bids on the same ad opportunity and selects a winner. Takes place at the publisher.
Impression – When a creative (the actual ad file) is downloaded and rendered on the user's device (i.e. the ad was actually delivered and displayed).
Ad unit – The position on the page defined by the publisher where an impression can take place. Also called an ad slot or placement.
Media types – The permitted ad formats for an impression (banner, video, native, audio).
Banner – Image or HTML ads that (often) render in fixed-size placements.
Video – Ads shown before (pre-roll), during (mid-roll), after (post-roll) or alongside other content (including in-stream and out-stream).
Native – Ads defined by assets and layout rules rather than fixed sizes, designed to match the surrounding content.
Header bidding – An auction where multiple buyers bid simultaneously before the ad server makes its decision. Runs in the browser's header.
Prebid – An open source framework for header bidding, used to run auctions and communicate with buyers.
Client-side / Server-side – Whether the auction runs in the user's browser or is passed on to an external auction server such as Prebid Server. Also called C2S and S2S.
OpenRTB – Open Real-Time Bidding: The most widespread industry standard defining how bid requests and bid responses are structured.
SSP / DSP – Supply-Side Platforms sell inventory; Demand-Side Platforms buy it.
Consent – The legal permissions a user grants (or declines) for data processing and ad personalization – typically encoded via frameworks like TCF.
TCF – Transparency & Consent Framework: The industry standard in the EU that standardizes how consent is collected and passed along in the bid request.

These terms make up the shared vocabulary of programmatic seen from a technical perspective. With that baseline in place, we can zoom out.

So what is a bid request, really?

At the highest level, a bid request is a structured description of a single ad opportunity, sent from the publisher's stack to potential buyers with one simple question:

"Here is an ad opportunity – do you want to buy it, and at what price?"

Everything in the bid request exists to help the buyer answer exactly that question.

The five questions every bid request must answer

Whether you use Prebid, OpenRTB, client-side or server-side header bidding, every modern bid request tries to answer five fundamental questions:

What is being sold? Is it a banner, a video or a native placement? Which sizes, formats and constraints apply?
Where is it being sold? Which site, app or environment does this impression live in? What is the context?
Who might be seeing the ad? What do we know about the user via identity solutions, first-party data or contextual signals?
Under what rules may it be sold? Which privacy legislation applies? What consent has been given (or not given)?
How should the auction be run? How much time is available? Who runs the auction? Client-side or server-side?

If a bid request cannot answer one of these 5 questions clearly, bidders will either bid conservatively or not at all.

Why bid requests look "complicated"

Standardization: Buyers and sellers need a common language (OpenRTB).
Flexibility: Every publisher, format and market is different.
Regulation & trust: Privacy legislation, identity loss and supply chain transparency all have to be encoded in real time.

The result is not pretty, but it is deliberate. And yes – sometimes it is genuinely annoying to work with.

Why this matters (even if you do not write code)

Whether you work in publishing, monetization, ad operations, sales, product or ad tech, the bid request is what determines:

How buyers value your inventory
Which demand can participate
How identity and consent affect your yield
Why two impressions that look "identical" can monetize completely differently

If you do not understand what goes into your bid requests, you do not have full control over your revenue.

What the series will cover

In the coming articles I take the bid request apart, one major component at a time – published weekly over the next 9 weeks:

Each article focuses on why a given part exists – not just what it looks like.

Next: Part 1 of 9: The auction & the control layer →

Part 0 of 9: Programmatic auctions from a bird's-eye view

First, let's get the terminology straight

So what is a bid request, really?

The five questions every bid request must answer

Why bid requests look "complicated"

Why this matters (even if you do not write code)

What the series will cover

Ready to optimize your campaigns?

Related articles

Is This the Death of Open Web Programmatic?

What is actually hiding in a bid request?

Part 1 of 9: The auction & the control layer

Part 0 of 9: Programmatic auctions from a bird's-eye view

First, let's get the terminology straight

So what is a bid request, really?

The five questions every bid request must answer

Why bid requests look "complicated"

Why this matters (even if you do not write code)

What the series will cover

Ready to optimize your campaigns?

Related articles

Is This the Death of Open Web Programmatic?

What is actually hiding in a bid request?

Part 1 of 9: The auction & the control layer