Header Bidding Explained: Prebid and Auction Basics

Every ad that appears on a web page is the outcome of a very small sale. A visitor arrives, an empty slot is waiting, and several buyers decide in a fraction of a second how much that moment is worth to them. For a publisher, the interesting questions are who gets to bid, in what order, under which rules, and who makes the final call. Header bidding and Prebid are among the most common answers to those questions, and they come wrapped in a thick layer of jargon: SSPs, DSPs, adapters, floors, timeouts, price buckets.

This guide is written for site owners, publishers and ad operations staff who want the mental model before they touch a configuration file. It starts with why an auction exists at all, looks at the older waterfall and its limits, follows a header bidding auction from page load to winner, and introduces the Prebid components. It then covers the settings that shape an auction, the role of the ad server, the client-side versus server-side choice, the page experience cost, ads.txt and a measurement routine. Technical statements rest on the Prebid.org documentation and web.dev; where a version number, setting value or performance figure was not stated there, we do not supply one. No section promises a revenue lift, a latency number or an ideal count of bidders. Examples are fictional and contain no figures.

The Case for Selling Ad Space by Auction

A publisher with unsold ad inventory has a simple problem: an empty slot earns nothing, and a slot sold too cheaply earns less than it could. An auction is a way of letting the market state a price for each impression instead of the publisher guessing it in advance. Because programmatic buying happens in milliseconds and across many buyers, the auction has to be automated, and the rules that surround it matter as much as the bids themselves.

Who takes part and what wins

The following definitions are general industry background rather than statements from a single vendor, and platforms sometimes use the terms with small differences.

• Publisher: the owner of the site or app that has ad space to sell.
• Ad server: the system that holds the publisher's slots and campaigns and decides which ad is shown where. Google Ad Manager is one widely used example.
• SSP (supply-side platform): a platform that offers the publisher's inventory to buyers and gathers bids.
• DSP (demand-side platform): a platform that decides, on an advertiser's behalf, which impressions to bid on and how much to offer.
• Ad exchange: a marketplace where supply and demand platforms trade impressions.
• Bidder: in Prebid's vocabulary, a demand source that submits a bid into the auction. It may be an SSP, a DSP or an exchange.

A small site rarely needs to master all of these roles at once. Typically it has an ad server and a handful of demand partners. The vocabulary becomes useful when you start comparing partners, because each one fills a slightly different position in the chain.

In most auctions the highest valid bid wins, and the word valid carries a lot of weight. The publisher decides what is valid: the minimum acceptable price, the creative sizes allowed, the advertisers blocked and the time limit for answering. A bid that arrives late or below the floor is not a winner, however attractive it looks. We return to each of those rules below.

If you are still deciding between selling space directly and selling it through auctions, our article on direct ad buying versus programmatic compares the two models. This guide stays inside the programmatic world and looks at the plumbing: how bids are gathered and who has the last word.

Competition and cost pull in opposite directions

More bidders usually means healthier price discovery, because each impression is contested by more buyers. Every extra bidder, however, adds network traffic, script weight and operational upkeep. Almost every design decision in header bidding is a negotiation between those two forces: more competition on one side, less delay and less complexity on the other.

Waterfalls: How They Worked and Why Publishers Moved On

To see what header bidding changed, it helps to describe the arrangement it replaced. The waterfall explanation in this section is general industry knowledge, and implementations vary.

How a waterfall works

In a waterfall, the publisher ranks demand sources in a priority order. The ad server asks the first source whether it can fill the slot at or above a set price. If it cannot, the ad server moves to the second, then the third, and so on until something fills the slot or the list runs out. The order is usually set by hand, often based on each source's historical average earnings.

Where the waterfall struggles

• Hidden competition: a source near the top of the list can take the impression at its threshold price while a source further down would have paid more. The lower source never gets to say so.
• Manual upkeep: priorities and price thresholds drift out of date, and keeping them aligned with the market takes steady effort.
• Serial delay: every step means waiting for an answer, and a run of empty replies can leave a slot unfilled for longer.
• Thin visibility: it is hard to see what each demand source would actually have offered, because most never get asked.

These limits led to the idea of asking every source at once, on equal terms, and comparing the answers. Header bidding is the practical form of that idea. It is not free of trade-offs, though: parallel requests put work on the visitor's browser and create a new kind of page experience cost, which we cover in a dedicated section below.

