> For the complete documentation index, see [llms.txt](https://docs.hbwrapper.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hbwrapper.com/glossary.md). # 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 ``. **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](/key-values.md). **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](/configuration.md). **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](/rich-media.md). *** ## 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](/configuration.md). **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](/configuration.md) for every setting, or [Public API](/public-api.md) for the commands your own code can call. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.hbwrapper.com/glossary.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.