skip to Main Content

The Release Of Prebid 7.0

We’re extremely excited to announce we have released Prebid 7! 

Prebid.js 7, like other major versions, is a collection of “breaking” changes where the publisher and module maintainers should check the release notes for any behavior changes or new configuration requirements before upgrading. Like other past major versions, we’ll continue to release bug fixes and adapter commits to the 6.x code base for sixty days. After that, we may still merge code to old branches on an ad hoc basis but there won’t be any more releases against the 6.x code base. Releasing these breaking changes as a group is designed to make it so publishers can count on doing minor upgrades not breaking their interface, and can do so regularly with less extensive testing.

What’s in Prebid.js 7? 

This time we’ve put the release notes on the website in addition to Github, so you can see the final product without having to dive into how the sausage was made at Some of the highlights are: updated ORTB2 object interface and internals, updated page referrer interface and internals, storage manager permissioning, and continued consolidation of adapter parameters.

The largest group of changes are deprecated modules; for example, the FLOC module. We release module deprecations in major versions so that publisher build processes don’t fail without warning when a module disappears. Staying with that example, the FLOC module has had no function for some time, but it is removed in the major version so that publishers relying on its existence get a notification to change their configuration. We also removed TCF1 support from consent management. 

A couple of publisher API deprecations accompany some really big changes in Prebid internals in version 7. One is the removal of support for setConfig(‘publisherDomain’). Setting that parameter will now have no effect, and no bidder reads that field. A full refactor of the way bidders identify the current page and its referrer has been completed, with changes done to every bidder. Bidders should actually double check they are getting what they expect, as there was some ambiguity in what referrer means (the page the user is on or the previous page) in some adapter code choices. In Prebid 7, bidders setting the equivalent of OpenRTB should see the publisher configured page URL, the canonical link in the page meta tags, or information provided from the browser in that fallback order. We noticed that widely disparate implementations on this across bidders had led to some bidders reaching different conclusions about the page the impression is occurring on; this should no longer be the case. 

Another large internal change is accompanying the removal of setConfig(‘fpd’). The taxonomy committee has been hard at work to align our first-party data specification with the OpenRTB object, and as such, it should now be specified within it. Prebid 7 also allows for this object to vary over auctions in cases where the contextual information is varying for a single page application or video embed. The big change this necessitated was that the OpenRTB object is now delivered to modules as part of the bid request, and bidders no longer should refer to it with a getConfig. 

Some of the breaking changes in Prebid 7 are following the model of Prebid 5, in which common bidder parameters should only need to be specified once. Publishers can now rely on certain parameters no longer needing to be set in bidder configuration, including (a) the instl flag on an ad unit, (b) the position parameter, and (c) the banned categories (bcats). Bidders should consider that if they are accepting any OpenRTB field in their configuration parameters, they should also check the Prebid.js ORTB2 object for that field.

One other big change designed to enable publisher compliance and further buttress publisher trust in the project: bidders can no longer access device storage without explicit publisher permission. Many bidders have this functionality, but we want to make sure publishers are aware of each one and have agreed to it, so they can include it in their communication to readers about how they use device storage on their sites. Of note, this does not apply to RTD and User ID modules, as their use of storage is the rule, not the exception. Publishers using those module types should discuss with the provider how they are using storage if they have their own disclosure requirements to meet.

A couple of other minor things to mention: if you’re loading Prebid twice on the same page or using a very old version of Prebid Server, check the release notes for some details on behavior changes in those areas. 

What else has Prebid released recently?

Prebid releases new functionality all the time and doesn’t hold it for a major release unless it is expected to break someone’s configuration. The Demand Chain module is a great example of that. We’ve been working in coordination with the IAB Buyer Transparency team, and Prebid publishers can now accumulate demand chains in a particular place for them, or their analytics providers, to extract information from. Prebid will also attempt to construct an incomplete dchain even when it is missing. Currently, Xandr, the module developer, is the only known integration to pass the dchain in a bid response, but we’re expecting that to grow quickly, as buyer transparency is a top publisher priority. 

Another recent change is support for Libraries. There has long been a module rule that modules could only import from core. Libraries are now eligible to be imported from, but won’t be part of the build unless a module requires it. This should help to reduce code duplication within the project substantially. 

On the fly inclusion of debugging code is now possible. A standalone prebid module for debugging that was not included at build time can now be loaded and enhance the debugging workflow, including the ability to generate faux bid responses from any bidder. The recent release of Professor Prebid already is a valuable tool in the ad ops workflow and the new debugging functionality is scheduled to be fully baked into it. 

Prebid is quickly becoming the hub in which publishers centralize information on reader identity and first-party data. We’ve recently exposed an API to get an identifier asynchronously so callers don’t have to poll for identifiers to exist. Prebid also has released functionality to pass an identifier to GAM as a GAM encrypted signal or a GAM PPID (not to be confused with the Prebid PPID module). Amazon APSTAG has started to ingest identity information from Prebid locations. We expect the pattern of Prebid being the publisher tool that other libraries ingest from to continue with seller-defined audiences and transaction identifiers. 

What’s coming for Prebid.js? 

Prebid is extremely excited about the upcoming merge of the video module. It promises to dramatically improve the internals of the video workflow. Right now, things like simply identifying a winning bid to mark it as rendered are challenging. Likewise, native is getting an overhaul, with some announced changes expecting to be merged in soon. We’re hoping to reduce implementation friction a bunch on both of these media types. There’s also some audio media type demand brewing, and more formal, standardized support for that is in discussion. 

In the near future, in partnership with, we plan to publish some usage statistics about recent releases, so publishers can also see when a minor version or particular module has achieved strong adoption. Companies have various levels of comfort between the bleeding edge and the tried and true, so we want to provide better guidance as to where those lines are. We also recognize the adoption curve might not be the same for core as it is for a module, and usage statistics for a various vendor or core module will convey extremely useful information to publishers selecting their partners and components.

One of the more ambitious projects on our near-term road map is an enhanced ORTB2 interface. Publishers are populating an ORTB2 object now via setConfig, RTD modules, or the first-party data enrichment module. We plan to greatly expand on that model, with a few proposals on the table, including an ORTB2 Bidder module on which ORTB2-based endpoints could become submodules, a dramatic expansion of the current ORTB2 object exposed to bidders, and/or utility functions in Prebid core that convert the current bidrequest object into ORTB2.  This would have some enormous advantages: The build size could be dramatically reduced if bid modules were much smaller. Many bid modules largely duplicate each others’ efforts to convert a prebid internal object into something their endpoint can expect. Also, we would expect to see some bidder integrations that may have been intimidated by learning our internals build direct integrations utilizing this more ORTB2-ready request object. Bid modules would be much easier to maintain, and the bid request objects would be much more uniform across bidders. For example, when a new thing is added [eg device.sua, regs.ext.gpc, or source.tid] to the internal ORBT2 object, all bidders consuming that object would automatically see the new field without the need of a pull request. Likewise, an ORTB2 response processing utility function should have similar benefits to publishers.

We’re also planning to continue to be a test bed for proposed standards and emerging technologies. Whether or not the various proposals in the privacy sandbox and other similar efforts are successful, one can expect Prebid.js to be where many of the tires are kicked. For example, publishers can expect Prebid.js to soon enable their SSP partners to participate in FLEDGE auctions or augment their bid requests with information from the Topics API. We’ll be there to enable publisher monetization on any emerging browser interface.

We’re planning to host a webinar to dive into a few of these topics on July 27th at Noon EST. Stay tuned (watch your emails) for details. 

Patrick McCann

Committee Chair, Prebid.js


Back To Top