Following One Page View Through a Header Bidding Auction

Prebid's introduction describes Prebid as a free, open-source header bidding solution and distinguishes two ways of using it. As a header bidding library, Prebid collects bids before the ad server is called and the ad server makes the final decision. As a complete bidding library, demand sources, including the publisher's ad server if there is one, bid into Prebid, and Prebid selects the winning ad. The two modes get a longer treatment later. The walkthrough here follows the Prebid overview page (Opens in a new tab).

The sequence on a typical page view

1. A visitor opens the page, and the publisher's code declares which ad slots exist and which creative sizes each accepts.
2. Prebid sends bid requests to the chosen bidders. As the documentation puts it, requests go out to bidders concurrently rather than one at a time.
3. Each bidder answers within the time allowed. A deadline is enforced, and a bidder that has not responded in time is left out of the auction.
4. Publisher rules, such as a price floor, filter the bids that came back.
5. Depending on the mode, the result is either handed to the ad server as targeting data or chosen directly by Prebid.
6. The winning ad is displayed, and impression and revenue records follow.

What parallel bidding changes

In a waterfall, nobody at the bottom of the list gets heard unless everyone above has failed. In a parallel auction, every bidder is asked at once, so the contest is fairer. The price is extra work for the page: each bidder is another request and another piece of processing. The Prebid documentation advises publishers to run A/B tests on the number of bidders, the timeouts and the client-versus-server placement in order to manage latency. We will not name a number of bidders to aim for. The right figure depends on page structure, visitor connections and how quickly your partners respond.

A made-up page view, step by step

Fictional example: a hobby cooking site has two ad slots on every recipe page and three bidders connected through Prebid. On each page view, all three are asked at the same time. One bidder is slow, and when the deadline passes it is dropped from that auction while the other two bids are compared. Later, the site team reviews which bidder most often misses the deadline and considers whether it deserves a slot on the page at all. The example uses no figures and no real company; it only illustrates the decision logic.

Meet the Prebid Components

Prebid is a family of parts rather than a single file. The overview page lists Prebid.js, a browser-based JavaScript library that it calls the core product of the suite; Prebid Server, a server-side option; and Prebid Mobile, SDKs for iOS and Android. Around those sit bid adapters and modules for analytics, identity, price floors and more.

Prebid.js in the browser

According to the documentation, Prebid.js supports display, video and native formats. Publishers assemble a build containing only the adapters and modules they need. That choice matters for performance, because every adapter is additional code that visitors must download and run.

What an adapter does

An adapter connects Prebid to a particular bidder. The overview describes bid adapters as the pieces linking Prebid to SSPs, DSPs and exchanges. To add a demand partner, the publisher includes that partner's adapter and supplies the parameters the partner expects on each ad unit, such as an account or placement identifier. Parameter names differ from adapter to adapter, so check the relevant documentation page rather than copying a pattern from another partner.

Prebid Mobile and modules

Prebid Mobile brings header bidding to iOS and Android apps and works with Prebid Server. The modules handle supporting functions such as analytics, user identity and price floors. As with adapters, each module you add enlarges the build, so include only those you will genuinely use.

The table summarizes the Prebid overview. Because versions and module names change quickly, we do not quote version numbers here; the Prebid.org documentation is the place to confirm current details.

Timeouts, Floors and Price Buckets: The Settings Behind Every Auction

A few settings influence nearly every auction. This section covers the concepts and the setting names that appear in the Prebid documentation. It does not recommend values, because the right ones depend on your site.

Timeouts and the wait for bids

Bid collection is limited by a time window. The Prebid.js configuration reference describes a global bidder timeout setting called bidderTimeout and adds a caution: the timeout can be triggered later than expected, so a bid may occasionally join the auction late. That detail changes how you should think about the number you configure. It is a target for the auction, not a hard promise about what visitors will experience. A short window reduces delay but shuts out slower bidders. A long window may attract more bids but keeps the slot empty for longer.

The same reference mentions neighbouring settings, among them ttlBuffer, which subtracts a buffer from bid time-to-live, and disableAjaxTimeout, which stops Prebid from ending requests when the auction times out. Whether to change any of these is a matter for testing, not a rule of thumb. The Prebid.js configuration reference (Opens in a new tab) holds the current definitions.

Price floors: the lowest bid you will accept

