Back to Publisher API Reference

pbjs.setConfig(options)

• Overview
• PBJS Core Configuration
  • Debugging
  • Device Access
  • Bidder Timeouts
  • Enable sharing of transaction IDs
  • Max Requests Per Origin
  • Disable Ajax Timeout
  • Set TTL Buffer
  • Send All Bids
  • Configure Send Bids Control
  • Use Bid Cache
  • Bid Cache Filter Function
  • Minimum bid cache TTL
  • Event history TTL
  • Bidder Order
  • Page URL
  • Price Granularity
    • Auto Granularity
    • Dense Granularity
    • Custom CPM Bucket Sizing
  • Media Type Price Granularity
  • Custom CPM Rounding
  • Server to Server
  • Mobile App Post-Bid
  • Configure User Syncing
    • User Sync Properties
    • User Sync Examples
    • How User Syncing Works
  • Configure Targeting Controls
  • Configure Responsive Ads
  • COPPA
  • First Party Data
  • Video Module to integrate with Video Players
  • Client-side Caching of VAST XML
  • Instream tracking
  • Site Configuration
  • Auction Options
  • maxNestedIframes
  • Real-Time Data Modules
  • Topics Iframe Configuration
  • Disable performance metrics
  • Setting alias registry to private
  • Set Max Bid
  • General adapter Configuration
  • Troubleshooting your configuration

Overview

setConfig() is the main way to tell Prebid.js how you want to run the header bidding auction. Every call to setConfig() overwrites supplied values at the top level. e.g. if ortb2 is provided as a value, any previously-supplied ortb2 values will disappear. If this is not the desired behavior, there is a mergeConfig() function that will preserve previous values to do not conflict with the newly supplied values.

This page covers the setConfig() values supported by the core of Prebid.js. There are other options available if certain modules are included in the Prebid.js build:

Module-specific configuration:

• Currency module
• Consent Management
• User ID module
• Adpod
• IAB Category Translation

PBJS Core Configuration

Debugging

Debug mode can be enabled permanently in a page if desired. In debug mode, Prebid.js will post additional messages to the browser console and cause Prebid Server to return additional information in its response. If not specified, debug is off. Note that debugging can be specified for a specific page view by adding pbjs_debug=true to the URL’s query string. e.g. /pbjs_demo.html?pbjs_debug=true See Prebid.js troubleshooting guide for more information.

Turn on debugging permanently in the page:

pbjs.setConfig({ debug: true });

Note that turning on debugging for Prebid Server causes most server-side adapters to consider it a test request, meaning that they won’t count on reports.

Device Access

You can prevent Prebid.js from reading or writing cookies or HTML localstorage by setting this flag:

pbjs.setConfig({ deviceAccess: false });

This can be useful in GDPR, CCPA, COPPA or other privacy scenarios where a publisher has determined that header bidding should not read from or write the user’s device.

Note that bid adapters are normally denied access to device storage even when deviceAccess is true; see the storageAllowed bidder setting.

Bidder Timeouts

Set a global bidder timeout:

pbjs.setConfig({ bidderTimeout: 3000 });

Bid Timeouts and JavaScript Timers Note that it’s possible for the timeout to be triggered later than expected, leading to a bid participating in the auction later than expected. This is due to how setTimeout works in JS: it queues the callback in the event loop in an approximate location that should execute after this time but it is not guaranteed. With a busy page load, bids can be included in the auction even if the time to respond is greater than the timeout set by Prebid.js. However, we do close the auction immediately if the threshold is greater than 200ms, so you should see a drop off after that period. For more information about the asynchronous event loop and setTimeout, see How JavaScript Timers Work.

Enable sharing of transaction IDs

Prebid generates unique IDs for both auctions and ad units within auctions; these can be used by DSPs to correlate requests from different sources, which is useful for many applications but also a potential privacy concern. Since version 8 they are disabled by default (see release notes), and can be re-enabled with enableTIDs:

pbjs.setConfig({ enableTIDs: true });

Max Requests Per Origin

Since browsers have a limit of how many requests they will allow to a specific domain before they block, Prebid.js will queue auctions that would cause requests to a specific origin to exceed that limit. The limit is different for each browser. Prebid.js defaults to a max of 4 requests per origin. That value can be configured with maxRequestsPerOrigin.

// most browsers allow at least 6 requests, but your results may vary for your user base.  Sometimes using all
// `6` requests can impact performance negatively for users with poor internet connections.
pbjs.setConfig({ maxRequestsPerOrigin: 6 });

// to emulate pre 1-x behavior and have all auctions queue (no concurrent auctions), you can set it to `1`.
pbjs.setConfig({ maxRequestsPerOrigin: 1 });

Disable Ajax Timeout

Prebid core adds a timeout on XMLHttpRequest request to terminate the request once auction is timedout. Since Prebid is ignoring all the bids after timeout it does not make sense to continue the request after timeout. However, you have the option to disable this by using disableAjaxTimeout.

pbjs.setConfig({ disableAjaxTimeout: true });

Set TTL Buffer

