How Machine Learning is Automating Price Floor Optimization at Scale
Google's May 2016 announcement carried the first measured claim for machine-learned floor pricing: optimized pricing applied to about 15 percent of transactions and created over 5 percent lift in revenue for publishers using the Open Auction. The vendor reported those numbers itself on May 12, 2016, and the auction it describes predates the unified auction. Treat the 5 percent as historical vendor reporting, not as an expectation for your inventory. The durable idea in the announcement is the decision unit: one price computed per query, at the instant a bid request exists, by a model nobody at the publisher touches.
Floors have since moved from a spreadsheet one analyst owned to a model output a pipeline owns. Google now runs two automated floor systems inside Ad Manager, the Prebid project runs a third as an open source module, and a December 2025 rules change made bidder-level floors a standard control. Each system decides something different, at a different granularity, with a different failure mode, and treating the three as one feature is the fastest way to mis-price inventory.
What a floor does in a first-price auction
In a second-price world, a floor behaved like a door policy: buyers below it went home, and the winner paid the clearing price. In first-price auctions, buyers shade bids below their true value and bid just above what they expect the auction to clear at, so the floor works as a signal as much as a threshold. Set it too high and bidders walk, leaving impressions unsold or dumped to defaults. Set it too low and clearing prices cluster just above the floor, and the gap between what buyers would have paid and what they did pay accumulates quietly.
The signal runs in both directions. Buy-side shading models estimate clearing prices from the floors they observe, so an erratic floor schedule teaches buyer models noise, while a coherent one teaches them your actual reservation. Expected-value ranking adds a second dimension on top: when the auction weights projected delivery or viewability into the comparison, the top bid does not always win, and a floor that suppresses bids the ranker would have scored highly changes the winner set, not just the clearing price. We lay out the mechanics, expected-value ranking, first-price bid shading and reserve prices, in our programmatic auction guide.
The scale problem is arithmetic. A site with 200 ad units, six sizes and 40 geos spans 48,000 price cells before anyone splits by buyer or hour of day. A human setting one floor per ad unit manages 200 numbers and leaves the other 47,800 combinations unpriced. A model setting one price per query prices all of them, including cells that clear twice a month. Machine learning reached floor pricing because the grid outran the analyst.
Google's two automated floors
Target CPM is the older and simpler of the two. You indicate a target, and Ad Manager dynamically sets floor prices on individual bid requests, higher or lower than the indicated target, aiming for an average CPM at or above the target. It applies to non-guaranteed demand such as Authorized Buyers, Open Bidding and remnant line items. The publisher keeps the target and hands over the per-request price.
Optimized floor prices, still in Beta, go further. According to Google's optimized floor prices documentation, the feature leverages a machine learning model to maximize long-term revenue and sets a price per query rather than per rule. Per query means the price can vary with everything that varies on a single impression request: ad unit, size, geography, device and the buyer mix present at that instant. A rule cannot match that, because rules fire on segments, and segments stay coarser than queries.
Two constraints shape deployment. The model overrides floors from overlapping pricing rules but leaves advertiser-specific and bidder-specific floors alone, and it requires the "Set pricing for everything" option, which turns pricing on globally instead of segment by segment. Both constraints deserve a written note in your runbook, because they decide what the model can and cannot touch on day one.
The December 2025 change completes the picture. Google removed unified pricing rules, renamed the feature pricing rules, and let publishers set floor prices for specific programmatic bidders. The old carve-out is now a working control: hold a floor for one bidder, protect an advertiser floor, and let the model manage everything else. Write the override order down before you configure anything, because the model overrides overlapping rule floors and leaves advertiser-specific and bidder-specific floors in place.
Picking between Target CPM and optimized floor prices is a governance decision more than a technical one. Target CPM answers a finance question: hold my average around this number. Optimized floor prices answer a yield question: take the best price this traffic can bear over the long run. The two objectives diverge whenever demand turns volatile, so decide which question you are answering before you enable either.
Practitioner analysis of optimized pricing adds three cautions, and all three are operational facts rather than opinions. First, the model only raises floors, never lowers them, so a rule floor you set too high stays too high; automation fixes under-pricing, not over-pricing. Second, it operates at the network level, so you cannot enable it per ad unit or per traffic slice. Third, you cannot A/B test it, which restricts measurement to a before-and-after comparison with every confound that implies: seasonality, demand shifts, layout changes, everything else shipped that month.
The before-and-after constraint dictates your testing discipline. Freeze the rest of the stack around the switch: no layout changes, no new demand partners, no viewability projects inside the same window. Compare equal-length periods on both sides of the switch date at the same ad unit granularity, and log every change in a shared change log. Treat any lift figure you read elsewhere as a number from someone else's auction in someone else's demand period: Google's own 5 percent came from the Open Auction of 2016, before first-price auctions changed what a floor even does.
The Prebid route: floors you can test
Prebid's Price Floors Module is the open source counterpart, and it differs from Google's systems on the axis operations teams care about most: you own the model, the data and the experiment. Floors arrive from configurable floor data providers as JSON, and the wrapper fetches them in real time before the auction, with an optional auction delay to give the fetch time to land. Enforcement sits on the bid stream itself: the module marks all bids below the floor as bids rejected, and those bids never reach the auction.
Schema version 2 turns testing from an aspiration into a config file. You supply multiple floor models with weights, and the wrapper samples across them per request, which lets you serve the incumbent model on 90 percent of traffic and a challenger on 10 percent in the same hour, on the same inventory, for A/B style testing. That closes the biggest gap the network-level Google feature leaves open: a genuine holdout instead of a before-and-after narrative. It also lets you test a model that lowers floors on segments the incumbent over-prices, which optimized floor prices cannot do by design.
Open source changes the governance model as much as the math. Google's feature accepts your inventory as input and returns a price you cannot inspect; the wrapper route returns a JSON document you can read, diff, version and roll back. The cost of that control is ownership: someone on your side owns the provider contract, the fetch schedule, the schema version and the weight split, and that someone needs a name. Publishers with wrapper engineering run floors as infrastructure and review them like code. Publishers without it borrow the ownership from a partner, and that works as long as the contract says who watches the reject stream.
The remaining costs sit in the plumbing. The auction delay buys floor accuracy with response time, and adapter timeouts tax every millisecond you add, so set the delay deliberately and re-check timeout rates after each change. Know what your wrapper does when the floor JSON fails to arrive, because a provider outage at request volume is not an edge case. Refresh floor data often enough to track demand shifts and rarely enough to respect the provider endpoint, and cache provider responses where the architecture allows.
Managed floors and the curation layer
We are OnlyMedia: an ad network, an SSP and an agency in one company, working with thousands of publishers, each above one million monthly pageviews. A curation layer sits in front of the auction: managed floors, demand mapping, whitelists, pre-bid brand safety filtering and MFA filtering aligned with the IAB Content Taxonomy. The order of operations matters. Filtering removes demand that fails a quality bar before price enters the picture, and the floor then prices what survives. A floor hike is the wrong tool for a made-for-advertising problem, because a higher floor does not remove junk demand, it just charges it more.
Demand mapping and whitelists do the narrowing that floors cannot. Mapping assigns each incoming seat to a demand category, whitelists restrict which categories bid on which inventory, and the floor then prices a known pool instead of an open one. When the pool is known, the model's clearing-price history means something; when anything can bid, that history blends demand you would never keep with demand you would.
Our SSP runs one unified auction per impression, with AdX via MCM, Prebid and OpenRTB seats competing in a single bid pool, and it enforces managed floors where all of that demand meets. One auction per impression is a precondition here, not a slogan. When header bidding demand clears in one auction and AdX clears in another, a floor that holds in only one of them leaks: buyers route around it to the cheaper auction, and the model prices nothing. A floor model's output matches what buyers actually pay only when every seat competes inside the same auction.
Managed floors exist because single sites under-sample. One publisher rarely clears enough auctions in any given geo, size and buyer cell to estimate a price with confidence, and a model that draws on a single site's history learns noise. Running floors across a network pools clearing history, stabilizes the estimates and fills cells a lone publisher cannot. The managed floor work runs inside a curated programmatic demand network, and we pay CPM based, Net 30, with no chasing and no sliding terms.
Measurement closes the loop. Our reporting console refreshes every metric every ten minutes, with API access, so a floor change shows its effect the same day it ships, and you catch a bad cap inside a day rather than at month end. That cadence is the actual product; the model is a component inside it. For agencies advising publishers, the due diligence list is short: payout basis, payment rhythm, and the override order. The first two tell you who carries pricing risk, and the third tells you what the model will do on day one.
How to audit an automated floor
Automation moves the work from setting prices to auditing them, and the audit standardizes across Google's systems and Prebid alike. Run it whenever a floor system changes, and rerun it on a fixed calendar even when nothing changed, because demand moves even when code does not. Seven checks cover it:
- Map the override order. Write down which floor wins per impression before you change anything: optimized floor prices override overlapping pricing rules, while advertiser-specific and bidder-specific floors survive. If two people on your team describe that order differently, you have found the first defect.
- Check the prerequisites. Optimized floor prices require the "Set pricing for everything" option, and enabling it changes how every existing rule behaves. Read the resulting configuration diff, not just the checkbox.
- Assign the caps. Models move floors inside the bounds you set, so define hard minimum and maximum floors per ad unit before handing over the middle of the range. A model without a ceiling trades impression volume for CPM past the point where total revenue follows.
- Instrument the reject stream. The Prebid module marks every bid below the floor as bids rejected; track the rejected share per ad unit and per bidder on a schedule. A rising reject share with flat effective CPM means the floors moved ahead of demand rather than ahead of value.
- Design the experiment before switching. For Google's features, freeze the stack and compare equal-length periods with a written change log. For Prebid, use schema version 2 weights to hold out a control slice and read the difference within the same demand period.
- Treat latency as a floor metric. The optional auction delay buys accuracy with response time, and adapter timeouts tax every millisecond you add. Set the delay explicitly, then re-check timeout rates after each release.
- Reconcile bidder floors after the rename. Pricing rules now let you floor specific programmatic bidders, so verify each floor attaches to the bidder you intended, and re-verify after any change in demand seats.
The audit fits in an afternoon once it has a template, and it pays for itself the first time a model change and a layout change land in the same week. A written template also travels across clients, which matters to an agency running the same stack for a dozen publishers.
The floor is now an output
A decade ago, floor optimization meant an analyst raising hand-picked floors and reading the monthly report. Google's 2016 claim, 15 percent of transactions and over 5 percent lift, marked the first public evidence that a model could beat that workflow, and the vendor reported it from an auction that no longer exists. The systems that ship now set prices per query, per bid request and per model weight, and the controls that stay human are the audit's seven checks: override order, caps, holdouts, reject rates, latency.
The publishers who benefit most treat floor automation as a measurable system with named owners, not as a switch someone flipped during a migration. Name the owner, run the audit, hold out a control slice where the stack allows it, and never confuse a raised floor with a solved problem.