A floor is the minimum a bid must reach to be considered. The Price Floors module documentation defines a floor as the lowest CPM price a bid will need to meet for each Prebid auction, and describes the module as an open-source framework that lets publishers set their own floors or work with a floor vendor.

• Rules can come from three places: dynamic data fetched remotely, the package configured through setConfig, or the ad unit itself. Each auction uses rules from only one location, in the priority order dynamic, then setConfig, then ad unit.
• Rules can match on dimensions including ad unit, GPT slot name, media type, ad size and domain, and custom dimensions are supported.
• The enforceJS setting controls whether bids that do not exceed a matching floor are suppressed.
• floorMin sets a minimum, and the module uses the greater of floorMin and the matched rule value.
• skipRate randomly skips the floor logic so that auctions with and without floors can be compared.

For remote floor data the documentation describes an auctionDelay setting that governs how long an auction may wait, and says that package-level data can serve as a fallback if the endpoint fails or answers too late. Read the Price Floors module documentation (Opens in a new tab) before relying on any of these behaviours. A floor set too high can leave slots unfilled, and one set too low can sell valuable impressions cheaply. Only your own comparison data can tell you where the balance lies. To interpret the results, see our explanation of RPM, eCPM and fill rate.

Price buckets and the hb_pb key

When Prebid works with an ad server, bid prices travel as key-values. The configuration reference says that the price granularity setting, priceGranularity, defines the price bucket granularity used for the hb_pb keyword. It lists standard options named low, medium, high, auto and dense, plus a custom configuration object. Finer buckets give more price resolution, yet they can also mean more line items to manage in the ad server. Finer is therefore not automatically better; precision trades off against operational workload.

The Ad Server's Role in Picking the Winner

One of the most common sources of confusion is who actually declares the winner. Prebid's ad operations documentation describes two modes, and the choice affects how revenue operations and engineering share the work. The description below follows the Prebid ad ops introduction (Opens in a new tab).

Header bidding mode: the ad server decides

Here Prebid gathers bids before the ad server is called, and the ad server makes the final decision. The documentation says the ad server reads the targeting information and looks for matching line items, so ad operations must confirm that those line items exist and are set up properly. In practice a Prebid bid competes with whatever else the ad server holds, such as direct campaigns and guaranteed delivery goals, and the ad server's own rules determine the winner.

Complete bidding mode: Prebid decides

In this mode Prebid is the decision layer, and the ad server, if there is one, takes part in the Prebid auction like any other demand source. The documentation notes that no price-bucket line items are needed for Prebid bids in this setup. Ad operations instead configures the ad server's own campaigns, such as reservation priority, sponsorships and house campaigns. On the engineering side, the behaviour is enabled through a setting on the ad server adapter.

Choosing between the two

This is a business-model question more than a technical one. A publisher with a busy direct sales operation inside the ad server may prefer to keep the decision there. A mostly programmatic publisher who wants a single place for decision logic may look at the complete bidding approach. Whichever you pick, move a small slice of traffic first and compare outcomes using the same metrics on both sides.

The auction products and line item rules that an ad server such as Google Ad Manager offers on its own are a separate subject. Check the Google Ad Manager Help Center for their current terms, because product names and settings change often.

Browser or Server: Deciding Where Bidding Runs

Prebid can run in the visitor's browser or on a server. The overview page describes Prebid Server as the server-side option that moves some or all auctions off the browser, reducing client load and latency. It also says server-side bidding is required where HTML headers are unavailable, such as mobile apps and AMP pages.

What server-side bidding gives and what it takes

The Prebid Server overview calls it an open-source solution for server-to-server header bidding (Opens in a new tab). It checks and enriches incoming requests, passes them to server-side bidder adapters and builds the response. The page lists mobile apps, AMP, server-side web with Prebid.js, connected TV, digital out-of-home and audio as use cases, and notes that privacy regulations can be enforced before bidders are called.

The same page is candid about the price. Prebid Server is a server, so it needs somewhere to run, and that place should be scalable, distributed and fast. Installing it is described as not nearly as easy as Prebid.js, and the open-source community provides no configuration tools. Server-side bidding can therefore reduce the browser's workload while increasing your operational workload. The page also says several Prebid.org members host the software, which is why many publishers buy a hosted service. If you evaluate one, compare contracts, data flows and reporting against your own needs; this guide does not recommend any provider.

A blended setup