When an adapter bids, it provides a TTL (time-to-live); the bid is considered expired and unusuable after that time has elapsed. Core subtracts from it a buffer of 1 second; that is, a bid with TTL of 30 seconds is considered expired after 29 seconds. You can adjust this buffer with:

pbjs.setConfig({ 
  ttlBuffer: 10  // TTL buffer in seconds 
});

Send All Bids

When enableSendAllBids is true (the default), the page will send keywords for all bidders to your ad server. The ad server can then make the decision on which bidder will win. Some ad servers, such as Google Ad Manager, can then generate reporting on historical bid prices from all bidders.

However, there will be a set of ad server targeting values for each bidder, so if you run many bidders this could cause an issue with how much data is being sent to the ad server.

There are several ways to address the issue of sending too much data to the ad server:

1. Set enableSendAllBids to false. This will minimize the number of targeting variables sent to the ad server; only the top bid will be sent.
2. Define the auctionKeyMaxChars setting. This allows you to establish a limit on the number of bytes sent to the ad server. See targetingControls for more details.
3. Set enableSendAllBids to false and targetingControls.alwaysIncludeDeals to true. This will send the top bid and any deals.
4. Set enableSendAllBids to false, targetingControls.alwaysIncludeDeals to true, and auctionKeyMaxChars. This will send the top bid and any deals up to the maximum number of characters.

Note that targeting config must be set before either pbjs.setTargetingForGPTAsync() or pbjs.getAdserverTargeting() is called.

Example results where enableSendAllBids is true

{
  "hb_adid_audienceNetw": "1663076dadb443d",
  "hb_pb_audienceNetwor": "9.00",
  "hb_size_audienceNetw": "300x250",
  "hb_format_audienceNe": "banner",
  "hb_source_audienceNe": "client",
  "hb_adid_rubicon": "3485968928",
  "hb_pb_rubicon": "8.00",
  "hb_size_rubicon": "300x250",
  "hb_deal_rubicon": "11111111",
  "hb_format_rubicon": "banner",
  "hb_source_rubicon": "client",
  "hb_adid_appnexus": "191f4aca0c0be8",
  "hb_pb_appnexus": "10.00",
  "hb_size_appnexus": "300x250",
  "hb_format_appnexus": "banner",
  "hb_source_appnexus": "client",
  // the winning bid is copied to attributes without a suffix
  "hb_bidder": "appnexus",
  "hb_adid": "191f4aca0c0be8",
  "hb_pb": "10.00",
  "hb_size": "300x250",
  "hb_format": "banner"
}

You can see how the number of ad server targeting variable could get large when many bidders are present.

Example of setting enableSendAllBids to false

Turning off enableSendAllBids will cause the system to return only the winning bid. However, this could be a problem if you need to support deals, as often a deal may be chosen to win over an open market bid.

To make sure that deal bids are sent along with the winning bid in the enableSendAllBids:false scenario, use the alwaysIncludeDeals flag that’s part of targetingControls:

pbjs.setConfig({
  enableSendAllBids: false,
  targetingControls: {
    alwaysIncludeDeals: true
  }
});

Configure Send Bids Control

The sendBidsControl object passed to pbjs.setConfig provides the publisher with the ability to adjust the targeting behavior when sendAllBids is enabled.

Details on the bidLimit setting

Below is an example config containing bidLimit:

pbjs.setConfig({
  sendBidsControl: {
    bidLimit: 2
  }
});

When this property is set, the value assigned to bidLimit is the maximum number of bids that will be sent to the ad server. If bidLimit is set to 0, sendAllBids will have no maximum bid limit and all bids will be sent. This setting can be helpful if you know that your ad server has a finite limit to the amount of query characters it will accept and process.

Note that this feature overlaps and can be used in conjunction with targetingControls.auctionKeyMaxChars. Please see that section for tips on controlling the number of characters being sent to the ad server.

Use Bid Cache

Prebid.js currently allows for caching and reusing bids in a very narrowly defined scope. However, if you’d like, you can disable this feature and prevent Prebid.js from using anything but the latest bids for a given auction.

This option is available in version 1.39 as true-by-default and became false-by-default as of Prebid.js 2.0. If you want to use this feature in 2.0 and later, you’ll need to set the value to true.

pbjs.setConfig({ useBidCache: true })

Bid Cache Filter Function

When Bid Caching is turned on, a custom Filter Function can be defined to gain more granular control over which “cached” bids can be used. This function will only be called for “cached” bids from previous auctions, not “current” bids from the most recent auction. The function should take a single bid object argument, and return true to use the cached bid, or false to not use the cached bid. For Example, to turn on Bid Caching, but exclude cached video bids, you could do this:

pbjs.setConfig({
    useBidCache: true,
    bidCacheFilterFunction: bid => bid.mediaType !== 'video'
});

Minimum bid cache TTL

By default, Prebid keeps every bid it receives stored in memory until the user leaves the page, even after the bid actually times out and is no longer available for new auctions. This can cause high memory usage on long-running single-page apps; you can configure Prebid to drop stale bids from memory with minBidCacheTTL:

