Floor price optimization: a floor strategy for first-price auctions

In a second-price auction, the winner pays the runner-up's bid, so a floor mattered mostly when only one buyer bid above it. In a first-price auction, the winner pays its own bid, and buyers use bid shading to bid just above what they expect to need. A floor gives that shading model a hard lower bound. If the buyer values the impression above the floor, it bids at least the floor. If not, the impression goes unsold.

So every floor change has two effects. It lifts the price on auctions where the top buyer would have shaded below the floor but values the impression more. And it loses auctions where no buyer values the impression at the floor. The net result depends on which group is larger, and only data can tell you. The shading side of this is explained in bid shading explained.

Take one ad unit with 1,000,000 bid requests a month and a $1.00 floor. You consider $1.50. Split the traffic into four groups by the top shaded bid and the top buyer's true value. All figures are illustrative, built on the shading logic in bid shading explained.

Average price per sold impression, the eCPM, rises from $1.87 to $2.03. Revenue falls by $60, or 3.6%. Now shift 50,000 requests from group C to group B. At $1.00 the total is still $1,680, but at $1.50 it becomes $1,695, a gain of 0.9%, with fill rate at 85%. The same floor wins or loses money depending on a split you cannot see without testing. This is why a higher eCPM alone never proves a floor works.

Most exchanges now run first-price auctions with hard floors. The other types still show up in contracts and ad server settings, so it helps to know what each one does.

Soft floors mix two auction types in one, which confuses buyers' shading. Microsoft's Xandr exchange documentation says soft floors "use a floor price to achieve a combination of first and second price in a single auction". It marks such auctions with at 1, because it cannot promise a second-price outcome (Microsoft Learn, Xandr bidder transparent auction FAQ, updated 21 October 2025). If you still run soft floors, expect buyers to shade as if the auction were first price.

A static floor is a fixed table: this ad unit, this size, this price. A dynamic floor changes with the context of each request, such as device, geography, time of day, page or bidder. Static floors are easy to audit. Dynamic floors usually earn more but need a model, a feedback loop and guardrails.

Prebid's Price Floors module supports both. Floors come from one of three "rule locations": a real-time data service (dynamic), the setConfig call (package) or the ad unit (Prebid.org, Price Floors module). Rules can use ad unit, GPT slot, media type, size and domain, and Prebid.js lets you add custom dimensions. When several rules match, the most specific one wins, with specificity weighted from the left-most field. A * acts as a catch-all.

You can build the model in-house or buy it. The Prebid documentation lists Magnite, OpenX, PubMatic, Assertive Yield, pubX and Mile as floor providers, each with its own description. One provider advertises an average revenue uplift of 22% (company claim) (Prebid.org, floors providers). Treat any such figure as a hypothesis for your own test, not as a forecast.

Schema 2 of the floors data lets you run two or more floor models at once and split traffic between them by weight (Prebid.org, schema 2). The file below is what a dynamic floors endpoint could return. It compares a current model with a challenger set about 10% higher, and skips floors on 10% of auctions as a no-floor control. Values are illustrative.

Enforcement is set in the page's setConfig, not in the data file. The settings below enforce floors in the browser and in Prebid Server, leave deals to the deal floor, and apply bid adjustments so floors compare net prices.

The floorMin value is a minimum the module never goes below, and Prebid notes it is not a way to set a static floor. The floorDeals setting defaults to false. The bidAdjustment setting defaults to true, because turning it off can signal a gross floor when a bidder expects net (Prebid.org, Price Floors module).

For server-side auctions, Prebid Server fetches and caches floor files per account, applies skipRate, and can enforce floors on only a share of auctions with enforceRate (Prebid.org, Prebid Server floors). Account-level floor files fit naturally into Prebid Server stored requests, and the wider wrapper set-up is in the Prebid.js guide.

If Google Ad Manager is your ad server, its unified pricing rules set floors for most non-guaranteed demand at once. They apply to the Open Auction, Private Auctions, First Look, Open Bidding exchanges, remnant line items, header bidding trafficking and SDK bidding. They do not apply to Programmatic Direct (Google Ad Manager Help, pricing rules).

Target CPM lets Ad Manager set floors per request so that the average CPM meets your target. Google's own example shows two queries where a $2.00 floor sells one impression, while a $2.00 target sells both. eCPM falls 5% and revenue rises 95% (Google Ad Manager Help, understand target CPM). Read that as an illustration of the mechanism, not as an expected result.

Optimized floor prices, in beta on 9 November 2026, set a floor per query to maximise long-term revenue. They override overlapping rules, except advertiser- or bidder-specific floors, and only work with "Set pricing for everything" (Google Ad Manager Help, optimize floor prices). Google recommends testing them with a manual experiment and warns against overlapping experiments, which can mislead through spillover. Publishers weighing other ad servers can compare them in Google Ad Manager alternatives.

Floors and shading models now train against each other. Each time a shaded bid falls below your floor, the exchange can return loss code 100, "Bid was Below Auction Floor", or 101 for a deal floor (OpenRTB 3.0, loss reason codes). Each loss notification teaches the buyer where your floor sits. If you also send the floor in imp.bidfloor, the buyer knows it before bidding.

