Prebid & Header Bidding Infrastructure.
The open-source publisher execution layer: Prebid.js, Prebid Server, Prebid Mobile, SharedID, first-party data, consent modules, identity, floors, analytics — and what a configurable auction wrapper means when agents run the sell side.
This is a deep dive inside the six-layer standards system, not a seventh pillar. Prebid is not a standards body and not a protocol: per its own documentation it is a product suite, a community, and an independent organization — free and fully open source. What earns it a place in a standards system is what it does to standards: OpenRTB conventions, consent frameworks, identity formats, and transparency declarations stop being documents here and start being configuration. This page maps what Prebid is, what it is not, and where a publisher’s actual choices live.
Prebid is not a protocol standard. It is the open-source publisher execution layer where many standards become operational.
Fast read
- What it is
- A deep-dive guide to Prebid — the open-source publisher execution layer for header bidding — and to the configuration surfaces that decide which standards, signals, and partners actually operate in a publisher’s auction.
- What it covers
- Prebid.js, Prebid Server, Prebid Mobile, SharedID, modules and adapters, ortb2 first-party data and segtax, consent modules and Activity Controls, identity, price floors, analytics, and agentic seller-side execution.
- What it is not
- Not a seventh standards pillar — a deep dive inside the six-layer system. And not a protocol standard: per its own docs, Prebid is a product suite, a community, and an independent organization — not an IAB body, an SSP, a DSP, an ad server, a compliance guarantee, or a measurement standard.
- Why it matters
- Header bidding is where publisher strategy becomes executable. Every standard the buy side negotiates — OpenRTB conventions, consent strings, identity, floors — either operates inside this wrapper or never reaches the auction.
- Best for
- Publisher, AdTech, agency, media, data, identity, and analytics leaders building or evaluating sell-side execution and agentic publisher workflows.
- Best next read
- Core AdTech Standards, Privacy & Consent Standards, and the Publisher Platform / SSP / Curation ecosystem surface.
Where Prebid fits.
The six-layer standards system covers the transaction rails, the permission rules, and the trust layer. Prebid is none of those layers — and it touches all of them, because it is where a publisher turns them on. OpenRTB conventions become ortb2 configuration; TCF and GPP strings become module settings and activity rules; identity formats become enabled submodules; floors and analytics become auction policy. A standard a publisher never wires into the wrapper is, for that publisher’s open-auction revenue, theoretical.
The relationship
Prebid operationalizes standards. It does not replace them.
What Prebid is.
Prebid’s own documentation defines it as three things at once — “a product suite, a community, and an independent organization” — that are “free and fully open source, available to any publisher.” Take the self-description seriously: each of the three parts carries a different operating consequence for the publisher who adopts it.
- 01
A product suite
Per its own documentation, Prebid is first a product suite: Prebid.js in the browser, Prebid Server for server-to-server, Prebid Mobile for iOS and Android, SharedID as a first-party identifier — plus managed services offered by member companies for publishers who outsource the operating work.
- 02
A community
Public GitHub repositories open to members and non-members alike, with what the official docs call the largest repository of working header bidding adapters. The codebase is the meeting point: bidders, vendors, and publishers all ship modules into the same project.
- 03
An independent organization
Prebid.org describes itself as “a collection of leading ad tech companies that oversees & funds the development.” Governance runs through Project Management Committees that establish and prioritize the roadmap; PMC participation is members-only, and the Technology and Publisher PMCs each seat one voted board representative yearly.
- 04
Free and fully open source
The code is released under the Apache License, and Prebid states that all its technology remains available at no charge to all companies regardless of membership. Membership funds development and buys a seat at the governance table — not access to the software.
- 05
An adapter ecosystem
Prebid’s docs describe support for “more than 300 demand partners” client-side, with 230+ server-side adapters listed on the Prebid Server overview as of June 2026 — both figures attributed to Prebid’s own pages, and both moving targets. Modules are add-on code outside the core: bid adapters, analytics adapters, user ID modules, consent modules, floors.
Why it matters
Prebid is where publisher strategy becomes executable.
What Prebid is not.
Most confusion about Prebid comes from assigning it a role it does not hold. Six misreadings are worth retiring explicitly — and none of them is a criticism. Prebid is more useful precisely because it does not pretend to be these things.
- 01
Not a standards body
Prebid writes none of the standards it runs on. OpenRTB, TCF, GPP, and VAST are governed elsewhere — Prebid consumes them and turns them into working configuration. Its own conventions are open-source project conventions, not industry standards output.
- 02
Not an SSP
An SSP is a business with demand relationships and a balance sheet. Prebid is software the publisher runs — and many SSPs appear inside it as bid adapters. The wrapper arbitrates; it does not represent inventory commercially.
- 03
Not a DSP
Prebid buys nothing. It solicits bids, applies publisher policy — floors, timeouts, permissions — and surfaces the results. The buying decision happens in the systems behind the adapters.
- 04
Not an ad server
In most integrations the winning Prebid bid is handed to the publisher’s ad server for the final decision against direct campaigns and other demand. Prebid Mobile documents a No Ad Server direct-render path, but as one option among four — the wrapper does not replace the decision engine.
- 05
Not a compliance guarantee
Prebid’s own privacy resources carry the disclaimer that nothing there should be construed as legal advice and that Prebid.org “makes no guarantees about compliance with any law or regulation.” Consent modules are plumbing for a privacy program — never the program itself.
- 06
Not a measurement standard
Analytics adapters report auction mechanics — bids, timeouts, win rates. Measurement and verification standards (OM SDK, OMID, accreditation) live in the trust layer, beside the auction, and the wrapper replaces none of them.
The Prebid product suite.
Five names carry the weight: a browser library, a server, a mobile SDK, a first-party identifier, and the module model that extends all of them. Version specifics on this page are deliberately coarse — the release train moves roughly weekly, so cite lines, not versions, and validate before building.
- The core product
Prebid.js
A JavaScript library that runs in the browser — the core product of the suite, launched 2015. It reduces latency by concurrently calling the selected bidders within a set timeout, and ships as a customized bundle: publishers compile in exactly the bid adapters and modules they want. The current major line is 11.x as of June 2026, with minor releases shipping roughly weekly — cite the line, never a minor version, and validate before building.
- Server-to-server
Prebid Server
An open-source solution for server-to-server header bidding, with two official implementations — Go and Java, separately versioned and documented — handling request validation, currency conversion, and bid caching, with 230+ server-side adapters listed as of June 2026. The official use cases: “mobile app, AMP, server-side web with Prebid.js, and server-side ad inclusion scenarios such as CTV, Digital Out of Home and audio.”
- In-app
Prebid Mobile
An open-source SDK for iOS and Android providing end-to-end in-app header bidding — and it requires a Prebid Server: the auction runs server-side, not on-device. It supports display, video, and native, with four documented integration methods: No Ad Server (direct render), GAM Bidding-Only, GAM Prebid-Rendered, and mediation via AdMob or AppLovin MAX. Current SDK line: 3.0 as of June 2026.
- First-party identity
SharedID
Per current official docs, “a convenient Prebid-owned first party identifier within the Prebid UserId Module framework” — a random UUID stored in a first-party cookie on the publisher’s domain, no registration required. PubCommon ID was merged into SharedID at Prebid.js 5.0, and since 5.0 it makes no external sync calls. Default lifetime is 365 days (effectively about 7 in Safari under ITP), and creation and reads are suppressed without TCF Purpose 1 consent.
- The extension model
Modules & adapters
Modules are add-on code outside the core: bid adapters, analytics adapters, user ID submodules, consent modules, the floors framework. They are compiled into the bundle at build time — which makes the build itself the first governance decision. A module left out of the build cannot run, no matter what the page config says.
Prebid and the standards stack.
The working matrix: which standards Prebid touches, who actually governs each one, what the wrapper does with it — and, just as important, what it deliberately does not do.
| Standard / framework | Governed by | How Prebid operationalizes it | What Prebid does not do |
|---|---|---|---|
| OpenRTB / ORTB2 | IAB Tech Lab | Adopts OpenRTB-shaped ortb2 conventions for first-party data and request fields; Prebid Server transacts server-to-server | Define the protocol — Prebid consumes it |
| TCF + GPP | IAB Europe / IAB Tech Lab | Consent modules fetch CMP strings and pass them to adapters (gppConsent, ortb2.regs gpp / gpp_sid), and translate them into Activity Control rules | Act as a CMP, or guarantee compliance with any regulation |
| VAST | IAB Tech Lab | Auctions video demand through video ad units; the winning creative is still served and rendered per VAST | Serve or render the video — players and ad servers do that |
| OM SDK / OMID | IAB Tech Lab | Nothing directly — measurement and verification run beside the auction, on their own standards, where integrated | Replace measurement standards — Prebid is not one |
| ads.txt | IAB Tech Lab | Prebid demand partners are the kind of authorized sellers the publisher’s file declares | Validate or enforce the file — that happens buy-side |
| sellers.json / SupplyChain | IAB Tech Lab | Requests can carry supply-chain data per OpenRTB conventions where configured — validate current module documentation | Audit the chain — transparency is declared here, checked elsewhere |
| Privacy Sandbox (PAAPI) | Google (Chrome) | Supported via modules through the 10.x line; Prebid.js 11.0 (March 2026) states “PAAPI is no longer supported” and removed the modules | State a reason — the release notes give none. Chrome separately announced retiring its Privacy Sandbox ad APIs in October 2025; validate current status |
The publisher control layer.
The strategic value of Prebid is not the auction mechanics — it is that the auction’s policy surface belongs to the publisher. Eight control surfaces decide what the wrapper may do, and every one of them is configuration the publisher can version, test, and audit.
- 01
Build composition
Which modules exist at all is decided when the bundle is built. Every adapter and module compiled in is a capability granted; every one left out is a policy. Treat the build manifest as the top of the governance stack.
- 02
Bidders and timeouts
The wrapper concurrently calls the selected bidders within a set timeout. Who is invited, and how long the auction waits, are pure publisher configuration — and both are levers with measurable revenue and latency consequences.
- 03
Price floors
The floors module sets the lowest CPM a bid must meet per auction — configured at the ad-unit level, the package level via setConfig, or fetched dynamically from a floor provider. Official docs discourage static floors.
- 04
First-party data permissions
Global ortb2 data goes to all bidders; setBidderConfig() restricts supplied data so only named bidders receive it. Different bidders can receive different datasets — permissioning is built in, if the publisher uses it.
- 05
Identity configuration
The User ID module framework: which ID submodules run, how each is stored and refreshed, a per-submodule bidders array controlling which bidder codes may receive each ID, and idPriority to resolve conflicts. IDs surface to adapters in ORTB EID format.
- 06
Consent and Activity Controls
TCF and GPP consent modules fetch CMP strings; Activity Controls (allowActivities) gate twelve named activities, including transmitUfpd and transmitEids. Consent modules write rules; publisher rules at priority one can override; deny beats allow at equal priority.
- 07
Analytics selection
Analytics adapters are build-time modules enabled via enableAnalytics(), hooking into the Prebid.js event system. The publisher decides who observes the auction — and what telemetry exists to govern with.
- 08
Ad server handoff
How winning bids reach the final decision: passed to the publisher’s ad server in most integrations, or — in Prebid Mobile — one of four documented integration paths, including direct rendering without an ad server. The handoff design is a publisher choice, not a default.
First-party data and signal governance.
Prebid’s first-party data feature follows OpenRTB conventions through the ortb2 object: ortb2.site for context, ortb2.user for user data and segments, IAB taxonomy segments carrying segtax identifiers, custom attributes under ext.data, and ad-unit-level data via ortb2Imp.ext.data. Two governance rails sit on top: setBidderConfig() restricts supplied data so only named bidders receive it — different bidders can receive different datasets — and, since Prebid 7, first-party data can also be passed per-auction to requestBids() for contexts like infinite scroll. The same OpenRTB-shaped conventions are what server-side paths consume, where supported — validate current Prebid Server documentation for the specifics. What the plumbing does not do is decide whether a signal should travel at all. That is the governance work, and it has a checklist.
- 01 — Inventory every ortb2 field you populate — site, user, content — and the source system behind each one.
- 02 — Declare taxonomies explicitly: segments without a segtax identifier are noise to the buy side.
- 03 — Separate contextual data (site, content) from user-level data — the consent obligations differ, and Prebid’s own docs note user FPD may require special consent in certain regions.
- 04 — Default-deny user data: decide which bidders receive ortb2.user at all, and grant access via setBidderConfig — not by habit.
- 05 — Scope ad-unit data with ortb2Imp.ext.data instead of globalizing everything.
- 06 — Gate transmission with Activity Controls: transmitUfpd and transmitEids are publisher decisions, not defaults.
- 07 — Map every signal to a legal basis before it ships — the module passes data; it does not justify it.
- 08 — Version the wrapper config and review first-party-data changes like code — because they are code.
- 09 — Measure signal value: use analytics to test whether a permitted signal actually moves bids before widening access to it.
- 10 — Re-validate on a cycle: modules, activities, and conventions move with a roughly weekly release train.
The test
A signal is only valuable if it is permitted, understood, measurable, and controlled.
Client-side vs server-side.
Prebid.js runs the auction in the browser; Prebid Server runs it in a server the publisher or a vendor operates. Neither is the upgrade of the other — they trade visibility for weight and reach, and the official use-case lists make the division of labor explicit.
| Dimension | Client-side — Prebid.js | Server-side — Prebid Server |
|---|---|---|
| Where the auction work runs | In the browser, on the page — Prebid.js is a JavaScript library the page loads | In a server the publisher or a vendor operates — Go and Java implementations |
| Page weight and latency profile | Adapter code ships in the page bundle; bidders are called concurrently within the page timeout | One request leaves the device; adapter fan-out happens server-side |
| Signals and identity access | Direct access to browser state and the User ID modules running on the page | Client signals must be forwarded to the server — what arrives is implementation-sensitive |
| Transparency and debugging | The auction is observable in the browser’s developer tools | Visibility lives in server logs and analytics — design it in deliberately |
| Adapter coverage | “More than 300 demand partners” per Prebid’s own docs | 230+ server-side adapters per the Prebid Server overview, as listed June 2026 |
| Where each fits | Web display — the on-page unified auction | Per official docs: mobile app, AMP, server-side web with Prebid.js, and server-side ad inclusion scenarios such as CTV, Digital Out of Home and audio |
The trade
Client-side maximizes observable browser context and debuggability; server-side moves work off the page and reaches environments the browser never sees. Treat the split as an architecture decision, implementation-sensitive — not a default.
Privacy, consent, and identity.
Prebid ships substantial privacy tooling — and frames it carefully. Its own privacy resources state the tools support user privacy while making “no guarantees about compliance with any law or regulation.” Here is where each module actually stands per current documentation, and what remains a publisher decision no module can make.
- Active — GDPR
TCF consent module
The consentManagementTcf module fetches TCF v2.x consent strings from CMPs implementing the IAB framework and makes them available to adapters during the auction, with cmpApi, timeout, and defaultGdprScope configuration. An optional TCF control module enforces consent-based activity restrictions on top.
- Active — multi-regime
GPP consent module
The GPP module works with CMPs implementing the IAB GPP framework (GPP 1.0, with 1.1 support added around Prebid.js 8.6 in July 2023); adapters read consent via gppConsent and the OpenRTB 2.6 ortb2.regs gpp and gpp_sid fields. Per the docs it supplements other consent modules — it does not replace them.
- No longer recommended
US Privacy (USP) module
The CCPA/US Privacy module carries an official notice: it is “no longer recommended, as the signal is no longer supported by a contractual framework as of January 31, 2024.” The module still exists in the repo and docs — deprecated in recommendation, not removed. GPP is the active US-privacy path.
- Framework
User ID modules and SharedID
The User ID module is a framework for pseudonymous ID submodules — a long, frequently changing list — configured with storage type, lifetime, refresh, and a per-submodule bidders array restricting which bidder codes may receive each ID. IDs surface as ORTB EIDs. SharedID is the Prebid-owned, first-party entry in that framework. With the TCF module and no Purpose 1 consent, no external ID calls are made and nothing is stored.
- The enforcement rail
Activity Controls
Introduced in Prebid.js 7.52, allowActivities gates twelve named activities — among them fetchBids, syncUser, enrichEids, transmitEids, transmitUfpd, transmitPreciseGeo, and reportAnalytics. Rules carry priorities (publisher config defaults to one, modules to ten; lower wins; deny beats allow at equal priority), and consent modules translate regulatory strings into these rules.
- Removed in 11.0
PAAPI module status
Prebid.js 11.0 (released March 2026) states “PAAPI is no longer supported” and removed the paapi, paapiForGpt, and topLevelPaapi modules; the release notes give no reason. Chrome had separately announced retiring its Privacy Sandbox ad APIs in October 2025. Note the docs page for the module was still live without a deprecation banner as of June 2026 — it documents the 10.x line. Validate current status.
| Topic | Prebid’s role | The publisher decision |
|---|---|---|
| GDPR / TCF | Fetches TCF v2.x strings from the CMP and passes them to adapters; optional control module enforces activities | Choose the CMP, the legal bases, and the enforcement posture — the module is plumbing, not policy |
| GPP | Passes GPP strings and section IDs (gpp / gpp_sid) to adapters; supplements other consent modules | Decide which regimes apply and how their strings translate into activity rules |
| US Privacy (USP) | Legacy module, officially no longer recommended since the framework sunset of January 31, 2024 | Migrate US-privacy handling to GPP-based signals; build nothing new on USP |
| User identity (EIDs) | Runs configured ID submodules and exposes IDs to permitted bidders in ORTB EID format | Which IDs to enable, with what storage and lifetime — and which bidders may receive each one |
| SharedID | Generates a Prebid-owned first-party UUID; no external sync calls since 5.0; consent-gated | Whether a first-party identifier fits the privacy posture, and how it is disclosed |
| Activity Controls | Central allowActivities config gating twelve activities, with consent modules writing rules | Define the default-deny posture and its exceptions — this is where policy becomes config |
The warning
Do not treat an enabled privacy module as a compliance program. It is a technical support layer.
Beyond web display.
Prebid Server’s official use-case list is the honest map of where the project reaches past the browser: “mobile app, AMP, server-side web with Prebid.js, and server-side ad inclusion scenarios such as CTV, Digital Out of Home and audio.” In each channel, Prebid contributes the auction layer — the channel’s own standards still govern delivery, measurement, and proof.
- In-app
Mobile
Prebid Mobile pairs the iOS/Android SDK with a mandatory Prebid Server — the auction runs server-side. Four documented integration methods cover GAM and mediation via AdMob or AppLovin MAX. The browser’s context never existed here: signal availability is a design problem, not an assumption.
- Players render
Video
Prebid auctions video demand; VAST still does the serving and the player still does the rendering. One moving part to track: long-form adpod support was removed in Prebid.js 11.0 — validate current documentation before planning around legacy video workflows.
- Server-side insertion
CTV
CTV appears on Prebid Server’s official use-case list under “server-side ad inclusion scenarios.” The execution realities — SSAI, constrained runtimes, partial measurement coverage — are the Video & Mobile deep dive’s territory; the auction layer is what Prebid Server contributes.
- Named use case
DOOH
Digital Out of Home is named in Prebid Server’s official use-case list. The channel’s physics — venue context, modeled multipliers, proof-of-play — live in OpenRTB 2.6 and the DOOH deep dive; Prebid Server is one execution path onto those rails, where supported.
- Named use case
Audio
Audio closes Prebid Server’s official use-case list. Delivery and measurement run on the audio stack’s own standards — VAST’s audio support and the podcast measurement guidelines — covered in the Audio & Podcast deep dive. The wrapper supplies the auction, not the proof.
Floors, analytics, and optimization.
Two module families form the wrapper’s yield machinery: the Price Floors Module decides what a bid must clear, and analytics adapters decide what anyone can see. Together they are the optimization loop — and the place where careless automation does the quietest damage.
- The framework
The Price Floors Module
An open-source framework for publishers to configure price floors on their own or with a floor vendor. A floor is the lowest CPM a bid must meet for each Prebid auction — a standing filter on every transaction the wrapper runs.
- Three config locations
Ad unit, setConfig, provider
Floors configure in three places: at the ad-unit level, at the package level via setConfig, or fetched dynamically from a floor provider’s endpoint at auction time. The further right you move, the fresher the floor — and the more you depend on the provider’s model.
- Two schemas
Schema 1 vs schema 2
Schema 1 carries one floor data group. Schema 2 lets floor providers A/B-test floor groups at auction time through weighted model sampling — experimentation built into the floor data itself. Rule dimensions include gptSlot, adUnitCode, mediaType, size, and domain.
- The official stance
Static floors, discouraged
Prebid’s docs explicitly discourage static floors, describing them as blunt tools that go stale. Supported, yes — recommended, no. If a floor strategy cannot adapt, the official guidance is that it will quietly underperform.
- The telemetry
Analytics adapters
Vendor-specific modules compiled into the bundle at build time, enabled at runtime via enableAnalytics() with a provider name and options, hooking into the Prebid.js event system. Without them, the auction is a black box — including to the team that configured it.
- The loop
Optimization, governed
Floors plus analytics plus experimentation form the optimization loop: change a floor, measure bid behavior, keep or revert. Schema 2’s A/B floor groups formalize the experiment; the discipline of versioning and review has to come from the publisher.
The warning
A floor is a standing rejection rule that runs on every auction. Misconfigured floors do not announce themselves — they silently turn demand away. Treat floor changes like price changes: versioned, tested, and measured.
What this means for agentic advertising.
Most agentic-advertising attention sits on the buy side. The sell side’s equivalent is already here, hiding in plain sight: a declarative, versionable, policy-rich configuration surface that decides what every auction may do. An agent operating a publisher’s wrapper is not science fiction — it is a config-management problem with revenue attached. Seven implications follow.
- 01
The wrapper is the policy surface
Everything an agent could change on the sell side — bidders, floors, signals, identity, timeouts — is already expressed as configuration. That makes the wrapper the natural enforcement point for publisher-side agent guardrails.
- 02
Config-as-code is agent-legible
Declarative configuration — setConfig, allowActivities, floors schemas — is exactly what agents read and write well. The property that makes automation easy makes ungoverned automation dangerous: version and review wrapper changes like code.
- 03
Floors are the first levers agents pull
Floor providers already A/B-test floor groups under schema 2. An agent adjusting floors needs the same discipline — bounded ranges, holdouts, and analytics that detect silent demand rejection before the revenue report does.
- 04
Signal governance precedes signal automation
Before an agent enriches bid requests, the permission map must exist: which ortb2 fields, which bidders via setBidderConfig, which activities via transmitUfpd and transmitEids. Govern first, then automate.
- 05
Telemetry is the feedback loop
Analytics adapters are how an agent learns whether a change helped. No instrumentation, no optimization — only drift. The analytics build decision is an agentic-readiness decision.
- 06
Version fragility is operational risk
The 11.x line ships roughly weekly, and major versions remove capabilities — PAAPI and adpod both went in 11.0. Agentic workflows need pinned builds, upgrade testing, and removal-watching, not silent auto-updates.
- 07
Server-side is where agents leave the page
Prebid Server’s official use cases — app, AMP, CTV, DOOH, audio — are the surfaces seller-side agentic execution expands into. The governance model has to travel with it, because the browser’s visibility does not.
The point
The agentic opportunity is not autonomous chaos. It is governed publisher-side control.
Implementation lens.
The same execution layer lands differently depending on where you sit in the chain. Select your company type for the version of this page that applies to you.
Own the wrapper as a governed product: a versioned build, an explicit bidder list, dynamic floors, default-deny data permissions, consent modules wired to Activity Controls, and analytics that prove what each choice earns. Treat managed-service configs as code you review, not magic you rent.
Prebid Mobile requires Prebid Server — the auction runs server-side. Choose among the four integration methods deliberately (No Ad Server, GAM Bidding-Only, GAM Prebid-Rendered, mediation via AdMob or AppLovin MAX), and design signal forwarding explicitly, because the browser’s context never existed here.
You do not run Prebid, but your spend travels through it. Ask sellers which signals reach which bidders, how floors are set and tested, and which identity modules are active — and validate transparency claims against ads.txt and sellers.json buy-side, rather than assuming the wrapper enforces them.
Your bid adapter is your storefront in an ecosystem whose own docs cite more than 300 demand partners. Keep it current against a roughly weekly release train, honor the consent and activity signals it receives, and consume ortb2 first-party data per the conventions — not through side channels.
Bid requests arrive pre-shaped by publisher policy: permitted first-party data, permitted EIDs, gpp and gpp_sid in ortb2.regs. Build bidding logic that treats absent signals as policy rather than data loss — and never assume an ID or segment is universally present.
Ship modules that respect the governance rails: User ID submodules with per-bidder access arrays, floor-provider endpoints on schema 2 with A/B floor groups, and documentation that is honest about consent dependencies. Build-time inclusion means your module is a publisher policy decision.
Analytics adapters compile into the bundle and enable via enableAnalytics(). Instrument the events publishers need to govern agents — bid rates against floors, signal lift, timeout losses — and stay precise about what auction telemetry does and does not prove. Measurement standards live elsewhere.
No Fluff POV.
The industry argues about standards in working groups and then quietly decides them in wrapper configs. That is what makes Prebid strategically interesting: it is where a publisher’s standards posture stops being a position and starts being a setting. Teams that treat the wrapper as a monetization widget get whatever their managed service defaults to; teams that treat it as a governed policy surface get a sell side that is ready for agents — theirs and everyone else’s.
- Say it precisely: Prebid is not a protocol standard — it is the open-source publisher execution layer where many standards become operational.
- Treat the wrapper build as governance: every module compiled in is a capability granted; every module left out is a policy.
- Default-deny data and identity: setBidderConfig, per-submodule bidder arrays, and Activity Controls exist so access is granted deliberately.
- Treat enabled privacy modules as plumbing, not compliance — Prebid’s own documentation disclaims any compliance guarantee.
- Keep floors dynamic and measured: official docs discourage static floors, and a floor is a standing rejection rule on every auction.
- Cite version lines, not versions: the 11.x line ships roughly weekly — pin, test, and upgrade deliberately.
- Remove retired dependencies deliberately: PAAPI support ended in Prebid.js 11.0 and the USP module is no longer recommended — validate current status.
- Instrument before you automate: an agent optimizing a wrapper it cannot observe is optimizing in the dark — analytics adapters are the feedback loop.
The point
In agentic advertising, the auction wrapper becomes a policy surface.
Primary sources to validate.
Prebid, module, adapter, privacy, identity, and server-side implementation references last validated: June 2026. Validate current Prebid and official standards documentation before implementation.
Primary sources to validate 18 sources
- Prebid.org — homepage ↗ Official docs
Self-description: 'the most popular unified auction solution' (Prebid's own claim — attribute it, do not assert market share) and 'completely open source' under the Apache License, with public GitHub repos open to members and non-members. Product lineup: Prebid.js, Prebid Server, Prebid Mobile, SharedID, and managed services from member companies; Project Management Committees (PMCs) establish and prioritize the roadmap. Supports: How Prebid describes itself, Product suite enumeration, Apache open-source licensing, PMC governance mention.
- What is Prebid? (intro docs) ↗ Official docs
Canonical definition: Prebid is 'a product suite, a community, and an independent organization' — 'free and fully open source, available to any publisher.' Prebid.js is a JavaScript library that runs in the browser and the core product of the suite, concurrently calling selected bidders within a set timeout; modules (bid adapters, analytics adapters, user ID modules) extend the core. States the ecosystem supports 'more than 300 demand partners' (Prebid's own figure; counts change — do not state exact adapter counts). Not an IAB or IAB Tech Lab standard. Supports: Canonical Prebid definition, Prebid.js core + module architecture, '300+ demand partners' (attributed), Independent-organization framing.
- About Prebid.org (governance) ↗ Official docs
Prebid.org self-describes as 'a collection of leading ad tech companies that oversees & funds the development.' Prebid.js launched in 2015. Governance: the Technology and Publisher PMCs each elect one board representative yearly; the rest of the board is leader-tier member companies. PMC participation is members-only, but all Prebid technology remains available at no charge to all companies regardless of membership. The page states no legal entity type (do not call it a non-profit) and names no founders. Supports: Org structure and governance, Board/PMC composition, Membership vs free-software distinction, Prebid.js 2015 launch.
- Prebid Server Overview ↗ Official docs
Prebid Server is 'an open-source solution for server-to-server header bidding' with two official implementations — Go and Java, separately versioned and documented — plus request validation, currency conversion, bid caching, and 230+ server-side bid adapters (as listed June 2026; counts change). Official use cases: 'mobile app, AMP, server-side web with Prebid.js, and server-side ad inclusion scenarios such as CTV, Digital Out of Home and audio.' Supports: Prebid Server definition, Go vs Java implementations, Official use cases (app/AMP/S2S web/CTV/DOOH/audio), 230+ server-side adapters (attributed).
- Prebid Mobile Overview ↗ Official docs
Prebid Mobile is an open-source iOS/Android SDK for end-to-end in-app header bidding that requires a Prebid Server ('you must have a Prebid Server available in order to use Prebid Mobile') — the auction runs server-side, not on-device. Supports display, video, and native, with four integration methods: No Ad Server (direct render), GAM Bidding-Only, GAM Prebid-Rendered, and mediation via AdMob / AppLovin MAX. Current SDK line: 3.0 as of June 2026. Supports: SDK platforms (iOS/Android), Mandatory Prebid Server pairing, Four integration methods incl. GAM and mediation, Mobile SDK 3.0 line (June 2026).
- Price Floors Module ↗ Official docs
Open-source framework for publishers to configure price floors themselves or work with a floor provider; a floor is 'the lowest CPM price a bid will need to meet for each Prebid auction.' Three config locations: ad-unit level, package level via setConfig, and dynamic fetch from a floor-provider endpoint. Schema 1 allows one data group; schema 2 lets providers A/B-test floor groups via weighted model sampling. The docs explicitly discourage static floors ('blunt tools and you'll forget to update them') — supported, but not recommended. Supports: Floors capabilities and config locations, Schema 1 vs schema 2 (A/B floor groups), Official stance discouraging static floors.
- First Party Data Feature ↗ Official docs
First-party data follows OpenRTB-shaped ortb2 conventions: setConfig({ortb2}) for global data (ortb2.site context, ortb2.user data, custom attributes under ext.data, IAB taxonomy segments with segtax identifiers in site.content.data / user.data); setBidderConfig() restricts FPD so only named bidders receive it; ortb2Imp.ext.data carries ad-unit-level data; since Prebid 7, FPD can be passed per-auction to requestBids(). Docs note user FPD 'may require special consent in certain regions' — permissioning is a Prebid.js mechanism, not an enforcement guarantee. Supports: ortb2 FPD conventions incl. segtax, setBidderConfig per-bidder permissions, ortb2Imp ad-unit data, Prebid 7+ auction-specific FPD.
- Prebid Analytics Overview ↗ Official docs
Analytics adapters are vendor-specific modules compiled into the Prebid.js bundle at build time and enabled at runtime via enableAnalytics() with a provider name and options; they hook into the Prebid.js event system to capture auction and bid performance. Supports: Analytics adapter architecture, Build-time inclusion + enableAnalytics() flow.
- Prebid.js Releases (GitHub) ↗ Official GitHub
Release history for Prebid.js. As of June 2026 the current major line is 11.x, with minor releases shipping roughly weekly (11.17.0 on June 11, 2026); 10.x continues as a maintained legacy line. VERSION-FRAGILE: cite the 11.x line, never a specific minor or patch, and re-validate before publishing. Supports: Current major version line (11.x, June 2026), Roughly-weekly release cadence, Version-fragility flag.
- Prebid.org Membership ↗ Official docs
Confirms a formal membership agreement and Prebid bylaws exist; tier and fee details are not enumerated on-page — do not state membership prices. Use the About page for governance facts. Supports: Existence of membership agreement and bylaws.
- Consent Management — TCF Module ↗ Official docs
Active GDPR/TCF consent module (consentManagementTcf): fetches TCF v2.x consent strings from IAB-compliant CMPs and makes them available to adapters during the auction. Config: cmpApi ('iab' or 'static'), timeout, actionTimeout, defaultGdprScope. An optional TCF control module enforces consent-based activity restrictions. TCF v1 is not covered. Consent plumbing, not a compliance guarantee. Supports: TCF module status (active) and config, TCF v2.x scope, TCF control module companion.
- Consent Management — GPP Module ↗ Official docs
Active GPP consent module: works with IAB GPP-compliant CMPs (GPP 1.0; 1.1 support added around Prebid.js 8.6, July 2023); adapters read consent via bidderRequest.gppConsent and the OpenRTB 2.6 ortb2.regs gpp / gpp_sid fields. Docs state it 'is not yet intended to replace other consent modules; it supplements them' — do not say GPP replaces the TCF or USP modules. Supports: GPP module status and config, GPP-supplements-not-replaces framing.
- Consent Management — US Privacy (USP) Module ↗ Official docs
CCPA/US Privacy module carrying the official notice: 'This module is no longer recommended, as the signal is no longer supported by a contractual framework as of January 31, 2024.' Deprecated in recommendation, not removed — the module still exists in the repo and docs; GPP is the active US-privacy path per Prebid's privacy resources. Supports: USP deprecation status (exact official wording), US Privacy sunset date (Jan 31, 2024).
- User ID Module ↗ Official docs
Framework for pseudonymous ID submodules (60+ listed; the list changes — avoid exact counts) configured via userSync.userIds: name, storage (cookie/html5, expiry, refresh), params, and an optional per-submodule bidders array restricting which bidder codes may receive that ID. IDs surface as bidRequest.userId and userIdAsEids (ORTB EID format); userSync.idPriority resolves conflicts. With the TCF module and no Purpose 1 consent: 'Calls to an external user ID vendor are not made. Nothing is stored to cookies or HTML5 local storage.' Supports: User ID framework mechanics, Per-submodule bidder access control, GDPR Purpose 1 gating of ID storage/calls.
- SharedID (identity overview) ↗ Official docs
Current official description: SharedID is 'a convenient Prebid-owned first party identifier within the Prebid UserId Module framework' — a random UUID stored in a first-party cookie on the publisher's domain. PubCommon ID was merged into SharedID at Prebid.js 5.0, which also removed external sync calls — do not describe SharedID as cookie-syncing or making third-party calls. Default lifetime 365 days (effectively ~7 days in Safari under ITP); suppressed without TCF Purpose 1 consent; honors opt-out and COPPA flags; no registration required. Supports: Current SharedID definition (Prebid-owned, first-party), PubCommon merge at 5.0, Storage and consent dependencies.
- Activity Controls ↗ Official docs
Centralized privacy gating introduced in Prebid.js 7.52, configured via setConfig({allowActivities}). Gates 12 named activities: accessDevice, accessRequestCredentials (since v10), enrichEids, enrichUfpd, fetchBids, reportAnalytics, syncUser, transmitEids, transmitPreciseGeo, transmitTid, transmitUfpd, loadExternalScript. Rules carry a priority (publisher config defaults to 1, modules to 10; lower wins; deny beats allow at equal priority), an optional condition function, and an allow flag; consent modules translate regulatory strings into these rules, and publishers can override. Supports: allowActivities structure, Full 12-activity list incl. transmitUfpd/transmitEids, Rule priority semantics.
- Prebid.js 11.0 Release Notes (PAAPI and Adpod removal) ↗ Official docs
Official Prebid.js 11.0 notes (11.0.0 released March 12, 2026) state verbatim: 'PAAPI is no longer supported.' and 'Adpod is no longer supported.' — the paapi, paapiForGpt, and topLevelPaapi modules were removed, along with adpod/long-form modules; DNT support was also removed (getDNT() now always returns false). The notes give no reason for the PAAPI removal — do not attribute it to Chrome's October 2025 Privacy Sandbox retirement as Prebid's stated rationale. The live docs PAAPI module page documents 10.x and earlier and carries no deprecation banner — do not cite it as evidence of current 11.x support. Supports: PAAPI module status post-retirement (removed in 11.0), Adpod removal, DNT removal, Docs-vs-release-notes discrepancy caveat.
- Prebid Privacy Resources ↗ Official docs
Prebid's privacy hub mapping tools to regimes — GPP and US state protocols (US Privacy/CCPA deprecated), GDPR and DSA via IAB TCF, Quebec Law 25 — with the explicit disclaimer: 'This resource should not be construed as legal advice and Prebid.org makes no guarantees about compliance with any law or regulation.' Prebid tooling supports privacy workflows; it is not a compliance guarantee. Supports: Map of Prebid privacy modules, Prebid's own no-compliance-guarantee disclaimer.
Platform capabilities and naming change quickly. Last validated: June 12, 2026. Check current documentation before implementation.Prebid, module, adapter, privacy, identity, and server-side implementation references last validated: June 2026. Validate current Prebid and official standards documentation before implementation.
Building publisher-side execution into an agentic workflow?
The operating work is to turn wrapper configuration into governed policy — bidder selection, signal permissions, floors, identity, and analytics wired into the execution path before agents scale whatever the auction actually permits.