How Do I Set Up a Header Bidding Wrapper for My Website?
The Aditude Team
Setting up header bidding for the first time feels complicated. There are acronyms to decode, accounts to create, code to deploy, and an ad server to configure — and that's before you start optimizing anything.
The process is well-documented and the technology is mature, and there are two paths through it. You can build and manage the implementation yourself using open-source tools, or you can work with a managed wrapper provider who handles most of the technical work for you. Both are legitimate. Which one is right depends on your team's capacity, not your site's size.
This guide walks through both paths — what you need before you start, how the setup process works, and what to watch for once you're live.
What You'll Need Before You Start
The most common reason header bidding implementations stall is a prerequisites problem — missing an account, waiting on SSP approval, or not having site access — not a technical one.
Google Ad Manager (GAM) account. Header bidding passes its winning bid to an ad server to compete in a final auction. GAM is the standard. If you don't have one, it's free up to a certain traffic threshold. You'll need admin access to create line items and key-value targeting.
SSP relationships. Supply-side platforms are your demand partners — the buyers who will bid on your inventory. Getting approved takes time. Some SSPs have minimum traffic requirements (100k–500k monthly pageviews is a common threshold, though it varies). Apply to your target SSPs before you start the technical setup so approvals are ready when you need them.
Basic site access. For a client-side implementation, someone needs to be able to add JavaScript to the <head> of your pages. For a managed wrapper, your provider may handle deployment via a tag manager like Google Tag Manager, which lowers the technical bar considerably.
A clear list of your ad units. Sizes, placements, and whether they're above or below the fold. You'll need this to configure your wrapper and set appropriate floor prices.
A decision on implementation path. Knowing before you start which approach you're taking — self-managed Prebid.js vs. managed cloud wrapper — shapes every step that follows.
Step 1: Choose Your Implementation Path
There are two ways to implement a header bidding wrapper. The technical outcome is similar. The operational burden is not.
Self-managed Prebid.js (client-side): Prebid.js is the open-source industry standard — free, flexible, and widely supported. You download the library, configure bid adapters for each SSP, set up GAM line items, and deploy the code to your site. You also own ongoing maintenance: adapter updates, Prebid.js version upgrades, QA when something breaks. This path works well for publishers with an ad ops or engineering resource who can own the setup and keep it current.
Managed cloud wrapper: A vendor like Aditude provides the wrapper infrastructure, handles adapter management, configures your bidder mix, and deploys updates on your behalf. You get the same auction functionality with significantly less engineering overhead, typically via a tag manager snippet. This path works well for publishers who want header bidding benefits without a dedicated ad tech resource.
If you're not sure which fits your situation, start here: What Is a Cloud-Based Header Bidding Wrapper? →
The steps below follow the managed wrapper path, since it's the more accessible starting point. The underlying logic applies to self-managed setups as well.
Step 2: Configure Your Demand Partners (Bidders)
Your wrapper is only as good as the demand connected to it. This step is where you select which SSPs will bid on your inventory and configure their adapters.
Work with your wrapper provider — or Prebid's adapter directory if self-hosting — to identify which SSPs are approved to serve your content category and geography. Start with a focused set. Most publishers see yield improvements adding up to five or six strong partners, with diminishing returns above that number before latency costs start eating into the gains.
For each SSP, you'll need your publisher ID or site ID with that partner, the ad formats and sizes they're approved to serve on your site, and any floor price requirements they've specified. A managed wrapper provider will typically handle SSP account setup and integration. In a self-managed Prebid.js setup, you'll add each partner as a bidder configuration block in your Prebid config file, specifying their adapter name and account parameters.
Step 3: Define Your Ad Units
Your wrapper needs to know what inventory it's managing. For each ad unit on your site, you'll define the div ID or slot identifier that matches your page markup, accepted ad sizes (for example, 300x250, 728x90, 320x50), and a floor price for that unit — the minimum CPM below which bids are rejected.
Floor prices matter more than most publishers realize at setup. Without them, buyers in low-competition auctions will underbid because nothing forces them higher. Start conservative — don't set floors so high you kill fill rate — and optimize based on data after launch.
Step 4: Set Your Timeout
Timeout is how long your wrapper waits for bid responses before closing the auction and passing the highest received bid to GAM. It's one of the highest-leverage configuration decisions you'll make.
Set it too short and you cut off valid bids from slower-responding SSPs, leaving money on the table. Set it too long and you hurt page load times and risk Core Web Vitals degradation. The industry commonly lands in the 800–1,200ms range, but the right number depends on your bidder mix, your audience's device and connection profile, and how much latency you're willing to accept. A managed wrapper provider will typically have benchmarks from similar publishers to guide this.
For a full breakdown of how to find your optimal setting, see: What Is a Good Header Bidding Timeout? →
Step 5: Configure GAM Line Items
This is the most operationally intensive step of a self-managed setup — and one of the clearest advantages of managed wrappers.
For header bidding to work with GAM, you need to create a set of line items that correspond to bid price ranges. When your wrapper passes a winning bid to GAM, it sends it as a key-value pair (for example, hb_pb = 1.50). GAM matches that value against a line item at the $1.50 price point and allows it to compete against your direct-sold and AdX demand.
A full price granularity setup requires hundreds of line items, covering $0.01 increments from $0 to $20. Doing this manually in the GAM UI is not realistic — publishers typically use scripts to automate line item creation via the GAM API. A managed wrapper provider handles GAM trafficking setup as part of onboarding, which removes this burden entirely.
Step 6: Deploy to Staging and Test
Before going live on production, test your setup in a staging environment. Verify that the wrapper loads without JavaScript errors; that bid requests are firing to each configured SSP (check the browser console or use the Prebid Debug Chrome extension); that bids are returning from at least some partners; that the winning bid is passing correctly to GAM as a key-value pair; that ads are rendering in the correct placements; and that page load time has not degraded beyond your acceptable threshold.
For a managed wrapper, your provider will typically run QA alongside you. For a self-managed setup, the Prebid Debug tool is your primary instrument — it shows you exactly what's happening in each auction in real time.
Step 7: Go Live and Monitor the First 72 Hours
Launch on production and watch these metrics closely for the first three days.
Fill rate by ad unit: a significant drop vs. your pre-header-bidding baseline suggests a configuration problem. eCPM by SSP: check that each partner is returning bids and that the values look reasonable. Timeout rate: if a high percentage of auctions are timing out, your timeout window may be too short or a partner has a latency problem. Page load time: compare against your pre-launch baseline; any meaningful regression needs investigation before it affects Core Web Vitals.
After the first 72 hours, you should have enough data to see which SSPs are participating and contributing, which aren't, and where the early optimization opportunities are.
Common Setup Mistakes to Avoid
Skipping GAM line item QA. Misconfigured key-value targeting is one of the most common causes of header bids not competing correctly in GAM. Verify that each price bucket is set up correctly before you go live.
Starting with too many bidders. More SSPs can mean more latency and more overlapping demand paths. Start with five to eight strong partners and expand based on performance data.
Setting price floors too aggressively. Floors that are too high kill fill rate before you've established a baseline. Start lower than you think you need to, then raise them once you understand your true bid distribution.
Ignoring timeout rate after launch. A high timeout rate is a quiet revenue killer — bids that would have won are being cut off. Timeout rates above 10–15% typically mean your timeout is too short for your current bidder mix.
Not establishing a maintenance plan. Prebid.js releases updates. SSP adapters change. A setup that isn't actively maintained drifts out of date and underperforms. Know who owns this before you launch.
The Managed Alternative
If the GAM line item setup or ongoing maintenance ownership isn't something your team can absorb right now, a managed wrapper is worth a serious look.
The setup process above still applies, but the technical execution shifts to your provider. You define your ad units, approve your SSP partners, and review configuration before launch. Your provider handles the wrapper code, GAM trafficking, adapter updates, and monitoring. For publishers without a dedicated ad tech resource, this is typically the faster path to a production-ready setup — and to the revenue improvement that makes header bidding worth doing in the first place.
See how Aditude's Cloud Wrapper → and Prebid Server → solutions handle the setup process on your behalf.
Get your header bidding wrapper configured by Aditude →
