Attaching header bidding to ad slots you already have

Plenty of publishers have years of GPT code embedded in their CMS templates, their AMP pages and their app webviews. Being told that adopting header bidding means rewriting all of it is often what kills the project.

It does not. There are two integration models, and the choice between them is about ownership, not capability.

Model A — the wrapper owns the slots

You remove your defineSlot calls and let the platform define, size, target and refresh everything. You get central control: sizes, lazy loading, refresh and collapse behaviour are all managed from one place, and changing them does not require a deploy.

The cost is that your ad rendering now lives outside your codebase.

Model B — you own the slots, header bidding attaches

Your page keeps defining its own slots. The wrapper reads them, matches each to a configured ad unit, and contributes bids. In ssm.codes this is the dfp_hb ad unit type.

You keep your existing code and your existing deployment process. What you give up is central control of the things you did not hand over — if a slot's sizes are wrong, that is a template fix, not a dashboard change.

Matching units to slots

The mapping needs a stable key. In order of reliability: the ad unit path as passed to defineSlot, the div id the slot renders into, or the GPT slot element id. Paths are the most robust because they rarely change; div ids are convenient but tend to get regenerated by CMS templates, which breaks the mapping silently.

// Your existing code — unchanged.
googletag.cmd.push(function () {
  googletag.defineSlot('/1234567/homepage_top', [[970,250],[728,90]], 'div-top')
           .addService(googletag.pubads());
  googletag.enableServices();
});

// Configured in the dashboard as a dfp_hb unit:
//   path  = /1234567/homepage_top
//   sizes = 970x250, 728x90   (must match the slot)
//   div   = div-top

The one thing you must get right

The ad request still has to wait for the auction. If your page calls googletag.pubads().refresh() or relies on enableSingleRequest() firing immediately on load, the request goes out before any bid arrives and header bidding contributes nothing.

So one line does change: the moment the ad request fires. Either hand that trigger to the wrapper, or gate your own refresh on the auction completing. Everything else — slot definitions, sizes, targeting, your own key-values — stays untouched.

Sizes have to agree

If the slot accepts 728×90 and the ad unit is configured for 300×250, you will get bids that cannot render. The impression is logged, no creative appears, and your discrepancy grows. Audit this first whenever a dfp_hb unit underperforms.

Related questions