Client and server are not mutually exclusive. Some bidders can run in the browser while others run on the server. A sensible path is to measure the current setup, identify slow or heavy bidders and try moving only those. After the move, watch revenue and delay together, because user matching and similar matters may behave differently on the server side. The overview does not go into that topic and points to a separate cookie sync document, so we make no claims about it here.

In a blended setup, write down which bidder runs where, which setting lives in which layer and which report comes from which source. Without that record, a revenue dip becomes very hard to attribute to the browser side or the server side.

Seller Transparency and ads.txt

Programmatic buyers want to know who is authorized to sell a publisher's inventory. The IAB Tech Lab page explains that ads.txt stands for Authorized Digital Sellers and calls it a simple, flexible and secure method for publishers to publicly list the companies they authorize to sell their inventory. Its stated aim is to increase transparency in the programmatic advertising ecosystem, and it says a public record of authorized sellers makes it harder for bad actors to profit from selling counterfeit inventory.

How it relates to header bidding

With header bidding, several demand sources reach your inventory. Each should be authorized to represent you, and ads.txt is how that authorization becomes visible to buyers. When you add a new bidder, updating its ads.txt entry belongs to the same piece of work. If the entry is missing, a buyer may not recognize the seller behind a bid. That is how the system works in general terms; whether a specific buyer insists on it depends on your contract.

For where the file lives and how its lines are structured, read our ads.txt publisher setup guide. The IAB Tech Lab page also lists variables introduced across versions, including OWNERDOMAIN, MANAGERDOMAIN, INVENTORYDOMAIN, SUBDOMAIN and CONTACT. Confirm which ones apply to you using the IAB Tech Lab ads.txt page (Opens in a new tab) and the current specification.

A short transparency checklist

• Does every active demand source have a matching ads.txt entry?
• Have entries for bidders you no longer use been removed?
• Do seller identifiers match exactly what each partner supplied?
• Is the file publicly reachable and up to date?

Reviewing the file regularly matters as much as adding to it, since stale entries create confusion.

What Bidding Costs the Visitor: Speed and Layout Shift

Header bidding creates revenue opportunities and also puts weight on the page. A setup that ignores this weight can degrade the visitor experience and, over time, the revenue it was meant to raise. We discuss the broader tension in balancing ads and Core Web Vitals; this section covers what is specific to bidding.

Extra scripts and requests

Each adapter adds code and each bidder adds a network request. The size of the effect varies from page to page and cannot be summarized by one figure. The reliable method is to measure the same page under the same conditions before and after adding a bidder. Removing adapters and modules you no longer use is one of the simplest wins available.

Reserving room for the ad slot

Ads usually arrive after the rest of the page. If the slot is empty and no space was reserved, the content moves down when the ad appears. The web.dev guidance on layout shifts sets a target of 0.1 or less for CLS for at least 75 percent of page visits and treats values above 0.25 as poor. Its guide to optimizing CLS (Opens in a new tab) makes these recommendations for ads and embeds:

• Reserve space with a min-height rule, or with aspect-ratio for responsive ads.
• If ad sizes vary, reserve the smallest likely size so later growth causes less shift.
• Keep a placeholder when no ad loads, because removing the reserved space can also cause a shift.
• Adjust placeholder sizes for different screen sizes with media queries.
• Place late-loading content lower in the viewport, where it disturbs less.

This advice weighs heavily in header bidding, because the size of the creative that wins may not be known until bidding ends. Reserving the smallest likely size limits the movement. The guide also notes that CLS is measured across the whole life of a page, so shifts after load can count, and that field data is needed alongside Lighthouse. Do not rely on a lab test alone.

The price of reserved space and a sensible order of work

Reserved room has a cost too. An empty reserved area is worth less to the visitor than a filled one, and it constrains layout design. The publisher has to strike the balance on purpose. A slot in the middle of an article might tolerate looser rules than one at the very top of the page. Do not decide this by guesswork; look at what each slot earns in your own data first.

1. Measure first: record page speed and CLS with the current setup.
2. Remove adapters and modules that are not needed.
3. Reserve space for every ad slot.
4. Change the timeout and the number of bidders one at a time, and watch the effect.
5. If needed, move slow bidders to the server side.

This is a suggested priority, not a guarantee of improvement. Repeat the same measurement after each change.

Measuring Results and Testing Changes

