Prebid Insights Is Live. Use It to Audit Your Wrapper

What Prebid.org launched

On April 24, 2025, Prebid.org introduced Prebid Insights, a free, publicly available dashboard built with Burt Intelligence. According to the announcement, it aggregates data from Prebid instances running across hundreds of thousands of sites and shows commonly used Prebid versions, the most downloaded bid adapters and modules, and adoption trends over time. It is embedded on the Prebid.org website and open to publishers, SSPs, developers and anyone else in the industry.

For most publishers, the dashboard's value is not the industry trivia. It is a reference point. It tells you what a typical Prebid setup looks like today, which makes it easier to see where yours differs, and whether those differences are deliberate.

Why wrappers drift

Header bidding wrappers are rarely neglected on purpose. They are set up during a launch or redesign, then left alone because they work. Over time, adapters are added for a test and never removed, modules are left on defaults, the build falls several releases behind, and nobody remembers why a particular setting was chosen. Each of these costs a little in latency, revenue or compliance. Together they can cost a lot.

A practical audit, using the dashboard as a benchmark

1. Version

Check which Prebid.js version you run and compare it with what the ecosystem is using. Newer releases bring adapter fixes, performance improvements, new consent and identity support, and security updates. Being more than a major version behind usually means missing adapter improvements your SSPs have shipped. Plan upgrades as routine maintenance, tested in staging, rather than as rare, risky projects.

2. Adapters

List every bid adapter in your build and pull 90 days of performance for each: bid rate, win rate, average response time, timeout rate and revenue. Remove adapters that rarely win and add latency. Check that adapters you do use are configured with current parameters; SSPs sometimes change required fields, and stale configs quietly reduce bids.

3. Modules

Prebid's modules do much of the work that determines revenue and compliance. Review at minimum:

• Consent management: the TCF module for Europe and the GPP module for U.S. state privacy signals, with timeouts that don't stall the auction.
• Supply chain: a correct schain configuration, especially if you work with intermediaries, so buyers can verify the path to your inventory.
• User ID: which identity providers are enabled, whether each one adds measurable revenue, and whether consent governs each.
• Price floors: whether you use the floors module or rely only on ad server rules, and whether floors are data-driven or static.
• Analytics: at least one analytics adapter, so you can see bid-level performance rather than only ad server totals.

Comparing your module list with the most common modules on the dashboard is a quick way to spot something important you are missing, or something you load that almost nobody else needs.

4. Build size and loading

Prebid lets you build a package with only the adapters and modules you need. A bloated build slows every page. Confirm your package includes only what is in use, loads asynchronously and starts the auction as early as is practical.

5. Configuration

Review timeouts by device, size mapping for responsive layouts, and how the wrapper interacts with lazy loading and refresh. Settings that made sense for last year's templates may not fit today's.

6. Client-side versus server-side

Prebid Server can move some bidders out of the browser to reduce page load. It changes cookie matching and latency characteristics, so test before migrating major partners, and measure revenue per session, not only page speed.

Red flags to look for

• Duplicate demand. The same SSP called through several paths, such as a direct adapter, a reseller and server-side, competing against itself and adding latency.
• Debug settings left on. Debug mode or verbose logging in production slows pages and can expose configuration details.
• Hard-coded floors nobody owns. Static floors set years ago that no longer reflect demand, often in both the wrapper and the ad server, contradicting each other.
• Missing sizes. Slots that accept sizes in the ad server but not in the wrapper, or the reverse, which quietly removes bidders from those auctions.
• Stale ads.txt. Adapters calling partners whose seller lines are missing or wrong in ads.txt, so buyers discard the bids.

Each of these is easy to fix once found, and each one tends to survive for months because nothing visibly breaks.

Test changes properly

Many wrapper changes have small effects that are easy to misread from before-and-after comparisons, because demand varies by day and season. Wherever possible, run changes as split tests: randomly assign users to the current and new configuration, run the test long enough to cover weekly patterns, and compare revenue per session, viewability and page performance. Prebid's configuration flexibility makes this straightforward, and it prevents good-looking changes that do not actually help.

Make it routine

A single audit fixes today's issues. A schedule prevents tomorrow's. A reasonable cadence for most publishers:

• Monthly: adapter performance review and timeout check.
• Quarterly: version upgrade and module review, including a look at Prebid Insights for ecosystem trends.
• After any redesign: full configuration review, since template changes affect slot placement, lazy loading and layout stability.

An open-source wrapper gives you control over your auction. It only pays off if someone uses that control regularly.

If your wrapper is managed by a partner, ask for a copy of your current build configuration and the reasoning behind each major setting. The answers should be quick and specific.