How Prebid.js Works — and Why Gaming Sites Need Custom Adapters

Prebid.js is the most widely used open-source header bidding wrapper. If you run display ads on a gaming site with header bidding, there is a good chance you are using it — whether you configured it yourself or a monetization partner set it up for you.

Understanding how Prebid.js actually works gives you the foundation to evaluate your setup, ask the right questions of your partners, and identify where gaming-specific customizations make a material difference.

How Prebid.js Works: The Auction in 6 Steps

Every time a player loads a page on your site, Prebid.js executes a precisely timed sequence:

Step 1: Ad Unit Registration

Before any auction runs, Prebid.js needs to know what ad slots exist on the page. You define ad units — each one describes a placement (e.g., "sidebar-300×250") and which bidders should compete for it.

Each ad unit specifies:

• Media types — banner, video, or native
• Sizes: the creative dimensions accepted (e.g., 300×250, 728×90)
• Bidder configs: per-bidder parameters like placement IDs, site IDs, and custom key-value pairs

For a gaming site with 4 ad slots and 10 bidders, this means 40 individual bidder-to-slot configurations. Each one matters because bidders use these parameters to match your inventory against their demand.

Step 2: Bid Requests

When pbjs.requestBids() fires, Prebid.js iterates through every ad unit and sends parallel bid requests to all configured bidders. Each request includes the ad unit details, page context, user IDs (if available), and any first-party data you have attached.

Client-side bidders receive these requests directly in the browser via HTTPS calls. Server-side bidders receive them through Prebid Server in a single batched request.

The number of outbound requests depends on the adapters. Many adapters bundle every ad unit into a single request, while others send one request per ad unit. On a gaming page with 4 slots and 10 client-side bidders, that means anywhere from 10 to 40 requests. Moving some bidders to Prebid Server replaces their requests with one request to your Prebid Server.

Step 3: Bid Collection and Timeout

Bids return asynchronously. Some bidders respond in 80 ms; some take 600 ms. Because the requests run in parallel, the auction takes as long as the slowest bidder, not the sum of all of them. Prebid.js waits until either all bids have returned or the timeout expires, whichever comes first.

The client-side timeout (bidderTimeout) is set globally and defaults to 3000 ms; for gaming sites we usually recommend 800–1200 ms. Prebid Server bidders are also governed by a separate timeout in s2sConfig. When the client-side timeout fires, any bids not yet received are discarded. This is where timeout optimization becomes critical: set it too low and you lose high-value bids that were 50 ms from arriving. Set it too high and your ads render late while the page is loading.

Step 4: Auction

Once bids are collected, Prebid.js runs the auction. The default auction algorithm is simple: highest bid wins per ad unit. But you can configure custom auction logic, including:

• Floor enforcement: bids below a specified CPM are rejected (via the Price Floors module)
• Deal priority: private marketplace deals can be given preference over open auction bids at the same price
• Bid adjustment: multipliers that adjust bids from specific bidders (useful for normalizing gross vs net bids)

The auction output is a set of winning bids, one per ad unit, along with targeting key-value pairs that get passed to your ad server.

Step 5: Ad Server Handoff

Prebid.js sets targeting keys on the ad server request (usually Google Ad Manager). These keys tell the ad server which Prebid bidder won and at what price. The ad server then runs its own auction, comparing the Prebid winner against its own demand (AdX, direct campaigns, etc.) and serving the overall winner.

This two-stage auction is a common source of confusion. Prebid.js does not serve the ad directly. It passes a recommendation to the ad server, which makes the final call.

Step 6: Creative Rendering

When the Prebid bid wins at the ad server level, a Prebid creative renders in the ad slot. This creative is a lightweight HTML snippet that calls back to Prebid.js to retrieve the actual ad markup from the winning bidder. The ad then renders in the slot.

For video ads, this step is more involved: the video player loads the VAST response, buffers the video, and manages playback, with OMID handling measurement. (VPAID is deprecated; ask for VAST 4.x, with SIMID if you need interactivity.) Rendering latency for video is significantly higher than for display.

Where Default Prebid Falls Short for Gaming

The six steps above work identically whether your site is a news publisher or a gaming portal. The problem is not in the flow; it is in the default configurations and adapter ecosystem that assume a content publishing model.

Here are the four areas where gaming sites need custom work.

1. Gaming-Endemic Demand Partners

The Prebid.js adapter library includes hundreds of bidder adapters. Most of them are general-purpose programmatic exchanges. Only a handful are gaming-endemic demand sources: ad networks and DSPs that specialize in gaming audiences and have dedicated gaming advertiser budgets.

Gaming-endemic partners matter because they often bid higher on gaming inventory than general exchanges. They have advertisers (game studios, hardware brands, esports sponsors) who specifically want to reach gamers and will pay for that targeting.