The safest way to run a header bidding setup is to change one thing at a time and measure each step. Prebid's own guidance recommends A/B testing bidder counts, timeouts and the client-versus-server split, and you can build your routine on that advice.

Metrics to track and how to design the test

• Revenue metrics: revenue per thousand page views (RPM), eCPM and fill rate, as defined in the revenue metrics article linked earlier.
• Bidding behaviour: how often each bidder responds, how often it misses the deadline and how often it wins.
• Page experience: CLS and the other Core Web Vitals, from field data wherever possible.
• Technical health: slots that stay empty, errors and unresponsive partners.

Splitting traffic when you change a setting is how you separate the effect of the change from ordinary swings over time. The Price Floors module supports this approach with options such as skipRate and the labels modelVersion and modelTimestamp. As a general rule, change only one variable at a time. Otherwise you cannot say what caused the result.

How long to test depends on traffic volume and seasonality. If weekday and weekend behaviour differ on your site, a test that runs for only a few days can mislead. We give no fixed duration, but run it long enough for both groups to experience comparable conditions.

A fictional timeout trial

Fictional example: a news site wants to shorten its bidder timeout. It applies the new value to part of its traffic and leaves the rest unchanged, then compares the two groups over the same week on slot fill, revenue per page and CLS. If the picture is mixed, say delay falls while revenue also dips, the team does not settle the question with a single metric. It looks at which slots matter most. The example contains no numbers and no result from a real site.

Keeping a change log

For every change, write down the date, the setting, the expected effect and what you observed. A month later, when revenue wobbles, this log becomes your most useful resource, and it survives staff changes.

Mistakes That Cost Publishers Time

• Adding many bidders without measuring: each one adds weight. Measure the same page before and after.
• Treating the timeout as exact: the Prebid.js reference warns that it can fire later than expected.
• Skipping reserved space: a late ad shifts content and damages CLS.
• Raising floors all at once: fill may fall; use controls such as skipRate for a fair comparison.
• Blurring the two modes: if nobody knows whether the ad server or Prebid decides, the reports will contradict each other.
• Forgetting ads.txt: a new bidder needs its entry added.
• Leaving unused adapters in the build: unneeded code only increases page weight.
• Looking at a single metric: watching only revenue or only speed is misleading.
• Copying setting names from an old source: Prebid changes quickly, so check the current documentation.

Frequently Asked Questions

What is header bidding in plain terms?

Header bidding is a way of inviting several demand sources to bid on the same ad slot at the same moment, and collecting those bids before the ad server makes its choice. Prebid's documentation describes this as gathering bids before the ad server is called, with the ad server then making the final decision. The older waterfall approach asked demand sources one after another instead.

Is Prebid the same thing as header bidding?

No. Header bidding is the technique and Prebid is one open-source way of doing it. The Prebid.org documentation presents Prebid as a free, open-source header bidding solution made up of Prebid.js for the browser, Prebid Server for server-side auctions and Prebid Mobile for apps.

Should auctions run in the browser or on a server?

There is no universal answer. Server-side auctions aim to cut browser load and latency, but they need infrastructure that someone has to run. Prebid recommends testing the number of bidders, the timeout and the client-versus-server split through A/B tests, so the decision should rest on your own measurements.

Can header bidding hurt page speed or layout stability?

It can. Collecting bids means extra network requests and extra script work, and an ad slot with no reserved space can push content around when the ad arrives. web.dev advises reserving space with min-height or aspect-ratio and keeping the placeholder when no ad loads. How large the effect is depends on the page, so measure it with your own field data.

Do I need ads.txt if I use Prebid?

We do not claim it is mandatory in every case. The IAB Tech Lab describes ads.txt as a simple way for publishers to publicly list the companies authorized to sell their inventory, with the goal of improving transparency in programmatic advertising. Whether a particular buyer requires it depends on your agreements, but keeping it accurate is a sensible habit.

Conclusion

Header bidding is the practice of letting several demand sources compete for the same impression on equal terms, and Prebid is an open-source toolkit for doing it. The design questions come down to a handful of choices: where bids are collected, who makes the final call, how long to wait, what minimum price to enforce, and what all of that costs in page speed and layout stability. None of them has a universal answer. What works is changing one thing at a time, measuring with the same metrics, and keeping transparency records such as ads.txt current.

If you are looking to sell or buy ad placements, you can browse the ad spaces on Akua Adforce; scope and terms are described on the relevant page.