The User ID module supports multiple ways of establishing pseudonymous IDs for users, which is an important way of increasing the value of header bidding. Instead of having several exchanges sync IDs with dozens of demand sources, a publisher can choose to integrate with one of these ID schemes:
setConfig()is called, and if the user has consented to storing IDs locally, the module is invoked to call the URL if needed
Note that User IDs aren’t needed in the mobile app world because device ID is available in those ad serving scenarios.
Also note that not all bidder adapters support all forms of user ID. See the tables below for a list of which bidders support which ID schemes.
While the Unified ID approach is open to other cookie vendors, the only one currently supporting Prebid.js is The Tradedesk. Prebid.org welcomes other ID vendors - create a PR or email email@example.com.
When paired with the
CookieConsent module, privacy rules are enforced:
You can get set up for Unified ID in one of these ways:
1) Publisher has a partner ID with The TradeDesk, and is using the default endpoint for Unified ID.
2) Publisher supports UnifiedID with a vendor other than Tradedesk, HTML5 local storage, and wants to delay the auction up to 250ms to obtain the user ID:
3) Publisher has integrated with unifiedID on their own and wants to pass the unifiedID directly through to Prebid.js
4) Publisher supports PubCommonID and first party domain cookie storage
5) Publisher supports both unifiedID and PubCommonID and first party domain cookie storage
By including this module, the following options become available in
all of them under the
usersync object as attributes of the
of sub-objects. See the examples above for specific use cases.
|Param under usersync.userIds||Scope||Type||Description||Example|
|params||Required for unifiedId||Object||Details for unifiedId.|
|params.partner||Required if using Tradedesk||String||This is the partner ID value obtained from registering with The TradeDesk.||
|params.url||Required if not using TradeDesk||String||If specified for unifiedId, overrides the default Tradedesk URL.||“https://unifiedid.org/somepath?args”|
||Object||The publisher must specify some kind of local storage in which to store the results of the call to get the user ID. This can be either cookie or HTML5 storage.|
|storage.type||Required||String||Must be either
|storage.name||Required||String||The name of the cookie or html5 local storage where the user ID will be stored.||
|storage.expires||Optional||Integer||How long (in days) the user ID information will be stored. Default is 30 for unifiedId and 1825 for PubCommonID||
|value||Optional||Object||Used only if the page has a separate mechanism for storing the unified ID. The value is an object containing the values to be sent to the adapters. In this scenario, no URL is called and nothing is added to local storage||
For bidders that want to support one or more of these ID systems, and for publishers who want to understand their options, here are the specific details.
|ID System Name||ID System Host||Prebid.js Attr||Prebid Server Attr||Notes|
|PubCommon ID||n/a||bidRequest.userIds.pubcid||user.ext.tpid.source=”pubcid”||PubCommon is unique to each publisher domain.|
If you’re an ID provider that want to get on this list, feel free to submit a PR or an Issue.
If you’re bidder that wants to support the User ID module in Prebid.js, you’ll need to update your bidder adapter to read the indicated bidRequest attributes.
If you’re bidder that wants to support the User ID module in Prebid Server, you’ll n eed to update your server-side bid adapter to read the indicated OpenRTB attributes. For example: