",
timeout: 1500,
- bidders: ["appnexus", "rubicon", "pubmatic"],
+ bidders: ["msft", "rubicon", "pubmatic"],
includeKey: "axei",
excludeKey: "axex",
macroKey: "axem",
@@ -105,7 +105,7 @@ The Scope3 AEE returns signals in this format:
"exclude": ["competitor_exposed"],
"macro": "eyJjb250ZXh0IjogImhpZ2hfdmFsdWUifQ==",
"bidders": {
- "appnexus": {
+ "msft": {
"segments": ["seg1", "seg2"],
"deals": ["DEAL123"]
},
diff --git a/dev-docs/modules/sirdataRtdProvider.md b/dev-docs/modules/sirdataRtdProvider.md
index 724a036dac..0e10ca0f00 100644
--- a/dev-docs/modules/sirdataRtdProvider.md
+++ b/dev-docs/modules/sirdataRtdProvider.md
@@ -125,7 +125,7 @@ Bidders can receive common setting :
As indicated above, it is possible to provide your own bid augmentation functions. This is useful if you know a bid adapter's API supports segment fields which aren't specifically being added to request objects in the Prebid bid adapter.
-Please see the following example, which provides a function to modify bids for a bid adapter called ix and overrides the appnexus.
+Please see the following example, which provides a function to modify bids for a bid adapter called ix and overrides the msft.
data Object format for usage in this kind of function :
```json
@@ -182,7 +182,7 @@ data Object format for usage in this kind of function :
```
```javascript
-function overrideAppnexus (adUnit, segmentsArray, dataObject, bid) {
+function overrideMsft (adUnit, segmentsArray, dataObject, bid) {
for (var i = 0; i < segmentsArray.length; i++) {
if (segmentsArray[i]) {
bid.params.user.segments.push(segmentsArray[i]);
@@ -205,8 +205,8 @@ pbjs.setConfig({
contextualMinRelevancyScore: 50, //Min score to keep contextual category in the bidders (0-100 scale)
actualUrl: actual_url, //top location url, for contextual categories
bidders: [{
- bidder: 'appnexus',
- customFunction: overrideAppnexus,
+ bidder: 'msft',
+ customFunction: overrideMsft,
curationId: '111'
},{
bidder: 'ix',
@@ -227,7 +227,7 @@ pbjs.setConfig({
To view an example of available segments returned by Sirdata's backends:
```bash
-gulp serve --modules=rtdModule,sirdataRtdProvider,appnexusBidAdapter
+gulp serve --modules=rtdModule,sirdataRtdProvider,msftBidAdapter
```
and then point your browser at:
diff --git a/dev-docs/modules/symitriDapRtdProvider.md b/dev-docs/modules/symitriDapRtdProvider.md
index 66211f6908..ab93999dae 100644
--- a/dev-docs/modules/symitriDapRtdProvider.md
+++ b/dev-docs/modules/symitriDapRtdProvider.md
@@ -107,7 +107,7 @@ pbjs.setConfig({
To view an example of available segments returned by dap:
```bash
-gulp serve --modules=rtdModule,symitriDapRtdProvider,appnexusBidAdapter,sovrnBidAdapter
+gulp serve --modules=rtdModule,symitriDapRtdProvider,msftBidAdapter,sovrnBidAdapter
```
and then point your browser at:
diff --git a/dev-docs/modules/weboramaRtdProvider.md b/dev-docs/modules/weboramaRtdProvider.md
index f558c47da3..1d21923776 100644
--- a/dev-docs/modules/weboramaRtdProvider.md
+++ b/dev-docs/modules/weboramaRtdProvider.md
@@ -219,16 +219,16 @@ This property support the following types
| Type | Description | Example | Notes |
| :------------ | :------------ | :------------ |:------------ |
| Boolean|If true, send data to all bidders, or not in case of false| `true` | default value |
-| String|Will send data to only one bidder | `'appnexus'` | |
-| Array of Strings|Will send data to only some bidders | `['appnexus','pubmatic']` | |
-| Object |Will send data to only some bidders and some ad units | `{appnexus: true, pubmatic:['adUnitCode1']}` | |
-| Callback |Will be executed for each adunit, expects return a true value to set prebid targeting or not| `function(bid, adUnitCode){return bid.bidder == 'appnexus' && adUnitCode == 'adUnitCode';}` | |
+| String|Will send data to only one bidder | `'msft'` | |
+| Array of Strings|Will send data to only some bidders | `['msft','pubmatic']` | |
+| Object |Will send data to only some bidders and some ad units | `{msft: true, pubmatic:['adUnitCode1']}` | |
+| Callback |Will be executed for each adunit, expects return a true value to set prebid targeting or not| `function(bid, adUnitCode){return bid.bidder == 'msft' && adUnitCode == 'adUnitCode';}` | |
A better look on the `Object` type
```javascript
sendToBidders: {
- appnexus: true, // send profile to appnexus on all ad units
+ msft: true, // send profile to msft on all ad units
pubmatic: ['adUnitCode1'],// send profile to pubmatic on this ad units
}
```
@@ -254,8 +254,8 @@ It is possible customize the targeting based on the parameters:
```javascript
sendToBidders: function(bid, adUnitCode, data, metadata){
- if (bid.bidder == 'appnexus' && adUnitCode == 'adUnitCode1'){
- data['foo']=['bar']; // add this section only for appnexus + adUnitCode1
+ if (bid.bidder == 'msft' && adUnitCode == 'adUnitCode1'){
+ data['foo']=['bar']; // add this section only for msft + adUnitCode1
delete data['other']; // remove this section
}
return true;
@@ -282,7 +282,7 @@ sendToBidders: function(bid, adUnitCode, data, metadata){
In case of using bid _aliases_, we should match the same string used in the adUnit configuration.
```javascript
-pbjs.aliasBidder('appnexus', 'foo');
+pbjs.aliasBidder('msft', 'foo');
pbjs.aliasBidder('criteo', 'bar');
pbjs.aliasBidder('pubmatic', 'baz');
pbjs.setConfig({
@@ -503,7 +503,7 @@ pbjs.que.push(function () {
weboCtxConf: {
token: "to-be-defined", // mandatory
setPrebidTargeting: ['adUnitCode1',...], // set target only on certain adunits
- sendToBidders: ['appnexus',...], // overide, send to only some bidders
+ sendToBidders: ['msft',...], // overide, send to only some bidders
enabled: true,
},
weboUserDataConf: {
@@ -553,7 +553,7 @@ pbjs.que.push(function () {
token: "to-be-defined", // mandatory
targetURL: "https://prebid.org", // default is document.URL
setPrebidTargeting: true, // override param.setPrebidTargeting or default true
- sendToBidders: ['appnexus',...], // overide, send to only some bidders
+ sendToBidders: ['msft',...], // overide, send to only some bidders
defaultProfile: { // optional
webo_ctx: ['moon'],
webo_ds: ['bar']
@@ -565,7 +565,7 @@ pbjs.que.push(function () {
accountId: 12345, // recommended
setPrebidTargeting: ['adUnitCode1',...], // set target only on certain adunits
sendToBidders: { // send to only some bidders and adunits
- 'appnexus': true, // all adunits for appnexus
+ 'msft': true, // all adunits for msft
'pubmatic': ['adUnitCode1',...] // some adunits for pubmatic
// other bidders will be ignored
},
@@ -582,7 +582,7 @@ pbjs.que.push(function () {
return adUnitCode == 'adUnitCode1';
},
sendToBidders: function(bid, adUnitCode){ // specify sendToBidders via callback
- return bid.bidder == 'appnexus' && adUnitCode == 'adUnitCode1';
+ return bid.bidder == 'msft' && adUnitCode == 'adUnitCode1';
}
defaultProfile: { // optional
lite_occupation: ['gérant', 'bénévole'],
@@ -603,7 +603,7 @@ pbjs.que.push(function () {
We currently support the following bidder adapters with dedicated code:
-* AppNexus SSP
+* Microsoft SSP
We also set the bidder (and global, if no specific bidders are set on `sendToBidders`) ortb2 `site.ext.data` and `user.ext.data` sections (as arbitrary data). The following bidders may support it, to be sure, check the `First Party Data Support` on the feature list for the particular bidder from [here](https://docs.prebid.org/dev-docs/bidders).
@@ -645,7 +645,7 @@ We also set the bidder (and global, if no specific bidders are set on `sendToBid
To view an example of available segments returned by Weborama's backends:
-`gulp serve --notest --nolint --modules=rtdModule,weboramaRtdProvider,smartadserverBidAdapter,pubmaticBidAdapter,appnexusBidAdapter,rubiconBidAdapter,criteoBidAdapter`
+`gulp serve --notest --nolint --modules=rtdModule,weboramaRtdProvider,smartadserverBidAdapter,pubmaticBidAdapter,msftBidAdapter,rubiconBidAdapter,criteoBidAdapter`
and then point your browser at:
diff --git a/dev-docs/modules/wurflRtdProvider.md b/dev-docs/modules/wurflRtdProvider.md
index 4721c0ea3e..93f4e86308 100644
--- a/dev-docs/modules/wurflRtdProvider.md
+++ b/dev-docs/modules/wurflRtdProvider.md
@@ -100,7 +100,7 @@ While the WURFL RTD module enriches the OpenRTB 2.0 payload, SSP adapters must a
To build the WURFL RTD module with Prebid.js:
```bash
-gulp build --modules="wurflRtdProvider,appnexusBidAdapter,..."
+gulp build --modules="wurflRtdProvider,msftBidAdapter,..."
```
## Configuration
@@ -137,7 +137,7 @@ pbjs.setConfig({
To test the WURFL RTD module locally:
```bash
-gulp serve --modules=wurflRtdProvider,appnexusBidAdapter
+gulp serve --modules=wurflRtdProvider,msftBidAdapter
```
Then navigate to:
diff --git a/dev-docs/plugins/bc/about-bc-prebid-plugin.md b/dev-docs/plugins/bc/about-bc-prebid-plugin.md
index 98f24954ca..f36746c00a 100644
--- a/dev-docs/plugins/bc/about-bc-prebid-plugin.md
+++ b/dev-docs/plugins/bc/about-bc-prebid-plugin.md
@@ -29,9 +29,9 @@ The Brightcove Prebid Plugin supports the following features:
* Single Ad Playback via VAST XML at one or more ad break positions within a video. (For example, you can specify options for a preroll and a postroll ad in a single call to the plugin.)
* Versions up thru VAST 3.0
* Both Video and VPAID creatives
- * If the AppNexus Viewability Wrapper is delivered:
- * AppNexus viewability measurement
- * AppNexus domain detection
+ * If the Microsoft Viewability Wrapper is delivered:
+ * Microsoft viewability measurement
+ * Microsoft domain detection
* The plugin supports more than one ad renderer by default.
* If Google Ad Manager is detected as the primary ad server (indicated by the presence of dfpParameters) for *any* of the ad breaks specified in the Prebid options, then the Brightcove IMA Plugin will be used to render the ad.
diff --git a/dev-docs/plugins/bc/bc-prebid-plugin-api.md b/dev-docs/plugins/bc/bc-prebid-plugin-api.md
index d9be241b21..19c99c263f 100644
--- a/dev-docs/plugins/bc/bc-prebid-plugin-api.md
+++ b/dev-docs/plugins/bc/bc-prebid-plugin-api.md
@@ -123,9 +123,9 @@ If the results of the prebid process is being determined outside of the plugin,
}
},
"bids": [{
- "bidder": "appnexus",
+ "bidder": "msft",
"params": {
- "placementId": 8845778
+ "placement_id": 8845778
}
}]
},
diff --git a/dev-docs/plugins/bc/bc-prebid-plugin-integration-dynamic.md b/dev-docs/plugins/bc/bc-prebid-plugin-integration-dynamic.md
index 0a4e4af9dc..72909a5b17 100644
--- a/dev-docs/plugins/bc/bc-prebid-plugin-integration-dynamic.md
+++ b/dev-docs/plugins/bc/bc-prebid-plugin-integration-dynamic.md
@@ -66,16 +66,16 @@ Once the Brightcove Player has loaded, then publisher needs to call `renderAd()`
// define options for ad playback
window.bc_plugin_pbjs = {plugin_prebid_options: {}};
// specify prebid parameters as the value of biddersSpec
- // the set of bidders here shows how to specify the AppNexus video bidder: appnexus
+ // the set of bidders here shows how to specify the Microsoft video bidder: msft
var params = {
code : 'my-video-tag',
sizes : [640, 480],
mediaType: 'video',
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 12334567,
+ placement_id: 12334567,
video: {
skippable: true,
playback_method: ['auto_play_sound_off']
@@ -172,16 +172,16 @@ To do this, the publisher must add code in the body of the document where the Br
// define options for prebid
var plugin_options = {};
// specify prebid parameters as the value of biddersSpec
- // the set of bidders here shows how to specify the AppNexus video bidder: appnexus
+ // the set of bidders here shows how to specify the Microsoft video bidder: msft
var params = {
code : 'my-video-tag',
sizes : [640, 480],
mediaType: 'video',
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 12334567,
+ placement_id: 12334567,
video: {
skippable: true,
playback_method: ['auto_play_sound_off']
diff --git a/dev-docs/plugins/bc/bc-prebid-plugin-integration-studio.md b/dev-docs/plugins/bc/bc-prebid-plugin-integration-studio.md
index d7f53f6e03..d5fb9c78a1 100644
--- a/dev-docs/plugins/bc/bc-prebid-plugin-integration-studio.md
+++ b/dev-docs/plugins/bc/bc-prebid-plugin-integration-studio.md
@@ -143,9 +143,9 @@ var adOptions =
}
},
"bids": [{
- "bidder": "appnexus",
+ "bidder": "msft",
"params": {
- "placementId": 8845778
+ "placement_id": 8845778
}
}]
},
@@ -252,7 +252,7 @@ None
"bidderAliases": [
{
"name": "alias1",
- "bidderName": "appnexus"
+ "bidderName": "msft"
}
],
"biddersSpec": {
@@ -268,9 +268,9 @@ None
}
},
"bids": [{
- "bidder": "appnexus",
+ "bidder": "msft",
"params": {
- "placementId": 8845778,
+ "placement_id": 8845778,
"video": {"skippable": true,
"playback_method":
["auto_play_sound_off"]
@@ -329,7 +329,7 @@ None
}
]
},
- "appnexus": {
+ "msft": {
"adserverTargeting": [
{
"key": "hb_size",
diff --git a/dev-docs/plugins/bc/bc-prebid-plugin-multiad-options.md b/dev-docs/plugins/bc/bc-prebid-plugin-multiad-options.md
index 7edbfcf383..2651465f7b 100644
--- a/dev-docs/plugins/bc/bc-prebid-plugin-multiad-options.md
+++ b/dev-docs/plugins/bc/bc-prebid-plugin-multiad-options.md
@@ -58,9 +58,9 @@ The following is a sample JSON definition of the plugin configuration defining c
},
"bids": [
{
- "bidder": "appnexus",
+ "bidder": "msft",
"params": {
- "placementId": 12527596
+ "placement_id": 12527596
}
}
]
@@ -153,9 +153,9 @@ The following is a sample JSON definition of the plugin configuration defining c
},
"bids": [
{
- "bidder": "appnexus",
+ "bidder": "msft",
"params": {
- "placementId": 12531984
+ "placement_id": 12531984
}
}
]
@@ -259,9 +259,9 @@ The following is a sample JSON definition of the plugin configuration defining c
},
"bids": [
{
- "bidder": "appnexus",
+ "bidder": "msft",
"params": {
- "placementId": 12527596
+ "placement_id": 12527596
}
}
]
@@ -355,9 +355,9 @@ The following is a sample JSON definition of the plugin configuration defining c
},
"bids": [
{
- "bidder": "appnexus",
+ "bidder": "msft",
"params": {
- "placementId": 12531984
+ "placement_id": 12531984
}
}
]
@@ -451,9 +451,9 @@ The following is a sample JSON definition of the plugin configuration defining c
},
"bids": [
{
- "bidder": "appnexus",
+ "bidder": "msft",
"params": {
- "placementId": 12531977
+ "placement_id": 12531977
}
}
]
diff --git a/dev-docs/plugins/bc/bc-prebid-plugin-prebid-options.md b/dev-docs/plugins/bc/bc-prebid-plugin-prebid-options.md
index 0c28b7e060..1635d26d5b 100644
--- a/dev-docs/plugins/bc/bc-prebid-plugin-prebid-options.md
+++ b/dev-docs/plugins/bc/bc-prebid-plugin-prebid-options.md
@@ -129,11 +129,11 @@ None
```javascript
"bidderAliases": [
{
- "bidderName": "appnexus",
+ "bidderName": "msft",
"name": "alias1"
},
{
- "bidderName": "appnexus",
+ "bidderName": "msft",
"name": "alias2"
}
]
@@ -610,7 +610,7 @@ No
The publisher must pass the prebid parameters to the plugin, via the `biddersSpec` option, if the plugin is expected to invoke the prebid process. The syntax for these parameters is defined in [Bidders' Params]({{site.baseurl}}/dev-docs/bidders.html) on Prebid.org.
-Use the parameters for AppNexus bidder to include an AppNexus bidder for video ads.
+Use the parameters for Microsoft bidder to include an Microsoft bidder for video ads.
If these parameters are not specified, the plugin assumes that the prebid process has occurred outside of the plugin and that the results of the header bidding will be provided to the plugin via the `headerBiddingResult` option.
diff --git a/dev-docs/plugins/bc/bc-prebid-plugin-sample-prebid-body.md b/dev-docs/plugins/bc/bc-prebid-plugin-sample-prebid-body.md
index 9a5970d373..32b2e94391 100644
--- a/dev-docs/plugins/bc/bc-prebid-plugin-sample-prebid-body.md
+++ b/dev-docs/plugins/bc/bc-prebid-plugin-sample-prebid-body.md
@@ -69,16 +69,16 @@ The following is a sample Brightcove Player Prebid Plugin integration that invok
// set the prebid options
// specify prebid parameters as the value of biddersSpec
- // the set of bidders here shows how to specify the AppNexus video bidder: appnexus
+ // the set of bidders here shows how to specify the Microsoft video bidder: msft
var params = {
code : 'my-video-tag',
sizes : [640, 480],
mediaType: 'video',
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 12334567,
+ placement_id: 12334567,
video: {
skippable: true,
playback_method: ['auto_play_sound_off']
diff --git a/dev-docs/plugins/bc/bc-prebid-plugin-sample-prebid-header.md b/dev-docs/plugins/bc/bc-prebid-plugin-sample-prebid-header.md
index 11062bc016..6f35b5d230 100644
--- a/dev-docs/plugins/bc/bc-prebid-plugin-sample-prebid-header.md
+++ b/dev-docs/plugins/bc/bc-prebid-plugin-sample-prebid-header.md
@@ -47,7 +47,7 @@ The following is a sample Brightcove Player Prebid Plugin integration that invok
window.bc_plugin_pbjs = { plugin_prebid_options: {} };
// specify prebid parameters as the value of biddersSpec
- // the set of bidders here shows how to specify the AppNexus video bidder: appnexus
+ // the set of bidders here shows how to specify the Microsoft video bidder: msft
var params = {
code : 'my-video-tag',
mediaTypes: {
@@ -61,9 +61,9 @@ The following is a sample Brightcove Player Prebid Plugin integration that invok
}
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 12334567
+ placement_id: 12334567
}
}
]
diff --git a/dev-docs/plugins/bc/bc-prebid-plugin-sample-studio-integration-general-method.md b/dev-docs/plugins/bc/bc-prebid-plugin-sample-studio-integration-general-method.md
index 6f6ca02132..ef161b5522 100644
--- a/dev-docs/plugins/bc/bc-prebid-plugin-sample-studio-integration-general-method.md
+++ b/dev-docs/plugins/bc/bc-prebid-plugin-sample-studio-integration-general-method.md
@@ -65,9 +65,9 @@ This page presents a sample publisher page using the General Integration Method
}
},
"bids": [{
- "bidder": "appnexus",
+ "bidder": "msft",
"params": {
- "placementId": 8845778
+ "placement_id": 8845778
}
}]
},
diff --git a/dev-docs/plugins/bc/bc-prebid-plugin-sample-third-party-ad-server.md b/dev-docs/plugins/bc/bc-prebid-plugin-sample-third-party-ad-server.md
index 4efd8fb244..e4b92f7962 100644
--- a/dev-docs/plugins/bc/bc-prebid-plugin-sample-third-party-ad-server.md
+++ b/dev-docs/plugins/bc/bc-prebid-plugin-sample-third-party-ad-server.md
@@ -42,16 +42,16 @@ The following is a sample Brightcove Prebid Plugin integration that invokes preb
window.bc_plugin_pbjs = { plugin_prebid_options: {} };
// specify prebid parameters as the value of biddersSpec
- // the set of bidders here shows how to specify the AppNexus video bidder: appnexus
+ // the set of bidders here shows how to specify the Microsoft video bidder: msft
var params = {
code : 'my-video-tag',
sizes : [640, 480],
mediaType: 'video',
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 12334567,
+ placement_id: 12334567,
video: {
skippable: true,
playback_method: ['auto_play_sound_off']
@@ -152,16 +152,16 @@ The following is a sample Brightcove Prebid Plugin integration that invokes preb
// set the prebid options
// specify prebid parameters as the value of biddersSpec
- // the set of bidders here shows how to specify the AppNexus video bidder: appnexus
+ // the set of bidders here shows how to specify the Microsoft video bidder: msft
var params = {
code : 'my-video-tag',
sizes : [640, 480],
mediaType: 'video',
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 12334567,
+ placement_id: 12334567,
video: {
skippable: true,
playback_method: ['auto_play_sound_off']
diff --git a/dev-docs/plugins/cross-player-prebid-component/cross-player-config.md b/dev-docs/plugins/cross-player-prebid-component/cross-player-config.md
index ee65cff4a8..98c9365d14 100644
--- a/dev-docs/plugins/cross-player-prebid-component/cross-player-config.md
+++ b/dev-docs/plugins/cross-player-prebid-component/cross-player-config.md
@@ -109,11 +109,11 @@ None
```javascript
"bidderAliases": [
{
- "bidderName": "appnexus",
+ "bidderName": "msft",
"name": "alias1"
},
{
- "bidderName": "appnexus",
+ "bidderName": "msft",
"name": "alias2"
}
]
@@ -324,9 +324,9 @@ Here is a sample Prebid configuration JSON object returned via URL:
},
"bids": [
{
- "bidder": "appnexus",
+ "bidder": "msft",
"params": {
- "placementId": 9999
+ "placement_id": 9999
}
}
]
@@ -372,10 +372,10 @@ Here is a sample Prebid configuration JSON object returned via URL:
}
]
},
- "appnexus": {
+ "msft": {
"adserverTargeting": [
{
- "key": "hb_appnexus_key1",
+ "key": "hb_msft_key1",
"val": [
"valueIsFunction",
"function (bidResponse) {",
@@ -384,7 +384,7 @@ Here is a sample Prebid configuration JSON object returned via URL:
]
},
{
- "key": "hb_appnexus_key2",
+ "key": "hb_msft_key2",
"val": [
"valueIsFunction",
"function (bidResponse) {",
@@ -393,7 +393,7 @@ Here is a sample Prebid configuration JSON object returned via URL:
]
},
{
- "key": "hb_appnexus_key3",
+ "key": "hb_msft_key3",
"val": "value3"
}
]
diff --git a/dev-docs/publisher-api-reference/addAdUnits.md b/dev-docs/publisher-api-reference/addAdUnits.md
index 4af75f0210..54be615a65 100644
--- a/dev-docs/publisher-api-reference/addAdUnits.md
+++ b/dev-docs/publisher-api-reference/addAdUnits.md
@@ -112,9 +112,9 @@ pbjs.addAdUnits({
},
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13232354
+ placement_id: 13232354
}
}
]
@@ -143,9 +143,9 @@ pbjs.addAdUnits({
}
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13232361
+ placement_id: 13232361
}
}]
});
@@ -167,9 +167,9 @@ pbjs.addAdUnits({
},
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13232361
+ placement_id: 13232361
}
}]
});
@@ -219,9 +219,9 @@ pbjs.addAdUnits({
},
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13144370
+ placement_id: 13144370
}
}
]
diff --git a/dev-docs/publisher-api-reference/aliasBidder.md b/dev-docs/publisher-api-reference/aliasBidder.md
index 590cfc3584..5489c9a52d 100644
--- a/dev-docs/publisher-api-reference/aliasBidder.md
+++ b/dev-docs/publisher-api-reference/aliasBidder.md
@@ -9,11 +9,11 @@ To define an alias for a bidder adapter, call this method at runtime:
```javascript
-pbjs.aliasBidder('appnexus', 'newAlias', optionsObject);
+pbjs.aliasBidder('msft', 'newAlias', optionsObject);
```
-Defining an alias can help avoid user confusion since it's possible to send parameters to the same adapter but in different contexts (e.g, The publisher uses `"appnexus"` for demand and also uses `"newAlias"` which is an SSP partner that uses the `"appnexus"` adapter to serve their own unique demand).
+Defining an alias can help avoid user confusion since it's possible to send parameters to the same adapter but in different contexts (e.g, The publisher uses `"msft"` for demand and also uses `"newAlias"` which is an SSP partner that uses the `"msft"` adapter to serve their own unique demand).
If you define an alias and are using `pbjs.sendAllBids`, you must also set up additional line items in the ad server with keyword targeting that matches the name of the alias. For example:
diff --git a/dev-docs/publisher-api-reference/bidderSettings.md b/dev-docs/publisher-api-reference/bidderSettings.md
index a319828a39..641d33d637 100644
--- a/dev-docs/publisher-api-reference/bidderSettings.md
+++ b/dev-docs/publisher-api-reference/bidderSettings.md
@@ -120,13 +120,13 @@ Note that the existence of `bidderSettings.adserverTargeting.standard` will prev
**Keyword targeting for a specific bidder**
Let’s say the bidder prefers a separate set of line items. You can overwrite the bidder
-settings as the below example for AppNexus shows.
+settings as the below example for Microsoft shows.
*Note that the line item setup has to match the targeting change*
```javascript
pbjs.bidderSettings = {
- appnexus: {
+ msft: {
sendStandardTargeting: false,
adserverTargeting: [
{
@@ -145,7 +145,7 @@ pbjs.bidderSettings = {
}
```
-In other words, the above config sends 2 pairs of key/value strings targeting for every AppNexus bid and for every ad unit. The 1st pair would be `apn_pbMg` => the value of `bidResponse.pbMg`. The 2nd pair would be `apn_adId` => the value of `bidResponse.adId`. See [common bid response parameters](/troubleshooting/troubleshooting-guide.html#common-bid-response-parameters) for bidResponse object documentation.
+In other words, the above config sends 2 pairs of key/value strings targeting for every Microsoft bid and for every ad unit. The 1st pair would be `apn_pbMg` => the value of `bidResponse.pbMg`. The 2nd pair would be `apn_adId` => the value of `bidResponse.adId`. See [common bid response parameters](/troubleshooting/troubleshooting-guide.html#common-bid-response-parameters) for bidResponse object documentation.
Note that sendStandardTargeting is set to false so that the standard Prebid targeting (hb_bidder, etc.) aren't also sent to the ad server.
@@ -322,7 +322,7 @@ pbjs.bidderSettings = {
allowedAlternateBidderCodes: ["groupm"],
[...]
},
- appnexus: {
+ msft: {
allowAlternateBidderCodes: true,
allowedAlternateBidderCodes: ["*"],
bidCpmAdjustment: function(bidCpm, bid){ return bidCpm * .90; },
@@ -336,7 +336,7 @@ pbjs.bidderSettings = {
```
In the above example, `groupm` bid will have a bid adjustment of 80% since the `bidCpmAdjustment` function says so.
-If `appnexus` bids with another bidder code, say `appnexus2`. This bidder code will adjust the bid cpm to 95% because it will apply the `bidCpmAdjustment` function from `standard` setting, since the `bidCpmAdjustment` is missing for given bidder code I.e `appnexus2`
+If `msft` bids with another bidder code, say `msft2`. This bidder code will adjust the bid cpm to 95% because it will apply the `bidCpmAdjustment` function from `standard` setting, since the `bidCpmAdjustment` is missing for given bidder code I.e `msft2`
### 2.11. adjustAlternateBids
@@ -361,7 +361,7 @@ pbjs.bidderSettings = {
bidCpmAdjustment: function(bidCpm, bid){ return bidCpm * .85; },
[...]
},
- appnexus: {
+ msft: {
allowAlternateBidderCodes: true,
allowedAlternateBidderCodes: ["*"],
bidCpmAdjustment: function(bidCpm, bid){ return bidCpm * .90; },
diff --git a/dev-docs/publisher-api-reference/getAdserverTargeting.md b/dev-docs/publisher-api-reference/getAdserverTargeting.md
index 296c69a785..e100db4b8c 100644
--- a/dev-docs/publisher-api-reference/getAdserverTargeting.md
+++ b/dev-docs/publisher-api-reference/getAdserverTargeting.md
@@ -11,7 +11,7 @@ Returns all ad server targeting for all ad units. Note that some bidder's respon
The targeting keys can be configured in [ad server targeting](/dev-docs/publisher-api-reference/bidderSettings.html).
-When [deals are enabled]({{site.baseurl}}/adops/deals.html), the object returned by this method may include a field `hb_deal_BIDDERCODE`, where `BIDDERCODE` is replaced by the name of the bidder, e.g., AppNexus, Rubicon, etc.
+When [deals are enabled]({{site.baseurl}}/adops/deals.html), the object returned by this method may include a field `hb_deal_BIDDERCODE`, where `BIDDERCODE` is replaced by the name of the bidder, e.g., Microsoft, Rubicon, etc.
**Kind**: static method of `pbjs`
@@ -32,10 +32,10 @@ When [deals are enabled]({{site.baseurl}}/adops/deals.html), the object returned
"hb_pb": "1.00"
},
"/9968336/header-bid-tag-2": {
- "hb_bidder": "appnexus",
+ "hb_bidder": "msft",
"hb_adid": "147ac541a",
"hb_pb": "2.50",
- "hb_deal_appnexus": "ABC_123"
+ "hb_deal_msft": "ABC_123"
}
}
```
diff --git a/dev-docs/publisher-api-reference/getAdserverTargetingForAdUnitCodeStr.md b/dev-docs/publisher-api-reference/getAdserverTargetingForAdUnitCodeStr.md
index bd4fe3627a..0e28261df8 100644
--- a/dev-docs/publisher-api-reference/getAdserverTargetingForAdUnitCodeStr.md
+++ b/dev-docs/publisher-api-reference/getAdserverTargetingForAdUnitCodeStr.md
@@ -23,5 +23,5 @@ Returns the query string targeting parameters available at the moment for the sp
```javascript
const targetingStrings = pbjs.getAdserverTargetingForAdUnitCodeStr('div-1');
-// ["hb_bidder=appnexus", "hb_adid=233bcbee889d46d", ...]
+// ["hb_bidder=msft", "hb_adid=233bcbee889d46d", ...]
```
diff --git a/dev-docs/publisher-api-reference/getBidResponses.md b/dev-docs/publisher-api-reference/getBidResponses.md
index 276d9b6f97..a4fce6c82a 100644
--- a/dev-docs/publisher-api-reference/getBidResponses.md
+++ b/dev-docs/publisher-api-reference/getBidResponses.md
@@ -33,7 +33,7 @@ This function returns the bid responses at the given moment.
| `creativeId` | String | Bidder-specific creative ID | `"12345678"` |
| `mediaType` | String | One of: banner, native, video | `banner` |
| `dealId` | String | (Optional) If the bid is [associated with a Deal]({{site.baseurl}}/adops/deals.html), this field contains the deal ID. | "ABC_123" |
-| `adserverTargeting` | Object | Contains all the adserver targeting parameters | `{ "hb_bidder": "appnexus", "hb_adid": "7a53a9d3" }` |
+| `adserverTargeting` | Object | Contains all the adserver targeting parameters | `{ "hb_bidder": "msft", "hb_adid": "7a53a9d3" }` |
| `native` | Object | Contains native key value pairs. | `{ "title": "", "body": "" }` |
| `status` | String | Status of the bid. Possible values: targetingSet, rendered | `"targetingSet"` |
| `ttl` | Integer | How long (in seconds) this bid is considered valid. See this [FAQ entry]({{site.github.url}}/dev-docs/faq.html#does-prebidjs-cache-bids) for more info. | `300` |
@@ -70,7 +70,7 @@ This function returns the bid responses at the given moment.
{
"/9968336/header-bid-tag-0": [
{
- "bidderCode": "appnexus",
+ "bidderCode": "msft",
"width": 300,
"height": 250,
"adId": "7a53a9d3",
@@ -81,11 +81,11 @@ This function returns the bid responses at the given moment.
"responseTimestamp": 1444844944180,
"timeToRespond": 85,
"adUnitCode": "/19968336/header-bid-tag-0",
- "bidder": "appnexus",
+ "bidder": "msft",
"usesGenericKeys": true,
"size": "300x250",
"adserverTargeting": {
- "hb_bidder": "appnexus",
+ "hb_bidder": "msft",
"hb_adid": "7a53a9d3",
"hb_pb": "0.50"
}
@@ -203,7 +203,7 @@ This function returns the bid responses at the given moment.
"pbCg" : "",
"adUnitCode" : "div-banner-outstream-native",
"size" : "0x0",
- "bidder" : "appnexus",
+ "bidder" : "msft",
"pbAg" : "10.00",
"adId" : "473965c9df19d2",
"adserverTargeting" : {
@@ -213,7 +213,7 @@ This function returns the bid responses at the given moment.
"hb_adid" : "473965c9df19d2",
"hb_pb" : "10.00",
"hb_source" : "client",
- "hb_bidder" : "appnexus",
+ "hb_bidder" : "msft",
"hb_native_image" : "https://vcdn.adnxs.com/p/creative-image/9e/26/5f/b2/9e265fb2-50c8-43f0-88ef-a5a48a9d0dcf.jpg",
"hb_size" : "0x0",
"hb_mediatype" : "native",
@@ -244,7 +244,7 @@ This function returns the bid responses at the given moment.
},
"timeToRespond" : 143,
"mediaType" : "native",
- "bidderCode" : "appnexus",
+ "bidderCode" : "msft",
"source" : "client",
"auctionId" : "1338a6fb-e514-48fc-8db6-872ddf3babdb",
"responseTimestamp" : 1516315716205,
diff --git a/dev-docs/publisher-api-reference/setConfig.md b/dev-docs/publisher-api-reference/setConfig.md
index 0e3d8a7de1..b0e1a82790 100644
--- a/dev-docs/publisher-api-reference/setConfig.md
+++ b/dev-docs/publisher-api-reference/setConfig.md
@@ -229,13 +229,13 @@ Note that targeting config must be set before either `pbjs.setTargetingForGPTAsy
"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",
+ "hb_adid_msft": "191f4aca0c0be8",
+ "hb_pb_msft": "10.00",
+ "hb_size_msft": "300x250",
+ "hb_format_msft": "banner",
+ "hb_source_msft": "client",
// the winning bid is copied to attributes without a suffix
- "hb_bidder": "appnexus",
+ "hb_bidder": "msft",
"hb_adid": "191f4aca0c0be8",
"hb_pb": "10.00",
"hb_size": "300x250",
@@ -1563,8 +1563,8 @@ pbjs.setConfig({
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
+ bidder: 'msft',
+ iframeURL: 'https://microsoft.com:8080/topics/fpd/topic.html', // dummy URL
expiry: 7 // Configurable expiry days
}]
}
@@ -1619,7 +1619,7 @@ Prebid modules sometimes need to know the [IAB Global Vendor List](https://iabeu
```javascript
pbjs.setConfig({
gvlMapping: {
- appnexus: 4,
+ msft: 4,
someModule: 123
}
});
diff --git a/dev-docs/publisher-api-reference/setTargetingForAst.md b/dev-docs/publisher-api-reference/setTargetingForAst.md
index 5a58ec6ff9..1e07a89d6f 100644
--- a/dev-docs/publisher-api-reference/setTargetingForAst.md
+++ b/dev-docs/publisher-api-reference/setTargetingForAst.md
@@ -6,7 +6,7 @@ sidebarType: 1
---
-Set query string targeting for AST ([Seller Tag](https://docs.xandr.com/bundle/seller-tag/page/seller-tag.html)) ad unit(s). Note that this function has to be called after all ad units on page are defined. For working example code, see [Using Prebid.js with AppNexus Publisher Ad Server]({{site.github.url}}/dev-docs/examples/use-prebid-with-appnexus-ad-server.html). If the function is invoked without arguments it will set targeting for all adUnits defined.
+Set query string targeting for AST ([Seller Tag](https://docs.xandr.com/bundle/seller-tag/page/seller-tag.html)) ad unit(s). Note that this function has to be called after all ad units on page are defined. For working example code, see [Using Prebid.js with Microsoft Publisher Ad Server]({{site.github.url}}/dev-docs/examples/use-prebid-with-microsoft-ad-server.html). If the function is invoked without arguments it will set targeting for all adUnits defined.
**Kind**: static method of pbjs API
diff --git a/dev-docs/renderer.md b/dev-docs/renderer.md
index 89a870c57f..f9cbceafd5 100644
--- a/dev-docs/renderer.md
+++ b/dev-docs/renderer.md
@@ -221,9 +221,9 @@ pbjs.addAdUnits({
},
bids: [
{
- bidder: "appnexus",
+ bidder: "msft",
params: {
- placementId: 13144370,
+ placement_id: 13144370,
},
},
],
diff --git a/dev-docs/requirements/tcf2/PrebidSupportforEnforcingTCF2.html b/dev-docs/requirements/tcf2/PrebidSupportforEnforcingTCF2.html
index bd7edfa7a2..73158843a1 100644
--- a/dev-docs/requirements/tcf2/PrebidSupportforEnforcingTCF2.html
+++ b/dev-docs/requirements/tcf2/PrebidSupportforEnforcingTCF2.html
@@ -1 +1 @@
-Prebid Support for Enforcing TCF 2.0
Overview
Definitions
Assumptions
Summary of Prebid TCF 2.0 Enforcement
Basic-vs-Full Enforcement
Basic Enforcement
Full Enforcement (Prebid Server Only)
Prebid.js Functional Requirements
Prebid SDK Functional Requirements
Prebid Server Functional Requirements
Overview
The IAB's Transparency and Consent Framework version 2.0 for enhanced support of GDPR is scheduled to take effect Apr 1 2020. It's a major update from TCF 1.1 which Prebid currently supports, and is not compatible with the previous release.
The key changes are:
- More 'purposes' are defined.
- More flexibility for the legal bases used by vendors.
- Different in-page javascript API
References
Definitions
- GDPR - General Data Protection Regulation. The EU's privacy regulations.
- EEA - European Economic Area. The region where the GDPR is in effect.
- IAB - Interactive Advertising Bureau. The ad industry consortium that developed the TCF as a way to help the ad ecosystem adhere to GDPR rules.
- TCF - Transparency and Consent Framework.
- CMP - Consent Management Platform. The user interface part of the TCF.
- GVL - Global Vendors List. The place where each ad entity registers what they do with user data.
- PBS - Prebid Server
- PBJS - Prebid.js
- PBS Host Company - the organization running a cluster of Prebid Servers
- Purpose 1 - Under TCF, there are many defined uses of private data. "Purpose 1" is "Store and/or access information on a device". This means that users must consent before an ad tech vendor reads or writes data from their computer or phone. Those of us dealing with these things a lot memorize the numbers. Forgive us.
- Purpose 2 - "Basic Ad Selection". This looks to be one of the bigger areas of concern because the TCF policy could be interpreted to be a form of ad blocking. Or maybe not. Talk to your lawyers.
- Purpose 4 - "Personalized Ad Selection". Basically, if the user doesn’t consent, they don’t want ads based on any type of direct user profile.
- Purpose 7 - "Measure ad performance". This is another area of concern, because the TCF policy doesn’t clearly define what it means to measure the “effectiveness” of ads. Talk to your lawyers about what this means for your organization.
- Special Feature 1 - "Use precise geolocation data". Special Features are quite different than Purposes. They only allow user "opt-in", and don't have as many layers of nuance as Purposes.
- Legal Basis - how an ad tech vendor views the importance of each Purpose for their mission. If they define "consent" as their "basis" for a given Purpose, they're able to work without some or all aspects of the user's data. But if they define "Legitimate Interest" (LI), they're basically saying "We can't do our job without this data".
- Basic enforcement - a high-level mode of consent confirmation where the looks for a good-faith indication that the user has provided consent or legal basis signals before engaging in a privacy-protected activity. Does not read the GVL.
- Full enforcement - a detailed confirmation mode that reads the GVL, interprets the consent string, and performs legal basis analysis.
Assumptions
Important Legal Note: Prebid.org cannot provide legal advice about GDPR or any other governmental regulation. Our aim is to provide a toolkit of functionality that will let publishers configure header bidding as defined by their legal counsel. We will consider feature suggestions, and review any code offered by the community.
Enforcement of Purpose 2 (basic ad selection) looks to be one of the bigger areas of concern because the TCF policy could be interpreted to be a form of ad blocking. You will need to work with your legal counsel to determine how you intend to handle this scenario. Prebid.js and Prebid Server offer publishers the ability to enforce or not-enforce purposes individually. As an example of the kind of flexibility we aim to offer (*), here are some options you could discuss with your lawyers:
- Treat Purpose 2 as an ad blocker.
- Ignore enforcement of selected Purposes at the Prebid level entirely, assuming that downstream vendors will handle the TCF strings appropriately.
- Ignore enforcement Purpose 2, assuming that users who object to ‘Basic Ads’ will also object to ‘Personalized Ads’, causing any User IDs to be removed from ad requests.
- Ignore the Purpose-Consent portion of Purpose 2, but allow the user to block specific vendors.
(*) - Note on phasing: Please be aware that Prebid.js and Prebid Server will likely not deliver on the full TCF functionality by April 1st. Our initial goal for both products is to support Purpose 1 (Device Access) enforcement by that date. The ability to enforce the other purposes will be developed as soon as we can.
(**) Did we mention that you cannot rely on this document to learn how to configure your header bidding for GDPR? Seriously, talk to your lawyers. |
General
- Prebid.org is neither a data controller nor data processor, but we supply software to both types of entities. Therefore, our software should provide a flexible set of controls necessary for both types of entities to run their businesses.
- Even if Prebid is configured to enforce activities by parsing consent data, publishers and downstream vendors are still responsible for ensuring their legal bases using the consent data they're provided.
- Prebid will ignore the TCF "stack" feature, assuming that the CMP will set the underlying Purposes appropriately.
- Data from the CMP will never be modified before passing to downstream entities.
- If TCF processing is turned on, and the user is determined to be in GDPR scope, and hasn’t provided a consent string, the system should assume a consent string that has no consent offered.
Prebid.js
- Prebid.js will only support parsing the TCF 2.0 consent string.
- TCF 2.0 features are available in Prebid.js only in a consent module, not as part of core. This allows publishers to build two versions of their wrappers: one for users in the EEA, one for users outside of the EEA.
- It's assumed that publishers run in two modes:
- A CMP is loaded on every page so TCF functions and data are fully available.
- Consent data is stored in first party storage and passed to Prebid directly. TCF functions are not available from the CMP.
- Prebid.js will not load the Global Vendors List (GVL) as this would significantly impact the success of header bidding implementations. However, Prebid.js will require a mapping of GVL vendor IDs to Prebid.js bidder codes.
- Further, we assume that not all Prebid adapters will be in the GVL, so we'll need to support reference by GVL ID or bidder code.
- Further, we assume that bidder aliases within one adapter may have different GVL IDs.
- As a result of not having access to GVL entries, Prebid.js will only support ‘Basic Enforcement’.
- TCF2 will be supported in Prebid.js 3.x, with 'no enforcement' being the default option. Prebid.js 4.0 will enforce Purpose 1 by default when the module is included.
- PurposeOneTreatment is ignored for Prebid.js. Publishers who don’t want to enforce Purpose 1 (or any other purpose) need to set Prebid’s configuration appropriately.
Prebid Server
- Prebid Server will need concurrent support of TCF 1.1 and TCF 2.0.
- Prebid Server will need to support “Full Enforcement” checks.
- AMP TCF 2.0 will be passed on the same parameter as TCF 1.1.
Prebid SDK
- Prebid SDK should parse the consent string in order to read the IDFA. Other than that, SDK just passes consent values to Prebid Server..
Summary of Prebid TCF 2.0 Enforcement
TCF Field | In-scope Activities | System | Enforcement | Publisher/ Host Company Controls |
Purpose 1 - Store and/or access information on a device | usersync pixels, user ID modules, and device storage | Prebid.js and Prebid Server and Prebid SDK | May result in preventing one or more uesrsync activities for one or more vendors. | Do not enforce purpose 1 Do not enforce purpose 1 for vendor V Enforce purpose 1 at the vendor level only. |
Purpose 2 - Select basic ads | call bid adapters | Prebid.js and Prebid Server | May result in skipping one or more bid adapters.
All configured modules will be called as usual unless all bidders are eliminated. | Do not enforce purpose 2 Do not enforce purpose 2 for vendor V Enforce purpose 2 at the vendor level only.
|
Purpose 4 - Select Personalized Ads | call bid adapters with userIds | Prebid.js and Prebid Server | May result in removing the userIds before calling one or more bid adapters. | Do not enforce purpose 4 Do not enforce purpose 4 for vendor V Enforce purpose 4 at the vendor level only. |
Purpose 7 - Measure ad performance | initiate analytics | Prebid.js and Prebid Server | May result in skipping one or more analytics adapters. | Do not enforce purpose 7 Do not enforce purpose 7 for vendor V Enforce purpose 7 at the vendor level only. |
Special Feature 1 - Use precise geolocation data | passing lat/long to server-side bid adapters | Prebid Server | May result in rounding lat/long values and IP address before sending to server-side adapters. | Do not enforce Special Feature 1 |
Special Purpose 2 - Technically deliver ads or content | n/a |
Special Purposes do not require consent. If a publisher’s legal team wants to consider SP2, Prebid software should not be called. |
PurposeOneConsent | n/a | Prebid does not provide specific support for enforcing this flag. Instead, publishers may use the provided controls for Purpose 1 and other Prebid configuration to control whether the user’s device is accessed. |
Basic-vs-Full Enforcement
Prebid offers publishers several controls for whether consent/legal basis confirmation is even performed. The following flowchart shows how the controls
Basic Enforcement
The goal of 'basic enforcement' is to confirm that there's enough evidence of consent to pass data on to vendors who have access to the GVL and can fully parse and enforce.
Before allowing a Purpose for a given Vendor, one of these scenarios must be true: :
- User’s purpose consent and user’s vendor consent
- The Prebid-specific ‘enforceVendor’ flag is set and user’s vendor consent
- purpose LI established and vendor LI established
- The Prebid-specific ‘enforceVendor’ flag is set and vendor LI established
In terms of the TCF 2.0 fields, Purpose P is ok for vendor V if either of these is true:
- PurposesConsent[P,V]==1 AND VendorConsentBitfield[V]==1
- pbEnforceVendor[P]==true AND VendorConsentBitfield[V]==1
- PurposesLITransparency[P]==1 AND VendorLegitimateInterestBitfield[V]==1
- pbEnforceVendor[P,V]==true AND VendorLegitimateInterestBitfield[V]==1
Before allowing Special Feature 1, SpecialFeatureOptIns[1] must be true.
Full Enforcement (Prebid Server Only)
The big difference between 'basic' and 'full' enforcement is that Prebid Server has the GVL available to examine vendor legal bases.
Before allowing an activity that falls under a specific Purpose for a given Vendor, one of these 6 basic scenarios needs to be true:
- Vendor claims consent as their basis, publisher doesn't restrict the purpose, user consents to the purpose (if the enforcePurpose flag is on), and user consents to the vendor (if the enforceVendor flag is on).
- Vendor claims (inflexible) legitimate interest as their basis, publisher doesn't restrict the purpose, user was provided notice of the legitimate interest basis for this purpose (if the enforcePurpose flag is on), and user was provided notice for the LI basis for this vendor (if the enforceVendor flag is on)
- Vendor claims flexible legal basis with legitimate interest as the default, publisher restriction doesn't require consent, and ((user was provided notice of the legitimate interest basis for this purpose+vendor) OR (user consents to purpose+vendor)) [Purpose checked only if the enforcePurpose flag is on, and vendor checked only if the enforceVendor flag is on]
- Vendor claims flexible legal basis with legitimate interest as the default, publisher does require consent, user consents to the purpose, and user consents to the vendor. [Purpose checked only if the enforcePurpose flag is on, and vendor checked only if the enforceVendor flag is on]
- Vendor claims flexible legal basis with consent as the default, publisher restriction doesn't require legitimate interest, ((user consents to the purpose+vendor) OR (user was provided notice for the legitimate interest basis for this purpose+vendor)) [Purpose checked only if the enforcePurpose flag is on, and vendor checked only if the enforceVendor flag is on]
- Vendor claims flexible legal basis with consent as the default, publisher restriction does require legitimate interest, and user was provided notice for the legitimate interest basis for this purpose+vendor. [Purpose checked only if the enforcePurpose flag is on, and vendor checked only if the enforceVendor flag is on]
Note that there are many more scenarios where the activity would not be allowed.
The technical definition in terms of the TCF 2.0 fields follows. Purpose P is ok for vendor V if any of these is true:
- GVL[V].purposes contains P and GVL[V].flexiblePurposes doesn't contain P and publisherRestrictions[P]!=0 and (!enforcePurpose[P] or PurposesConsent[P]==1) AND (!enforceVendor[P,V] or VendorConsentBitfield[V]==1)
- GVL[V].legIntPurposes contains P and GVL[V].flexiblePurposes doesn't contain P and publisherRestrictions[P]!=0 and (!enforcePurpose[P] or PurposesLITransparency[P]==1) AND (!enforceVendor[P,V] or VendorLegitimateInterestBitfield[V]==1)
- GVL[V].legIntPurposes contains P and GVL[V].flexiblePurposes contains P and publisherRestrictions[P]==2 and (((!enforcePurpose[P] or PurposesConsent[P]==1) AND (!enforceVendor[P,V] or VendorConsentBitfield[V]==1)) OR ((!enforcePurpose[P] or PurposesLITransparency[P]==1) AND (!enforceVendor[P,V] or VendorLegitimateInterestBitfield[V]==1)))
- GVL[V].legIntPurposes contains P and GVL[V].flexiblePurposes contains P and publisherRestrictions[P]==1 and (!enforcePurpose[P] or PurposesConsent[P]==1) AND (!enforceVendor[P,V] or VendorConsentBitfield[V]==1)
- GVL[V].purposes contains P and GVL[V].flexiblePurposes contains P and publisherRestrictions[P]==1 and (((!enforcePurpose[P] or PurposesConsent[P]==1) AND (!enforceVendor[P,V] or VendorConsentBitfield[V]==1)) OR ((!enforcePurpose[P] or PurposesLITransparency[P]==1) AND (!enforceVendor[P,V] or VendorLegitimateInterestBitfield[V]==1)))
- GVL[V].purposes contains P and GVL[V].flexiblePurposes contains P and publisherRestrictions[P]==2 and (!enforcePurpose[P] or PurposesLITransparency[P]==1) AND (!enforceVendor[P,V] or VendorLegitimateInterestBitfield[V]==1)
Before allowing Special Feature 1, SpecialFeatureOptIns[1] must be true.
Prebid.js Functional Requirements
1) An optional module must be available for reading the IAB TCF 2.0 API data. Publishers will include this module in their Prebid.js package when they need to support EEA users.
2) Prebid.js must support scenarios where the TCF string parsing functions are not available. If the codebase for parsing the TCF string is significant, it should be made an optional module separate from the enforcement functions. A key goal of Prebid.js is to include only the code that publishers need for their particular use case. The technical design should consider whether it makes sense to bundle all of these components together, or break them into 2 or 3 separate modules:
- Reading the TCF string
- Enforcing the TCF string
- Parsing the TCF string (?)
3) Prebid.js must support the following publisher controls:
- Don't even read the TCF string (accomplished by not configuring the module)
- Enforce/Do not enforce purpose P
- Enforce/Do not enforce purpose P for vendor V
Here's a set of proposed configurations within the existing consentManagement config object:
Param | Type | Description | Details |
gdpr.allowAuctionWithoutConsent | boolean | Available in 3.x only, defines behavior for backwards compatibility. | For 3.x: If true, consider all Purposes as not enforceable. If false, consider only Purpose 2 enforceable. |
gdpr.consentData | object | Consent data provided statically. | Used when cmpApi is "static". |
gdpr.defaultGdprScope | boolean |
|
|
gdpr.rules | object | Lets the publisher override the defaults set by the enforceMode |
|
gdpr.rules[].purpose | string | Possible values are "storage", "basicAds", "personalizedAds", and "measurement" corresponding to Purposes 1,2,4, and 7 respectively. | For some reason, people tend to prefer using the string names rather than the numbers. |
gdpr.rules[].enforcePurpose | boolean | Whether to enforce this purpose or not. Overrides the setting from enforceMode. | The default in PBJS 3.x will be to enforce no purposes, and in 4.0 to enforce Purpose 1 and no others. |
gdpr.rules[].enforceVendor | boolean | Whether to enforce vendor consent/legal basis for this purpose or not.. | The default in PBJS 3.x will be to enforce no purposes, and in 4.0 to enforce Purpose 1 and no others. |
gdpr.rules[].vendorExceptions | array of strings | Which biddercodes or module names should be treated as the opposite of the enforceVendor flag. | If enforceVendor=false, then vendorExceptions are those that will be treated as true. If enforce=true, then vendorExceptions are those that will be treated as false. |
Example configurations:
pbjs.setConfig({ consentManagement: { gdpr: { cmpApi: 'iab', defaultGdprScope: true/false (0/1?) timeout: 3000, // allowAuctionWithoutConsent: false, // deprecated rules: [{ // don’t enforce Purpose 1 except for bidderA. // this means that TCF approval is only considered // for this one bidder. purpose: "storage", enforcePurpose: false, enforceVendor: false, vendorExceptions: ["bidderA"] },{ // Allow the user to object to vendors for Purpose 2 // but don’t allow them to turn off header bidding // altogether. // The exception is bidderB, which the user will // not be allowed to reject purpose: "basicAds", enforcePurpose: false, enforceVendor: true, vendorExceptions: ["bidderB"] },{ // allow the user to have their userId removed from // header bidding except for bidders A and B purpose: "personalizedAds", enforcePurpose: true, enforceVendor: true vendorExceptions: ["bidderA","bidderB"] },{ // analytics adapters are ok purpose: "measurement", enforcePurpose: false, enforcePurpose: false }] } } }); |
You may notice that the examples above provide more flexibility than TCF requires. This allows publishers to establish custom legal bases in consultation with their legal counsel.
4) If the 'gdprApplies' flag is defined and is false, then Prebid.js may assume that GDPR is not in scope and therefore doesn't need to be enforced. All Purposes will be set to enforce=false.
4) There should be a way for bidAdapters to supply a GVL ID for each alias they support.
5) The aliasBidder() function should be extended to support specification of a GVL ID. e.g.
pbjs.aliasBidder('appnexus', 'newAlias', 999);
6) If a bidder code isn't associated with a GVL ID, enforcement should assume that the vendor is not allowed unless the publisher has specifically named their bidder code.
7) Analytics adapters must be associated with a GVL ID and/or a "name" to allow the system to determine which analytics adapter(s) are permitted to operate in the current context.
8) User ID modules and Real Time Data modules should be associated with a GVL ID and/or a "name" to allow the system to determine which modules are permitted to operate in the current context.
9) The system must be able to verify vendor consent in two ways:
- User consents to GVL ID 52, and Prebid.js knows that 52 corresponds to the Rubicon bid adapter (and the Rubicon analytics adapter)
10) The internal interface to bid adapters should remain the same: bidrequest.gdprConsent
11) The OpenRTB interface to Prebid Server should remain the same:
- regs.ext.gdpr
- user.ext.consent
12) The system must support all the activity enforcement noted in the 'Summary of Prebid TCF 2.0 Enforcement' section.
- If Purpose 1 is being enforced:
- Before invoking usersync pixels for each enforceable vendor, verify consent as described in 'Basic Enforcement'.
- Before reading or storing cookies or HTML 5 localstorage for each enforceable vendor, verify consent as described in 'Basic Enforcement'. This will require enhancing the getCookie and setCookie utility functions to determine or accept the biddercode or module name.
- Before invoking each enforceable userID sub-module, verify consent as described in 'Basic Enforcement'.
- If Purpose 2 is being enforced, verify consent for each vendor as described in 'Basic Enforcement' before calling a bid adapter. If consent is not granted, log a console warning and skip it.
- If Purpose 4 is being enforced, verify consent for each vendor that passed the Purpose 2 test. If consent is not granted, log a console warning, remove the bidrequest.userId attribute and call the adapter.
- If Purpose 7 is being enforced, verify consent for each analytics module. If consent is not granted, log a console warning and skip it.
13) If consentManagement.gdpr is configured but no consent string is available, the system must assume that the user does not consent to either purpose or vendor. Activities may still take place if the publisher has configured the relevant Purposes as 'not enforced'.
13) Bid adapters must do one of the following for all device access activities (reading or setting cookies or local storage):
- Use the PBJS core utility functions, which will handle Purpose 1 enforcement.
- Post a public disclosure in the code and on prebid.org explaining the legal basis for not adhering to GDPR.
14) Prebid core must make the following information available to analytics adapters:
- Enforcement status of Purposes 1,2,4 and 7.
- An array of bidders and modules skipped due to TCF enforcement.
15) It should be possible for a pub to define a mapping between a module code and a GVL ID
pbjs.setConfig({
gvlMapping: {
“id5”: 9999
“bidderX”: 8888
}
Prebid SDK Functional Requirements
1) Prebid SDK must accept the following optional parameters to support TCF 2.0. It’s assumed the app will pass these values directly or indirectly from a mobile CMP.
- GDPR in-scope
- TCF Consent string
- ‘deviceAccessConsent’ flag defining whether the SDK is allowed to read the IDFA or equivalent. It’s assumed that the app will parse the consent string to confirm the user has consented to Purpose 1.
2) When a request is defined to be GDPR in-scope, the SDK must confirm that the ‘deviceAccessConsent’ flag is true. Here’s the truth table for when the SDK is allowed to access the device ID:
| deviceAccessConsent=true | deviceAccessConsent=false | deviceAccessConsent undefined |
GDPR scope=false | Yes, read IDFA | No, don’t read IDFA | Yes, read IDFA |
GDPR scope=true | Yes, read IDFA | No, don’t read IDFA | No, don’t read IDFA |
GDPR scope undefined | Yes, read IDFA | No, don’t read IDFA | Yes, read IDFA |
3) The SDK must pass the consent data to Prebid Server on the same OpenRTB attributes as defined in TCF 1.1:
- GDPR in-scope flag is regs.ext.gdpr
- Consent string is user.ext.consent
Prebid Server Functional Requirements
1) Optional configuration must be available for host companies to turn on and off enforcing GDPR with IAB TCF 2.0 API data. There should be global and publisher account level configuration. The default should be to enforce.
2) If enforcement is turned on for this request, Prebid Server must be able to determine whether it's in-scope for GDPR processing. If any of the following conditions are true, the request is in-scope:
- the incoming request defines regs.ext.gdpr:true.
- regs.ext.gdpr is undefined, geo-lookup is turned on, and the user's IP address is in a configurable set of countries.
- regs.ext.gdpr is undefined and the host company's default scope is to enforce.
3) Prebid Server must support the following host company controls:
- Enforce/Do not enforce purpose P (globally and per-account)
- Enforce/Do not enforce purpose P for vendor V (globally and per-account)
- Enforce/Do not enforce special purpose 1
- Enforce/Do not enforce special purpose 1 for vendor V
- ACCOUNT
4) Prebid Server must give host company config to say what to do with the purposeOneTreatment - both as a default and for each account:
- ignore the flag entirely
- if purposeOneTreatment=1 and IsServiceSpecific=1 then Purpose 1 is overridden to no-access-allowed
- if purposeOneTreatment=1 and IsServiceSpecific=1 then Purpose 1 is overridden to access-allowed
The implementation of this “PurposeOneTreatmentInterpretation flag modifies the flowchart above: it may short-circuit the logic, jumping straight to Yes or No without a normal enforcement check.
5) It must be possible for a Host Company to define its GVL ID to use for confirming user user consent for setting cookies.
Example configuration/DB entries:
gdpr.host-vendor-id: 52
gdpr.enabled: true/false // default true
gdpr.purpose.P.enforcePurpose: no/basic/full // default full
gdpr.purpose.P.enforceVendors: true/false // default true
gdpr.purpose.P.vendorExceptions: list of biddercodes
gdpr.specialfeature.S.enforce: true/false // default true
gdpr.specialfeature.S.vendorExceptions: list of biddercodes
gdpr.purposeOneTreatmentInterpretation: ignore/no-access-allowed/access-allowed
account.A.gdpr.enabled: true/false // default true
account.A.gdpr.purpose.P.enforcePurpose
account.A.gdpr.purpose.P.enforceVendors
account.A.gdpr.purpose.P.vendorExceptions
account.A.gdpr.specialfeature.S.enforce
account.A.gdpr.specialfeature.S.vendorExceptions
account.A.gdpr.purposeOneTreatmentInterpretation
geolocation.VENDOR.server: url // location of geo lookup service
6) There should be a way for bidAdapters to supply a GVL ID for each alias they support.
7) The external definition of aliases should be extended to support specification of a GVL ID. e.g.
"ext": {
"prebid": {
"aliases": { // existing feature
"districtm": "appnexus"
},
"aliasgvlids": { // new feature
"districtm": 144
}
}
}
8) Prebid Server's enforcement should be "Full" mode unless it doesn't have access to the proper GVL version.
9) Prebid Server should be able to read the TCF2.0 GVL that's specified in the consent string. If it does not have immediate access to that version of the GVL, it may downgrade enforcement to "Basic". The assumption is that subsequent requests for that version of the GVL will succeed. The system should log any usage of Basic Enforcement.
10) If a bidder code isn't associated with a GVL ID, enforcement should assume that the vendor is not allowed unless the publisher has specifically named the bidder code as a configured exception.
11) Analytics adapters must be associated with a GVL ID and/or a "name" to allow the system to determine which analytics adapter(s) are permitted to operate in the current context.
12) User ID modules and Real Time Data modules should be associated with a GVL ID and/or a "name" to allow the system to determine which modules are permitted to operate in the current context.
13) The system must be able to verify vendor consent in two ways:
- User consents to GVL ID 52, and Prebid Server knows that 52 corresponds to the Rubicon bid adapter (and the Rubicon analytics adapter)
- The Host Company consents to the name "bidderB", which would allow that biddercode to bid even if the user's Purpose 1 doesn't have specific consent.
14) The internal interface to bid adapters should remain the same.
15) The OpenRTB interface to Prebid Server should remain the same:
- regs.ext.gdpr
- user.ext.consent
16) The system must support all the activity enforcement noted in the 'Summary of Prebid TCF 2.0 Enforcement' section.
- If Purpose 1 is being enforced:
- Before invoking /cookie_sync pixels for each enforceable vendor, verify consent as appropriate for the enforcement method.
- Before setting a cookie on /setuid, verify consent for the Host Company's GVL ID as appropriate for the enforcement method
- Before passing ID values to each enforceable vendor, verify consent as appropriate for the enforcement method.
- If Purpose 2 is being enforced, verify consent for each vendor as appropriate for the enforcement method before calling a bid adapter. If consent is not granted, log a metric and skip it.
- If Purpose 4 is being enforced, verify consent for each vendor that passed the Purpose 2 test. If consent is not granted, log a metric, remove the bidrequest.userId attribute and call the adapter.
- If Purpose 7 is being enforced, verify consent for each analytics module. If consent is not granted, log a metric and skip it.
- If Special Feature 1 is being enforced, verify user opt-in. If the user has opted out, round off the IP address and lat/long details and log a metric.
- IP masking: for IPv4, zero out the last byte. For IPv6, zero out the last 2 bytes.
- Check the OpenRtb packet for $.device.geo.lat, $.device.geo.lon, $.user.geo.lat, $.user.geo.lon. Round off the values to the last two decimal points if they exist.
17) If GDPR is being enforced but no consent string is available, the system must assume that the user does not consent to either purpose or vendor. Activities may still take place if the Host Company has configured the relevant Purposes as 'not enforced'.
18) Prebid Server core must make the following information available to analytics adapters:
- Enforcement status of Purposes 1,2,4,7, and Special Purpose 1
- An array of bidders and modules skipped due to TCF enforcement.
+Prebid Support for Enforcing TCF 2.0
Overview
Definitions
Assumptions
Summary of Prebid TCF 2.0 Enforcement
Basic-vs-Full Enforcement
Basic Enforcement
Full Enforcement (Prebid Server Only)
Prebid.js Functional Requirements
Prebid SDK Functional Requirements
Prebid Server Functional Requirements
Overview
The IAB's Transparency and Consent Framework version 2.0 for enhanced support of GDPR is scheduled to take effect Apr 1 2020. It's a major update from TCF 1.1 which Prebid currently supports, and is not compatible with the previous release.
The key changes are:
- More 'purposes' are defined.
- More flexibility for the legal bases used by vendors.
- Different in-page javascript API
References
Definitions
- GDPR - General Data Protection Regulation. The EU's privacy regulations.
- EEA - European Economic Area. The region where the GDPR is in effect.
- IAB - Interactive Advertising Bureau. The ad industry consortium that developed the TCF as a way to help the ad ecosystem adhere to GDPR rules.
- TCF - Transparency and Consent Framework.
- CMP - Consent Management Platform. The user interface part of the TCF.
- GVL - Global Vendors List. The place where each ad entity registers what they do with user data.
- PBS - Prebid Server
- PBJS - Prebid.js
- PBS Host Company - the organization running a cluster of Prebid Servers
- Purpose 1 - Under TCF, there are many defined uses of private data. "Purpose 1" is "Store and/or access information on a device". This means that users must consent before an ad tech vendor reads or writes data from their computer or phone. Those of us dealing with these things a lot memorize the numbers. Forgive us.
- Purpose 2 - "Basic Ad Selection". This looks to be one of the bigger areas of concern because the TCF policy could be interpreted to be a form of ad blocking. Or maybe not. Talk to your lawyers.
- Purpose 4 - "Personalized Ad Selection". Basically, if the user doesn’t consent, they don’t want ads based on any type of direct user profile.
- Purpose 7 - "Measure ad performance". This is another area of concern, because the TCF policy doesn’t clearly define what it means to measure the “effectiveness” of ads. Talk to your lawyers about what this means for your organization.
- Special Feature 1 - "Use precise geolocation data". Special Features are quite different than Purposes. They only allow user "opt-in", and don't have as many layers of nuance as Purposes.
- Legal Basis - how an ad tech vendor views the importance of each Purpose for their mission. If they define "consent" as their "basis" for a given Purpose, they're able to work without some or all aspects of the user's data. But if they define "Legitimate Interest" (LI), they're basically saying "We can't do our job without this data".
- Basic enforcement - a high-level mode of consent confirmation where the looks for a good-faith indication that the user has provided consent or legal basis signals before engaging in a privacy-protected activity. Does not read the GVL.
- Full enforcement - a detailed confirmation mode that reads the GVL, interprets the consent string, and performs legal basis analysis.
Assumptions
Important Legal Note: Prebid.org cannot provide legal advice about GDPR or any other governmental regulation. Our aim is to provide a toolkit of functionality that will let publishers configure header bidding as defined by their legal counsel. We will consider feature suggestions, and review any code offered by the community.
Enforcement of Purpose 2 (basic ad selection) looks to be one of the bigger areas of concern because the TCF policy could be interpreted to be a form of ad blocking. You will need to work with your legal counsel to determine how you intend to handle this scenario. Prebid.js and Prebid Server offer publishers the ability to enforce or not-enforce purposes individually. As an example of the kind of flexibility we aim to offer (*), here are some options you could discuss with your lawyers:
- Treat Purpose 2 as an ad blocker.
- Ignore enforcement of selected Purposes at the Prebid level entirely, assuming that downstream vendors will handle the TCF strings appropriately.
- Ignore enforcement Purpose 2, assuming that users who object to ‘Basic Ads’ will also object to ‘Personalized Ads’, causing any User IDs to be removed from ad requests.
- Ignore the Purpose-Consent portion of Purpose 2, but allow the user to block specific vendors.
(*) - Note on phasing: Please be aware that Prebid.js and Prebid Server will likely not deliver on the full TCF functionality by April 1st. Our initial goal for both products is to support Purpose 1 (Device Access) enforcement by that date. The ability to enforce the other purposes will be developed as soon as we can.
(**) Did we mention that you cannot rely on this document to learn how to configure your header bidding for GDPR? Seriously, talk to your lawyers. |
General
- Prebid.org is neither a data controller nor data processor, but we supply software to both types of entities. Therefore, our software should provide a flexible set of controls necessary for both types of entities to run their businesses.
- Even if Prebid is configured to enforce activities by parsing consent data, publishers and downstream vendors are still responsible for ensuring their legal bases using the consent data they're provided.
- Prebid will ignore the TCF "stack" feature, assuming that the CMP will set the underlying Purposes appropriately.
- Data from the CMP will never be modified before passing to downstream entities.
- If TCF processing is turned on, and the user is determined to be in GDPR scope, and hasn’t provided a consent string, the system should assume a consent string that has no consent offered.
Prebid.js
- Prebid.js will only support parsing the TCF 2.0 consent string.
- TCF 2.0 features are available in Prebid.js only in a consent module, not as part of core. This allows publishers to build two versions of their wrappers: one for users in the EEA, one for users outside of the EEA.
- It's assumed that publishers run in two modes:
- A CMP is loaded on every page so TCF functions and data are fully available.
- Consent data is stored in first party storage and passed to Prebid directly. TCF functions are not available from the CMP.
- Prebid.js will not load the Global Vendors List (GVL) as this would significantly impact the success of header bidding implementations. However, Prebid.js will require a mapping of GVL vendor IDs to Prebid.js bidder codes.
- Further, we assume that not all Prebid adapters will be in the GVL, so we'll need to support reference by GVL ID or bidder code.
- Further, we assume that bidder aliases within one adapter may have different GVL IDs.
- As a result of not having access to GVL entries, Prebid.js will only support ‘Basic Enforcement’.
- TCF2 will be supported in Prebid.js 3.x, with 'no enforcement' being the default option. Prebid.js 4.0 will enforce Purpose 1 by default when the module is included.
- PurposeOneTreatment is ignored for Prebid.js. Publishers who don’t want to enforce Purpose 1 (or any other purpose) need to set Prebid’s configuration appropriately.
Prebid Server
- Prebid Server will need concurrent support of TCF 1.1 and TCF 2.0.
- Prebid Server will need to support “Full Enforcement” checks.
- AMP TCF 2.0 will be passed on the same parameter as TCF 1.1.
Prebid SDK
- Prebid SDK should parse the consent string in order to read the IDFA. Other than that, SDK just passes consent values to Prebid Server..
Summary of Prebid TCF 2.0 Enforcement
TCF Field | In-scope Activities | System | Enforcement | Publisher/ Host Company Controls |
Purpose 1 - Store and/or access information on a device | usersync pixels, user ID modules, and device storage | Prebid.js and Prebid Server and Prebid SDK | May result in preventing one or more uesrsync activities for one or more vendors. | Do not enforce purpose 1 Do not enforce purpose 1 for vendor V Enforce purpose 1 at the vendor level only. |
Purpose 2 - Select basic ads | call bid adapters | Prebid.js and Prebid Server | May result in skipping one or more bid adapters.
All configured modules will be called as usual unless all bidders are eliminated. | Do not enforce purpose 2 Do not enforce purpose 2 for vendor V Enforce purpose 2 at the vendor level only.
|
Purpose 4 - Select Personalized Ads | call bid adapters with userIds | Prebid.js and Prebid Server | May result in removing the userIds before calling one or more bid adapters. | Do not enforce purpose 4 Do not enforce purpose 4 for vendor V Enforce purpose 4 at the vendor level only. |
Purpose 7 - Measure ad performance | initiate analytics | Prebid.js and Prebid Server | May result in skipping one or more analytics adapters. | Do not enforce purpose 7 Do not enforce purpose 7 for vendor V Enforce purpose 7 at the vendor level only. |
Special Feature 1 - Use precise geolocation data | passing lat/long to server-side bid adapters | Prebid Server | May result in rounding lat/long values and IP address before sending to server-side adapters. | Do not enforce Special Feature 1 |
Special Purpose 2 - Technically deliver ads or content | n/a |
Special Purposes do not require consent. If a publisher’s legal team wants to consider SP2, Prebid software should not be called. |
PurposeOneConsent | n/a | Prebid does not provide specific support for enforcing this flag. Instead, publishers may use the provided controls for Purpose 1 and other Prebid configuration to control whether the user’s device is accessed. |
Basic-vs-Full Enforcement
Prebid offers publishers several controls for whether consent/legal basis confirmation is even performed. The following flowchart shows how the controls
Basic Enforcement
The goal of 'basic enforcement' is to confirm that there's enough evidence of consent to pass data on to vendors who have access to the GVL and can fully parse and enforce.
Before allowing a Purpose for a given Vendor, one of these scenarios must be true: :
- User’s purpose consent and user’s vendor consent
- The Prebid-specific ‘enforceVendor’ flag is set and user’s vendor consent
- purpose LI established and vendor LI established
- The Prebid-specific ‘enforceVendor’ flag is set and vendor LI established
In terms of the TCF 2.0 fields, Purpose P is ok for vendor V if either of these is true:
- PurposesConsent[P,V]==1 AND VendorConsentBitfield[V]==1
- pbEnforceVendor[P]==true AND VendorConsentBitfield[V]==1
- PurposesLITransparency[P]==1 AND VendorLegitimateInterestBitfield[V]==1
- pbEnforceVendor[P,V]==true AND VendorLegitimateInterestBitfield[V]==1
Before allowing Special Feature 1, SpecialFeatureOptIns[1] must be true.
Full Enforcement (Prebid Server Only)
The big difference between 'basic' and 'full' enforcement is that Prebid Server has the GVL available to examine vendor legal bases.
Before allowing an activity that falls under a specific Purpose for a given Vendor, one of these 6 basic scenarios needs to be true:
- Vendor claims consent as their basis, publisher doesn't restrict the purpose, user consents to the purpose (if the enforcePurpose flag is on), and user consents to the vendor (if the enforceVendor flag is on).
- Vendor claims (inflexible) legitimate interest as their basis, publisher doesn't restrict the purpose, user was provided notice of the legitimate interest basis for this purpose (if the enforcePurpose flag is on), and user was provided notice for the LI basis for this vendor (if the enforceVendor flag is on)
- Vendor claims flexible legal basis with legitimate interest as the default, publisher restriction doesn't require consent, and ((user was provided notice of the legitimate interest basis for this purpose+vendor) OR (user consents to purpose+vendor)) [Purpose checked only if the enforcePurpose flag is on, and vendor checked only if the enforceVendor flag is on]
- Vendor claims flexible legal basis with legitimate interest as the default, publisher does require consent, user consents to the purpose, and user consents to the vendor. [Purpose checked only if the enforcePurpose flag is on, and vendor checked only if the enforceVendor flag is on]
- Vendor claims flexible legal basis with consent as the default, publisher restriction doesn't require legitimate interest, ((user consents to the purpose+vendor) OR (user was provided notice for the legitimate interest basis for this purpose+vendor)) [Purpose checked only if the enforcePurpose flag is on, and vendor checked only if the enforceVendor flag is on]
- Vendor claims flexible legal basis with consent as the default, publisher restriction does require legitimate interest, and user was provided notice for the legitimate interest basis for this purpose+vendor. [Purpose checked only if the enforcePurpose flag is on, and vendor checked only if the enforceVendor flag is on]
Note that there are many more scenarios where the activity would not be allowed.
The technical definition in terms of the TCF 2.0 fields follows. Purpose P is ok for vendor V if any of these is true:
- GVL[V].purposes contains P and GVL[V].flexiblePurposes doesn't contain P and publisherRestrictions[P]!=0 and (!enforcePurpose[P] or PurposesConsent[P]==1) AND (!enforceVendor[P,V] or VendorConsentBitfield[V]==1)
- GVL[V].legIntPurposes contains P and GVL[V].flexiblePurposes doesn't contain P and publisherRestrictions[P]!=0 and (!enforcePurpose[P] or PurposesLITransparency[P]==1) AND (!enforceVendor[P,V] or VendorLegitimateInterestBitfield[V]==1)
- GVL[V].legIntPurposes contains P and GVL[V].flexiblePurposes contains P and publisherRestrictions[P]==2 and (((!enforcePurpose[P] or PurposesConsent[P]==1) AND (!enforceVendor[P,V] or VendorConsentBitfield[V]==1)) OR ((!enforcePurpose[P] or PurposesLITransparency[P]==1) AND (!enforceVendor[P,V] or VendorLegitimateInterestBitfield[V]==1)))
- GVL[V].legIntPurposes contains P and GVL[V].flexiblePurposes contains P and publisherRestrictions[P]==1 and (!enforcePurpose[P] or PurposesConsent[P]==1) AND (!enforceVendor[P,V] or VendorConsentBitfield[V]==1)
- GVL[V].purposes contains P and GVL[V].flexiblePurposes contains P and publisherRestrictions[P]==1 and (((!enforcePurpose[P] or PurposesConsent[P]==1) AND (!enforceVendor[P,V] or VendorConsentBitfield[V]==1)) OR ((!enforcePurpose[P] or PurposesLITransparency[P]==1) AND (!enforceVendor[P,V] or VendorLegitimateInterestBitfield[V]==1)))
- GVL[V].purposes contains P and GVL[V].flexiblePurposes contains P and publisherRestrictions[P]==2 and (!enforcePurpose[P] or PurposesLITransparency[P]==1) AND (!enforceVendor[P,V] or VendorLegitimateInterestBitfield[V]==1)
Before allowing Special Feature 1, SpecialFeatureOptIns[1] must be true.
Prebid.js Functional Requirements
1) An optional module must be available for reading the IAB TCF 2.0 API data. Publishers will include this module in their Prebid.js package when they need to support EEA users.
2) Prebid.js must support scenarios where the TCF string parsing functions are not available. If the codebase for parsing the TCF string is significant, it should be made an optional module separate from the enforcement functions. A key goal of Prebid.js is to include only the code that publishers need for their particular use case. The technical design should consider whether it makes sense to bundle all of these components together, or break them into 2 or 3 separate modules:
- Reading the TCF string
- Enforcing the TCF string
- Parsing the TCF string (?)
3) Prebid.js must support the following publisher controls:
- Don't even read the TCF string (accomplished by not configuring the module)
- Enforce/Do not enforce purpose P
- Enforce/Do not enforce purpose P for vendor V
Here's a set of proposed configurations within the existing consentManagement config object:
Param | Type | Description | Details |
gdpr.allowAuctionWithoutConsent | boolean | Available in 3.x only, defines behavior for backwards compatibility. | For 3.x: If true, consider all Purposes as not enforceable. If false, consider only Purpose 2 enforceable. |
gdpr.consentData | object | Consent data provided statically. | Used when cmpApi is "static". |
gdpr.defaultGdprScope | boolean |
|
|
gdpr.rules | object | Lets the publisher override the defaults set by the enforceMode |
|
gdpr.rules[].purpose | string | Possible values are "storage", "basicAds", "personalizedAds", and "measurement" corresponding to Purposes 1,2,4, and 7 respectively. | For some reason, people tend to prefer using the string names rather than the numbers. |
gdpr.rules[].enforcePurpose | boolean | Whether to enforce this purpose or not. Overrides the setting from enforceMode. | The default in PBJS 3.x will be to enforce no purposes, and in 4.0 to enforce Purpose 1 and no others. |
gdpr.rules[].enforceVendor | boolean | Whether to enforce vendor consent/legal basis for this purpose or not.. | The default in PBJS 3.x will be to enforce no purposes, and in 4.0 to enforce Purpose 1 and no others. |
gdpr.rules[].vendorExceptions | array of strings | Which biddercodes or module names should be treated as the opposite of the enforceVendor flag. | If enforceVendor=false, then vendorExceptions are those that will be treated as true. If enforce=true, then vendorExceptions are those that will be treated as false. |
Example configurations:
pbjs.setConfig({ consentManagement: { gdpr: { cmpApi: 'iab', defaultGdprScope: true/false (0/1?) timeout: 3000, // allowAuctionWithoutConsent: false, // deprecated rules: [{ // don’t enforce Purpose 1 except for bidderA. // this means that TCF approval is only considered // for this one bidder. purpose: "storage", enforcePurpose: false, enforceVendor: false, vendorExceptions: ["bidderA"] },{ // Allow the user to object to vendors for Purpose 2 // but don’t allow them to turn off header bidding // altogether. // The exception is bidderB, which the user will // not be allowed to reject purpose: "basicAds", enforcePurpose: false, enforceVendor: true, vendorExceptions: ["bidderB"] },{ // allow the user to have their userId removed from // header bidding except for bidders A and B purpose: "personalizedAds", enforcePurpose: true, enforceVendor: true vendorExceptions: ["bidderA","bidderB"] },{ // analytics adapters are ok purpose: "measurement", enforcePurpose: false, enforcePurpose: false }] } } }); |
You may notice that the examples above provide more flexibility than TCF requires. This allows publishers to establish custom legal bases in consultation with their legal counsel.
4) If the 'gdprApplies' flag is defined and is false, then Prebid.js may assume that GDPR is not in scope and therefore doesn't need to be enforced. All Purposes will be set to enforce=false.
4) There should be a way for bidAdapters to supply a GVL ID for each alias they support.
5) The aliasBidder() function should be extended to support specification of a GVL ID. e.g.
pbjs.aliasBidder('msft', 'newAlias', 999);
6) If a bidder code isn't associated with a GVL ID, enforcement should assume that the vendor is not allowed unless the publisher has specifically named their bidder code.
7) Analytics adapters must be associated with a GVL ID and/or a "name" to allow the system to determine which analytics adapter(s) are permitted to operate in the current context.
8) User ID modules and Real Time Data modules should be associated with a GVL ID and/or a "name" to allow the system to determine which modules are permitted to operate in the current context.
9) The system must be able to verify vendor consent in two ways:
- User consents to GVL ID 52, and Prebid.js knows that 52 corresponds to the Rubicon bid adapter (and the Rubicon analytics adapter)
10) The internal interface to bid adapters should remain the same: bidrequest.gdprConsent
11) The OpenRTB interface to Prebid Server should remain the same:
- regs.ext.gdpr
- user.ext.consent
12) The system must support all the activity enforcement noted in the 'Summary of Prebid TCF 2.0 Enforcement' section.
- If Purpose 1 is being enforced:
- Before invoking usersync pixels for each enforceable vendor, verify consent as described in 'Basic Enforcement'.
- Before reading or storing cookies or HTML 5 localstorage for each enforceable vendor, verify consent as described in 'Basic Enforcement'. This will require enhancing the getCookie and setCookie utility functions to determine or accept the biddercode or module name.
- Before invoking each enforceable userID sub-module, verify consent as described in 'Basic Enforcement'.
- If Purpose 2 is being enforced, verify consent for each vendor as described in 'Basic Enforcement' before calling a bid adapter. If consent is not granted, log a console warning and skip it.
- If Purpose 4 is being enforced, verify consent for each vendor that passed the Purpose 2 test. If consent is not granted, log a console warning, remove the bidrequest.userId attribute and call the adapter.
- If Purpose 7 is being enforced, verify consent for each analytics module. If consent is not granted, log a console warning and skip it.
13) If consentManagement.gdpr is configured but no consent string is available, the system must assume that the user does not consent to either purpose or vendor. Activities may still take place if the publisher has configured the relevant Purposes as 'not enforced'.
13) Bid adapters must do one of the following for all device access activities (reading or setting cookies or local storage):
- Use the PBJS core utility functions, which will handle Purpose 1 enforcement.
- Post a public disclosure in the code and on prebid.org explaining the legal basis for not adhering to GDPR.
14) Prebid core must make the following information available to analytics adapters:
- Enforcement status of Purposes 1,2,4 and 7.
- An array of bidders and modules skipped due to TCF enforcement.
15) It should be possible for a pub to define a mapping between a module code and a GVL ID
pbjs.setConfig({
gvlMapping: {
“id5”: 9999
“bidderX”: 8888
}
Prebid SDK Functional Requirements
1) Prebid SDK must accept the following optional parameters to support TCF 2.0. It’s assumed the app will pass these values directly or indirectly from a mobile CMP.
- GDPR in-scope
- TCF Consent string
- ‘deviceAccessConsent’ flag defining whether the SDK is allowed to read the IDFA or equivalent. It’s assumed that the app will parse the consent string to confirm the user has consented to Purpose 1.
2) When a request is defined to be GDPR in-scope, the SDK must confirm that the ‘deviceAccessConsent’ flag is true. Here’s the truth table for when the SDK is allowed to access the device ID:
| deviceAccessConsent=true | deviceAccessConsent=false | deviceAccessConsent undefined |
GDPR scope=false | Yes, read IDFA | No, don’t read IDFA | Yes, read IDFA |
GDPR scope=true | Yes, read IDFA | No, don’t read IDFA | No, don’t read IDFA |
GDPR scope undefined | Yes, read IDFA | No, don’t read IDFA | Yes, read IDFA |
3) The SDK must pass the consent data to Prebid Server on the same OpenRTB attributes as defined in TCF 1.1:
- GDPR in-scope flag is regs.ext.gdpr
- Consent string is user.ext.consent
Prebid Server Functional Requirements
1) Optional configuration must be available for host companies to turn on and off enforcing GDPR with IAB TCF 2.0 API data. There should be global and publisher account level configuration. The default should be to enforce.
2) If enforcement is turned on for this request, Prebid Server must be able to determine whether it's in-scope for GDPR processing. If any of the following conditions are true, the request is in-scope:
- the incoming request defines regs.ext.gdpr:true.
- regs.ext.gdpr is undefined, geo-lookup is turned on, and the user's IP address is in a configurable set of countries.
- regs.ext.gdpr is undefined and the host company's default scope is to enforce.
3) Prebid Server must support the following host company controls:
- Enforce/Do not enforce purpose P (globally and per-account)
- Enforce/Do not enforce purpose P for vendor V (globally and per-account)
- Enforce/Do not enforce special purpose 1
- Enforce/Do not enforce special purpose 1 for vendor V
- ACCOUNT
4) Prebid Server must give host company config to say what to do with the purposeOneTreatment - both as a default and for each account:
- ignore the flag entirely
- if purposeOneTreatment=1 and IsServiceSpecific=1 then Purpose 1 is overridden to no-access-allowed
- if purposeOneTreatment=1 and IsServiceSpecific=1 then Purpose 1 is overridden to access-allowed
The implementation of this “PurposeOneTreatmentInterpretation flag modifies the flowchart above: it may short-circuit the logic, jumping straight to Yes or No without a normal enforcement check.
5) It must be possible for a Host Company to define its GVL ID to use for confirming user user consent for setting cookies.
Example configuration/DB entries:
gdpr.host-vendor-id: 52
gdpr.enabled: true/false // default true
gdpr.purpose.P.enforcePurpose: no/basic/full // default full
gdpr.purpose.P.enforceVendors: true/false // default true
gdpr.purpose.P.vendorExceptions: list of biddercodes
gdpr.specialfeature.S.enforce: true/false // default true
gdpr.specialfeature.S.vendorExceptions: list of biddercodes
gdpr.purposeOneTreatmentInterpretation: ignore/no-access-allowed/access-allowed
account.A.gdpr.enabled: true/false // default true
account.A.gdpr.purpose.P.enforcePurpose
account.A.gdpr.purpose.P.enforceVendors
account.A.gdpr.purpose.P.vendorExceptions
account.A.gdpr.specialfeature.S.enforce
account.A.gdpr.specialfeature.S.vendorExceptions
account.A.gdpr.purposeOneTreatmentInterpretation
geolocation.VENDOR.server: url // location of geo lookup service
6) There should be a way for bidAdapters to supply a GVL ID for each alias they support.
7) The external definition of aliases should be extended to support specification of a GVL ID. e.g.
"ext": {
"prebid": {
"aliases": { // existing feature
"districtm": "msft"
},
"aliasgvlids": { // new feature
"districtm": 144
}
}
}
8) Prebid Server's enforcement should be "Full" mode unless it doesn't have access to the proper GVL version.
9) Prebid Server should be able to read the TCF2.0 GVL that's specified in the consent string. If it does not have immediate access to that version of the GVL, it may downgrade enforcement to "Basic". The assumption is that subsequent requests for that version of the GVL will succeed. The system should log any usage of Basic Enforcement.
10) If a bidder code isn't associated with a GVL ID, enforcement should assume that the vendor is not allowed unless the publisher has specifically named the bidder code as a configured exception.
11) Analytics adapters must be associated with a GVL ID and/or a "name" to allow the system to determine which analytics adapter(s) are permitted to operate in the current context.
12) User ID modules and Real Time Data modules should be associated with a GVL ID and/or a "name" to allow the system to determine which modules are permitted to operate in the current context.
13) The system must be able to verify vendor consent in two ways:
- User consents to GVL ID 52, and Prebid Server knows that 52 corresponds to the Rubicon bid adapter (and the Rubicon analytics adapter)
- The Host Company consents to the name "bidderB", which would allow that biddercode to bid even if the user's Purpose 1 doesn't have specific consent.
14) The internal interface to bid adapters should remain the same.
15) The OpenRTB interface to Prebid Server should remain the same:
- regs.ext.gdpr
- user.ext.consent
16) The system must support all the activity enforcement noted in the 'Summary of Prebid TCF 2.0 Enforcement' section.
- If Purpose 1 is being enforced:
- Before invoking /cookie_sync pixels for each enforceable vendor, verify consent as appropriate for the enforcement method.
- Before setting a cookie on /setuid, verify consent for the Host Company's GVL ID as appropriate for the enforcement method
- Before passing ID values to each enforceable vendor, verify consent as appropriate for the enforcement method.
- If Purpose 2 is being enforced, verify consent for each vendor as appropriate for the enforcement method before calling a bid adapter. If consent is not granted, log a metric and skip it.
- If Purpose 4 is being enforced, verify consent for each vendor that passed the Purpose 2 test. If consent is not granted, log a metric, remove the bidrequest.userId attribute and call the adapter.
- If Purpose 7 is being enforced, verify consent for each analytics module. If consent is not granted, log a metric and skip it.
- If Special Feature 1 is being enforced, verify user opt-in. If the user has opted out, round off the IP address and lat/long details and log a metric.
- IP masking: for IPv4, zero out the last byte. For IPv6, zero out the last 2 bytes.
- Check the OpenRtb packet for $.device.geo.lat, $.device.geo.lon, $.user.geo.lat, $.user.geo.lon. Round off the values to the last two decimal points if they exist.
17) If GDPR is being enforced but no consent string is available, the system must assume that the user does not consent to either purpose or vendor. Activities may still take place if the Host Company has configured the relevant Purposes as 'not enforced'.
18) Prebid Server core must make the following information available to analytics adapters:
- Enforcement status of Purposes 1,2,4,7, and Special Purpose 1
- An array of bidders and modules skipped due to TCF enforcement.
diff --git a/dev-docs/show-long-form-video-with-gam.md b/dev-docs/show-long-form-video-with-gam.md
index 573d25680d..b12f4af3cd 100644
--- a/dev-docs/show-long-form-video-with-gam.md
+++ b/dev-docs/show-long-form-video-with-gam.md
@@ -22,10 +22,10 @@ The code example below was built with Prebid.js and the following:
* The [`dfpAdServerVideo` module](/dev-docs/modules/dfp_video.html), which will provide the video ad support.
* The [`categoryTranslation` module](/dev-docs/modules/categoryTranslation.html), to enable competitive separation.
-For example, to build with the AppNexus bidder adapter and GAM use the following command:
+For example, to build with the Microsoft bidder adapter and GAM use the following command:
```bash
-gulp build --modules=appnexusBidAdapter,dfpAdServerVideo
+gulp build --modules=msftBidAdapter,dfpAdServerVideo
```
For more information about how to build with modules, see the [Prebid module documentation](/dev-docs/modules/).
@@ -63,9 +63,9 @@ var videoAdUnit = [{
},
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 14542875
+ placement_id: 14542875
}
}
]
diff --git a/dev-docs/show-native-ads.md b/dev-docs/show-native-ads.md
index 7e71f1b57b..fbd9b37c0c 100644
--- a/dev-docs/show-native-ads.md
+++ b/dev-docs/show-native-ads.md
@@ -20,7 +20,7 @@ using the [improved Prebid.js native ad](/prebid/native-implementation.html) sup
In this tutorial, we'll set up Prebid.js to show native ads.
-We'll use the [AppNexus adapter]({{site.github.url}}/dev-docs/bidders.html#appnexus) since that adapter supports native ads, but the concepts and setup will be largely the same for any bidder adapter that supports the `"native"` media type.
+We'll use the [Micosoft adapter]({{site.github.url}}/dev-docs/bidders.html#msft) since that adapter supports native ads, but the concepts and setup will be largely the same for any bidder adapter that supports the `"native"` media type.
Similarly, we'll use Google Ad Manager as the ad server, but the concept and implementation should be pretty similar to other ad servers.
@@ -69,7 +69,7 @@ This section describes the implementation using code samples, but ignores some o
### 1. Set up your ad slot
-In this example we'll store the ad slot info in a variable for reference throughout the page. We use a 1x1 static ad slot size since AppNexus (our demand partner in this example) uses that size for native creatives.
+In this example we'll store the ad slot info in a variable for reference throughout the page. We use a 1x1 static ad slot size since Microsoft (our demand partner in this example) uses that size for native creatives.
```javascript
const slot = {
@@ -145,9 +145,9 @@ pbjs.addAdUnits({
}
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13232354
+ placement_id: 13232354
}
}, ]
})
@@ -187,9 +187,9 @@ const adUnits = [{
}
}
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13232354
+ placement_id: 13232354
}
}]
}];
diff --git a/dev-docs/show-outstream-video-ads.md b/dev-docs/show-outstream-video-ads.md
index 5446854e22..c812889a27 100644
--- a/dev-docs/show-outstream-video-ads.md
+++ b/dev-docs/show-outstream-video-ads.md
@@ -48,9 +48,9 @@ var videoAdUnits = [{
}
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13232385,
+ placement_id: 13232385,
}
}]
}];
diff --git a/dev-docs/show-prebid-ads-on-amp-pages.md b/dev-docs/show-prebid-ads-on-amp-pages.md
index 78fdedc434..3c2073fab5 100644
--- a/dev-docs/show-prebid-ads-on-amp-pages.md
+++ b/dev-docs/show-prebid-ads-on-amp-pages.md
@@ -131,7 +131,7 @@ The `amp-ad` elements in the page body need to be set up as shown below, especia
- `vendors` is an object that defines any vendors that will be receiving RTC callouts (including Prebid Server) up to a maximum of five. The list of supported RTC vendors is maintained in [callout-vendors.js](https://github.com/ampproject/amphtml/blob/master/src/service/real-time-config/callout-vendors.js). We recommend working with your Prebid Server hosting company to set up which bidders and parameters should be involved for each AMP ad unit.
- `timeoutMillis` is an optional integer that defines the timeout in milliseconds for each individual RTC callout. The configured timeout must be greater than 0 and less than 1000ms. If omitted, the timeout value defaults to 1000ms.
-e.g. for the AppNexus cluster of Prebid Servers:
+e.g. for the Microsoft cluster of Prebid Servers:
```html
Place this code in the page header.
}
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13232361 // Add your own placement id here
+ placement_id: 13232361 // Add your own placement id here
}
}]
};
diff --git a/examples/video/instream/jwplayer/pb-ve-jwplayer-platform.html b/examples/video/instream/jwplayer/pb-ve-jwplayer-platform.html
index fe8c1035af..772fbd724f 100644
--- a/examples/video/instream/jwplayer/pb-ve-jwplayer-platform.html
+++ b/examples/video/instream/jwplayer/pb-ve-jwplayer-platform.html
@@ -67,9 +67,9 @@ Place this code in the page header.
}
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13232361 //put your placement id here
+ placement_id: 13232361 //put your placement id here
}
}]
};
diff --git a/examples/video/instream/videojs/pb-ve-videojs.html b/examples/video/instream/videojs/pb-ve-videojs.html
index 68ba056f49..d5884c418f 100644
--- a/examples/video/instream/videojs/pb-ve-videojs.html
+++ b/examples/video/instream/videojs/pb-ve-videojs.html
@@ -84,9 +84,9 @@ Place this code in the page header.
}
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13232361
+ placement_id: 13232361
}
}]
};
diff --git a/examples/video/long-form/long-form-video-with-freewheel.html b/examples/video/long-form/long-form-video-with-freewheel.html
index 28f5e06c6b..f88cd24d1d 100644
--- a/examples/video/long-form/long-form-video-with-freewheel.html
+++ b/examples/video/long-form/long-form-video-with-freewheel.html
@@ -68,9 +68,9 @@
},
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 14542875
+ placement_id: 14542875
}
}
]
@@ -329,9 +329,9 @@ Prebid Freewheel Integration Demo
},
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 14542875
+ placement_id: 14542875
}
}
]
diff --git a/examples/video/long-form/pb-ve-lf-freewheel.html b/examples/video/long-form/pb-ve-lf-freewheel.html
index bbf15b1a6d..cc2e7ff78c 100644
--- a/examples/video/long-form/pb-ve-lf-freewheel.html
+++ b/examples/video/long-form/pb-ve-lf-freewheel.html
@@ -85,9 +85,9 @@ {{ page.title }}
},
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 14542875
+ placement_id: 14542875
}
}
]
diff --git a/examples/video/outstream/basic-ima.html b/examples/video/outstream/basic-ima.html
index 6c853181c2..cdbad74405 100644
--- a/examples/video/outstream/basic-ima.html
+++ b/examples/video/outstream/basic-ima.html
@@ -136,9 +136,9 @@ {{ page.title }}
},
bids: [
{
- bidder: "appnexus",
+ bidder: "msft",
params: {
- placementId: 13232385,
+ placement_id: 13232385,
},
},
],
diff --git a/examples/video/outstream/pb-ve-outstream-dfp.html b/examples/video/outstream/pb-ve-outstream-dfp.html
index 803e067576..5b31ae0d2c 100644
--- a/examples/video/outstream/pb-ve-outstream-dfp.html
+++ b/examples/video/outstream/pb-ve-outstream-dfp.html
@@ -101,9 +101,9 @@ Place this code in the page header.
},
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13232385
+ placement_id: 13232385
}
}
]
diff --git a/examples/video/outstream/pb-ve-outstream-no-server-specify-renderer.html b/examples/video/outstream/pb-ve-outstream-no-server-specify-renderer.html
index eb53b2dd88..5154ac5f71 100644
--- a/examples/video/outstream/pb-ve-outstream-no-server-specify-renderer.html
+++ b/examples/video/outstream/pb-ve-outstream-no-server-specify-renderer.html
@@ -135,9 +135,9 @@ Place this code in the page header.
}
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13232385
+ placement_id: 13232385
}
}]
}];
@@ -149,7 +149,7 @@ Place this code in the page header.
intercept: [
{
when: {
- bidder: 'appnexus',
+ bidder: 'msft',
},
then: {
cpm: 10,
diff --git a/overview/how-to-simplify-line-item-setup.md b/overview/how-to-simplify-line-item-setup.md
index a470df22b4..44f1f6ce54 100644
--- a/overview/how-to-simplify-line-item-setup.md
+++ b/overview/how-to-simplify-line-item-setup.md
@@ -65,7 +65,7 @@ There you go!
### Simplification 2: Remove the bidder dimension
-In this section, we'll learn how to remove the bidder dimension for header bidding. Before, a publisher would have to create different set of line items for different bidders. For example, 3 different set of line items for AppNexus, Pubmatic, and Rubicon. With Prebid.js, a publisher only need to create 1 set of line items for all bidders.
+In this section, we'll learn how to remove the bidder dimension for header bidding. Before, a publisher would have to create different set of line items for different bidders. For example, 3 different set of line items for Microsoft, Pubmatic, and Rubicon. With Prebid.js, a publisher only need to create 1 set of line items for all bidders.
There're a few reasons why previously you'd need different set of line items for bidders.
@@ -73,14 +73,14 @@ There're a few reasons why previously you'd need different set of line items for
2. Bidders all have different targeting parameters.
3. You need to run reports to learn fill rates and CPM from different bidders.
-Assume we have 1 set of line items for ALL bidders. Consider the below key-value pairs came in: (AppNexus bid $1.60, Rubicon bid $1.20. Ad IDs are used for rendering the right creative):
+Assume we have 1 set of line items for ALL bidders. Consider the below key-value pairs came in: (Microsoft bid $1.60, Rubicon bid $1.20. Ad IDs are used for rendering the right creative):
-* `appnexus_cpm`: 1.60
-* `appnexus_adId`: 65432
+* `msft_cpm`: 1.60
+* `msft_adId`: 65432
* `rubicon_cpm`: 1.20
* `rubicon_adId`: 23456
-The line item for $1.60 is chosen because it has the highest price. However, the creative attached to this line item will be given both `appnexus_ad_id`: 65432 and `rubicon_ad_id`: 23456. There's not an easy way for the right creative (in this case the AppNexus creative) to render.
+The line item for $1.60 is chosen because it has the highest price. However, the creative attached to this line item will be given both `msft_ad_id`: 65432 and `rubicon_ad_id`: 23456. There's not an easy way for the right creative (in this case the Microsoft creative) to render.
@@ -90,7 +90,7 @@ Prebid.js only picks the highest price bid and sends its key-value pairs to the
* `hb_pb`: 1.60
* `hb_adId`: 65432
-* `hb_bidder`: appnexus
+* `hb_bidder`: msft
This simplifies the setup and the right creative (with adId 65432) will get displayed.
diff --git a/overview/prebid-universal-creative.md b/overview/prebid-universal-creative.md
index 9a1c5c8e7f..a3eb7ca400 100644
--- a/overview/prebid-universal-creative.md
+++ b/overview/prebid-universal-creative.md
@@ -45,7 +45,7 @@ Since version 10.11.0, Prebid.js populates the `hb_ver` ad server key-value whic
This loads the PUC from the Prebid-maintained location. Your managed
service provider may have a different location.
-To see specific examples of how to use the PUC within your ad server, see the guides for [GAM](/adops/gam-creative-banner-sbs.html), [Microsoft](/adops/setting-up-prebid-with-the-appnexus-ad-server.html), or [other ad servers](/adops/adops-general-sbs.html).
+To see specific examples of how to use the PUC within your ad server, see the guides for [GAM](/adops/gam-creative-banner-sbs.html), [Microsoft](/adops/setting-up-prebid-with-the-microsoft-ad-server.html), or [other ad servers](/adops/adops-general-sbs.html).
## Features of the PUC
@@ -114,5 +114,5 @@ If safeframe support is required, some options are:
## Further Reading
- [Step by Step Guide to Google Ad Manager Setup](/adops/step-by-step.html)
-- [Setting up Prebid with the Xandr Monetize Ad Server](/adops/setting-up-prebid-with-the-appnexus-ad-server.html)
+- [Setting up Prebid with the Xandr Monetize Ad Server](/adops/setting-up-prebid-with-the-microsoft-ad-server.html)
- [Prebid.js dynamic creatives](/adops/js-dynamic-creative.html)
diff --git a/overview/what-is-prebid-org.md b/overview/what-is-prebid-org.md
index cfba8f7a0c..08f0502e32 100644
--- a/overview/what-is-prebid-org.md
+++ b/overview/what-is-prebid-org.md
@@ -7,7 +7,7 @@ sidebarType: 0
# About Prebid.org
-Header bidding has seen incredible adoption across the industry, and Prebid.js has been an integral part of that. AppNexus (now Xandr) created Prebid.js, but considered it too important to be owned by any one company. Thus, Prebid.org was created.
+Header bidding has seen incredible adoption across the industry, and Prebid.js has been an integral part of that. AppNexus (now Microsoft) created Prebid.js, but considered it too important to be owned by any one company. Thus, Prebid.org was created.
Formed in September of 2017, Prebid.org is an independent organization designed to ensure and promote fair, transparent, and efficient header bidding across the industry. Funded by dues-paying members, it manages the open source projects Prebid.js, Prebid Mobile, Prebid Server, Prebid Video, Prebid Native, and others.
diff --git a/prebid-mobile/dr-prebid.md b/prebid-mobile/dr-prebid.md
index 4683098357..ea280bf0af 100644
--- a/prebid-mobile/dr-prebid.md
+++ b/prebid-mobile/dr-prebid.md
@@ -98,7 +98,7 @@ These settings will help verify that Prebid Mobile and Prebid Server are connect
Select your Prebid Server host:
-- *AppNexus*
+- *AppNexus (Microsoft)*
- *Rubicon*
- *Custom*
diff --git a/prebid-mobile/pbm-api/android/code-integration-android.md b/prebid-mobile/pbm-api/android/code-integration-android.md
index 911fc9e71b..a6028faf58 100644
--- a/prebid-mobile/pbm-api/android/code-integration-android.md
+++ b/prebid-mobile/pbm-api/android/code-integration-android.md
@@ -313,7 +313,7 @@ PrebidMobile.setStoredAuctionResponse("response-prebid-banner-320-50")
Stored Bid Responses are similar to Stored Auction Responses in that they signal to Prebid Server to respond with a static pre-defined response, except Stored Bid Responses is done at the bidder level, with bid requests sent out for any bidders not specified in the bidder parameter. For more information on how stored auction responses work, refer to the written [description on github issue 133](https://github.com/prebid/prebid-mobile-android/issues/133).
```kotlin
-PrebidMobile.addStoredBidResponse("appnexus", "221144");
+PrebidMobile.addStoredBidResponse("msft", "221144");
PrebidMobile.addStoredBidResponse("rubicon", "221155");
```
diff --git a/prebid-mobile/pbm-api/ios/code-integration-ios.md b/prebid-mobile/pbm-api/ios/code-integration-ios.md
index 0c61ddaf5e..83ffc1a219 100644
--- a/prebid-mobile/pbm-api/ios/code-integration-ios.md
+++ b/prebid-mobile/pbm-api/ios/code-integration-ios.md
@@ -402,7 +402,7 @@ Prebid.shared.pbsDebug = true
Prebid.shared.storedAuctionResponse = "111122223333"
//or
-Prebid.shared.addStoredBidResponse(bidder: "appnexus", responseId: "221144")
+Prebid.shared.addStoredBidResponse(bidder: "msft", responseId: "221144")
Prebid.shared.addStoredBidResponse(bidder: "rubicon", responseId: "221155")
```
diff --git a/prebid-server/developers/add-a-module-go.md b/prebid-server/developers/add-a-module-go.md
index 1b31e12647..663c3f0daf 100644
--- a/prebid-server/developers/add-a-module-go.md
+++ b/prebid-server/developers/add-a-module-go.md
@@ -229,11 +229,11 @@ Notes:
"attributes": []string{"bcat"},
"bcat": []string{"IAB-1"},
},
- AppliedTo: hookanalytics.AppliedTo{Bidder: "appnexus", ImpIds: []string{"imp_ID1"}},
+ AppliedTo: hookanalytics.AppliedTo{Bidder: "msft", ImpIds: []string{"imp_ID1"}},
},
{
Status: hookanalytics.ResultStatusAllow,
- AppliedTo: hookanalytics.AppliedTo{Bidder: "appnexus", ImpIds: []string{"imp_ID2"}},
+ AppliedTo: hookanalytics.AppliedTo{Bidder: "msft", ImpIds: []string{"imp_ID2"}},
},
},
},
diff --git a/prebid-server/developers/add-new-bidder-go.md b/prebid-server/developers/add-new-bidder-go.md
index b9593b57ce..ea830a8783 100644
--- a/prebid-server/developers/add-new-bidder-go.md
+++ b/prebid-server/developers/add-new-bidder-go.md
@@ -1066,7 +1066,7 @@ func newAdapterBuilders() map[openrtb_ext.BidderName]adapters.Builder {
You need to provide default settings for your bid adapter. You can decide if you'd like your bid adapter to be enabled out of the box, and if so, you'll need to provide a default endpoint and default extra adapter info (if applicable). If your bid adapter requires host specific information to function properly, such as a security token or host account, then it's best to leave the adapter disabled.
{: .alert.alert-warning :}
-**HOST SPECIFIC INFO:** The default endpoint must not be specific to any particular host, such as Xandr/AppNexus. We may ask you about suspicious looking ids during the review process. Please reach out to individual hosts if you need to set specialized configuration.
+**HOST SPECIFIC INFO:** The default endpoint must not be specific to any particular host, such as Microsoft/AppNexus. We may ask you about suspicious looking ids during the review process. Please reach out to individual hosts if you need to set specialized configuration.
## Aliasing an Adapter
@@ -1077,7 +1077,7 @@ the whole adapter codebase. Rather, follow these steps to create a 'hardcoded' a
1. Add "aliasOf" in the config.yaml file with its value set to the name of the adapter you are creating an alias for
```yaml
-aliasOf: "appnexus"
+aliasOf: "msft"
```
Notes:
diff --git a/prebid-server/endpoints/info/pbs-endpoint-info.md b/prebid-server/endpoints/info/pbs-endpoint-info.md
index f9b5713ea4..6e8f85ff68 100644
--- a/prebid-server/endpoints/info/pbs-endpoint-info.md
+++ b/prebid-server/endpoints/info/pbs-endpoint-info.md
@@ -26,7 +26,7 @@ This endpoint returns JSON like:
```json
[
- "appnexus",
+ "msft",
"audienceNetwork",
"pubmatic",
"rubicon",
@@ -94,7 +94,7 @@ For example:
```json
{
- "appnexus": { /* A json-schema describing AppNexus' bidder params */ },
+ "msft": { /* A json-schema describing Microsoft's bidder params */ },
"magnite": { /* A json-schema describing Rubicon's bidder params */ },
"otherBidder": { /* A json-schema describing Rubicon's bidder params */ }
}
diff --git a/prebid-server/endpoints/openrtb2/pbs-endpoint-amp.md b/prebid-server/endpoints/openrtb2/pbs-endpoint-amp.md
index c1e56de9ed..6307c4515c 100644
--- a/prebid-server/endpoints/openrtb2/pbs-endpoint-amp.md
+++ b/prebid-server/endpoints/openrtb2/pbs-endpoint-amp.md
@@ -147,15 +147,15 @@ A sample response payload looks like this:
```javascript
{
"targeting": {
- "hb_bidder": "appnexus",
- "hb_bidder_appnexus": "appnexus",
+ "hb_bidder": "msft",
+ "hb_bidder_msft": "msft",
"hb_cache_id": "420d7329-30e8-4c4e-8eaa-fe937172e4e0",
- "hb_cache_id_appnexus": "420d7329-30e8-4c4e-8eaa-fe937172e4e0",
+ "hb_cache_id_msft": "420d7329-30e8-4c4e-8eaa-fe937172e4e0",
"hb_creative_loadtype": "html",
"hb_pb": "0.50",
- "hb_pb_appnexus": "0.50",
+ "hb_pb_msft": "0.50",
"hb_size": "300x250",
- "hb_size_appnexus": "300x250",
+ "hb_size_msft": "300x250",
"hb_env": "amp" // PBS-Java only
}
"errors": {
diff --git a/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.md b/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.md
index ff592862e8..e18b502002 100644
--- a/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.md
+++ b/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.md
@@ -739,18 +739,18 @@ This can be used to request bids from the same Bidder with different params. For
"mimes": ["video/mp4"]
},
"ext": {
- "appnexus": {
- "placementId": 123
+ "msft": {
+ "placement_id": 123
},
"districtm": {
- "placementId": 456
+ "placement_id": 456
}
}
}],
"ext": {
"prebid": {
"aliases": {
- "districtm": "appnexus"
+ "districtm": "msft"
}
}
}
@@ -768,12 +768,12 @@ For example, if the Request defines an alias like this:
```json5
"aliases": {
- "appnexus": "rubicon"
+ "msft": "rubicon"
}
```
-then any `imp[].ext.appnexus` params will actually go to the **rubicon** adapter.
-It will become impossible to fetch bids from AppNexus within that Request.
+then any `imp[].ext.msft` params will actually go to the **rubicon** adapter.
+It will become impossible to fetch bids from Microsoft within that Request.
##### Bidder Alias GVL IDs
@@ -1923,9 +1923,9 @@ For example, a request may return this in `response.ext`
{
"ext": {
"errors": {
- "appnexus": [{
+ "msft": [{
"code": 2,
- "message": "A hybrid Banner/Audio Imp was offered, but Appnexus doesn't support Audio."
+ "message": "A hybrid Banner/Audio Imp was offered, but Microsoft doesn't support Audio."
}],
"rubicon": [{
"code": 1,
diff --git a/prebid-server/endpoints/openrtb2/pbs-endpoint-video.md b/prebid-server/endpoints/openrtb2/pbs-endpoint-video.md
index b098600c34..34295d37d1 100644
--- a/prebid-server/endpoints/openrtb2/pbs-endpoint-video.md
+++ b/prebid-server/endpoints/openrtb2/pbs-endpoint-video.md
@@ -62,12 +62,12 @@ These key-values are returned to the SSAI server as part of the video response.
| podconfig.pods | Required | `Object[]` | Container object for describing the adPod(s) to be requested. |
| site | Required | `Object` | Container object for the URL of the impression to be shown. Can be excluded if app is included. |
| site.page | Required | `String` | URL of the page where the impression will be shown. |
-| site.publisher.id | Required | `String` | Appnexus member ID. |
+| site.publisher.id | Required | `String` | Microsoft member ID. |
| app | Required | `Object` | Container object for app information where the impression is to be shown. Can be excluded if site is included. |
| app.bundle | Optional | `String` | A platform-specific application identifier intended to be unique to the app and independent of the exchange. On Android, this should be a bundle or package name (e.g., com.foo.mygame). On iOS, it is typically a numeric ID. |
| app.domain | Required | `String` | The domain of the app. |
| app.name | Optional | `String` | The name of the app. |
-| app.publisher.id | Required | `String` | Appnexus member ID. |
+| app.publisher.id | Required | `String` | Microsoft member ID. |
| app.storeurl | Optional | `String` | App store URL for an installed app. |
| video | Required | `Object` | Container object for video player data. |
| video.w | Optional | `Integer` | Width of the video player in device independent pixels. |
@@ -169,7 +169,7 @@ These are the supported (registered) bidder names.
* "adform"
* "adkernelAdn"
* "adtelligent"
-* "appnexus"
+* "msft"
* "audienceNetwork"
* "beachfront"
* "eplanning"
@@ -241,7 +241,7 @@ Publishers can comply with CCPA regulations by setting `regs.ext.us.privacy` to
"yob": 1982,
"gender": "M",
"buyeruids": {
- "appnexus": "unique_id_an"
+ "msft": "unique_id_an"
},
"gdpr": {
"consentrequired": false,
diff --git a/prebid-server/features/pbs-default-request.md b/prebid-server/features/pbs-default-request.md
index 5053f8401d..c94fae0ef5 100644
--- a/prebid-server/features/pbs-default-request.md
+++ b/prebid-server/features/pbs-default-request.md
@@ -43,7 +43,7 @@ For both PBS-Go and PBS-Java, here's an example default request file:
"ext": {
"prebid": {
"aliases": {
- "districtm": "appnexus"
+ "districtm": "msft"
}
}
}
diff --git a/prebid-server/features/pbs-storedreqs-go.md b/prebid-server/features/pbs-storedreqs-go.md
index 92b8bb4e63..0110de7b98 100644
--- a/prebid-server/features/pbs-storedreqs-go.md
+++ b/prebid-server/features/pbs-storedreqs-go.md
@@ -39,7 +39,7 @@ Add the file `stored_requests/data/by_id/stored_imps/{id}.json` and populate it
"ext": {
"prebid": {
"bidder": {
- "appnexus": {
+ "msft": {
"placement_id": 12883451
}
}
@@ -97,7 +97,7 @@ You can also store _part_ of the Imp on the server. For example:
"ext": {
"prebid": {
"bidder": {
- "appnexus": {
+ "msft": {
"placement_id": 12883451
}
}
diff --git a/prebid-server/features/pbs-storedreqs-java.md b/prebid-server/features/pbs-storedreqs-java.md
index d9249deb78..c354b9da19 100644
--- a/prebid-server/features/pbs-storedreqs-java.md
+++ b/prebid-server/features/pbs-storedreqs-java.md
@@ -53,7 +53,7 @@ Add the file `stored_imps/{id}.json` and populate it with some [imp](https://www
"ext": {
"prebid": {
"bidder": {
- "appnexus": {
+ "msft": {
"placement_id": 10433394
}
}
@@ -104,7 +104,7 @@ You can also store _part_ of the `imp` on the server. For example:
"ext": {
"prebid": {
"bidder": {
- "appnexus": {
+ "msft": {
"placement_id": 10433394
}
}
diff --git a/prebid-server/pbs-modules/greenbids-real-time-data.md b/prebid-server/pbs-modules/greenbids-real-time-data.md
index 062366d70a..c67f47c56b 100644
--- a/prebid-server/pbs-modules/greenbids-real-time-data.md
+++ b/prebid-server/pbs-modules/greenbids-real-time-data.md
@@ -204,7 +204,7 @@ Here's an example analytics tag that might be produced for use in an analytics a
"fingerprint": "ad63524e-b13f-4359-a975-dba9b5dc08f4",
"keptInAuction": {
"improvedigital": false,
- "appnexus": true,
+ "msft": true,
"pubmatic": false,
"rubicon": true,
"teads": false
diff --git a/prebid-server/use-cases/pbs-amp.md b/prebid-server/use-cases/pbs-amp.md
index bf2b03b61c..089e192528 100644
--- a/prebid-server/use-cases/pbs-amp.md
+++ b/prebid-server/use-cases/pbs-amp.md
@@ -52,7 +52,7 @@ There are two basic ways of invoking AMP RTC:
```
{: .alert.alert-info :}
-**Note:** the `prebidrubicon` and `prebidappnexuspsp` AMP vendor strings define slightly different parameters; AppNexus uses "PLACEMENT_ID" as the argument to rtc-config while Rubicon uses "REQUEST_ID". They both translate to `tag_id` when passed to Prebid Server.
+**Note:** the `prebidrubicon` and `prebidappnexuspsp` AMP vendor strings define slightly different parameters; Microsoft uses "PLACEMENT_ID" as the argument to rtc-config while Rubicon uses "REQUEST_ID". They both translate to `tag_id` when passed to Prebid Server.
- The other option is to construct a direct URL from component pieces: w, h, slot, targeting, gdpr_consent, account, page url (purl), etc.
diff --git a/prebid-server/use-cases/pbs-sdk.md b/prebid-server/use-cases/pbs-sdk.md
index dd14f5de6c..4638855806 100644
--- a/prebid-server/use-cases/pbs-sdk.md
+++ b/prebid-server/use-cases/pbs-sdk.md
@@ -63,7 +63,7 @@ The resulting OpenRTB generated by the SDK and sent to Prebid Server would be:
{
"id": "random-uuid",
"app": {
- "bundle": "AppNexus.PrebidMobileDemo",
+ "bundle": "Microsoft.PrebidMobileDemo",
"ext": {
"prebid": {
"version": "0.2.0",
diff --git a/prebid-video/video-integrating-solo.md b/prebid-video/video-integrating-solo.md
index eb6095632f..cc770c93d3 100644
--- a/prebid-video/video-integrating-solo.md
+++ b/prebid-video/video-integrating-solo.md
@@ -38,15 +38,15 @@ The mediaTypes.video.playerSize field is where you define the player size that w
For full details on video ad unit parameters, see [Ad Unit Reference for Video]({{site.baseurl}}/dev-docs/adunit-reference.html#adunitmediatypesvideo)
-In your ad unit you also need to define your list of bidders. For example, including AppNexus as a bidder would look something like this:
+In your ad unit you also need to define your list of bidders. For example, including Microsoft as a bidder would look something like this:
```javascript
var adUnit1 = {
// ...
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: '123456789',
+ placement_id: '123456789',
}
}]
}
diff --git a/prebid-video/video-long-form.md b/prebid-video/video-long-form.md
index 38bed5fbbe..d8feb2caa7 100644
--- a/prebid-video/video-long-form.md
+++ b/prebid-video/video-long-form.md
@@ -78,9 +78,9 @@ var longFormatAdUnit = {
}
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 123456789,
+ placement_id: 123456789,
}
}]
}
@@ -171,7 +171,7 @@ pbjs.setConfig({
adpod: {
prioritizeDeals: true,
dealTier: {
- 'appnexus': {
+ 'msft': {
prefix: 'tier',
minDealTier: 5
},
diff --git a/tools/line-item-manager.md b/tools/line-item-manager.md
index de88441b0b..975fa0a234 100644
--- a/tools/line-item-manager.md
+++ b/tools/line-item-manager.md
@@ -131,10 +131,10 @@ This would create a set of orders for bidder Rubicon
{:class="pb-xlg-img"}
```bash
-line_item_manager create my_config.yml -b rubicon -b appnexus -b openx
+line_item_manager create my_config.yml -b rubicon -b msft -b openx
```
-This would create a set of orders for bidders Rubicon, Appnexus and OpenX
+This would create a set of orders for bidders Rubicon, Microsoft and OpenX
{:class="pb-xlg-img"}
diff --git a/troubleshooting/troubleshooting-guide.md b/troubleshooting/troubleshooting-guide.md
index d62d726bc1..9641cdd4a5 100644
--- a/troubleshooting/troubleshooting-guide.md
+++ b/troubleshooting/troubleshooting-guide.md
@@ -376,7 +376,7 @@ The following parameters in the `bidResponse` object are common across all bidde
{: .table .table-bordered .table-striped }
| Name | Type | Description | Example |
|----------+---------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------|
-| `bidder` | String | Unique bidder code used by ad server's line items to identify the bidder | `"appnexus"` |
+| `bidder` | String | Unique bidder code used by ad server's line items to identify the bidder | `"msft"` |
| `adId` | String | Unique identifier of a bid creative. Used by the line item's creative as in [this example](/adops/gam-creative-banner-sbs.html) | `"123"` |
| `pbLg` | String | Low granularity price bucket: $0.50 increment, capped at $5, floored to 2 decimal places (0.50, 1.00, 1.50, ..., 5.00) | `"1.50"` |
| `pbMg` | String | Medium granularity price bucket: 0.10 increment, capped at $20, floored to 2 decimal places (0.10, 0.20, ..., 19.90, 20.00) | `"1.60"` |
@@ -395,7 +395,7 @@ The below snippet can be added to your page to better understand the Auction whe
```javascript
pbjs.que.push(function() {
pbjs.addAdUnits(adUnits);
- pbjs.aliasBidder('appnexus', 'waitForMe');
+ pbjs.aliasBidder('msft', 'waitForMe');
pbjs.aliasBidder('rubicon', 'doNotWaitForMe');
pbjs.setConfig({
'auctionOptions': {
'
diff --git a/dev-docs/examples/meta-bid-filtering.md b/dev-docs/examples/meta-bid-filtering.md
index 7ff0d28077..79d167923a 100644
--- a/dev-docs/examples/meta-bid-filtering.md
+++ b/dev-docs/examples/meta-bid-filtering.md
@@ -38,9 +38,9 @@ var adUnits = [{
}
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13144370
+ placement_id: 13144370
},
}]
diff --git a/dev-docs/examples/native-ad-example.md b/dev-docs/examples/native-ad-example.md
index 4d87c6fe72..a2032dd2aa 100644
--- a/dev-docs/examples/native-ad-example.md
+++ b/dev-docs/examples/native-ad-example.md
@@ -95,9 +95,9 @@ pbjs.que.push(function() {
}
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13232354,
+ placement_id: 13232354,
allowSmallerSizes: true
}
}]
@@ -127,9 +127,9 @@ pbjs.que.push(function() {
}
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13232354,
+ placement_id: 13232354,
allowSmallerSizes: true
}
}]
diff --git a/dev-docs/examples/no-adserver.md b/dev-docs/examples/no-adserver.md
index c1b2dee071..141e7f5490 100644
--- a/dev-docs/examples/no-adserver.md
+++ b/dev-docs/examples/no-adserver.md
@@ -30,9 +30,9 @@ jsfiddle_link: jsfiddle.net/Prebid_Examples/svumodbe/embedded/html,result
},
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13144370
+ placement_id: 13144370
}
}
]
@@ -46,9 +46,9 @@ jsfiddle_link: jsfiddle.net/Prebid_Examples/svumodbe/embedded/html,result
},
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13144370
+ placement_id: 13144370
}
}
]
diff --git a/dev-docs/examples/postbid.md b/dev-docs/examples/postbid.md
index b4e0579047..1b7623917e 100644
--- a/dev-docs/examples/postbid.md
+++ b/dev-docs/examples/postbid.md
@@ -44,9 +44,9 @@ var adUnits = [{
}
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13144370
+ placement_id: 13144370
}
}]
}];
diff --git a/dev-docs/examples/size-mapping.md b/dev-docs/examples/size-mapping.md
index 4ad3401392..e54918a5da 100644
--- a/dev-docs/examples/size-mapping.md
+++ b/dev-docs/examples/size-mapping.md
@@ -59,9 +59,9 @@ var adUnits = [
},
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13144370
+ placement_id: 13144370
}
}
]
diff --git a/dev-docs/examples/sync-tid.md b/dev-docs/examples/sync-tid.md
index 0922e41ffd..69ae0a0d00 100644
--- a/dev-docs/examples/sync-tid.md
+++ b/dev-docs/examples/sync-tid.md
@@ -69,9 +69,9 @@ pbjs.que.push(function() {
},
bids: [
{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13144370,
+ placement_id: 13144370,
},
},
],
diff --git a/dev-docs/examples/use-prebid-with-appnexus-ad-server.md b/dev-docs/examples/use-prebid-with-microsoft-ad-server.md
similarity index 95%
rename from dev-docs/examples/use-prebid-with-appnexus-ad-server.md
rename to dev-docs/examples/use-prebid-with-microsoft-ad-server.md
index 45dbb89fad..7efe0d663d 100644
--- a/dev-docs/examples/use-prebid-with-appnexus-ad-server.md
+++ b/dev-docs/examples/use-prebid-with-microsoft-ad-server.md
@@ -58,9 +58,9 @@ var adUnits = [
}
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13144370
+ placement_id: 13144370
}
}]
},
@@ -72,9 +72,9 @@ var adUnits = [
}
},
bids: [{
- bidder: 'appnexus',
+ bidder: 'msft',
params: {
- placementId: 13144370
+ placement_id: 13144370
}
}]
}
diff --git a/dev-docs/modules/1plusXRtdProvider.md b/dev-docs/modules/1plusXRtdProvider.md
index 8ce79efad6..1e0c25c357 100644
--- a/dev-docs/modules/1plusXRtdProvider.md
+++ b/dev-docs/modules/1plusXRtdProvider.md
@@ -26,7 +26,7 @@ The 1plusX RTD module appends User and Contextual segments to the bidding object
1. Compile the 1plusX RTD Module along with your bid adapter and other modules into your Prebid build:
```bash
- gulp build --modules="rtdModule,1plusXRtdProvider,appnexusBidAdapter,..."
+ gulp build --modules="rtdModule,1plusXRtdProvider,msftBidAdapter,..."
```
2. Use `setConfig` to instruct Prebid.js to initilize the 1plusX RTD module, as specified below.
@@ -45,7 +45,7 @@ pbjs.setConfig({
waitForIt: true,
params: {
customerId: 'acme',
- bidders: ['appnexus', 'rubicon'],
+ bidders: ['msft', 'rubicon'],
timeout: TIMEOUT,
fpidStorageType: 'html5'
}
diff --git a/dev-docs/modules/51DegreesRtdProvider.md b/dev-docs/modules/51DegreesRtdProvider.md
index eb5ef9fc90..708a63de13 100644
--- a/dev-docs/modules/51DegreesRtdProvider.md
+++ b/dev-docs/modules/51DegreesRtdProvider.md
@@ -56,7 +56,7 @@ Free cloud and on premise solutions can be expanded to support unlimited request
Compile the 51Degrees RTD Module with other modules and adapters into your Prebid.js build:
```bash
-gulp build --modules="rtdModule,51DegreesRtdProvider,appnexusBidAdapter,..."
+gulp build --modules="rtdModule,51DegreesRtdProvider,msftBidAdapter,..."
```
> Note that the 51Degrees RTD module is dependent on the global real-time data module, `rtdModule`.
@@ -171,7 +171,7 @@ pbjs.setConfig({
If you want to see an example of how the 51Degrees RTD module works,\
run the following command:
-`gulp serve --modules=rtdModule,51DegreesRtdProvider,appnexusBidAdapter`
+`gulp serve --modules=rtdModule,51DegreesRtdProvider,msftBidAdapter`
and then open the following URL in your browser:
diff --git a/dev-docs/modules/adpod.md b/dev-docs/modules/adpod.md
index 9e173e4f4e..60426e3220 100644
--- a/dev-docs/modules/adpod.md
+++ b/dev-docs/modules/adpod.md
@@ -83,7 +83,7 @@ pbjs.setConfig({
adpod: {
prioritizeDeals: true,
dealTier: {
- 'appnexus': {
+ 'msft': {
prefix: 'tier',
minDealTier: 5
},
diff --git a/dev-docs/modules/airgridRtdProvider.md b/dev-docs/modules/airgridRtdProvider.md
index 3e06e61d00..e85b72f43c 100644
--- a/dev-docs/modules/airgridRtdProvider.md
+++ b/dev-docs/modules/airgridRtdProvider.md
@@ -27,7 +27,7 @@ injected into bid request objects destined for different bidders in order to opt
Compile the AirGrid RTD module (`airgridRtdProvider`) into your Prebid build, along with the parent RTD Module (`rtdModule`):
-`gulp build --modules=rtdModule,airgridRtdProvider,appnexusBidAdapter`
+`gulp build --modules=rtdModule,airgridRtdProvider,msftBidAdapter`
Next we configure the module, via `pbjs.setConfig`. See the **Parameter Descriptions** below for more detailed information of the configuration parameters.
@@ -45,7 +45,7 @@ pbjs.setConfig(
apiKey: 'apiKey',
accountId: 'accountId',
publisherId: 'publisherId',
- bidders: ['appnexus', 'pubmatic']
+ bidders: ['msft', 'pubmatic']
}
}
]
@@ -66,7 +66,7 @@ pbjs.setConfig(
| params.publisherId | `String` | Publisher partner specific publisher ID | Required |
| params.bidders | `Array` | Bidders with which to share segment information | Optional |
-_Note: Although the module supports passing segment data to any bidder using the ORTB2 spec, there is no way for this to be currently monetised. Please reach out to support, to discuss using bidders other than Xandr/AppNexus._
+_Note: Although the module supports passing segment data to any bidder using the ORTB2 spec, there is no way for this to be currently monetised. Please reach out to support, to discuss using bidders other than Xandr/Microsoft._
If you do not have your own `apiKey`, `accountId` & `publisherId` please reach out to [support@airgrid.io](mailto:support@airgrid.io) or you can sign up via the [AirGrid platform](https://app.airgrid.io).
@@ -75,7 +75,7 @@ If you do not have your own `apiKey`, `accountId` & `publisherId` please reach o
To view an example of the on page setup required:
```bash
-gulp serve-fast --modules=rtdModule,airgridRtdProvider,appnexusBidAdapter
+gulp serve-fast --modules=rtdModule,airgridRtdProvider,msftBidAdapter
```
Then in your browser access:
diff --git a/dev-docs/modules/anonymisedRtdProvider.md b/dev-docs/modules/anonymisedRtdProvider.md
index d69192bd34..745ebc9eac 100644
--- a/dev-docs/modules/anonymisedRtdProvider.md
+++ b/dev-docs/modules/anonymisedRtdProvider.md
@@ -37,7 +37,7 @@ gulp build --modules=rtdModule,anonymisedRtdProvider,...
waitForIt: true,
params: {
cohortStorageKey: "cohort_ids",
- bidders: ["appnexus", "onetag", "pubmatic", "smartadserver", ...],
+ bidders: ["msft", "onetag", "pubmatic", "smartadserver", ...],
segtax: 1000,
tagConfig: {
clientId: 'testId'
diff --git a/dev-docs/modules/blueconicRtdProvider.md b/dev-docs/modules/blueconicRtdProvider.md
index a419c0da36..d73442bb8e 100644
--- a/dev-docs/modules/blueconicRtdProvider.md
+++ b/dev-docs/modules/blueconicRtdProvider.md
@@ -24,7 +24,7 @@ BlueConic's Real-time Data Provider automatically obtains segmentation data and
Compile the BlueConic RTD module into your Prebid build:
-`gulp build --modules=rtdModule,blueconicRtdProvider,appnexusBidAdapter`
+`gulp build --modules=rtdModule,blueconicRtdProvider,msftBidAdapter`
Add the BlueConic RTD provider to your Prebid config. In this example we will configure
publisher 1234 to retrieve segments, profile data from BlueConic. See the
@@ -71,13 +71,13 @@ tests.
To run test suite for blueconic:
-`gulp test --modules=rtdModule,blueconicRtdProvider,appnexusBidAdapter`
+`gulp test --modules=rtdModule,blueconicRtdProvider,msftBidAdapter`
## Example
To view an example of available segments & profile data:
-`gulp serve --modules=rtdModule,blueconicRtdProvider,appnexusBidAdapter`
+`gulp serve --modules=rtdModule,blueconicRtdProvider,msftBidAdapter`
and then point your browser at:
diff --git a/dev-docs/modules/captifyRtdProvider.md b/dev-docs/modules/captifyRtdProvider.md
index e8de341105..44acdb7755 100644
--- a/dev-docs/modules/captifyRtdProvider.md
+++ b/dev-docs/modules/captifyRtdProvider.md
@@ -37,7 +37,7 @@ Contact