Header Bidding for Gaming Sites: Why Configuration Matters More Than Partners

Picture a familiar quarter: you add several demand partners to your header bidding stack, and revenue rises a little. Then you spend an afternoon adjusting timeouts and floor prices, and revenue rises again, by more.

That is a pattern we see often on the gaming sites we work with: configuration changes frequently outperform partner changes. Yet most header bidding guides spend most of their ink on which SSPs to include and barely mention the parameters that decide how much those partners actually pay.

Why Standard Configurations Underperform on Gaming Sites

Most header bidding setups are tuned with content publishers in mind — news sites, blogs, recipe pages — which means short sessions, lightweight pages, and mostly Tier 1 traffic.

Gaming sites break each of those assumptions:

• Sessions are much longer. Casual-game sessions on a portal are long and span many pageviews, and a player can sit on a single game page for many minutes. Without proper refresh configuration, you monetize the first few seconds of that page and leave the rest on the table.
• Pages are heavier. Game assets, scripts, and frameworks often push initial page weight to several megabytes. When header bidding competes with game loading for bandwidth, both suffer.
• Traffic is globally distributed. Gaming sites often get a large share of traffic from Tier 2 and Tier 3 geos. A single global floor price either leaves money on the table in high-CPM markets or chokes fill rate in low-CPM ones.
• User attention is focused. Players are engaged with the game, not scrolling past ads. Viewability patterns are fundamentally different from content sites, which changes how bidders value your inventory.

Running a default Prebid configuration on a gaming site is like putting road tires on a rally car. Technically it works. Practically, you are giving up revenue on every session.

The 5 Configuration Parameters That Drive Gaming Revenue

In our experience, these five parameters produce the largest revenue impact on gaming sites.

1. Timeout Settings

The timeout defines how long your auction waits for bids before sending the ad call to the ad server. Prebid.js ships with a default bidderTimeout of 3000 ms, and many sites never change it. If you run Prebid Server, it has its own timeout, set in s2sConfig.

For gaming sites, the default is far too long.

Client-side timeouts need to be tighter. Gaming pages have heavy initial loads. If the auction waits up to 3 seconds on top of a 3-second game load, ads render late, and the player may already be mid-game or gone. Bidders are called in parallel, so the timeout is not per bidder; it is how long the whole auction waits for the slowest ones. In our experience, gaming sites do best with client-side timeouts of 800–1200 ms: tight enough to protect page load, long enough to capture most bids.

Keep the server-side timeout inside the client-side one. The Prebid Server auction runs server to server, but its response still has to reach the browser before the client-side timeout expires. Set the s2sConfig timeout comfortably below your bidderTimeout, or server-side bids will arrive too late to count.

The key insight: test timeout changes in 100 ms steps. On gaming sites, each 100 ms cut usually costs almost nothing in bid coverage until you reach a cliff where bids start dropping off sharply. Find that cliff and settle just above it.

2. Ad Refresh Intervals

Many setups do not refresh at all, and those that do often run on a blind timer. For gaming sites, viewable refresh is one of the biggest untapped revenue levers.

For example, a player who spends 15 minutes on one game page next to a 300×250 slot generates 1 impression from that slot if it never refreshes. With viewable refresh every 30 seconds, the same slot can serve up to 30 impressions if it stays in view the whole time (900 seconds ÷ 30). In practice it will be fewer, because players scroll and switch tabs.

But crude refresh kills your CPMs. Bidders discount inventory that refreshes too aggressively because viewability metrics drop. The sweet spot for gaming sites is:

• 30 seconds for ad slots that are consistently in-view (sidebar placements next to the game)
• 45–60 seconds for placements that are only intermittently in view
• Event-triggered refresh at natural breaks (level completion, game over, menu navigation)

In every case, refresh only slots that are currently in view, and never faster than every 30 seconds.