pbjs.setConfig({
  minBidCacheTTL: 60  // minimum time (in seconds) that bids should be kept in cache
})

When set, bids are only kept in memory for the duration of their actual TTL lifetime or the value of minBidCacheTTL, whichever is greater. Setting minBidCacheTTL: 0 causes bids to be dropped as soon as they expire.

Put another way, this setting doesn’t define each bid’s TTL, but rather controls how long it’s kept around in memory for analytics purposes.

Event history TTL

By default, Prebid keeps in memory a log of every event since the initial page load, and makes it available to analytics adapters and getEvents(). This can cause high memory usage on long-running single-page apps; you can set a limit on how long events are preserved with eventHistoryTTL:

pbjs.setConfig({
  eventHistoryTTL: 60 // maximum time (in seconds) that events should be kept in memory
})

Bidder Order

Set the order in which bidders are called:

pbjs.setConfig({ bidderSequence: "fixed" })   /* default is "random" */

Page URL

Override the Prebid.js page referrer for some bidders.

pbjs.setConfig({ pageUrl: "https://example.com/index.html" })

Price Granularity

This configuration defines the price bucket granularity setting that will be used for the hb_pb keyword.

pbjs.setConfig({ priceGranularity: "medium" })

Standard values:

• "low": $0.50 increments, capped at $5 CPM
• "medium": $0.10 increments, capped at $20 CPM (the default)
• "high": $0.01 increments, capped at $20 CPM
• "auto": Applies a sliding scale to determine granularity as shown in the Auto Granularity table below.
• "dense": Like "auto", but the bid price granularity uses smaller increments, especially at lower CPMs. For details, see the Dense Granularity table below.
• customConfigObject: If you pass in a custom config object (as shown in the Custom CPM Bucket Sizing example below), you can have much finer control over CPM bucket sizes, precision, and caps.

Auto Granularity

Dense Granularity

Custom CPM Bucket Sizing

To set up your own custom CPM buckets, create an object like the following, and pass it into setConfig:

const customConfigObject = {
  "buckets" : [{
      "precision": 2,  //default is 2 if omitted - means 2.1234 rounded to 2 decimal places = 2.12
      "max" : 5,
      "increment" : 0.01  // from $0 to $5, 1-cent increments
    },
    {
      "max" : 8,
      "increment" : 0.05  // from $5 to $8, round down to the previous 5-cent increment
    },
    {
      "max" : 40,
      "increment" : 0.5   // from $8 to $40, round down to the previous 50-cent increment
    }]
};

//set custom config object
pbjs.setConfig({
    priceGranularity: customConfigObject
})

Here are the rules for CPM intervals:

• max and increment must be specified
• A range’s minimum value is assumed to be the max value of the previous range. The first interval starts at a min value of 0.
• precision is optional and defaults to 2

Media Type Price Granularity

The standard Prebid price granularities cap out at 20, which isn’t always convenient for video ads, which can command more than that. One solution is to set up a custom price granularity as described above. Another approach is to use mediaTypePriceGranularity config that may be set to define different price bucket structures for different types of media:

• for each of five media types: banner, video, video-instream, video-outstream, and native.
• it is recommended that defined granularities be custom. It’s possible to define “standard” granularities (e.g. “medium”), but it’s not possible to mix both custom and standard granularities.

const customPriceGranularityVideo = {
            'buckets': [
              { 'precision': 2, 'max': 5, 'increment': 0.25 },
              { 'precision': 2, 'max': 20, 'increment': 0.5 },
              { 'precision': 2, 'max': 100, 'increment': 1 }
            ]
};
const customPriceGranularityBanner = {
            'buckets': [
              { 'precision': 2, 'max': 5, 'increment': 0.5 },
              { 'precision': 2, 'max': 20, 'increment': 1 }
            ]
};

pbjs.setConfig({'mediaTypePriceGranularity': {
          'video': customPriceGranularity,   // used as default for instream video
          'video-outstream': customPriceGranularityBanner,
          'banner': 'customPriceGranularityBanner'
        }
});

Any mediaTypePriceGranularity setting takes precedence over priceGranularity.

mediaTypePriceGranularity works in two modes: either auctions contain adunits with a single media type, or all defined price granularities are custom. i.e. You cannot run an auction containing a mix of mediatypes across an adunit AND having a mix of “custom” and “standard” price granularities across mediatypes.

Note that mediaTypePriceGranularity is the only place that ‘video-outstream’ or ‘video-instream’ are recognized. This was driven by the recognition that outstream often shares line items with banner. If the mediatype is video, the price bucketing code further looks at the context (e.g. outstream) to see if there’s a price granularity override. If it doesn’t find ‘video-outstream’ defined, it will then look for just ‘video’.

Custom CPM Rounding

Prebid defaults to rounding down all bids to the nearest increment, which may cause lower CPM ads to be selected. While this can be addressed through higher price granularity, Prebid also allows setting a custom rounding function. This function will be used by Prebid to determine what increment a bid will round to.

You can set a simple rounding function:

// Standard rounding
pbjs.setConfig({'cpmRoundingFunction': Math.round});

Or you can round according to more complex considerations:

