Case Study: How One Publisher Increased RPM By 42% In 90 Days

A Site With A Fill Rate Problem, Not A Traffic Problem

The site was a home improvement and DIY blog, five years old, ranking well for mid-funnel how-to content. 4.1 million monthly pageviews, roughly 11.2 million monthly ad impressions across four units per page after lazy load kicked in. Five demand sources fed the page: AdSense plus four regional and programmatic networks, all stacked in a fixed-priority waterfall that had been configured once, years earlier, and never revisited. Blended RPM was $8.40. That number hadn't moved more than 4% in either direction for six straight months, which is usually a sign the account is coasting on inertia rather than being actively managed.

The waterfall's structure was the real issue. Network #1 always got first look at every impression regardless of what it was actually willing to pay that day, and network #3 — which frequently had the highest true demand for certain units — never got a chance to bid until #1 and #2 had already passed. On a lot of days that meant 20-30% of the theoretical auction value was simply never captured, because the highest bidder wasn't necessarily the one making the decision.

Fill rate looked fine on paper at 89%, but a lot of that fill was low-value fill going to whichever network happened to sit at the top of the stack for a given unit. The account had never been broken down by unit-level floor performance, so nobody could actually say which slots were underpriced and which were overpriced. That gap in visibility is what the first 30 days were partly about fixing, even before the header bidding rollout itself finished.

• 4.1M monthly pageviews, ~11.2M monthly ad impressions
• Starting blended RPM: $8.40
• Fill rate: 89% (unweighted, not broken out by unit value)
• Five demand partners in a fixed-priority waterfall
• Single site-wide floor: $2.50 across every ad unit

Days 1-30: Tearing Out The Waterfall For Header Bidding

The team didn't flip the switch all at once. Header bidding went in as a staged rollout, starting with 10% of traffic in week one, specifically to catch integration issues before they touched the whole site. All five existing partners were kept — the point wasn't to add or drop demand yet, it was to change how those same five competed for each impression. That distinction mattered later; it meant the 18% lift in month one was attributable purely to auction mechanics, not new money entering the picture.

Week two expanded the rollout to 50% of traffic and this is where the account manager started watching page load and viewability metrics daily rather than weekly, because a header bidding wrapper adds real latency if it's not tuned. The initial timeout was set at 800 milliseconds, which felt safe and conservative — bidders had plenty of time to respond, so bid density looked great. RPM on the 50% test group was already tracking 12-14% ahead of the untouched control group by day 18.

Week three pushed to 100% of traffic and week four was spent stabilizing rather than making further changes. By the end of the month, blended RPM across the full site had moved from $8.40 to $9.91 — a clean 18% lift, with no traffic growth and no new demand partners. That's the number most case studies stop at, because it's the easy, clean win. The harder part happened in week two, and it's worth walking through separately.

• Week 1: wrapper installed, 10% traffic rollout, integration QA
• Week 2: expanded to 50% traffic, timeout and latency tuning begins
• Week 3: full 100% rollout across all ad units
• Week 4: stabilization, no further changes, results measured against holdout group

The Timeout Setting That Nearly Erased The First Month's Gains

An 800 millisecond timeout maximizes the number of bidders who get to respond, which is why it's a common default recommendation. What it doesn't account for is that every millisecond of wait time is a millisecond your page isn't rendering. Between day 10 and day 16 of the rollout, viewability on the above-fold leaderboard unit dropped from 74% to 61%, and the daily RPM chart for the 50% test group actually flattened for four straight days — a warning sign that got noticed specifically because the team was checking the dashboard daily rather than waiting for the monthly report.

The cause wasn't subtle once someone looked: one of the five bidders was consistently the slowest to respond, routinely taking 650-700ms of the 800ms window, and it was winning less than 3% of auctions anyway. It was contributing almost nothing and costing the page nearly a full second of added latency on a meaningful share of impressions. Cutting the global timeout to 550 milliseconds and dropping that one slow bidder from the above-fold unit specifically fixed both problems within three days.

Viewability recovered to 71% by day 20, still slightly below the original 74% but well within an acceptable range given the RPM upside, and the flattened growth curve resumed climbing immediately. This is the part most header bidding guides skip entirely — they'll tell you to set a timeout and move on, but the actual tuning happens through watching what a specific slow bidder costs you in page performance versus what it wins you in bid density, and those two numbers are rarely in balance on day one.