The problem: several gaming-specific demand partners either are not in the default Prebid adapter library or have adapters that need custom parameters for gaming sites. You may need to:

• Register custom adapter builds that include gaming SSPs not in the standard distribution
• Configure gaming-specific parameters (genre targeting, player demographics) that standard adapter configs do not expose
• Set up separate bidder configs for gaming inventory versus non-gaming content on the same site

If your Prebid build was assembled once from a generic list of adapters, you may be missing gaming-endemic demand sources that would compete meaningfully for your inventory.

2. Custom Ad Unit Definitions for Game Layouts

Content sites have predictable layouts: header, sidebar, in-content, footer. Prebid ad units map cleanly to these positions.

Gaming sites have layouts that change based on the game state. A player in a game sees different ad placements than a player browsing the game catalog. A leaderboard between levels is a high-viewability moment that deserves its own ad unit definition. A pause screen is another.

Standard Prebid implementations define ad units once at page load. Gaming sites need dynamic ad unit registration that responds to game events:

• Game load: Sidebar and top banner units are active
• Between levels: Interstitial or rewarded video unit registers
• Game over: Full-screen interstitial with high viewability
• Menu/browse: Standard display units for catalog pages

This requires integrating Prebid.js with your game's event system. When a game emits a "level complete" event, your Prebid integration should register a new ad unit, request bids, and render the winning creative, all within the natural pause in gameplay.

3. Session-Aware Refresh Modules

Prebid.js does not refresh ads by itself; refresh is whatever your page code (or your partner's wrapper) does. Most setups use a simple timer that refreshes all ad units every N seconds. For gaming sites, this is crude and costly.

A session-aware refresh module tracks the player's engagement state and adjusts refresh behavior accordingly:

• Active gameplay: Refresh in-view sidebar ads on a 30–45 second timer (player is focused on the game, but the ad is in peripheral view)
• Idle state: If the player has not interacted for 60+ seconds, pause refresh (they may have walked away; refreshing earns impressions but tanks viewability metrics)
• Transition moments: Refresh when the game state changes (level complete, game over, menu open), as long as the slot is in view and at least 30 seconds have passed since its last refresh
• Long-session gating: Slow refresh down in very long sessions, where repeated impressions to the same player earn less as advertisers' frequency caps kick in

Building this requires a refresh controller in your page code that subscribes to game events, tracks slot visibility, and calls pbjs.requestBids() and then the ad server's refresh for the slots it chooses.

4. Rewarded Video Pre-Caching

Rewarded video is the highest-CPM format available to gaming publishers: $15–30 CPMs are typical because completion rates run 80–95%. But rewarded video has a cold-start problem: the player clicks "watch ad for extra life" and expects the video to play immediately. If Prebid.js has to request bids, run an auction, and buffer a video at that moment, the delay can run to several seconds. Players abandon.

The solution is pre-caching: request and cache rewarded video bids before the player needs them. When the player triggers the rewarded moment, the cached bid is ready to play.

Implementation involves:

• A custom Prebid module that requests rewarded video bids during natural downtime (game loading, between levels)
• A cache manager that holds the top two or three bids and discards each one when its time-to-live (set by the bidder) expires, requesting fresh bids to replace it
• An integration layer that connects your game's reward trigger to the cached bid, instead of starting a new auction at that moment

Pre-caching improves rewarded video engagement because players get the instant response they expect. It also protects revenue: a slow auction no longer costs you the rewarded moment.

The Build vs Buy Decision

You can implement all of this yourself. Prebid.js is open source, well-documented, and extensible. A competent ad ops engineer can build gaming-specific modules over several weeks.

The question is whether that is the best use of your engineering time. The gaming-specific customizations described above require:

• Deep knowledge of the Prebid.js module system and auction lifecycle
• Relationships with gaming-endemic SSPs (to get adapter code and test accounts)
• Ongoing maintenance as Prebid.js releases new versions (roughly one major version a year, plus frequent minor releases)
• Continuous optimization based on auction data across multiple sites

A single gaming site optimizing alone has a sample size of one. A monetization partner working across many gaming sites has the data to know which adapters, configurations, and modules actually grow revenue, and can start from setups that have already worked elsewhere.

What To Do Next

If you are running Prebid.js on a gaming site, audit these four areas. Check whether your build includes gaming-endemic adapters. Ask whether your ad units are static or game-state-aware. Look at your refresh logic and see if it is timer-based or event-driven. And check whether your rewarded video implementation pre-caches bids or cold-starts every time.

If any of those answers are not what you want to hear, those are the places to start. For the configuration side, read why header bidding configuration matters more than partners, or see publisher results from gaming sites we work with.