Event-triggered refresh is the real unlock. When a player finishes a level, they are in a natural break — attention is available, viewability is high, and bidders tend to pay more. Tying refresh to game events rather than a fixed timer, while still respecting the 30-second minimum, usually improves the CPMs of refreshed impressions.

3. Floor Prices (Geo-Specific)

A single global floor price is a blunt instrument. Set it at $2 CPM and you block most bids in lower-CPM markets such as India, while US standard display, which typically clears $2–6 CPM, could often support a higher floor. Illustrative US ranges from our experience; your rates depend on geography, format and season.

Gaming sites benefit enormously from geo-tiered floor prices:

These are illustrative starting points, not gospel. The right floor for your site depends on your traffic composition, ad formats, and demand partner mix. But the principle holds: a gaming site with a large share of Tier 3 traffic running a $2 global floor blocks most of the bids in those geos. That is lost revenue.

Set floors per geo tier, then refine monthly based on bid landscape data. Most SSPs provide bid density reports that show where your floor sits relative to actual bid distribution.

4. Bid Caching

Bid caching keeps bids that lost an auction and lets them compete again in a later auction for the same ad unit, typically on the next refresh. For content sites where a visitor sees one or two pages, caching has limited impact. For gaming sites, where a player sits on the same page through many refreshes, it matters much more.

Here is why: a bid that arrived at $4 CPM but lost to a $5 bid still has value. On the next refresh, that cached $4 bid enters the auction alongside the fresh bids. It does not set a floor, and a higher fresh bid still wins, but if fresh demand is thin, the cached bid can win instead of the impression going to a lower price or going unfilled.

In Prebid.js this is the useBidCache setting, which is off by default. The implementation details matter:

• Respect bid lifetimes. Every bid carries a time-to-live set by the bidder, and Prebid discards it once that expires. Don't try to extend it.
• Clear on navigation. A full page load clears the cache naturally; single-page game portals should make sure bids are not carried across unrelated pages.
• Filter where needed. Prebid lets you filter which cached bids are eligible, for example to exclude a partner that does not allow reuse.

The caveat: not all SSPs allow their bids to be cached. Check partner agreements before enabling this. Most major exchanges permit it, but a few explicitly prohibit reuse.

5. Bidder Selection and Placement

Not all bidders are equal on gaming inventory. A general exchange that bids $2 CPM with 200 ms latency and a gaming-endemic SSP that bids $5 CPM with 400 ms latency should not be treated the same way.

Prebid calls bidders in parallel, so their order in your config makes little difference. What matters is which bidders you run and where you run them. Decide based on two factors:

• Win rate and bid value on your inventory. Partners that win often, or win at high prices, earn their place client-side.
• Latency profile. Slow bidders that rarely win should be moved to server-side or removed entirely.

Practically, this means reviewing bidder performance monthly and adjusting the configuration. A partner that was your top performer six months ago may have shifted budget. A new partner may be bidding aggressively on gaming inventory but timing out on most auctions.

We recommend a quarterly partner review where you evaluate each demand source against three metrics: win rate, average bid CPM, and p95 latency. A partner that rarely wins and is slower than average is a candidate for removal or server-side migration. There is little gain past roughly 10–12 client-side bidders; more than that run server-side, so quality matters more than count.

Putting It All Together

The five parameters above interact with each other. Tighter timeouts mean you need faster bidders in client-side. Higher refresh rates mean bid caching becomes more valuable. Geo-specific floors change which bidders are competitive in which markets.

This is why configuration is not a one-time setup. It is an ongoing practice. In our experience, gaming sites that review header bidding configuration monthly (testing, measuring, adjusting) do better than those that configure it once and leave it.

If you are running header bidding on a gaming site with default settings, there is likely easy revenue waiting. Start with timeout optimization (it is the fastest to test), then add geo-specific floors and refresh tuning. For the bigger picture of how header bidding fits into your revenue, read how ad monetization works for gaming publishers, or see publisher results from gaming sites we work with.