Days 30-60: Killing The Site-Wide Floor

With 30 days of real per-impression bid data now sitting in the reporting dashboard, the team could finally see something the waterfall had always hidden: what each ad unit was actually worth. The sidebar-low unit rarely cleared $1.10 in winning bids, yet it sat under the same $2.50 floor as everything else, which meant it lost auctions constantly. Meanwhile the in-content-top unit was routinely clearing $4.50 to $6.00, and the $2.50 floor did nothing to push bidders any higher than they needed to go — it was leaving margin on the table on the site's best inventory.

The fix was to segment floors by unit and, separately, by traffic source. Sidebar-low dropped to a $0.85 floor and immediately started winning more auctions. In-content-bottom, which had a miserable 52% fill rate under the old floor, dropped to $1.10 and climbed to 81% fill within the first week. In-content-top and the leaderboard were raised, not lowered — to $4.10 and $3.20 respectively — based on the median winning bid over the prior 30 days, not the average, since a handful of high outlier bids were skewing the average upward and would have led to an overly aggressive floor.

Traffic source segmentation mattered almost as much as unit segmentation. Social referral traffic on this site had historically monetized 30-35% lower than organic search traffic, something that had never shown up clearly before because it was buried inside a single blended average. Applying a separate, lower floor tier for social traffic — roughly 25% below the organic floor on the same units — recovered fill on those impressions without dragging down the premium organic numbers.

• Sidebar-low: $2.50 to $0.85
• In-content-bottom: $2.50 to $1.10 (fill rate 52% to 81%)
• In-content-top: $2.50 to $4.10 (based on median, not average, winning bid)
• Leaderboard: $2.50 to $3.20
• Social-referral traffic: separate floor tier, ~25% below organic

Four Days Of Cratered Fill On The Leaderboard

The in-content-top floor wasn't set at $4.10 on the first attempt. It was originally set at $5.50, based on the top-decile winning bids from the prior month rather than the median — an easy mistake to make when you're looking at a chart and your eye gets drawn to the highest numbers rather than the typical ones. For four days, fill rate on that specific unit fell from 94% down to 61%, and the unit that was supposed to be the site's best performer was instead sitting empty a third of the time. Estimated lost revenue during that window was roughly $1,100.

The daily fill-rate-by-unit dashboard flagged the drop on day two, not day four, because that's specifically what it was built to catch. The floor was rolled back to $4.10 by day four once the team confirmed the pattern wasn't a one-day fluctuation but a sustained drop tied directly to the change. Fill recovered to 91% within 48 hours of the correction.

By the end of week seven, that same unit's blended eCPM was up 22% versus its pre-floor baseline, achieved without the fill damage the $5.50 floor had caused. The lesson that stuck with the team afterward: set unit floors off the median or even the lower-quartile winning bid, never the top decile, because the top decile represents your best days, not your typical ones, and a floor calibrated to your best day will fail on every ordinary one.

Days 60-90: Two New Demand Partners, Ramped Deliberately

Only after header bidding was stable and floors were segmented did the account add new demand. That ordering was deliberate — adding partners earlier, into either the old waterfall or an unsegmented floor structure, would have muted their impact before they ever got a fair shot at winning impressions. The two partners chosen went through a vetting pass first: certification status, a latency budget under 200 milliseconds so they wouldn't reintroduce the timeout problem from month one, compliance coverage for both GDPR and CCPA, and confirmation that their primary demand sources didn't heavily overlap with the five networks already in place. You can diversify your demand all day, but adding a sixth network that buys from the same three exchanges as your existing five doesn't add much competitive density.

The first new partner went live in week nine, and its initial bid density came in well below projections — appearing on roughly 40% of eligible auctions instead of the 70%+ that had been expected based on the partner's own benchmarks. That's a common and underdiscussed issue: a lot of demand partners' algorithms need two to three weeks of live impression history on a specific site before their bidding models calibrate properly. Pulling the plug after a disappointing first week, which is the instinct a lot of publishers have, would have missed the ramp entirely.

The second partner onboarded in week ten, staggered rather than simultaneous specifically so any performance issue could be traced to one partner and not the other. By week twelve, the two new partners combined were winning 9-13% of auctions site-wide depending on the unit, and blended RPM had climbed to $11.93 — a 10% lift on top of where floors had left things, and a 42% cumulative lift from the $8.40 starting point, with zero change in traffic.

