We’re excited to announce the release of Prebid.js 4.0! Version 4.0 includes some important updates related to TCF 2.0 and a number of housekeeping items. You can find a bulleted summary of features included in this release on the Github release page. Here are the details of included features.
Moving Towards Standardization
Parameter Locations
Beginning now, rather than accepting parameter locations on bidder-specific parameters, new bidders will be required to conform to standard locations for the following parameters: first party data, floors, schain, video params, page referrer, and COPPA. Currently, bidders that support these parameters do so in a bidder-specific way, which means publishers have to copy the data from different locations and in different ways across different bidders. Since these parameters are often shared across bidders, we’ll be enforcing standard methods for passing these parameters across new bidder adapters, and will require existing adapters to change in a future major release.
Video Parameters
On a similar note, we are introducing another standardization to streamline consumption of OpenRTB video parameters. The vast majority of bidders require OpenRTB parameters for prebid video requests. However, there is currently no standard object for them to retrieve these parameters from in request objects. Rather, the parameters are typically duplicated individually for every bidder in unique or free form taxonomies, creating extra work for publishers and increasing opportunities for error. Adapter reviewers will now enforce that video parameters be retrieved from the mediaTypes.video object. This is an important step towards streamlining implementation of Prebid Video.
meta Taxonomy
Finally, we’ve found that Prebid has historically struggled with making granular data about bid responses easily consumable by publisher analytics and reporting systems, significantly limiting their ability to report and take action on individual ads running on their site.
We’re addressing this by introducing standards in the bidResponse.meta object that we plan on enforcing in future versions. Specifically, we’re outlining that the bidResponse.meta object will contain:
networkId: NETWORK_ID,
networkName: NETWORK_NAME
agencyId: AGENCY_ID,
agencyName: AGENCY_NAME,
advertiserId: ADVERTISER_ID,
advertiserName: ADVERTISER_NAME,
advertiserDomains: [ARRAY_OF_ADVERTISER_DOMAINS]
brandId: BRAND_ID,
brandName: BRAND_NAME,
primaryCatId: IAB_CATEGORY,
secondaryCatIds: [ARRAY_OF_IAB_CATEGORIES],
mediaType: MEDIA_TYPE
| Field | Scope | Type | Description |
|---|---|---|---|
meta.networkId | Optional | int | Bidder-specific Network/DSP ID |
meta.networkName | Optional | string | Network/DSP Name |
meta.agencyId | Optional | int | Bidder-specific Agency ID |
meta.agencyName | Optional | string | Agency Name |
meta.advertiserId | Optional | int | Bidder-specific Advertiser ID |
meta.advertiserName | Optional | string | Advertiser Name |
meta.advertiserDomains | Optional | array | Array of Advertiser Domains for the landing page(s). This is an array to align with the OpenRTB ‘adomain’ field. |
meta.brandId | Optional | int | Bidder-specific Brand ID (some advertisers may have many brands) |
meta.brandName | Optional | string | Brand Name |
meta.primaryCatId | Optional | string | Primary IAB category ID |
meta.secondaryCatIds | Optional | array | Array of secondary IAB category IDs [“IAB-222”,”IAB-333”] |
meta.mediaType | Optional | string | “banner”, “native”, or “video” – this should be set in scenarios where a bidder responds to a “banner” mediaType with a creative that’s actually a video (e.g. outstream) or native. |
While various fields may currently be passed in via bidResponse today, we think it’s important to the future functionality of Prebid to have a standardized taxonomy for this data. You’ll notice a number of important fields, for example meta.advertiserName and meta.advertiserId, that provide publishers with the ability to report against which advertisers are running on their website. This is all with an eye towards eventually being able to implement logic in the page relating to advertiser, DSP, category, etc.
In version 4.0 these fields are not required and this is not a breaking change. However, we expect some or all of these fields to become a requirement in the future. Bidders should begin implementing these fields properly as soon as possible. While not yet a global taxonomy, the bidders actively using the field in the near term will shape the community discussion around the final execution of the standardization.
Staying on top of Privacy
Prebid has developed flexible software solutions to help Publishers conform to TCF 2.0. This release includes updates to Prebid’s enforcement, specifically with regards to TCF Purposes 1 and 2. While Prebid.org can’t provide legal advice, and takes no position with regards to responsibility, we’ve provided an intuitive toolkit for publishers to implement header bidding per their internal requirements. From 4.0 onward, Prebid.js will enforce Purposes 1 and 2 by default, meaning that without consent or legitimate interest, Prebid.js may restrict device access and may remove some (or all) bidders from the auction. All of these settings are of course configurable, and can be changed with modifications to gdpr.rules[].enforcePurpose. See our privacy documents for more details.
Additional Changes and Details
Prebid.js 4.0 also contains a few other changes and coming updates:
- Remove AudienceNetwork adapter and Quantum bidder (deprecated).
- Stronger enforcement for bidders return bid meta data (#3115 (comment)) needs refinement. PR here #5358.
- #3873 – Proposal: set cookie domain in pubcid / userid on main domain, not subdomain.
Detailed discussion and links can be found here.