If the impression defines what is being sold, then the bidder configuration defines who can buy it, on what terms and in what context. This layer sits beneath the surface of the auction – it is where publishers establish relationships, build in commercial logic and steer demand without ever changing the auction algorithm itself.
This article explores how publishers use Prebid's configuration options to define the auction's business logic – from the rigid but essential params object to the broader modules and server-side tools that enrich and influence how bids are priced, filtered and evaluated.
Every bidder in Prebid requires a params object. This is where you pass along bidder-specific identifiers such as account IDs, placement IDs, site codes or zone IDs – the information that maps a specific ad unit on your page to a specific monetization endpoint at the SSP or exchange.
bids: [{
bidder: 'rubicon',
params: {
accountId: '1234',
siteId: '5678',
zoneId: '91011'
}
}]
Each adapter documents its own required fields. These parameters are not flexible – if a required field is missing or invalid, the bidder does not respond. And yet these IDs are absolutely central: They tell the SSP who you are, where the impression belongs, and how it should be routed and reported. They are also tied to specific pricing configurations and buyer access.
Different SSPs have different structures: Some use placement IDs, others use member and inventory codes, and some allow nested targeting. It all runs through params.
It is the handshake between publisher and demand partner.
It is also possible to set up custom params for a given bidder in cases where valuable information needs to be passed along that is not part of the standardized OpenRTB protocol.
Prebid ships with a broad and growing range of modules that let publishers enrich auctions with data, controls and signals – all without touching the core auction logic or manually changing params. At the time of writing, there are more than 80 modules on Prebid's official module documentation page, covering everything from identity resolution and privacy enforcement to analytics, real-time data and performance tuning.
To navigate them more easily, we can split them into four main types:
These are the modules the Prebid team encourages all publishers to consider. They provide essential auction infrastructure, primarily focused on the legal permissions around consent.
Examples:
These modules are especially important if you operate in the EU, where GDPR compliance is a legal requirement. Without the consentManagement module, neither Prebid.js nor the bidders involved can determine on what legal basis the auction is running – a concept we briefly touched on in the previous article, The impression (what is for sale?).
TCF's Global Vendor List (GVL) also requires vendors to disclose how they use storage on the device. The storageControl module uses that information to validate whether Prebid modules and bidder adapters only access declared identifiers and only within acceptable first-party domains.
Together, these modules form the compliance foundation of Prebid, ensuring that both consent and data-usage signals are transparent, enforceable and aligned with users' rights.
These extend Prebid with optional improvements in transparency, optimization or reporting.
Examples:
These modules are neither technical nor legal requirements for running ads in the EU, but they are strongly recommended if you want proper transparency and optimization in Prebid.
The Supply Chain Object is added to the bid request and contains critical metadata from the publisher's side. It includes references to the site's ads.txt and sellers.json data and connects them with the SSP's and DSP's supply chain records. The goal is full transparency across the entire programmatic chain – whether it actually delivers on that promise is perhaps a topic for a future article.
The Currency module enables real-time bidding to work across different currencies by automatically converting and normalizing bid values. It is especially useful with multinational demand or cross-border buyers. The Prebid Server Adapter, as the name suggests, lets publishers configure server-side auction endpoints. This allows them to run Prebid Server auctions in parallel with client-side auctions, creating hybrid auction setups that combine performance and control.
Developed or maintained by specific partners to add advanced functionality, often unique to their integrations.
Examples:
Most of these vendor-specific modules are used together with a vendor you already work with. They typically offer a plug-and-play setup that gives the vendor a deeper integration into the bid stream. That does not mean, however, that the module is strictly necessary for the service to work.
We use Neuwo, for example, as a contextual data provider in our ad network, but instead of using their module we have configured it via our own data layer and our tag management platform. That gives us more granular control, but the result is the same.
User ID modules support multiple methods for establishing pseudonymous identifiers for users – a critical factor in increasing the value of header bidding. Instead of relying on each exchange syncing IDs with dozens of demand sources, publishers can choose to integrate with one or more ID systems that consolidate user identification across bidders.
Examples:
Each module type plays its own role in enriching the bid request. You can think of them as modular extensions that can be added according to business needs. Their real value, however, depends on the buy side: which systems DSPs and DMPs support, and how they activate the data in campaigns.
It is not just about whether a module is active – it is about whether the buyer can use what the module enables.
The same goes for most user ID modules: Some are based on the publisher's own data points (like PubProvidedID), while others generate or sync their own unique pseudonymous identifiers.
Prebid is more than an auction engine – it is a configurable orchestration layer. Publishers have developed strategies that use configuration patterns to shape auction behavior in subtle but powerful ways:
setBidderConfig() you can share premium or sensitive segments exclusively with selected SSPs that have a direct relationship with the publisher. This ensures that valuable first-party data is not freely available across the entire open market.
These patterns let publishers move from reactive monetization to proactively shaping demand – where the Prebid configuration is used as a strategic tool rather than a technical requirement.
Bidder configuration is where the publisher's intent becomes a strategy that can be monetized. Through params, modular enrichment and advanced configuration practices, publishers influence how impressions are seen, scored and priced. All before a single bid is placed.
Today, Prebid supports over 80 modules across four core categories – from legal enforcement of consent to contextual data enrichment and custom ID solutions. Publishers activate them selectively to shape auction dynamics and tailor what each bidder sees, based on deal terms, data rights or inventory value.
Smart setups use bidder aliasing for special formats, restrict sensitive data to trusted SSPs and use Prebid modules to pass along user identity, floor prices and contextual metadata – all without changing the auction itself.
Ultimately, bidder configuration is not just about compatibility. It is where commercial logic and technical execution meet. Used correctly, it is a competitive advantage that gives publishers precise control over how their supply enters the market.
That was the third article in this nine-part series: What is actually hiding in a bid request?
Let us help you get the most out of your display campaigns.