• Certification status confirmed before integration
• Latency budget under 200ms per partner
• GDPR/CCPA compliance verified, not assumed
• Minimal overlap with existing demand sources' primary exchanges
• Staggered onboarding, one partner per week, not simultaneous

The Weekly Numbers That Proved Each Change Actually Worked

None of this would have been catchable without a reporting structure built to isolate cause and effect, and this is the part most publishers skip entirely. At every phase, 10% of traffic was held back as a control group running the prior configuration while the rest of the site moved forward. That holdout is what made it possible to say the header bidding lift was 18% and not some smaller number inflated by a naturally strong week for one of the networks.

Four numbers got checked daily rather than monthly: RPM by unit, fill rate by unit, eCPM by demand partner, and page-level viewability. A weekly quick review compared the test group against the holdout group and made a go/no-go call before expanding a rollout percentage — that's specifically the process that caught the timeout regression on day two of a four-day flattening trend, and caught the floor-price fill collapse on day two rather than day four or five.

Nothing here required expensive tooling. The dashboard was built from the ad server's and header bidding wrapper's native reporting, pulled into a shared spreadsheet updated each morning. What mattered wasn't the sophistication of the tooling, it was the discipline of checking it daily during any active change and comparing against a real control group rather than trusting a gut feeling that things seemed fine.

One habit worth stealing directly: every Friday, that week's numbers got compared not just to the prior week but to the same week's control group, side by side in the same spreadsheet. That comparison is what turned "RPM seems up" into "RPM is up 4.2% specifically because of the floor change, isolated from any day-of-week or seasonal swing." Without that discipline, a lot of these gains would have gotten chalked up to a good week rather than traced back to the actual cause.

Why The Order Mattered More Than Any Single Change

Run the floor segmentation before header bidding and you're setting floors based on waterfall-era data, which reflects fixed-priority bidding behavior, not real per-impression competition. The median winning bid under a waterfall understates what a unit is actually worth once every network has to compete for it head to head. Floors set on that basis would have been too conservative on the premium units and this publisher would have left additional margin unclaimed for the rest of the project, possibly permanently, since nobody would have known to revisit numbers that already looked reasonable.

Run the new demand partners before header bidding and they'd have been added into a fixed-priority waterfall where they almost certainly would have landed near the bottom of the stack, behind five existing relationships nobody wanted to disturb. A partner sitting at waterfall position six gets scraps — maybe a 2-3% contribution instead of the 10% these two delivered once they were competing in a real per-impression auction with segmented floors already protecting the account's downside.

Running all three simultaneously would have been the worst option, even though it's the most tempting one when a team wants faster results. When the timeout regression hit in week two, it was isolated to one clear cause because floors and new demand hadn't been touched yet. If all three changes had gone live together and RPM had dipped, there would have been no way to know whether it was a timeout issue, a floor set too aggressively, or an underperforming new partner — and untangling three simultaneous variables typically costs more time than doing them in sequence would have in the first place.

Where This Fits In Your Own Account

This exact 42% figure isn't a promise, and treating it as one is the wrong takeaway. The size of the lift here was a direct function of how far behind the starting setup was — a fixed-priority waterfall with a single blanket floor is a genuinely outdated configuration, and the further behind you're starting, the more room there is to recover. An account already running header bidding well, with floors already segmented by unit, isn't going to see an 18% jump from a step it's already taken.

Before assuming any of these numbers are repeatable in your account, it's worth actually looking at what you're running today rather than guessing. Running your setup through the eligibility checker is a faster way to see where your account stands against current header bidding, floor, and demand-partner practices than trying to reverse-engineer it from your own RPM chart alone. Some accounts will find they've already captured most of this; a lot of accounts running a legacy waterfall configuration haven't, and don't know it.

It's also worth being honest about the ceiling. Once an account has genuinely modern header bidding, segmented floors, and a healthy spread of certified demand partners, the next 90-day project usually produces single-digit gains, not 40%-plus ones, because the obvious inefficiencies are already gone. That's not a failure — it's what a mature setup looks like. The publishers who keep finding double-digit lifts quarter after quarter are almost always the ones still sitting on some version of the outdated waterfall-plus-one-floor setup this account started with.

Frequently Asked Questions