📖Glossary
New to header bidding, or coming from the business side rather than engineering? Start here. This page explains the terms used throughout the documentation in plain language. Each entry says what the thing is and why it matters, without assuming you write code.
If you only read one page before the rest, read this one.
The big picture
Header bidding A way of selling ad space on a website. Instead of asking one ad seller at a time, the page asks many ad buyers to bid at the same time, then sends the best price to the ad server. More competition usually means more revenue for the publisher. It's called "header" bidding because the code historically ran early in the page's HTML <head>.
Wrapper The software this documentation is about. It's a single script that a website loads once. The wrapper runs the whole header bidding process for you: it collects bids, runs the competition, talks to the ad server, and shows the winning ad. Think of it as the conductor of an orchestra — it coordinates all the other pieces so you don't have to wire them together by hand on every site.
Prebid.js The open-source, industry-standard library that actually runs the bidding. The wrapper is built on top of Prebid.js and adds automation, scale (thousands of sites from one place), extra features, and management of the Google ad server. When the docs mention a "Prebid" setting, it's a setting that comes from this underlying library.
Publisher The owner of the website that shows the ads and earns the revenue. If you manage sites, you're the publisher (or you work for one).
The ad-serving pieces
GAM (Google Ad Manager) Google's ad server — the system that ultimately decides which ad to show in each slot and records what was delivered. The wrapper talks to GAM for you, so you don't have to add Google's ad code to the page yourself.
DFP The old name for Google Ad Manager (it used to be called "DoubleClick for Publishers"). You'll still see dfp used as the name of several settings in the configuration files — for example dfp.collapseEmptyDivs. Whenever you see dfp in a setting name, read it as "Google Ad Manager." The name stuck around for backwards compatibility even though the product was renamed.
Ad unit A single ad placement — one spot on the page where an ad can appear (e.g. the leaderboard at the top, or the box in the sidebar). Each ad unit is set up in GAM and connected to a spot on the page.
Ad unit code / path The full identifier of an ad unit in GAM, written like a folder path, e.g. /22181265/Homepage/Leaderboard. Important: always use the ad unit CODE (the path), not the friendly display NAME you see in the GAM interface — they are not the same, and mixing them up is a common cause of ads not showing.
Slot Another word for the on-page container where a specific ad is rendered. Loosely interchangeable with "ad unit" in everyday use.
How an ad gets chosen
Auction The competition among ad buyers for a single ad slot, run by the wrapper before it asks GAM for an ad. All buyers bid in parallel, and the highest useful bid is passed along. Faster and fairer than asking buyers one at a time.
Bidder / SSP / demand partner / network A company that bids to buy the ad space (e.g. Rubicon, PubMatic, AppNexus). These terms are used loosely to mean "a source of ad demand." You configure which bidders compete for each ad unit.
Bid An offer from a bidder — a price they'll pay to show their ad in the slot.
CPM "Cost per mille" — the price for one thousand ad impressions. Ad prices are quoted this way. A $2.00 CPM means the buyer pays $2.00 for every 1,000 times the ad is shown. Most bid and floor settings are expressed as CPMs.
Floor / price floor The minimum price you'll accept for an ad. Bids below the floor are ignored. Floors help protect the value of your inventory.
Client-side vs. server-side (S2S) Two places the auction can happen. Client-side means the bidding runs in the visitor's browser. Server-side (also written S2S, "server-to-server") means some of the bidding is handed off to a server, which is faster for the browser and can include more bidders without slowing the page. This wrapper supports a hybrid approach — using both at once.
Amazon / A9 / UAM Amazon's separate ad-demand system, which runs alongside Prebid. The wrapper can include it in the competition; it's configured on its own because it works a bit differently from other bidders.
What the wrapper tracks and sends
Key-value (targeting key-value) A small labelled piece of information the wrapper attaches to each ad request so GAM can make decisions and you can report on them. For example, "the winning bidder was pubmatic" or "this visitor is on mobile." The wrapper sends many of these automatically. The full list is in Key-Values.
Impression One instance of an ad being shown to a visitor.
OpenRTB impression fields (ortb2Imp) Structured data attached to each ad slot in the bid request so buyers know which placement it is and whether HTTPS creatives are required. The wrapper sets these automatically: secure (1, HTTPS creatives required; a publisher-set value including 0 is honored), GPID, GAM adslot, and an interstitial flag (instl) when the placement is an interstitial.
GPID (Global Placement ID) A unique identifier for a specific slot on the page, sent as ortb2Imp.ext.gpid. When the same GAM path is used more than once (feeds, infinite scroll), the wrapper adds a # suffix so buyers can tell the slots apart.
Viewable / viewability Whether an ad was actually seen. The industry standard (and what the wrapper measures) is that at least 50% of the ad was on screen for at least 1 continuous second. Viewability drives some refresh behaviour and reporting.
Refresh Automatically requesting a new ad for a slot after some time or after it's been viewed, so the same visitor can generate more than one impression from the same spot. The wrapper gives you fine control over when and how often this happens.
Lazy loading Waiting to request an ad until the visitor is about to scroll it into view, instead of loading every ad up front. This speeds up the page and improves viewability, because ads aren't requested for spots the visitor never reaches.
Privacy, safety, and quality
GDPR / CCPA / consent Privacy regulations (Europe and California, respectively) that govern how visitor data can be used for advertising. The wrapper handles the required consent signals so bidders receive the right permissions.
SafeFrame A protective wrapper GAM can put around an ad so the ad can't interfere with the rest of your page. It's safer but limits what some bidders can do, which can reduce revenue. This wrapper offers a unique "flexible" mode that turns SafeFrames on only for specific impressions rather than all of them — see dfp.flexibleSafeFramesSignal in Configuration.
Bot / invalid traffic (IVT) Automated visitors that aren't real people. Showing ads to bots wastes money and can get you penalised, so the wrapper can detect and block them.
Rich media format A special, more interactive ad presentation — for example an ad that sticks to the bottom of the screen (adhesion), stays in place as you scroll (sticky), or covers the page (interstitial). See Rich Media Formats.
Delivery and configuration
CDN (Content Delivery Network) A globally distributed network of servers that delivers the wrapper script quickly to visitors anywhere. The wrapper is served from a CDN tuned for ad-tech so it loads fast and updates cleanly.
JSON config The settings files that control the wrapper. "JSON" is just a structured text format for settings — a series of names and values inside braces { }. You don't program the wrapper; you configure it by editing these files. The main ones are config.json (site-wide settings), adunits.json (per-placement settings), deviceDetection.json (screen-size rules), and modules.json (which bidders are included). All are documented in Configuration.
Build / CI/CD The automated process that turns your JSON settings into the finished script on the CDN. Every time you change a config, a fresh, versioned copy is built and deployed automatically. You don't run this by hand.
globalVar / pbjs The name of the wrapper's control object in the browser — the handle your custom code uses to talk to the wrapper (for example to refresh ads). Each site sets its own name via the globalVar setting; the examples in these docs use pbjs. Wherever you see pbjs in a code example, substitute your site's actual value if it's different.
Command queue (pbjs.cmd) A safe "to-do list" for the wrapper. Because the wrapper loads asynchronously, you don't call it directly — you push your instructions onto pbjs.cmd and the wrapper runs them as soon as it's ready. This is why the code examples wrap instructions in pbjs.cmd.push(function () { ... }).
Device detection How the wrapper decides whether a visitor is on desktop, tablet, or mobile — based on screen or window width. You define the size breakpoints in deviceDetection.json, and can add your own labels (for example a bigDesktop tier) beyond the default three.
Ready for detail? Continue to Configuration for every setting, or Public API for the commands your own code can call.
Last updated