// Custom rounding function
const roundToNearestEvenIncrement = function (number) {
  let ceiling = Math.ceil(number);
  let ceilingIsEven = ceiling % 2 === 0;
  if (ceilingIsEven) {
    return ceiling;
  } else {
    return Math.floor(number);
  }
}
pbjs.setConfig({'cpmRoundingFunction': roundToNearestEvenIncrement});

Server to Server

See the Prebid Server module.

Mobile App Post-Bid

To support post-bid scenarios on mobile apps, the prebidServerBidAdapter module will accept ortb2.app config to forward details through the server:

pbjs.setConfig({
  ortb2: {
    app: {
      bundle: "org.prebid.mobile.demoapp",
      domain: "prebid.org"
    }
  }
});

In PBJS 4.29 and earlier, don’t add the ortb2 level here – just app directly. Oh, and please upgrade. 4.29 was a long time ago.

Configure User Syncing

The user sync configuration options described in this section give publishers control over how adapters behave with respect to dropping pixels or scripts to cookie users with IDs. This practice is called “user syncing” because the aim is to let the bidders match IDs between their cookie space and the DSP’s cookie space. There’s a good reason for bidders to be doing this – DSPs are more likely to bid on impressions where they know something about the history of the user. However, there are also good reasons why publishers may want to control the use of these practices:

• Page performance: Publishers may wish to move ad-related cookie work to much later in the page load after ads and content have loaded.
• User privacy: Some publishers may want to opt out of these practices even though it limits their users’ values on the open market.
• Security: Publishers may want to control which bidders are trusted to inject images and JavaScript into their pages.

User syncing default behavior If you don’t tweak any of the settings described in this section, the default behavior of Prebid.js is to wait 3 seconds after the auction ends, and then allow every adapter to drop up to 5 image-based user syncs.

For more information, see the sections below.

• User Sync Properties
• User Sync Examples
• How User Syncing Works

User Sync Properties

For descriptions of all the properties that control user syncs, see the table below.

User Sync Examples

For examples of configurations that will change the default behavior, see below.

Push the user syncs to later in the page load:

pbjs.setConfig({
    userSync: {
        syncDelay: 5000 // write image pixels 5 seconds after the auction
    }
});

Turn off user syncing entirely:

pbjs.setConfig({
    userSync: {
        syncEnabled: false
    }
});

Delay auction to retrieve userId module IDs first:

pbjs.setConfig({
    userSync: {
        auctionDelay: 1000 // delay auction up to 1 second
    }
});

Allow iframe-based syncs (the presence of a valid filterSettings.iframe object automatically enables iframe type user-syncing):

pbjs.setConfig({
    userSync: {
        filterSettings: {
            iframe: {
                bidders: '*',   // '*' means all bidders
                filter: 'include'
            }
        }
    }
});

Note - iframe-based syncing is disabled by default. Image-based syncing is enabled by default; it can be disabled by excluding all/certain bidders via the filterSettings object._

Only certain bidders are allowed to sync and only certain types of sync pixels:

pbjs.setConfig({
    userSync: {
        filterSettings: {
            iframe: {
                bidders: ['def'],  // only this bidder is excluded from syncing iframe pixels, all other bidders are allowed
                filter: 'exclude'
            },
            image: {
                bidders: ['abc', 'def', 'xyz'],  //only these 3 bidders are allowed to sync image pixels
                filter: 'include'
            }
        },
        syncsPerBidder: 3, // and no more than 3 syncs at a time
        syncDelay: 6000, // 6 seconds after the auction
    }
});

If you want to apply the same bidder inclusion/exlusion rules for both types of sync pixels, you can use the all object instead specifying both image and iframe objects like so:

pbjs.setConfig({
    userSync: {
        /* only these bidders are allowed to sync.  Both iframe and image pixels are permitted. */
        filterSettings: {
            all: {
                bidders: ['abc', 'def', 'xyz'],
                filter: 'include'
            }
        },
        syncsPerBidder: 3, // and no more than 3 syncs at a time
        syncDelay: 6000, // 6 seconds after the auction
    }
});

