Prebid.js Setup: 12 Configuration Mistakes That Cost Money

Prebid.js is open source and free; a profitable Prebid configuration is neither obvious nor static. These are the most common configuration mistakes we find when auditing publisher wrappers.

Auction mechanics

• Timeout too short or too long. Under ~700ms you lose slow but valuable bidders; over ~1,500ms you trade revenue for latency that costs pageviews. Tune per geo — and per connection type if you can.
• Wrong price granularity. Coarse $0.50 buckets round bids down at the GAM line-item boundary. Use dense granularity (or custom buckets matching your line items) up to a sensible cap.
• No bid caching. On refresh and infinite-scroll inventory, cached losing bids can fill subsequent auctions instantly.
• Auction on page load for every slot. Run lazy auctions for below-the-fold units when they approach the viewport.

Demand hygiene

• Too many client-side bidders. Each adds script weight, auction CPU and timeout pressure. Keep ~6–10 proven winners client-side; push the rest to Prebid Server.
• No per-bidder analysis. Track bid rate, win rate, timeout rate, and revenue per bidder monthly. Cut or demote chronic underperformers.
• Identical floors everywhere. Sync your dynamic floors into Prebid's floors module — don't let header demand buy under your AdX floor.

Identity and consent

• Missing ID modules. With third-party cookies effectively gone, modules like SharedID and UID2 materially lift bid rates — when configured with consent.
• Consent misfires. A misconfigured TCF integration silently drops European bid requests. Validate the consent string actually reaches bidders.

Operational discipline

• Running a year-old Prebid version. Updates carry bidder fixes and performance work; stay within a few minor versions.
• No A/B harness. Every wrapper change should ship against a control group.
• No auction-level logging. Without it you're debugging blind. A managed wrapper service is essentially these twelve disciplines, automated and watched daily.