That has two consequences. First, where competition is thin, a shading buyer will often bid just above the floor, so the floor effectively becomes the price. That is good for you if the floor is close to the buyer's value and costly if it is far below. Second, a floor that is never tested goes stale, because buyers' models keep adapting. OpenRTB also lets exchanges return the price needed to win through ${AUCTION_MIN_TO_WIN}. An exchange may leave it empty, for example when a bid did not meet the floor (OpenRTB 2.6, section 4.4.1).

Buyers read floors in a fixed order. The deal floor comes first, then the video or audio floor, then the impression floor (OpenRTB implementation guide, section 7.11). Keep the three consistent, or a buyer may bid against the wrong one. The fields themselves are covered in OpenRTB 2.6 explained.

Floor changes are cheap to make and easy to misread. A short, disciplined test protects you from both. These eight steps work with Prebid's skipRate and model groups, or with Ad Manager experiments.

1. Pick one primary metric. Use revenue per 1,000 ad requests (RPM per request), not eCPM. It captures both price and fill.
2. Set guardrails. Agree in advance the fill rate, timeout rate and user-experience limits that stop the test.
3. Create a clean control. Keep a share of traffic on today's floors, plus a small no-floor group via skipRate, so you can see what floors are doing at all.
4. Change one thing. Test one floor table or one model against the current one. Do not change bidders or timeouts at the same time.
5. Split at random, per auction. Prebid's model weights are re-rolled every auction, so each arm sees the same mix of traffic (Prebid.org, schema 2).
6. Run long enough for buyers to adapt. Shading models learn from losses. Judge the result on the later weeks, not the first days.
7. Read results by segment. A floor can win on desktop and lose on mobile. Break results down by ad unit, device, geography and bidder.
8. Log enough to explain the result. Keep bid-level records of floor, bids, winner, loss reasons and the model version, as described in log-level data.

Here is how the primary metric can disagree with eCPM. Each arm sees 10,000,000 requests. The control fills 62% at a $2.10 eCPM, for $13,020 in revenue and an RPM per request of $1.302. The test fills 55% at $2.45, for $13,475 and $1.348. The test wins by 3.5% despite losing seven points of fill. Figures are illustrative; work them out with your own counts.

Video floors scale with ad length. OpenRTB 2.6 offers mincpmpersec, a floor per second, and durfloors, a table of floors by duration range (OpenRTB 2.6, Object: DurFloors). The specification's own example sets $5 for 1 to 15 seconds, $10 for 16 to 30 seconds and $20 above 31 seconds. A seller should use one form, not both, in the same object (OpenRTB implementation guide, section 7.11).

Ad pods change the arithmetic again. Google Ad Manager applies floors on podded app traffic to the combined CPM of the pod, so single ads can clear below the floor (Google Ad Manager Help, pricing rules). Pod mechanics are explained in SSAI and CTV ad serving.

1. Judging floors by eCPM. eCPM rises whenever fill falls. Use revenue per request.
2. Floors that ignore revenue share. In Ad Manager, floors compare with the net bid. A floor set on gross numbers filters more than you intended.
3. Forgetting deals. A deal floor below your open-market floor invites buyers to move spend into the deal. Review both together.
4. Leaving skipRate at zero forever. Without a no-floor control, you cannot tell what floors are earning.
5. Changing floors and bidders together. You will not know which change moved revenue.
6. Overlapping rules you have not mapped. In Ad Manager the higher price wins, so an old rule can silently override a new test.
7. Copying a vendor's uplift figure into a forecast. Test it on your own traffic first.
8. One floor for all video lengths. A 6-second and a 30-second ad are not the same product; use duration floors.

Floor strategy is one part of yield management for independent publishers; the publisher independence hub and the RTB architecture hub link the related pages, including header bidding explained.

1. Google, "An update on first price auctions for Google Ad Manager" (10 May 2019). https://blog.google/products/admanager/update-first-price-auctions-google-ad-manager/
2. Google Ad Manager Help, "Pricing rules" (accessed 9 November 2026). https://support.google.com/admanager/answer/9298008?hl=en
3. Google Ad Manager Help, "Understand target CPM" (accessed 9 November 2026). https://support.google.com/admanager/answer/10357452?hl=en
4. Google Ad Manager Help, "Optimize floor prices in pricing rules (Beta)" (accessed 9 November 2026). https://support.google.com/admanager/answer/11385824?hl=en
5. Prebid.org, "Module: Price Floors" (accessed 9 November 2026). https://docs.prebid.org/dev-docs/modules/floors.html
6. Prebid.org, "Prebid Server Price Floors" (accessed 9 November 2026). https://docs.prebid.org/prebid-server/features/pbs-floors.html
7. IAB Tech Lab, OpenRTB 2.6 specification, Objects Imp, Deal, DurFloors and section 4.4.1 (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/2.6.md
8. IAB Tech Lab, OpenRTB 2.x implementation guide, section 7.11 "Guidance on the Use of Floors" (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md
9. IAB Tech Lab, OpenRTB 3.0 specification, "List: Loss Reason Codes". https://github.com/InteractiveAdvertisingBureau/openrtb/blob/master/OpenRTB%20v3.0%20FINAL.md
10. Microsoft Learn, "Bidder transparent auction FAQ" (Xandr documentation, updated 21 October 2025). https://learn.microsoft.com/en-us/xandr/bidders/bidder-transparent-auction-faq