A complete header bidding platform, operated under your name. Your tenant goes live in one to two days — build pipeline, your own CDN, your own analytics store, your own management UI — and from there you add as many sites as you want. Over a billion pageviews last month, and a new release reaches production every week.
Your implementation on the page
<script src="//your-cdn-domain.com/site.js"></script>
Nothing on that page says HB Wrapper. Your domain, your global, your cookie names.
All publishers combined, updated daily
Building one takes a quarter. Keeping one takes an engineer who tracks every Prebid release, an ad ops person who knows why a slot went blank, somewhere to store enough data to answer “which sites lost fill last Tuesday”, and someone reachable when a bidder ships a bad adapter. That team does not get smaller as you add sites.
HB Wrapper is that platform and that person, running under your name. You keep the publishers, the demand relationships and the brand. Staying current is our job, every week.
You decide what each site should do and write it down as configuration. Everything after that — compiling it, shipping it, loading it, running the auction, rendering the ad and counting what happened — is ours, and none of it lands on your team.
You are choosing between building this yourself, licensing it, and paying someone a share of what clears. We do not win every row, so here is the whole table — including the one where building beats us.
| Build it | HB Wrapper | Revenue-share vendor | |
|---|---|---|---|
| What you spend | Engineering time, continuously | A fee per pageview | A share of what clears |
| Time to your first site | Quarters | Days | Weeks |
| Who tracks Prebid releases | You, forever | Us, every week | Them, on their schedule |
| Who owns the configuration | You | You | Usually them |
| Who your publishers see | You | You | Often them |
| Where it wins | Absolute control of the roadmap — and past a certain volume, paying per pageview stops making sense | You get the platform and keep the publisher relationship | Nothing to run, and no engineering at all |
The Prebid in your build comes from the official repository and is merged weekly. Our own work sits in separate modules around it, plus a small marked set of changes inside Prebid core. That is why a major version lands in weeks instead of quarters — and why you are on 11 rather than reading about it.
A new tenant is live in one to two days — pipeline, CDN, analytics store, management UI. After that, adding a site takes minutes: a few new configuration files, written by your team or by a language model, and that site’s wrapper is built and live. A tenant is a separate wrapper and not a config flag, so a mistake stops at one site instead of a platform. “Isolated” is easy to claim and hard to check, so here is the boundary, drawn where it actually falls.
And it isn't a black box. Standard setups are JSON, and anyone on your team with a technical feel for the stack can change them — the schema is documented, and a language model reads it as easily as a person does. That is the whole reason one person can carry hundreds of sites.
Traffic quality, monitoring, page-health analytics and the debugging tools usually arrive as three more contracts with three more vendors, each adding its own tag to the page. Here they are part of the wrapper, writing into the same store and read off the same screens.
| Part of the wrapper | Where this usually comes from |
|---|---|
| Invalid traffic scored 0 to 100 before the auction, with the threshold yours to set | An invalid-traffic vendor, priced per impression, with its own tag on the page |
| Uptime and delivery monitors, incidents and alerting to your own channels | A monitoring product — or nothing, and you hear about it from a publisher |
| Analytics that show what rendered, what didn’t, and why, per site and per day | A yield-analytics platform, priced per impression |
| Core Web Vitals per site, through the same beacon as everything else | A separate speed-monitoring tool, or a Lighthouse run somebody does by hand |
| An auction console openable on any live URL, by anyone you give the parameter to | A browser extension, plus a HAR file and a support ticket |
| Your own analytics store, one per tenant, roughly three years of history | Your own warehouse, and somebody to build the pipeline into it |
Every line on the right is a contract, a tag on the page, and a second place to look when something is wrong. That is the real cost of buying them separately, and it isn’t the invoice.
The deeper work — custom formats, unusual refresh rules, an edge case nobody has hit yet — is JavaScript, and it is yours to write. Custom scripts run inside the wrapper's own lifecycle, with no sandbox around what you are allowed to want.
Change which bidders are in play, which sizes are requested, what a placement looks like — conditionally, at runtime, per site.
Insert elements into the page, fire a third-party tag, fix something in the DOM. The script does not have to be about advertising at all.
Write your own Prebid analytics or RTD modules — including ones not yet in the upstream repository — and run them in your build.
A parallel hybrid auction: client-side Prebid bidders, multiple Prebid Servers and additional ORTB endpoints all open together rather than queueing behind one another, settled against a bid cache that survives the page and follows the session. More lanes open for the same slot is more demand competing for it — and no lane pays for another lane's latency.
We run the auction. We take no share of what clears through it, and there is no HB Wrapper demand in it competing with your partners.
You bring the demand. Because we take nothing out of the auction, there is no optimization that pays us and costs you — every change we ship is an engineering decision, not a commercial one.
The commercial model is usage-based and priced per pageview — not a percentage of your revenue, and not a per-seat licence.
Every wrapper has a happy path. What separates one that has been in production for years is what it does on the other three.
Traffic Integrity Score (TIS) is our proprietary scoring algorithm, built into the wrapper. Every request is scored from 0 to 100 for how likely it is not to be a real reader. Low is clean and monetizable. High is almost certainly invalid, and gets excluded before it reaches an auction — which is what protects your supply’s reputation with the demand partners you and your publishers depend on.
Everything below is a capability, not an argument. It is here so an evaluation can check it off, and each one has a configuration reference behind it.
Standard Prebid gives you a floor and a timeout. Most of the money is in what happens either side of them.
Price floors with geo, userId and ORTB2 schema extensions — not only standard Prebid floor rules.
Pubshare, server-side adjustments and per-network multipliers, for the cases a flat discount gets wrong.
Auction timing varies by device or geo, so slow paths do not hold up fast ones.
Bidders and UserID modules switched on and off per region, without a separate build.
FPD support with automatic enrichment passed into the auction.
Automatic GAM targeting: bidder, CPM, size, format, device, connection speed, viewability, refresh state and more.
Sizes configured for GAM only, header bidding only, or both on the same placement.
Global, per-ad-unit, or forced when CPM is under a floor. Impression-level from CPM, advertiser domain, IAB category or ad unit — revenue stays open where SafeFrames are not needed, sensitive inventory gets surgical protection.
A documented interface so your own code can change wrapper behaviour at runtime, from the page.
A timer alone burns impressions on slots nobody is looking at. Refresh here is driven by what the reader is actually doing, every trigger is a per-slot setting, and everything stays configurable at your fingertips.
Your settings are plain files in a git repository that belongs to you. Your team edits them. A language model can edit them. You grant access to whoever should have it and take it away when they leave. And because it is git, the history is permanent: three years from now you can still see exactly who changed that floor, when, and what it was before.
No ticket queue between you and a change you understand.
When a slot misbehaves, the answer is in the auction that just happened — not in a support queue and not in a HAR file you email to someone.
| Capability | What it covers | Configured in |
|---|---|---|
| Lazy load | Slots defined and requested as they approach the viewport, with per-slot distance thresholds | site config |
| Analytics | Pageviews, fill and fallback rates by branch, TIS distribution, abnormality flags | dashboard + API |
| A/B rollout | Every release runs at 10% before full deploy; the cohort is stable per user | release train |
| Rich media | Pluggable creative formats, per-unit CSS, own viewability tracking where you would rather not use GAM's | module + CSS |
Every claim on this page has a configuration reference behind it. The docs are public and complete — read them before you talk to anyone, including us.
When you want to see it running on your own inventory, write to contact@hbwrapper.com.