Note - the all field is mutually exclusive and cannot be combined with the iframe/image fields in the userSync config. This restriction is to promote clear logic as to how bidders will operate in regards to their userSync pixels. If the fields are used together, this will be considered an invalid config and Prebid will instead use the default userSync` logic (all image pixels permitted and all iframe pixels are blocked)._

The same bidders can drop sync pixels, but the timing will be controlled by the page:

pbjs.setConfig({
    userSync: {
        /* only these bidders are allowed to sync, and only image pixels */
        filterSettings: {
            image: {
                bidders: ['abc', 'def', 'xyz'],
                filter: 'include'
            }
        },
        enableOverride: true // publisher will call `pbjs.triggerUserSyncs()`
    }
});

As noted, there’s a function available to give the page control of when registered user syncs are added.

pbjs.triggerUserSyncs();

How User Syncing Works

The userSync.registerSync() function called by the adapter keeps a queue of valid userSync requests. It prevents unwanted sync entries from being placed on the queue:

• Removes undesired sync types. (i.e. blocks iframe pixels if filterSettings.iframe wasn’t declared)
• Removes undesired adapter registrations. (i.e. enforces the configured filtering logic from the filterSettings object)
• Makes sure there’s not too many queue entries from a given adapter. (i.e. enforces syncsPerBidder)

When user syncs are run, regardless of whether they are invoked by the platform or by the page calling pbjs.triggerUserSyncs(), the queue entries are randomized and appended to the bottom of the HTML tag.

Configure Targeting Controls

The targetingControls object passed to pbjs.setConfig provides some options to influence how an auction’s targeting keys are generated and managed.

Note that this feature overlaps and can be used in conjunction with sendBidsControl.bidLimit.

Details on the auctionKeyMaxChars setting

Below is an example config containing auctionKeyMaxChars:

pbjs.setConfig({
  targetingControls: {
    auctionKeyMaxChars: 5000,
  }
});

When this property is set up, the auctionKeyMaxChars setting creates an effective ceiling for the number of auction targeting keys that are passed to an ad server. This setting can be helpful if you know that your ad server has a finite limit to the amount of query characters it will accept and process. When there is such a limit, query characters that exceed the threshold are normally just dropped and/or ignored, which can cause potential issues with the delivery or rendering of the ad.

Specifically, Prebid will go through the following steps with this feature:

• Collect all the available targeting keys that were generated naturally by the auction. The keys are grouped by each of the adUnits that participated in the auction.
• Prioritize these groups of targeting keys based on the following factors:
  • Bids with deals are prioritized before bids without deals.
  • Bids with higher CPM are ranked before lower CPM bids. Note - The sorting follows this order specifically, so a bid with a deal that had a $10 CPM would be sorted before a bid with no deal that had a $15 CPM.
• Convert the keys for each group into the format that they are passed to the ad server (i.e., an encoded query string) and count the number of characters that are used.
• If the count is below the running threshold set in the setConfig call, that set of targeting keys will be passed along. If the keys exceed the limit, then they are excluded.

If you want to review the particular details about which sets of keys are passed/rejected, you can find them in the Prebid console debug log.

Finding the right value

Given the varying nature of how sites are set up for advertising and the varying mechanics and data-points needed by ad servers, providing a generic threshold setting is tricky. If you plan to enable this setting, it’s recommended you review your own setup to determine the ideal value. The following steps provide some guidance on how to start this process:

• Use Prebid to set up a test page that uses the typical setup for your site (in terms of the number of ad slots, etc.).
• Once it’s working, look for the average number of characters Prebid uses for the auction targeting keys.
  • You can do this by enabling the Prebid debug mode, enabling this setting in your setConfig with a high value, and then opening the browser’s console to review the Console Logs section.
• Also in the browser console, find your ad server’s ad URL in the Network tab and review the details of the request to obtain information about the query data (specifically the number of characters used).
  • You can copy the data to another tool to count the number of characters that are present.

Between these two values (Prebid’s targeting key count and the overall ad URL query character count), you will find the average number of characters that are used by your ad server. It’s likely that these ad server values will remain consistent given that type of setup. So if you know your ad server has a particular character limit, you can assume that these ad server characters will be reserved and the difference is what you could allot to Prebid.

Between this feature and the overlapping sendBidsControl.bidLimit, you should be able to make sure that there’s not too much data going to the ad server.

Details on the allowTargetingKeys setting

The allowTargetingKeys config creates a targeting key mask based on the default targeting keys defined in CONSTANTS.TARGETING_KEYS and CONSTANTS.NATIVE_KEYS. Any default keys that do not match the mask will not be sent to the adserver. This setting can be helpful if you find that your default Prebid.js implementation is sending key values that your adserver isn’t configured to process; extraneous key values may lead to the ad server request being truncated, which can cause potential issues with the delivery or rendering ads.

Prebid.js introduced the concept of optional targeting keys with 4.23. CONSTANTS.DEFAULT_TARGETING_KEYS is defined as a subset of CONSTANTS.TARGETING_KEYS. When a publisher defines targetingControls.allowTargetingKeys, this replaces the constant CONSTANTS.DEFAULT_TARGETING_KEYS and can include optional keys defined in CONSTANTS.TARGETING_KEYS. One example of this would be to make hb_adomain part of the default set.

To accomplish this, Prebid does the following:

• Collect original targeting generated by the auction.
• Generate new targeting filtered against allowed keys.
  • Custom targeting keys are always added to targeting.
  • Default targeting keys are added to targeting only if they match an allowed key named in setConfig.
• New targeting replaces original targeting before targeting is flattened.

The targeting key names and the associated prefix value filtered by allowTargetingKeys:

Below is an example config of allowTargetingKeys excluding all default targeting keys except hb_bidder, hb_adid, and hb_pb:

config.setConfig({
  targetingControls: {
    allowTargetingKeys: ['BIDDER', 'AD_ID', 'PRICE_BUCKET']
  }
});

Another example config showing the addition of hb_adomain and excluding all default targeting keys except hb_bidder, hb_adid, hb_size and hb_pb:

config.setConfig({
  targetingControls: {
    allowTargetingKeys: ['BIDDER', 'AD_ID', 'PRICE_BUCKET', 'SIZE', 'ADOMAIN']
  }
});

Details on the addTargetingKeys setting

The addTargetingKeys config is similar to allowTargetingKeys, except it adds to the keys in CONSTANTS.DEFAULT_TARGETING_KEYS instead of replacing them. This is useful if you need Prebid.js to generate targeting for some keys that are not allowed by default without removing any of the default ones (see allowTargetingKeys for details on how targeting is generated).

Note that you may specify only one of allowTargetingKeys or addTargetingKeys.

For example, this allows every default key, plus hb_adomain:

config.setConfig({
    targetingControls: {
        addTargetingKeys: ['ADOMAIN']
    }
});

Which is equivalent to:

config.setConfig({
    targetingControls: {
        allowTargetingKeys: [
            'BIDDER',
            'AD_ID',
            'PRICE_BUCKET',
            'SIZE',
            'DEAL',
            'FORMAT',
            'UUID',
            'CACHE_HOST',
            'title',
            'body',
            'body2',
            'privacyLink',
            'privacyIcon',
            'sponsoredBy',
            'image',
            'icon',
            'clickUrl',
            'displayUrl',
            'cta',
            'rating',
            'address',
            'downloads',
            'likes',
            'phone',
            'price',
            'salePrice',
            'rendererUrl',
            'adTemplate',
            'ADOMAIN'
        ]
    }
});

Details on the allowSendAllBidsTargetingKeys setting

The allowSendAllBidsTargetingKeys is similar to allowTargetingKeys except it limits any default bidder specific keys sent to the adserver when sendAllBids is enabled. Any default bidder specific keys that do not match the mask will not be sent to the adserver. This setting can be helpful if you find that your default Prebid.js implementation is sending key values that your adserver isn’t configured to process; extraneous key values may lead to the ad server request being truncated, which can cause potential issues with the delivery or rendering ads. An example of an extraneous key value many publishers may find redundant and want to remove is hb_bidder_biddercode = biddercode.

Below is an example config of allowSendAllBidsTargetingKeys excluding all default send all bids targeting keys except hb_adid_biddercode, hb_pb_biddercode:

config.setConfig({
  targetingControls: {
    allowSendAllBidsTargetingKeys: ['AD_ID', 'PRICE_BUCKET'],
  },
});

Configure Responsive Ads

See the size mapping or advanced size mapping modules.

COPPA

Bidder adapters that support the Child Online Privacy Protection Act (COPPA) read the coppa configuration. Publishers with content falling under the scope of this regulation should consult with their legal teams. The flag may be passed to supporting adapters with this config:

pbjs.setConfig({coppa: true});

First Party Data

The First Party Data feature allows publishers to specify key/value data in one place where each compatible bid adapter can read it. See the First Party Data Feature for more detailed examples.

Not all bid adapters currently support reading first party data in this way, but support should increase over time.

Scenario 1 - Global (cross-adunit) First Party Data open to all bidders

pbjs.setConfig({
   ortb2: {
       site: {
         // ...
       },
       user: {
         // ...
       }
    }
});

The ortb2 JSON structure reflects the OpenRTB standard:

• Fields that like keywords, search, content, gender, yob, and geo are values defined in OpenRTB, so should go directly under the site or user objects.
• Arbitrary values should go in site.ext.data or user.ext.data.
• Segments should go in site.content.data[] or user.data[].
• Any other OpenRTB 2.5 field could be added here as well, e.g. site.content.language.

Scenario 2 - Auction (cross-adunit) First Party Data open to all bidders

If a page needs to specify multiple different sets of top-level data (site, user, or app), use the ortb2 parameter of requestBids (example

Scenario 3 - Global (cross-adunit) First Party Data open only to a subset of bidders

If a publisher only wants certain bidders to receive the data, use the setBidderConfig function.

Scenario 4 - AdUnit-specific First Party Data

See the AdUnit Reference for AdUnit-specific first party data.

See Prebid Server First Party Data for details about passing data server-side.

Video Module to integrate with Video Players

The Prebid Video Module allows Prebid to directly integrate with a Video Player, allowing Prebid to automatically load the winning ad into the player, mark bids as won, fill the video and content oRTB params in the bid request, surface video analytics, and more. For more information please visit the Video Module docs.
To register a video player with Prebid, you must use setConfig to set a video config compliant with the following structure:

Note: You can integrate with different Player vendors. For this to work, you must ensure that the right Video Submodules are included in your build, and that the providers have the right vendorCodes and divIds.

Player Integration Example

Assuming your page has 2 JW Player video players, 1 video.js video player, and your ad server is GAM.

pbjs.setConfig({
    video: {
        providers: [{
            vendorCode: 1, // constant variable is JWPLAYER_VENDOR - see vendorCodes.js in the video library
            divId: 'jwplayer-div-1',
            playerConfig: {
                autoStart: true,
            }
        }, {
            vendorCode: 2, // constant variable is VIDEO_JS_VENDOR - see vendorCodes.js in the video library
            divId: 'videojs-div',
            playerConfig: {
                params : {
                    adPluginConfig: {
                        numRedirects: 10
                    },
                    vendorConfig: {
                        controls: true,
                        preload: "auto",
                    }
                }
            }
        }, {
            vendorCode: 1, // constant variable is JWPLAYER_VENDOR - see vendorCodes.js in the video library
            divId: 'jwplayer-div-2',
            playerConfig: {
                mute: true
            }
        }],
        adServer: {
            vendorCode: 'gam', // constant variable is GAM_VENDOR - see vendorCodes.js in the video library
            baseAdTagUrl: 'https://pubads.g.doubleclick.net/gampad/ads?iu=/12345/'
        }
    }
});

Client-side Caching of VAST XML

When serving video ads, VAST XML creatives must be cached on the network so the video player can retrieve them when it’s ready. Players don’t obtain the VAST XML from the JavaScript DOM in Prebid.js, but rather expect to be given a URL where it can be retrieved. There are two different flows possible with Prebid.js around VAST XML caching:

• Server-side caching:
  Some video bidders (e.g. Rubicon Project) always cache the VAST XML on their servers as part of the bid. They provide a ‘videoCacheKey’, which is used in conjunction with the VAST URL in the ad server to retrieve the correct VAST XML when needed. In this case, Prebid.js has nothing else to do. As of Prebid.js 4.28, a publisher may specify the ignoreBidderCacheKey flag to re-cache these bids somewhere else using a VAST wrapper.
• Client-side caching:
  Video bidders that don’t cache on their servers return the entire VAST XML body. In this scenario, Prebid.js needs to copy the VAST XML to a publisher-defined cache location on the network. Prebid.js POSTs the VAST XML to the named Prebid Cache URL. It then sets the ‘videoCacheKey’ to the key that’s returned in the response.

Here’s an example of basic client-side caching. Substitute your Prebid Cache URL as needed:

pbjs.setConfig({
        cache: {
            url: 'https://prebid.adnxs.com/pbc/v1/cache'
        }
});

The endpoint URL provided must be a Prebid Cache or be otherwise compatible with the Prebid Cache interface.

As of Prebid.js 4.28, you can specify the ignoreBidderCacheKey option:

pbjs.setConfig({
        cache: {
            url: 'https://my-pbs.example.com/cache',
            ignoreBidderCacheKey: true
        }
});

As of Prebid.js 2.36, you can track client-side cached VAST XML. This functionality is useful for publishers who want to allow their analytics provider to measure video impressions. The prerequisite to using this feature is the availability of a Prebid Server that supports:

• the /vtrack endpoint
• an analytics module with connection to an analytics system that supports joining the impression event to the original auction request on the bidid
• the ability of a publisher to utilize the feature (if account-level permission is enabled)

Given those conditions, the vasttrack flag can be specified:

pbjs.setConfig({
        cache: {
            url: 'https://my-pbs.example.com/vtrack',
            vasttrack: true
        }
});

Setting the vasttrack parameter to true supplies the POST made to the /vtrack Prebid Server endpoint with a couple of additional parameters needed by the analytics system to join the event to the original auction request.

Optionally, batchSize and batchTimeout can be utlilized as illustrated with the example below:

pbjs.setConfig({
        cache: {
            url: 'https://prebid.adnxs.com/pbc/v1/cache',
            batchSize: 4,
            batchTimeout: 50
        }
});

The example above states that a timer will be initialized and wait up to 50ms for 4 responses to have been collected and then will fire off one batch video cache request for all 4 responses. Note that the batch request will be made when the specified batchSize number is reached or with the number of responses that could be collected within the timeframe specified by the value for batchTimeout.

If a batchSize is set to 2 and 5 video responses arrive (within the timeframe specified by batchTimeout), then three batch requests in total will be made:

1. Batch 1 will contain cache requests for 2 videos
2. Batch 2 will contain cache requests for 2 videos
3. Batch 3 will contain cache requests for 1 video

Instream tracking

To enable this tracking, include the instreamTracking module in your Prebid.js build.

This configuration will allow Analytics Adapters and Bid Adapters to track BID_WON events for Instream video bids.

Instream Tracking Example

pbjs.setConfig({
        'instreamTracking': {
            enabled: true,
        }
});

More examples here.

Site Configuration

Adapters, including Prebid Server adapters, can support taking site parameters like language. Just set the ortb2.site object as First Party Data to make it available to client- and server-side adapters.

pbjs.setConfig({
  ortb2: {
    site: {
       content: {
           language: "en"
       }
    }
  }
});

In PBJS 4.29 and earlier, don’t add the ortb2 level here – just site directly. Oh, and please upgrade. 4.29 was a long time ago.

Auction Options

The auctionOptions object controls aspects related to auctions.

Examples

Exclude status of bidder doNotWaitForMe when checking auction completion.

pbjs.setConfig({
    'auctionOptions': {
        'secondaryBidders': ['doNotWaitForMe']
    }
});

Render winning bids only once.

pbjs.setConfig({
    'auctionOptions': {
        'suppressStaleRender': true
    }
});

More on Stale Rendering

When auto-refreshing is done incorrectly, it could cause the same bids to be rendered repeatedly. For instance, when googletag.pubads.refresh() is called directly without removing the PBJS targeting, the same hb_ variables get re-sent to GAM, re-chosen, and re-rendered. Over and over without ever asking PBJS for updated targeting variables.

PBJS performs following actions when stale rendering is detected.

• Log a warning in the browser console if pbjs_debug=true.
• Emit a STALE_RENDER event before BID_WON event.

Stale winning bids will continue to be rendered unless suppressStaleRender is set to true. Events including STALE_RENDER and BID_WON are unaffected by this option.

maxNestedIframes

Prebid.js will loop upward through nested iframes to find the top-most referrer. This setting limits how many iterations it will attempt before giving up and not setting referrer.

pbjs.setConfig({
    maxNestedIframes: 5   // default is 10
});

Real-Time Data Modules

All of the modules that fall under the Real-Time Data (RTD) category conform to a consistent set of publisher controls. The pub can choose to run multiple RTD modules, define an overall amount of time they’re willing to wait for results, and even flag some of the modules as being more “important” than others.

pbjs.setConfig({
    // ...,
    realTimeData: {
      auctionDelay: 100,     // OPTIONAL: applies to all RTD modules.
      dataProviders: [{
          name: "RTD-MODULE-1",
          waitForIt: true,   // OPTIONAL: flag this module as important
          params: {
            // ... module-specific parameters ...
          }
      },{
          name: "RTD-MODULE-2",
          waitForIt: false,   // OPTIONAL: flag this module as less important
          params: {
            //... module-specific parameters ...
          }
      }]
    }
});

The controls publishers have over the RTD modules:

The idea behind the waitForIt flag is that publishers can decide which modules are worth waiting for and which better hustle. For example, imagine a bus stop: the bus driver will wait up to 100ms for a few important passengers: A, J, and X. Once these three passengers are on the bus, it will leave immediately, even if 100ms hasn’t been reached. Other potential passengers need to be on before these three or they will be left behind. If A, J, or X doesn’t get on the bus before the 100ms are up, they, too, will be left behind.

This may not seem fair, but keep in mind that speed has a significant impact on ad performance: header bidding gets only a small amount of time to run the auction before the ad server is called. Some publishers carefully manage these precious milliseconds, balancing impact of the real-time data with the revenue loss from auction delay.

Notes:

• The only time waitForIt means anything is if some modules are flagged as true and others as false. If all modules are the same (true or false), it has no effect.
• Likewise, waitForIt doesn’t mean anything without an auctionDelay specified.

Topics Iframe Configuration

Topics iframe implementation is the enhancements of existing module under topicsFpdModule.js where different bidders will call the topic API under their domain to fetch the topics for respective domain and the segment data will be part of ORTB request under user.data object. Default config is maintained in the module itself. Below are the configuration which can be used to configure and override the default config maintained in the module.

pbjs.setConfig({
    userSync: {
        ...,
        topics: { 
            maxTopicCaller: 3, // SSP rotation 
            bidders: [{
                bidder: 'pubmatic',
                iframeURL: 'https://ads.pubmatic.com/AdServer/js/topics/topics_frame.html',
                expiry: 7 // Configurable expiry days
            },{
                bidder: 'rubicon',
                iframeURL: 'https://rubicon.com:8080/topics/fpd/topic.html', // dummy URL
                expiry: 7 // Configurable expiry days
            },{
                bidder: 'appnexus',
                iframeURL: 'https://appnexus.com:8080/topics/fpd/topic.html', // dummy URL
                expiry: 7 // Configurable expiry days
            }]
        }
        ....
    }
})

Disable performance metrics

Since version 7.17, Prebid collects fine-grained performance metrics and attaches them to several events for the purpose of analytics. If you find that this generates too much data for your analytics provider you may disable this feature with:

pbjs.setConfig({performanceMetrics: false})

Setting alias registry to private

The alias registry is made public by default during an auction. It can be referenced in the following way:

pbjs.aliasRegistry or pbjs.aliasRegistry[aliasName];

Inversely, if you wish for the alias registry to be private you can do so by using the option below (causing pbjs.aliasRegistry to return undefined):

pbjs.setConfig({aliasRegistry: 'private'})

Set Max Bid

Prebid ensures that the bid response price doesn’t exceed the maximum bid. If the CPM (after currency conversion) is higher than the maxBid, the bid is rejected. The default maxBid value is 5000. You can adjust maxBid with:

pbjs.setConfig({ 
  maxBid: 10  
});

General adapter Configuration

Some adapters may support other options, as defined in their documentation. To set arbitrary configuration values:

pbjs.setConfig({ <key>: <value> });

Troubleshooting your configuration

Towards catching syntax errors, one tip is to call pbjs.setConfig without an object, e.g.,

pbjs.setConfig('debug', 'true');

then Prebid.js will print an error to the console that says:

ERROR: setConfig options must be an object

If you don’t see that message, you can assume the config object is valid.

Back to Publisher API Reference