-
-
-
+
+ Header bidding unwrapped
-Earn more from your advertising with Prebid, a transparent, open-source solution that increases advertiser demand while maintaining a fast and responsive user experience.
-
+
+
-
-
-
-
-
-
-If you're a company providing Managed Prebid Solutions, [join Prebid.org](/overview/what-is-prebid-org.html) to get on this list.
diff --git a/prebid/prebidjsReleases.md b/prebid/prebidjsReleases.md
index 9ec879476c..068e50e609 100644
--- a/prebid/prebidjsReleases.md
+++ b/prebid/prebidjsReleases.md
@@ -16,6 +16,15 @@ The table below is a summary of feature changes and important bug fixes in core
{: .table .table-bordered .table-striped }
| Release | Feature |
| --- | --- |
+| 4.8 | GDPR updates around modules and storage manager. |
+| 4.6 | Removed cmpuishown event for TCF2 logic |
+| 4.5 | Price Floors: Add bid object into cpmAdjustment function |
+| 4.4 | DFP Video Module supports VAST 4 |
+| 4.3 | DFP Video Module bug fixed |
+| 4.1.1 | Release of the [GPT Pre-Auction Module](https://docs.prebid.org/dev-docs/modules/gpt-pre-auction.html). Price Floors: new signals (location: noData + floorProvider) |
+| 4.0 | TCF Purpose 1 and Purpose 2 enforced by default when GDPR enforcement module turned on. Removed Digitrust userId module. Removed audienceNetworkBidAdapter. |
+| 3.27.1 | DFP Video Module bug fixed |
+| 3.27 | An important bug in the DFP Video Module was introduced with this release and fixed in 4.3 and 3.27.1. The dfpVideoModule only looked in adunit.sizes but adunit.sizes was stripped. Unfortunately there's not a workaround - if you use that video module, you shouldn't use Prebid.js 3.27 through 4.2 inclusive. |
| 3.24 | PBS Bid Adapter allows setting site params |
| 3.23 | If a server-side bid contains imp.ext.prebid.event.win, pbsBidAdapter listens to BidsWon events and hits the URL. |
| 3.22 | Secure creatives use event.origin rather than a hard coded adServerDomain |
diff --git a/principles.md b/principles.md
index 8ac27dff2a..7143451e65 100644
--- a/principles.md
+++ b/principles.md
@@ -3,9 +3,6 @@ layout: page_v2
title: Project Principles
head_title: Project Principles
description: A set of principles that guide how we develop Prebid
-pid: 0
-top_nav_section: overview
-nav_section: intro
sidebarType: 0
---
@@ -13,7 +10,7 @@ sidebarType: 0
# Project Principles
-Prebid.org uses the following principles to guide how we develop [Prebid.js]({{site.baseurl}}/prebid/prebidjs.html), [Prebid Server]({{site.baseurl}}/prebid-server/prebid-server-overview.html), [Prebid Mobile]({{site.baseurl}}/prebid-mobile/prebid-mobile.html), and any future sub-projects:
+Prebid.org uses the following principles to guide how we develop [Prebid.js]({{site.baseurl}}/prebid/prebidjs.html), [Prebid Server](/prebid-server/overview/prebid-server-overview.html), [Prebid Mobile](/prebid-mobile/prebid-mobile.html), and any future sub-projects:
+ **Collaborative**: Foster a community of contribution.
diff --git a/privacy.md b/privacy.md
index b3cc26146d..74373d2556 100644
--- a/privacy.md
+++ b/privacy.md
@@ -8,9 +8,10 @@ sidebarType: 0
# Prebid.org Website Privacy Policy
{:.no_toc}
-Last updated Dec 18, 2018
+Last updated Aug 5, 2020
Prebid.org, Inc. respects your right to privacy. This Privacy Notice explains who we are, how we collect, share and use personal information about you, and how you can exercise your privacy rights. This Privacy Notice applies to personal information that we collect through our website at [https://prebid.org/](https://prebid.org/) and its subdomains ("**Website**") and via our marketing activities and events.
+This Privacy Notice does not apply to any information collected by third parties using our open source software.
If you have any questions or concerns about our use of your personal information, then please contact us using the contact details provided at the bottom of this Privacy Notice.
@@ -26,10 +27,11 @@ We recommend that you read this Privacy Notice in full to ensure you are fully i
Prebid.org is an industry consortium that provides free and open source solutions to implement header bidding. We’re utilized globally and headquartered in the United States. We seek to ensure and promote fair, transparent, and efficient header bidding across the ad tech industry, representing all parts of the programmatic ecosystem, from ad tech vendors to publishers and others.
-The open source software products we make available may be utilized by third parties for the purposes of serving online advertisements. These third parties may configure the software to enable pseudonymized data included in bid requests to be transmitted within the online advertising ecosystem. However, Prebid.org has no involvement in these transactions and does not itself transmit, store or otherwise process the pseudonymized data in these transactions. Prebid.org is not responsible for the privacy practices of such third parties and it is the responsibility of the third party concerned to handle data in accordance with applicable privacy laws.
+The open source software products we make available may be utilized by third parties for the purposes of serving online advertisements. These third parties may configure the software to enable pseudonymized data included in bid requests to be transmitted within the online advertising ecosystem. However, Prebid.org has no involvement in these transactions and does not itself transmit, store or otherwise process the pseudonymized data in these transactions. Prebid.org is not responsible for the privacy practices of third parties that use our software and it is the responsibility of the third party concerned to handle data in accordance with applicable privacy laws.
For more information about Prebid.org, please see the “About” section of our Website at [https://prebid.org/overview/what-is-prebid-org.html](/overview/what-is-prebid-org.html).
+
## What personal information does Prebid.org collect and why?
The personal information that we may collect from our Website or through our marketing activities broadly falls into the following categories:
@@ -56,6 +58,7 @@ Collecting this information enables us to better understand the visitors who com
Some of this information may be collected using cookies and similar tracking technology, as explained further in our [Cookies Notice](/cookies.html).
+
## Who does Prebid.org share my personal information with?
We may disclose your personal information to the following categories of recipients:
@@ -92,7 +95,7 @@ We use appropriate technical and organisational measures to protect the personal
Your personal information may be transferred to, and processed in, countries other than the country in which you are resident. We are headquartered in the US, and our member companies and third party service providers and partners operate around the world. Therefore, when we collect your personal information, we may process it in countries that have data protection laws that are different to the laws of your country and in some cases, may not be as protective.
-We will take appropriate safeguards to ensure that your personal information will remain protected in accordance with this Privacy Notice, including signing standard contractual clauses with our third party service providers, or engaging third party service providers that are Privacy Shield certified. Further details can be provided upon request – please write to us using the contact details further below.
+We will take appropriate safeguards to ensure that your personal information will remain protected in accordance with this Privacy Notice, including signing standard contractual clauses with our third party service providers. Further details can be provided upon request – please write to us using the contact details further below.
## Data retention
@@ -100,21 +103,39 @@ We retain personal information we collect from you where we have an ongoing legi
When we have no ongoing legitimate business need to process your personal information, we will either delete or anonymise it or, if this is not possible (for example, because your personal information has been stored in backup archives), then we will securely store your personal information and isolate it from any further processing until deletion is possible.
+
## Your data protection rights
-If you are a resident of the European Economic Area, you have the following data protection rights:
+If you are a resident of the European Economic Area or California, you have the right to request to access or request deletion of your personal information. You may exercise this right at any time by using the contact details provided under the ["How to contact us"](#contact) heading below.
-* If you wish to access, correct, update or request deletion of your personal information, you can do so at any time by using the contact details provided under the ["How to contact us"](#contact) heading below.
+In addition, if you are a resident of the European Economic Area, you have the following additional data protection rights:
-* In addition, you can object to processing of your personal information, ask us to restrict processing of your personal information or request portability of your personal information. Again, you can exercise these rights by contacting us using the contact details provided under the ["How to contact us"](#contact) heading below.
+* You may object to processing of your personal information, ask us to restrict processing of your personal information or request portability or correction of your personal information. Again, you can exercise these rights by contacting us using the contact details provided under the ["How to contact us"](#contact) heading below.
+* If we have collected and processed your personal information with your consent, then you can withdraw your consent at any time. Withdrawing your consent will not affect the lawfulness of any processing we conducted prior to your withdrawal, nor will it affect processing of your personal information conducted in reliance on lawful processing grounds other than consent.
+* You have the right to complain to a data protection authority about our collection and use of your personal information. For more information, please contact your local data protection authority. Contact details for data protection authorities in the European Economic Area are available [here](https://ec.europa.eu/justice/data-protection/article-29/structure/data-protection-authorities/index_en.htm).
-* You have the right to opt-out of marketing communications we send you at any time. You can exercise this right by clicking on the "unsubscribe" or "opt-out" link in the marketing e-mails we send you. Alternatively, you can opt out by using the contact details provided under the ["How to contact us"](#contact) heading below.
+Everyone has the right to opt-out of marketing communications we send you
+at any time. You can exercise this right by clicking on the "unsubscribe" or
+"opt-out" link in the marketing e-mails we send you. Alternatively, you can opt
+out by using the contact details provided under the ["How to contact us"](#contact) heading below.
-* Similarly, if we have collected and processed your personal information with your consent, then you can withdraw your consent at any time. Withdrawing your consent will not affect the lawfulness of any processing we conducted prior to your withdrawal, nor will it affect processing of your personal information conducted in reliance on lawful processing grounds other than consent.
+We respond to all requests we receive from individuals wishing to exercise their data protection rights in accordance with applicable data protection laws.
-* You have the right to complain to a data protection authority about our collection and use of your personal information. For more information, please contact your local data protection authority. Contact details for data protection authorities in the European Economic Area are available [here](https://ec.europa.eu/justice/data-protection/article-29/structure/data-protection-authorities/index_en.htm).
+## Additional information for California residents
+
+If you are a California resident, please review the following additional privacy disclosures under the California Consumer Privacy Act ("CCPA").
+
+You have the right to understand how we collect, use, and disclose your personal information, to access your information, to request that we delete certain information, and to not be discriminated against for exercising your privacy rights. You may exercise these rights as described in the ["Your data protection rights"](#data-protection-rights) section above.
+
+You also have the right to understand what information we collect, for what purpose, and how we disclose personal information to third parties. As described in the [What personal information does Prebid.org collect and why?](#what-personal-info) section, we collect the categories of personal information listed below, and we use and disclose these categories of information for the business purposes described in that section. The categories are:
+
+* Identifiers, like your name, email address, IP address, device ID, cookie ID, and other similar identifiers.
+* Internet or other electronic network activity information, such as the usage data we receive when you access or use our Website. This includes information about your interactions with the Website and about the devices and computers you use to access the Website.
+* Professional or employment related information, including any information (like your name, email address, or similar information) that you provide about your employment or employer.
+* Other information that you choose to provide.
+
+We share these categories of personal information as described in the [Who does Prebid.org share my personal information with?](#share-personal-info) section. We never sell the personal information we collect.
-We respond to all requests we receive from individuals wishing to exercise their data protection rights in accordance with applicable data protection laws.
## Updates to this Privacy Notice
diff --git a/support/index.md b/support/index.md
index 746ab735cd..a6db9daf8e 100644
--- a/support/index.md
+++ b/support/index.md
@@ -23,7 +23,7 @@ For questions about how an adapter works, it's best to reach out to the company
For Prebid news or general questions, we recommend the Ad Ops Slack Channel, Quora, or Twitter.
{: .alert.alert-success :}
-There are serveral Prebid.org members that will install & maintain Prebid on a publisher's behalf. See the list of [Managed Prebid Solutions](/prebid/managed.html).
+There are serveral Prebid.org members that will install & maintain Prebid on a publisher's behalf. See the list of [Managed Prebid Solutions](https://prebid.org/product-suite/managed-services/).
## GitHub
diff --git a/troubleshooting/pbs-troubleshooting.md b/troubleshooting/pbs-troubleshooting.md
index 0a1abab007..4175cd2f47 100644
--- a/troubleshooting/pbs-troubleshooting.md
+++ b/troubleshooting/pbs-troubleshooting.md
@@ -121,6 +121,22 @@ Could result in this response, assuming that the IDs exist in the database table
}
{% endhighlight %}
+## Request Logging
+
+(PBS-Java only)
+
+Sometimes you want to see what's coming into the server before being processed by PBS.
+If the admin endpoints are enabled and you have the admin endpoint password, you can
+hit these two URLs with the desired parameter values:
+
+- https://HOST/logging/[changelevel](/prebid-server/endpoints/pbs-endpoint-admin.html#loggingchangelevel)?level=debug&duration=10000
+- https://HOST/logging/[httpinteraction](/prebid-server/endpoints/pbs-endpoint-admin.html#logginghttpinteraction)?limit=100&endpoint=auction&account=1111
+
+Then you can check server logs for output like:
+```
+http-interaction : Requested URL: "/openrtb2/auction?debug=1", request body: "{ ... }"
+```
+
## Related Topics
{:.no_toc}
diff --git a/troubleshooting/troubleshooting-guide.md b/troubleshooting/troubleshooting-guide.md
index 0fdec8f924..8e3eac1799 100644
--- a/troubleshooting/troubleshooting-guide.md
+++ b/troubleshooting/troubleshooting-guide.md
@@ -417,6 +417,24 @@ When this event is logged, it shows that Prebid.js has requested to render the a
+## Common Bid Response Parameters + +The following parameters in the `bidResponse` object are common across all bidders. + +{: .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"` | +| `adId` | String | Unique identifier of a bid creative. Used by the line item's creative as in [this example]({{site.baseurl}}/adops/send-all-bids-adops.html#step-3-add-a-creative) | `"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"` | +| `pbHg` | String | High granularity price bucket: 0.01 increment, capped at $20, floored to 2 decimal places (0.01, 0.02, ..., 19.99, 20.00) | `"1.61"` | +| `size` | String | Size of the bid creative; concatenation of width and height by 'x' | `"300x250"` | +| `width` | Integer | Width of the bid creative in pixels | `300` | +| `height` | Integer | Height of the bid creative in pixels | `250` | +| `adTag` | String | Creative's payload in HTML | `"![](\"https://cdn.com/creative.png\")
"` |
+
+
## Related Topics
{:.no_toc}
diff --git a/wrapper_code_of_conduct.md b/wrapper_code_of_conduct.md
index 81c4bf654a..608521d72b 100644
--- a/wrapper_code_of_conduct.md
+++ b/wrapper_code_of_conduct.md
@@ -57,3 +57,4 @@ This Wrapper Code of Conduct establishes the principles by which we believe head
+ [Project Principles]({{site.baseurl}}/principles.html)
+ [Getting Started]({{site.baseurl}}/overview/getting-started.html)
++ [Prebid.org Community Code of Conduct](https://prebid.org/code-of-conduct/)
+
+
diff --git a/prebid/events.md b/prebid/events.md
index a98695cf16..19d95b126e 100644
--- a/prebid/events.md
+++ b/prebid/events.md
@@ -8,15 +8,20 @@ sidebarType: 0
# Prebid.org Events
{:.no_toc}
-## Upcoming events:
+## Upcoming Event:
+
+{: .table .table-bordered .table-striped }
+| Title: | How to Make Prebid the Supply Path Buyers Choose |
+| Date: | Aug 27, 2020 |
+| Registration: | [link](https://event.on24.com/eventRegistration/EventLobbyServlet?target=reg20.jsp&referrer=&eventid=2543494&sessionid=1&key=A724FF00CF11F4BF9C611B265C62DAEE®Tag=&sourcepage=register) |
+
-TBA
-# Past events:
+## Past Events:
{: .table .table-bordered .table-striped }
| Date | Description | Location |
|------+-------+------------|
| Jun 2, 2020 | Prebid Product Roadmap - Moving Forward While Staying In Place | [View webinar](https://event.on24.com/wcc/r/2366096/86825880B7AF15ACBCE71F188729FC63) |
-| Oct 24, 2019 | Prebid Meetup | San Francisco, CA, USA |
| Nov 19, 2019 | Prebid Meetup | Hamburg, Germany |
+| Oct 24, 2019 | Prebid Meetup | San Francisco, CA, USA |
diff --git a/prebid/managed.md b/prebid/managed.md
deleted file mode 100644
index 7a35f0ea04..0000000000
--- a/prebid/managed.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-layout: page_v2
-title: Managed Prebid
-description: Managed Prebid
-sidebarType: 0
----
-
-# Managed Prebid Solutions
-{:.no_toc}
-
-Several Prebid.org members will configure and host your Prebid implementations, helping publishers install Prebid.js, Prebid SDK, and/or Prebid Server.
-
-
+
-
-
-
-
-
+
+
-
-
+
-
+
-
+
-
-
+
+
+
+
-
-
+
-
-
- {% assign arrMsgs = site.data.message %}
- {% assign lastMsg = arrMsgs.last %}
- {% assign lastMsgSize = lastMsg.messageText | size %}
-
-
-
-
-
- 
- 
-
- Developers
-
-
-
-
- 
- 
-
- Get Started
-
-
+
+
+
- 
- 
-
- Ad Ops
+
+
+
+
+
+
+
+
+
+
+ Prebid Documentation
+Welcome to the Prebid.org technical documentation portal.
Here you will find the help you need to work with the Prebid.org family of products.
+
+
-
+
+ 
+ 
+ 
-
- Prebid.js
Prebid Server
Prebid Mobile SDK
-
- {% if lastMsgSize > 1 %}
-
+
+
+
-
+
+
+
diff --git a/examples/pb-video-template.html b/examples/pb-video-template.html
new file mode 100644
index 0000000000..a1482bdfcf
--- /dev/null
+++ b/examples/pb-video-template.html
@@ -0,0 +1,6 @@
+{% include head.html %}
+
+{% include nav.html %}
+
+
+{% include footer.html %}
\ No newline at end of file
diff --git a/examples/video/instream/akamai/pb-ve-amp.html b/examples/video/instream/akamai/pb-ve-amp.html
new file mode 100644
index 0000000000..d16d2ce507
--- /dev/null
+++ b/examples/video/instream/akamai/pb-ve-amp.html
@@ -0,0 +1,246 @@
+---
+layout: video_sample
+title: Prebid Video | Instream Example with Akamai Adaptive Media Player (AMP)
+description: An example of an instream pre roll ad with AMP and Prebid.js. AMP also provides a built-in prebid plugin
+ wich simplifies and integrates the common prebid.js bidding workflow without extra efforts.
+videoType: pb-is-amp
+isVideo: true
+sidebarType: 4
+---
+
+
+
+
-
-
-
+
+ 
+ 
+ 
+ 
+ 
+
- {% else %}
-
- {% endif %}
Display
Video
AMP
Native
Multi-Format
-
-
-
-
+
+
+
+
+
+
@@ -549,6 +571,11 @@ Prebid only supports the most recent major version. Within a month or so after a
+{: .alert.alert-info :}
+Note: If you receive an error during download you most likely selected a configuration that is not supported. Verify that each bidder / module is available in the selected version. Also please note that even though you can download older versions of Prebid.js,
+Prebid only supports the most recent major version. Within a month or so after a major release (e.g. 3.x), we won't patch the previous major release (e.g. 2.x).
+
+
The Benefits of Using Prebid
-
+
-
-
-We are excited to announce that Index Exchange (IX), one of the world’s largest independent ad exchanges, will be joining Prebid.org at the Leader level. [Read the official announcement](https://www.indexexchange.com/). +We are excited to announce that Index Exchange (IX), one of the world’s largest independent ad exchanges, will be joining Prebid.org at the Leader level. [Read the official announcement]( https://www.indexexchange.com/announcement-index-exchange-joins-prebid-org/). + diff --git a/_posts/2020-07-24-PB4-release.md b/_posts/2020-07-24-PB4-release.md new file mode 100644 index 0000000000..fdb737f8a6 --- /dev/null +++ b/_posts/2020-07-24-PB4-release.md @@ -0,0 +1,82 @@ +--- +layout: post +title: Prebid Releases 4.0 +description: +permalink: /blog/PB4-release +--- + +
+ +We're excited to announce the release of Prebid.js 4.0! Version 4.0 includes some important updates related to TCF 2.0 and a number of housekeeping items. You can find a bulleted summary of features included in this release on the [Github release page](https://github.com/prebid/Prebid.js/releases). Here are the details of included features. + +## Moving Towards Standardization + +**Parameter Locations** +Beginning now, rather than accepting parameter locations on bidder-specific parameters, new bidders will be required to conform to standard locations for the following parameters: first party data, floors, schain, video params, page referrer, and COPPA. Currently, bidders that support these parameters do so in a bidder-specific way, which means publishers have to copy the data from different locations and in different ways across different bidders. Since these parameters are often shared across bidders, we’ll be enforcing standard methods for passing these parameters across new bidder adapters, and will require existing adapters to change in a future major release. + +**Video Parameters** +On a similar note, we are introducing another standardization to streamline consumption of OpenRTB video parameters. The vast majority of bidders require OpenRTB parameters for prebid video requests. However, there is currently no standard object for them to retrieve these parameters from in request objects. Rather, the parameters are typically duplicated individually for every bidder in unique or free form taxonomies, creating extra work for publishers and increasing opportunities for error. Adapter reviewers will now enforce that video parameters be retrieved from the `mediaTypes.video` object. This is an important step towards streamlining implementation of Prebid Video. + +**meta Taxonomy** +Finally, we’ve found that Prebid has historically struggled with making granular data about bid responses easily consumable by publisher analytics and reporting systems, significantly limiting their ability to report and take action on individual ads running on their site. + +We’re addressing this by introducing standards in the `bidResponse.meta` object that we plan on enforcing in future versions. Specifically, we’re outlining that the bidResponse.meta object will contain: + +
++ [Prebid Server and AMP](/prebid-server/use-cases/pbs-amp.html)
++ [Setting up Prebid for AMP in Google Ad Manager](/adops/setting-up-prebid-for-amp-in-dfp.html) (Ad Ops Setup)
++ [AMP RTC Overview](https://github.com/ampproject/amphtml/blob/master/extensions/amp-a4a/rtc-documentation.md)
-[PBS]: {{site.baseurl}}/dev-docs/get-started-with-prebid-server.html
-[RTC-Overview]: https://github.com/ampproject/amphtml/blob/master/extensions/amp-a4a/rtc-documentation.md
+[PBS]: /prebid-server/overview/prebid-server-overview.html
[callout-vendors.js]: https://github.com/ampproject/amphtml/blob/master/extensions/amp-a4a/0.1/callout-vendors.js
diff --git a/developers.md b/developers.md
index 8b7edc20f1..5b7c7064c5 100644
--- a/developers.md
+++ b/developers.md
@@ -27,7 +27,7 @@ Key links for publisher developers.
+ [How Prebid on AMP works]({{site.baseurl}}/dev-docs/how-prebid-on-amp-works.html)
+ [Prebid AMP Implementation Guide]({{site.baseurl}}/dev-docs/show-prebid-ads-on-amp-pages.html)
-+ [Prebid Server AMP endpoint documentation]({{site.baseurl}}/prebid-server/endpoints/openrtb2/amp.html)
++ [Prebid Server AMP endpoint documentation]({{site.baseurl}}/prebid-server/endpoints/openrtb2/pbs-endpoint-amp.html)
### Prebid Mobile - integrating display, video, and native ads into iOS and Android apps
@@ -51,4 +51,4 @@ Key links for integrating into the Prebid ecosystem.
### Prebid Server - adding an adapter
-+ [Adding a new bid adapter]({{site.baseurl}}/prebid-server/developers/add-new-bidder.html)
++ [Adding a new bid adapter]({{site.baseurl}}/prebid-server/developers/add-new-bidder-go.html)
diff --git a/download.md b/download.md
index 321496a5e1..02bb783a1e 100644
--- a/download.md
+++ b/download.md
@@ -158,16 +158,17 @@ function get_form_data() {
# Customize and Download Prebid.js
{: .lead :}
-To improve the speed and load time of your site, build Prebid.js for only the header bidding partners you choose.
+
+{: .alert.alert-warning :}
+Prebid.js is open source software that is offered for free as a convenience. While it is designed to help companies address legal requirements associated with header bidding, we cannot and do not warrant that your use of Prebid.js will satisfy legal requirements. You are solely responsible for ensuring that your use of Prebid.js complies with all applicable laws. We strongly encourage you to obtain legal advice when using Prebid.js to ensure your implementation complies with all laws where you operate.
### Option 1: Customize your download here
{% assign bidder_pages = site.pages | where: "layout", "bidder" %}
{% assign module_pages = site.pages | where: "page_type", "module" %}
-{: .alert.alert-info :}
-Note: If you receive an error during download you most likely selected a configuration that is not supported. Verify that each bidder / module is available in the selected version. Also please note that even though you can download older versions of Prebid.js,
-Prebid only supports the most recent major version. Within a month or so after a major release (e.g. 3.x), we won't patch the previous major release (e.g. 2.x).
+{: .alert.alert-danger :}
+**Note:** an important bug in the [DFP Video Module](/dev-docs/modules/dfp_video.html) was introduced with 3.27 and fixed in 4.3. The dfpVideoModule only looked in adunit.sizes but adunit.sizes was stripped. Unfortunately there's not a workaround - if you use that video module, you shouldn't use Prebid.js 3.27 through 4.2 inclusive.
- 
+
+
+
+
+
+
+
+
+
+
@@ -112,11 +114,3 @@
-->
-
-
-
-
-
-
-
-
diff --git a/_posts/2019-01-08-updated-website.md b/_posts/2019-01-08-updated-website.md
index de8d561b5d..f3cd3d0ba0 100644
--- a/_posts/2019-01-08-updated-website.md
+++ b/_posts/2019-01-08-updated-website.md
@@ -23,7 +23,7 @@ permalink: /blog/updated-website
- [Product Management Committees](/overview/prebid-management-committees.html)
- [Community Code of Conduct](/overview/community-code-of-conduct.html)
- [Prebid Members and Partners](/partners/partners.html)
- - [Prebid Members providing Managed Services](/prebid/managed.html)
+ - [Prebid Members providing Managed Services](https://prebid.org/product-suite/managed-services/)
- [Format index page](/formats/formats.html)
### Coming Up:
diff --git a/_posts/2020-07-22-ix-joins-prebid.md b/_posts/2020-07-22-ix-joins-prebid.md
index dbf04b1476..043c0b8504 100644
--- a/_posts/2020-07-22-ix-joins-prebid.md
+++ b/_posts/2020-07-22-ix-joins-prebid.md
@@ -8,4 +8,5 @@ permalink: /blog/ix-joins-prebid
+
+
+
+
+
+
+
+ 
+
+
-
+ +
Download Prebid.js
-
- Maximize Earnings
- Bring additional advertiser demand into your ad server, ensuring you get the best possible price for your inventory.
+
+ 
+
+
-
+ +
Setup Prebid Server
-
+
- 
-
-
-
-
+ Use it Everywhere
- Apply header bidding to the most popular platforms and formats, including web, mobile app, video, native, AMP, and server-to-server.
+
+ 
+
+
+ +
Download Prebid Mobile SDK
+
+
+
+{% include footer.html %}
-
-
-
-
-
-
+
+
+
diff --git a/_layouts/pb-video-template.html b/_layouts/pb-video-template.html
new file mode 100644
index 0000000000..fd99e43929
--- /dev/null
+++ b/_layouts/pb-video-template.html
@@ -0,0 +1,42 @@
+{% include head.html %}
+
+{% include nav.html %}
+
+
+
+
-
-
+
+
+
+
+
+
-
- Prebid is completely open source! Join our community of developers.
-
-
-
-
-
-
-
- 
-
-
-
-
- Get Started Quickly
- Follow simple step-by-step instructions to download, integrate, and configure header bidding with Prebid.
-
-
-
-
+
- 
-
-
-
-
+
+
+
+
+
Join The Community
- Become part of our active community of advertising technology experts, where you can quickly resolve issues and contribute to the evolution of the leading header.
+
+
+
+ 
-
-
-
-
-
-
-
- Product Highlights
- - - - -
+
+
+
+{% include footer.html %}
\ No newline at end of file
diff --git a/_layouts/video_sample.html b/_layouts/video_sample.html
index 9abe8b91d7..e41635c5e6 100644
--- a/_layouts/video_sample.html
+++ b/_layouts/video_sample.html
@@ -1,5 +1,7 @@
{% if page.videoType == "pb-is-br" %}
{% include /video/pb-is-br.html %}
+{% elsif page.videoType == "pb-is-amp" %}
+ {% include /video/pb-is-amp.html %}
{% elsif page.videoType == "pb-is-app" %}
{% include /video/pb-is-app.html %}
{% elsif page.videoType == "pb-is-bc" %}
@@ -64,32 +66,32 @@
{% include nav.html %}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
-
+
-
+
-
-
+
-
-
+
+ {% include left_nav.html %}
+
+
+
+
-
+
{{ content }}
-
+
{% if page.description == "Partners" %}
{% include partners.html %}
{% endif %}
-
+
-
+
-We are excited to announce that Index Exchange (IX), one of the world’s largest independent ad exchanges, will be joining Prebid.org at the Leader level. [Read the official announcement](https://www.indexexchange.com/). +We are excited to announce that Index Exchange (IX), one of the world’s largest independent ad exchanges, will be joining Prebid.org at the Leader level. [Read the official announcement]( https://www.indexexchange.com/announcement-index-exchange-joins-prebid-org/). + diff --git a/_posts/2020-07-24-PB4-release.md b/_posts/2020-07-24-PB4-release.md new file mode 100644 index 0000000000..fdb737f8a6 --- /dev/null +++ b/_posts/2020-07-24-PB4-release.md @@ -0,0 +1,82 @@ +--- +layout: post +title: Prebid Releases 4.0 +description: +permalink: /blog/PB4-release +--- + +
+ +We're excited to announce the release of Prebid.js 4.0! Version 4.0 includes some important updates related to TCF 2.0 and a number of housekeeping items. You can find a bulleted summary of features included in this release on the [Github release page](https://github.com/prebid/Prebid.js/releases). Here are the details of included features. + +## Moving Towards Standardization + +**Parameter Locations** +Beginning now, rather than accepting parameter locations on bidder-specific parameters, new bidders will be required to conform to standard locations for the following parameters: first party data, floors, schain, video params, page referrer, and COPPA. Currently, bidders that support these parameters do so in a bidder-specific way, which means publishers have to copy the data from different locations and in different ways across different bidders. Since these parameters are often shared across bidders, we’ll be enforcing standard methods for passing these parameters across new bidder adapters, and will require existing adapters to change in a future major release. + +**Video Parameters** +On a similar note, we are introducing another standardization to streamline consumption of OpenRTB video parameters. The vast majority of bidders require OpenRTB parameters for prebid video requests. However, there is currently no standard object for them to retrieve these parameters from in request objects. Rather, the parameters are typically duplicated individually for every bidder in unique or free form taxonomies, creating extra work for publishers and increasing opportunities for error. Adapter reviewers will now enforce that video parameters be retrieved from the `mediaTypes.video` object. This is an important step towards streamlining implementation of Prebid Video. + +**meta Taxonomy** +Finally, we’ve found that Prebid has historically struggled with making granular data about bid responses easily consumable by publisher analytics and reporting systems, significantly limiting their ability to report and take action on individual ads running on their site. + +We’re addressing this by introducing standards in the `bidResponse.meta` object that we plan on enforcing in future versions. Specifically, we’re outlining that the bidResponse.meta object will contain: + +
+
+
+
+
+ networkId: NETWORK_ID,
+ networkName: NETWORK_NAME
+ agencyId: AGENCY_ID,
+ agencyName: AGENCY_NAME,
+ advertiserId: ADVERTISER_ID,
+ advertiserName: ADVERTISER_NAME,
+ advertiserDomains: [ARRAY_OF_ADVERTISER_DOMAINS]
+ brandId: BRAND_ID,
+ brandName: BRAND_NAME,
+ primaryCatId: IAB_CATEGORY,
+ secondaryCatIds: [ARRAY_OF_IAB_CATEGORIES],
+ mediaType: MEDIA_TYPE
+
+
+
+
+
+
+
+{: .table .table-bordered .table-striped }
+| Field | Scope | Type | Description |
+|---|-------------|---|---|
+| `meta.networkId` | Optional | int | Bidder-specific Network/DSP ID |
+| `meta.networkName` | Optional | string | Network/DSP Name |
+| `meta.agencyId` | Optional | int | Bidder-specific Agency ID |
+| `meta.agencyName` | Optional | string | Agency Name |
+| `meta.advertiserId` | Optional | int | Bidder-specific Advertiser ID |
+| `meta.advertiserName` | Optional | string | Advertiser Name |
+| `meta.advertiserDomain` | Optional | array | Array of Advertiser Domains for the landing page(s). This is an array to align with the OpenRTB ‘adomain’ field.|
+| `meta.brandId` | Optional | int | Bidder-specific Brand ID (some advertisers may have many brands)|
+| `meta.brandName` | Optional | string | Brand Name |
+| `meta.primaryCatId` | Optional | string | Primary IAB category ID |
+| `meta.secondaryCatIds` | Optional | array | Array of secondary IAB category IDs ["IAB-222","IAB-333"] |
+| `meta.mediaType` | Optional | string | “banner”, “native”, or “video” - this should be set in scenarios where a bidder responds to a “banner” mediaType with a creative that’s actually a video (e.g. outstream) or native. |
+
+
+While various fields may currently be passed in via bidResponse today, we think it’s important to the future functionality of Prebid to have a standardized taxonomy for this data. You’ll notice a number of important fields, for example **meta.advertiserName** and **meta.advertiserId**, that provide publishers with the ability to report against which advertisers are running on their website. This is all with an eye towards eventually being able to implement logic in the page relating to advertiser, DSP, category, etc.
+
+In version 4.0 these fields are not required and this is not a breaking change. However, we expect some or all of these fields to become a requirement in the future. Bidders should begin implementing these fields properly as soon as possible. While not yet a global taxonomy, the bidders actively using the field in the near term will shape the community discussion around the final execution of the standardization.
+
+## Staying on top of Privacy
+
+Prebid has developed flexible software solutions to help Publishers conform to [TCF 2.0](https://iabeurope.eu/tcf-2-0/). This release includes updates to Prebid’s enforcement, specifically with regards to TCF Purposes 1 and 2. While Prebid.org can’t provide legal advice, and takes no position with regards to responsibility, we’ve provided an intuitive toolkit for publishers to implement header bidding per their internal requirements. From 4.0 onward, Prebid.js will enforce Purposes 1 and 2 by default, meaning that without consent or legitimate interest, Prebid.js may restrict device access and may remove some (or all) bidders from the auction. All of these settings are of course configurable, and can be changed with modifications to gdpr.rules[].enforcePurpose. See our [privacy documents](http://prebid.org/dev-docs/modules/gdprEnforcement.html) for more details.
+
+## Additional Changes and Details
+
+Prebid.js 4.0 also contains a few other changes and coming updates:
+
+1. Remove AudienceNetwork adapter and Quantum bidder (deprecated).
+2. Stronger enforcement for bidders return bid meta data [(#3115 (comment))](https://github.com/prebid/Prebid.js/issues/3115) needs refinement. PR here [#5358](https://github.com/prebid/Prebid.js/pull/5358).
+3. [#3873](https://github.com/prebid/Prebid.js/issues/3873) - Proposal: set cookie domain in pubcid / userid on main domain, not subdomain.
+
+Detailed discussion and links can be found [here](https://github.com/prebid/Prebid.js/issues/4824).
diff --git a/adops/send-all-bids-adops.md b/adops/send-all-bids-adops.md
index 535d18ce02..940bc6efa2 100644
--- a/adops/send-all-bids-adops.md
+++ b/adops/send-all-bids-adops.md
@@ -4,13 +4,10 @@ title: Send All Bids to the Ad Server
head_title: Send All Bids to the Ad Server
description: Send all bids to the ad server for reporting and data analysis.
pid: 2
-top_nav_section: adops
-nav_section: tutorials
sidebarType: 3
---
-
# Send all bids to the ad server - Ad Ops setup
{: .no_toc }
@@ -153,6 +150,8 @@ See note above in regards to replacing *BIDDERCODE* placeholders.
{% include alerts/alert_note.html content=noteAlert %}
+{% include adops/adops-creative-declaration.html %}
+
For other ad servers:
diff --git a/adops/setting-up-prebid-for-amp-in-dfp.md b/adops/setting-up-prebid-for-amp-in-dfp.md
index 7b653bf540..cd948ec4b4 100644
--- a/adops/setting-up-prebid-for-amp-in-dfp.md
+++ b/adops/setting-up-prebid-for-amp-in-dfp.md
@@ -3,10 +3,6 @@ layout: page_v2
title: Setting up Prebid for AMP in Google Ad Manager
head_title: Setting up Prebid for AMP in Google Ad Manager
description: Setting up Prebid for AMP in Google Ad Manager
-pid: 3
-
-top_nav_section: adops
-nav_section: tutorials
sidebarType: 3
---
@@ -75,6 +71,7 @@ order), the creative and targeting will be different from the example shown here
{: .alert.alert-success :}
You can always get the latest version of the creative code from [the AMP example creative file in our GitHub repo](https://github.com/prebid/prebid-universal-creative/blob/master/template/amp/dfp-creative.html).
+{% include adops/adops-creative-declaration.html %}
## Further Reading
diff --git a/assets/css/style.css b/assets/css/style.css
old mode 100755
new mode 100644
index 8d15f1cc51..0af6a31a4c
--- a/assets/css/style.css
+++ b/assets/css/style.css
@@ -136,33 +136,33 @@ hr {
}
/* alerts */
-.pb-alert {
-
+.pb-alert {
+
padding:10px;
width:65wv;
margin: 10px 0;
}
-.pb-alert-note {
+.pb-alert-note {
background-color: #deecf7;
color: #4b6f8d;
border: 1px solid #4b6f8d;
}
-.pb-alert-warning {
+.pb-alert-warning {
background-color: #f3ddde;
color: #a94443;
border: 1px solid #a94443;
}
-.pb-alert-important {
+.pb-alert-important {
background-color: #ede5ba;
color: #85720f;
border: 1px solid #85720f;
}
-.pb-alert-tip {
+.pb-alert-tip {
background-color: #e3efd8;
color: #527542;
border: 1px solid #527542;
@@ -170,10 +170,10 @@ hr {
/**********************
- API
+ API
*********************/
-.pb-api-on {
+.pb-api-on {
display: block;
}
@@ -181,36 +181,36 @@ hr {
display: none;
}
-.pb-api-list ul {
+.pb-api-list ul {
list-style-type: none;
- margin: 0;
- padding: 0;
+ margin: 0;
+ padding: 0;
overflow: hidden;
}
-.pb-api-list-item li {
+.pb-api-list-item li {
border-bottom: 1px solid #cccccc;
border-bottom-width: 75%;
background-color:transparent;
margin-bottom: 10px;
}
-.pb-api-list-item-sans-border li {
+.pb-api-list-item-sans-border li {
background-color:transparent;
margin-bottom: 10px;
}
-.pb-api-categories {
+.pb-api-categories {
margin-top:15px;
}
-.pb-api-categories li {
+.pb-api-categories li {
float: left;
margin-right: 15px;
background-color: #eeeeee;
}
-.pb-api-categories a {
+.pb-api-categories a {
color: #333333;
font-family: 'Verdana', sans-serif;
font-size: 17px;
@@ -218,33 +218,33 @@ hr {
padding: 4px 10px;
}
-.pb-api-categories a:hover {
+.pb-api-categories a:hover {
color: #3498db;
}
-.pb-api-search {
+.pb-api-search {
float:right;
margin-right: 30px;
}
-.pb-api-title {
-
+.pb-api-title {
+
color: #EA9622;
font-family: 'Verdana', sans-serif;
font-size: 22px;
font-weight: 400;
margin-bottom: 10px;
margin-top: 15px;
-
+
}
.pb-api-code {
margin: 20px 0 20px 20px;
}
-.pb-api-code-wrapper {
+.pb-api-code-wrapper {
margin-left: 20px;
-
+
}
.pb-api-code-display {
@@ -252,16 +252,16 @@ hr {
width: 70%;
}
-.pb-api-code-block {
+.pb-api-code-block {
width: 70%;
backgeound-color: #333333;
}
-.pb-api-block {
+.pb-api-block {
margin: 20px 0 20px 20px;
}
-.pb-api-doc-title {
+.pb-api-doc-title {
color: #EA9622;
font-family: 'Verdana', sans-serif;
font-size: 20px;
@@ -269,7 +269,7 @@ hr {
margin-bottom: 10px;
}
-.pb-api-doc-description {
+.pb-api-doc-description {
color: #222222;
font-size: 16px;
font-family: 'Roboto', sans-serif;
@@ -277,12 +277,12 @@ hr {
margin-bottom:10px;
}
-.pb-api-doc-description ul, ol {
+.pb-api-doc-description ul, ol {
font-size: 15px;
}
-.pb-api-code-title-bar {
- background-color: #E4E8ED;
+.pb-api-code-title-bar {
+ background-color: #E4E8ED;
text-align: left;
border-top-left-radius: 5px;
border-top-right-radius: 5px;
@@ -291,7 +291,7 @@ hr {
margin-top: 10px;
}
-.pb-api-doc-sub-title {
+.pb-api-doc-sub-title {
color: #EA9622;
font-family: 'Verdana', sans-serif;
font-size: 17px;
@@ -306,17 +306,17 @@ hr {
margin:15px 0;
}
-.pb-api-list-item-description {
+.pb-api-list-item-description {
margin-top 5px;
font-size:17px;
}
-.pb-api-table {
+.pb-api-table {
margin-top: 20px;
width:70%;
}
-.pb-api-table-title {
+.pb-api-table-title {
color: #333333;
font-family: 'Verdana', sans-serif;
font-size: 17px;
@@ -327,7 +327,7 @@ hr {
border-top-right-radius: 5px;
}
-.pb-api-table-text {
+.pb-api-table-text {
color: #222222;
font-size: 16px;
font-family: 'Roboto', sans-serif;
@@ -335,15 +335,15 @@ hr {
}
-.pb-api-spacing {
+.pb-api-spacing {
margin-top: 25px;
}
-.pb-api-alert {
+.pb-api-alert {
font-size:15px;
}
-.pb-api-button {
+.pb-api-button {
width: 120px;
height: 30px;
background-color: #cccccc;
@@ -392,7 +392,7 @@ hr {
/* API */
-.categoryBox {
+.categoryBox {
background-color: #f3ddde;
color: #a94443;
border: 1px solid #a94443;
@@ -401,7 +401,7 @@ hr {
/* NavBar */
-.navbar {
+.navbar {
z-index:100
font-family: 'Roboto', sans-serif;
}
@@ -427,7 +427,7 @@ hr {
background: #fff;
}
-.navbar-brand img {
+.navbar-brand img {
max-width: 200px;
max-height: 35px;
}
@@ -438,25 +438,25 @@ hr {
padding:10px 15px;
font-size:18px;
line-height:20px
-
+
}
-.pb-mobile-nav {
+.pb-mobile-nav {
display: none;
}
-.pb-mobile-dropdown-header {
+.pb-mobile-dropdown-header {
font-size: 13px;
font-weight: 500;
color: #3498db;
}
-.pb-mobile-dropdown-item {
+.pb-mobile-dropdown-item {
font-size: 13px;
font-weight: 400;
}
-.navbar-default .navbar-nav > li > a.pb-mobile-dropdown {
+.navbar-default .navbar-nav > li > a.pb-mobile-dropdown {
font-size:13px;
margin:0;
padding-left:5px;
@@ -471,18 +471,34 @@ hr {
margin-top: 10px;
}
+.pb-video-list-title {
+ margin-top: 15px;
+ font-weight: 700;
+}
+
+.pb-video-list {
+ margin-top: 5px;
+ padding-top: 0;
+ list-style-type:none;
+ font-weight:400;
+}
+
+.pb-video-link {
+ font-weight: 400;
+}
+
/* DropDown*/
-.dropdown {
+.dropdown {
font-family: 'Roboto', sans-serif;
font-weight: 400;
}
-.dropdown-toggle {
+.dropdown-toggle {
font-weight: 400;
}
-.dropdown-menu>li>a {
+.dropdown-menu>li>a {
font-weight: 400;
}
@@ -517,7 +533,7 @@ hr {
/* 404 error */
-.error404 {
+.error404 {
width:100%;
height: 100%;
text-align: center;
@@ -525,7 +541,7 @@ hr {
}
-.error404 h1 {
+.error404 h1 {
color: #FF0000;
font-size: 60px;
font-weight: bold;
@@ -553,7 +569,7 @@ hr {
-.sidebar {
+.sidebar {
min-width: 300px;
background-color: #f6f8fa;
padding-left: 50px;
@@ -564,16 +580,16 @@ hr {
font-family: 'Verdana', sans-serif;
}
-.sidebar ul {
+.sidebar ul {
color: #333333;
}
.pb-section-title {
- display: inline-block;
+ display: inline-block;
font-size:17px;
padding-bottom: 10px;
margin-top:5px;
- margin-bottom: 5px;
+ margin-bottom: 5px;
color: #3498db;
}
@@ -581,10 +597,10 @@ hr {
font-size:16px;
padding-bottom: 10px;
margin-top:5px;
- margin-bottom: 5px;
+ margin-bottom: 5px;
}
-.pb-nav-item {
+.pb-nav-item {
display:inline-block;
font-size:14px;
padding-left: 5px;
@@ -598,12 +614,12 @@ hr {
padding-bottom: 10px;
}
-.list-group-item-header {
+.list-group-item-header {
font-weight: 400;
font-size: 20px;
}
-.list-group-item {
+.list-group-item {
font-weight: 400;
margin:0;
padding: 3px 0 3px 5px;
@@ -640,103 +656,99 @@ pre {
height: 90%;
}
-.pb-homepage-container {
- position:absolute;
- left:0;
- top:0;
- width:100%;
- height:100%;
+.pb-homepage-container {
+ text-align: center;
}
-.pb-homepage-image {
- z-index:1;
- width: 100%;
- height:100%;
+.pb-message-box {
+ display: inline-block;
+ width: 70%;
+ border: 1px solid gray;
+ border-radius: 50px;
+ font-family: 'Roboto', sans-serif;
+ font-size: 16px;
+ padding: 4px;
}
-.pb-obj-fit-fill {
- object-fit:cover;
- width:100%;
+.pb-message-box a:link {
+ color: #dd9e21;
}
+.pb-message-box a:hover {
+ color: #855a09;
+}
-.pb-homepage-content {
- z-index:2;
- color: #ffffff;
+.pb-message-box a:visited {
+ color: #1689db;
}
-.pb-top-text {
- text-align: center;
+.pb-align-left {
+ text-align: start;
}
-.pb-top-text h1 {
- color: #FFFFFF;
- font-size:69px;
- font-family: 'Verdana', sans-serif;
- font-weight:500;
+.pb-align-right {
+ text-align: right;
}
-.pb-top-text h2 {
- color: #FFFFFF;
- font-size:34px;
- font-family: 'Roboto', sans-serif;
- width: 66%;
- margin-right: auto;
- margin-left: auto;
- -webkit-text-fill-color: rgba(255, 255, 255, 1);
- -webkit-opacity: 1;
+.pb-margin-top {
+ margin-top:20px;
}
-.pb-panel-title {
- display: block;
- font-size:35px;
- font-weight: 700;
- color: #ffffff;
+.pb-outline {
+ border: 1px dashed purple;
}
-.pb-outer-title {
- margin-top: 5px;
+.pb-rule {
+ padding-top: 10px;
}
-.pb-center-title {
- margin-top: 0px;
+.pb-link-title {
+ font-family: 'Roboto', sans-serif;
+ font-weight: 700;
+ padding-top: 5px;
+ padding-bottom: 10px;
+ border-bottom-left-radius: 20px;
+ border-bottom-right-radius: 20px;
}
-
+
+
+
+
/**********Container****************/
-.pb-container {
- width:75%;
- margin-left:auto;
+.pb-container {
+ width:75%;
+ margin-left:auto;
margin-right:auto;
}
-.pb-outer {
- width:100%;
- padding-top:25%;
+.pb-outer {
+ width:100%;
+ padding-top:25%;
position:relative
}
-.pb-inner {
- position: absolute;
- top: 0;
- left: 0;
- right: 0;
- bottom: 0;
+.pb-inner {
+ position: absolute;
+ top: 0;
+ left: 0;
+ right: 0;
+ bottom: 0;
}
/*************Hover Effect***************/
-.pb-home-links {
+.pb-home-links {
width: 75%;
font-family: 'Verdana', sans-serif;
- margin-left:auto;
+ margin-left:auto;
margin-right:auto;
}
-.pb-home-links-panel {
+.pb-home-links-panel {
float:left;
margin-left:auto;
margin-right: auto;
@@ -745,13 +757,13 @@ pre {
text-align: center;
}
-.pb-home-links-panel img {
+.pb-home-links-panel img {
display: inline-block;
width: 60%;
height: 60%;
}
-.pb-home-links-outer-panel {
+.pb-home-links-outer-panel {
float:left;
margin-top:40px;
margin-left:auto;
@@ -762,58 +774,58 @@ pre {
}
-.pb-home-links-outer-panel img {
+.pb-home-links-outer-panel img {
display: inline-block;
width: 50%;
height: 50%;
}
-.pb-home-links-panel p {
+.pb-home-links-panel p {
margin-top:0px;
}
-.pb-panel-title {
+.pb-panel-title {
display: block;
font-size:35px;
color: #ffffff;
margin-top: 30px;
}
-.pb-center-title {
+.pb-center-title {
font-size:35px;
color: #ffffff;
margin-top: 20px;
}
-.pb-home-link-container:hover .pb-home-link-visible {
+.pb-home-link-container:hover .pb-home-link-visible {
display: none;
}
-.pb-home-link-container:hover .pb-home-link-hidden {
+.pb-home-link-container:hover .pb-home-link-hidden {
display: block;
}
-.pb-home-link-hidden {
+.pb-home-link-hidden {
display:none;
}
-.pb-lg-homelink {
+.pb-lg-homelink {
width: 40%;
height: 40%;
}
-.pb-md-honelink {
+.pb-md-honelink {
width:30%;
height:3 0%;
}
/**********Message****************/
-.pb-message-container {
+.pb-message-container {
margin-top: 140px;
- width:75%;
- margin-left:auto;
+ width:75%;
+ margin-left:auto;
margin-right:auto;
text-align: center;
}
@@ -829,7 +841,7 @@ pre {
padding: 5px;
}
-.pb--empty-message {
+.pb--empty-message {
display: inline-block;
margin-left: auto;
margin-right: auto;
@@ -839,7 +851,7 @@ pre {
padding: 5px;
}
-.pb-message > h3 {
+.pb-message > h3 {
color: #333333;
font-size:1.7vw;
font-family: 'Roboto', sans-serif;
@@ -850,85 +862,85 @@ pre {
/*===========Benefits===================*/
-.pb_benefits {
- background-color: #ffffff;
- width: 80%;
- padding-bottom: 40px;
+.pb_benefits {
+ background-color: #ffffff;
+ width: 80%;
+ padding-bottom: 40px;
margin-top:260px;
- margin-left: auto;
+ margin-left: auto;
margin-right: auto;
opacity:.80;
overflow:hidden;
}
-.pb-benefits-title {
+.pb-benefits-title {
text-align: center;
padding-top:5px;
padding-bottom:5px;
}
-.pb-benefits-title > h2 {
+.pb-benefits-title > h2 {
font-family: 'Roboto', sans-serif;
color: #47547c;
font-size:3.5vw;
font-weight: 400;
}
-.pb-benefits-container {
+.pb-benefits-container {
width: 100%;
height: 100%;
}
.pb-benefits-row {
display: inline-block;
- width:100%;
+ width:100%;
height: 42%;
}
-.pb-benefits-panel {
+.pb-benefits-panel {
width:100%;
height:100%;
margin-top:100px;
}
-.pb-benefits-panel-left {
+.pb-benefits-panel-left {
float:left;
width:50%;
}
-.pb-benefits-panel-right {
+.pb-benefits-panel-right {
float:right;
width:50%;
padding-right: 5%;
}
-.pb-benefits-panel-img {
+.pb-benefits-panel-img {
float: left;
height: 100%;
width:30%;
text-align:right;
padding-right:10px;
}
-
-.pb-benefits-panel-img > img {
+
+.pb-benefits-panel-img > img {
max-width:60%;
max-height:60%;
}
-.pb-benefits-panel-content {
+.pb-benefits-panel-content {
float:right;
height: 100%;
width:70%;
}
-.pb-benefits-panel-content-title {
+.pb-benefits-panel-content-title {
font-family: 'Roboto', sans-serif;
color: #47547c;
font-size:2.5vw;
font-weight: 400;
}
-.pb-benefits-panel-content-text {
+.pb-benefits-panel-content-text {
font-family: 'Lato', sans-serif;
color: #47547c;
font-size:1.7vw;
@@ -938,27 +950,27 @@ pre {
/************ Carousel ****************/
-.pb_home_belowfold_carousel {
+.pb_home_belowfold_carousel {
border-top-left-radius: 12px;
border-top-right-radius: 12px;
padding-top: 20px;
text-align:center;
}
-.pb_carousel_title {
+.pb_carousel_title {
margin-top:100px;
margin-bottom:50px;
margin-left:auto;
margin-right:auto;
padding-bottom: 10px;
color: #ffffff;
- font-family: 'Roboto', sans-serif;
+ font-family: 'Roboto', sans-serif;
font-size: 4vw;
font-weight: 700;
}
-
-.carousel-item > h3 {
- font-family: 'Roboto', sans-serif;
+
+.carousel-item > h3 {
+ font-family: 'Roboto', sans-serif;
font-size: 2.4vw;
padding-top: 5px;
padding-bottom:3px;
@@ -969,7 +981,7 @@ pre {
margin:0;
}
-.carousel-item > h4 {
+.carousel-item > h4 {
font-family: 'Lato', sans-serif;
font-size: 1.7vw;
color: #47547c;
@@ -977,7 +989,7 @@ pre {
padding-right: 10px;
}
-.slide {
+.slide {
background-color: #ffffff;
width: 70%;
height:250px;
@@ -985,14 +997,14 @@ pre {
margin-right: auto;
border-top-left-radius: 12px;
border-top-right-radius: 12px;
-
+
}
-.item {
+.item {
text-align: center;
}
-.pb_carousel_indicators {
+.pb_carousel_indicators {
margin-top: 150px;
}
@@ -1065,6 +1077,7 @@ pre {
right: -15%;
}
+
/************ pbTable ****************/
.pbtable {
@@ -1092,57 +1105,57 @@ pre {
/************ Partners ****************/
-.partners {
+.partners {
text-align: center;
}
-.partners div.title {
+.partners div.title {
width:100%;
padding-top: 30px;
}
-.partners div.tableTitle {
+.partners div.tableTitle {
width:100%;
padding-top: 30px;
padding-bottom: 30px;
}
-.partners h3 {
-
+.partners h3 {
+
margin:0;
padding: 0;
font-size:large;
}
-.partners img.founders {
-
+.partners img.founders {
+
width: 100px;
}
-.partners img.standard {
-
+.partners img.standard {
+
width: 125px;
}
-.pb_tbl_title h3 {
+.pb_tbl_title h3 {
padding-bottom: 20px;
}
-.pb_standard_tbl td {
+.pb_standard_tbl td {
padding-left: 10px;
padding-right: 10px;
}
-.partners ul {
-
+.partners ul {
+
list-style-type: none;
display: table;
width: 100%;
-
+
}
-.partners li {
+.partners li {
display: table-cell;
text-align: center;
}
@@ -1176,15 +1189,15 @@ pre {
Blog
***************************/
-.pb-blog {
+.pb-blog {
margin-left:50px;
font-family: 'Verdana', sans-serif;
font-size: 34px;
font-weight: 400;
}
-.pb-blog h1 {
-
+.pb-blog h1 {
+
display: table;
padding: 3px 8px;
font-family: 'Verdana', sans-serif;
@@ -1198,12 +1211,12 @@ pre {
Content Pages
*********************************/
-.bs-docs-container {
+.bs-docs-container {
margin-top: 70px;
margin-left:0;
}
-.col-sm-9 {
+.col-sm-9 {
padding-top: 20px;
margin:0;
}
@@ -1211,20 +1224,20 @@ pre {
.pb-content {
- padding: 20px;
+ padding: 20px;
margin-left: 20px;
}
-.pb-blog p {
-
+.pb-blog p {
+
font-family: 'Lato', sans-serif;
color: #222222;
font-size: 16px;
font-weight: 400;
}
-.pb-content h1 {
-
+.pb-content h1 {
+
/*background-color: #EA9622;*/
display: table;
padding: 3px 0px;
@@ -1235,24 +1248,24 @@ pre {
width:75wv;
}
-.pb-content, .pb-blog h2 {
-
+.pb-content, .pb-blog h2 {
+
font-family: 'Verdana', sans-serif;
color: #000000;
font-size: 27px;
font-weight: 400;
}
-.pb-content, .pb-blog h3 {
-
+.pb-content, .pb-blog h3 {
+
font-family: 'Verdana', sans-serif;
color: #333333;
font-size: 24px;
font-weight: 400;
}
-.pb-content, .pb-blog h4 {
-
+.pb-content, .pb-blog h4 {
+
font-family: 'Verdana', sans-serif;
color: #333333;
font-size: 20px;
@@ -1260,8 +1273,8 @@ pre {
}
-.pb-content, .pb-blog h5 {
-
+.pb-content, .pb-blog h5 {
+
font-family: 'Verdana', sans-serif;
color: #333333;
font-size: 18px;
@@ -1269,7 +1282,7 @@ pre {
}
-.pb-content, .pb-blog ul, ol, li {
+.pb-content, .pb-blog ul, ol, li {
font-family: 'Lato', sans-serif;
font-size: 18px;
}
@@ -1287,7 +1300,7 @@ pre {
Footer
******************/
-.pb_footer {
+.pb_footer {
display: block;
width: 75%;
font-family: 'Dosis', sans-serif;
@@ -1297,189 +1310,240 @@ pre {
margin-left: auto;
margin-right: auto;
text-align: center;
-
+
+}
+
+/************ Was This Helpful Form ****************/
+
+.wthHeader {
+ background-color: #EA9622;
+ border-top-left-radius: 5px;
+ border-top-right-radius: 5px;
+ height: 10px;
+ width: 100%;
+ margin-bottom: 15px;
+}
+
+.wthBordered {
+ border: 1px solid #cccccc;
+ border-top-left-radius: 5px;
+ border-top-right-radius: 5px;
+ margin-top: 10px;
+ padding-left: 7px;
+}
+
+.wthForm {
+ padding-left: 15px;
+}
+
+.wthForm.input {
+ margin-top: 5px;
+ margin-bottom: 5px;
}
+.wthSubmit {
+ margin-top: 5px;
+ margin-bottom: 5px;
+}
+.wthLabel {
-/*
+ font-family: 'Lato', sans-serif;
+ font-weight: 400;
+ font-size:18px;
+ color: #EA9622;
+ margin-top: 5px;
+ margin-bottom: 5px;
+}
+
+.wthTitle {
+
+ font-family: 'Lato', sans-serif;
+ font-weight: 700;
+ font-size:24px;
+ color: #3498db;
+}
+
+
+
+/*
Responsive
There are 3 trigger levels, 1024, 768 and 480
-
+
*/
/*small browsers*/
-@media screen and (max-width: 1300px) {
-
- .pb-top-text h1 {
+@media screen and (max-width: 1300px) {
+
+ .pb-top-text h1 {
font-size:60px;
}
-
+
.pb-top-text h2 {
font-size:30px;
}
-
- .pb-panel-title {
+
+ .pb-panel-title {
font-size:33px;
}
-
- .slide {
+
+ .slide {
height: 140px;
}
-
-
- }
-
+
+
+ }
+
/*iPad Pro*/
- @media screen and (max-width: 1024px) {
-
- .pb-message-container {
+ @media screen and (max-width: 1024px) {
+
+ .pb-message-container {
margin-top: 100px;
}
-
- .pb_benefits {
+
+ .pb_benefits {
margin-top: 50px;
}
-
- .pb-benefits-panel {
+
+ .pb-benefits-panel {
margin-top:0px;
-
- .carousel-inner h3 {
+
+ .carousel-inner h3 {
font-size: 30px;
}
-
+
.carousel-inner h4 {
padding-top: 20px;
font-size: 24px;
}
-
- .pb_carousel_indicators {
+
+ .pb_carousel_indicators {
margin-top: 100px;
}
-
+
.bs-docs-section {
line-height: 1.6;
font-size: large;
margin-right: 10em;
}
-
- .slide {
+
+ .slide {
height: 160px;
}
-
+
.container {
width: 88%;
}
}
-
+
/*iPad */
- @media screen and (max-width: 768px) {
-
- .pb-top-text h1 {
+ @media screen and (max-width: 768px) {
+
+ .pb-top-text h1 {
font-size:40px;
}
-
+
.pb-top-text h2 {
font-size:20px;
}
-
- .pb-panel-title {
+
+ .pb-panel-title {
font-size:30px;
}
-
- .pb_benefits {
+
+ .pb_benefits {
margin-top: 50px;
}
-
- .pb_carousel_title {
+
+ .pb_carousel_title {
margin-top:50px;
margin-bottom:10px;
}
- .slide {
+ .slide {
height: 110px;
}
-
- .pb_carousel_indicators {
+
+ .pb_carousel_indicators {
margin-top: 150px;
}
-
+
}
-
+
/*iPhone Plus */
- @media screen and (max-width: 414px) {
-
+ @media screen and (max-width: 414px) {
+
/* hide side nav on phone devices*/
- #sidebar {
+ #sidebar {
display: none;
- }
-
- .pb-top-text h1 {
+ }
+
+ .pb-top-text h1 {
font-size:20px;
}
-
+
.pb-top-text h2 {
font-size:12px;
}
-
- .pb-home-links-panel {
+
+ .pb-home-links-panel {
margin-top: -10px;
}
-
- .pb-outer-title {
+
+ .pb-outer-title {
margin-top: 5px;
}
-
- .pb-home-links {
+
+ .pb-home-links {
margin-top:-10px;
}
-
- .pb-home-links-outer-panel {
+
+ .pb-home-links-outer-panel {
margin-top:20px;
}
-
- .pb-panel-title {
+
+ .pb-panel-title {
font-size:14px;
}
-
- .pb-message-container {
+
+ .pb-message-container {
margin-top: 50px;
}
-
- .pb_benefits {
+
+ .pb_benefits {
margin-top: 20px;
}
-
- .pb_carousel_title {
+
+ .pb_carousel_title {
margin-top:-10px;
margin-bottom:20px;
}
- .slide {
+ .slide {
height: 70px;
}
-
- .pb-main-nav {
+
+ .pb-main-nav {
display:none;
}
-
- .pb-mobile-nav {
+
+ .pb-mobile-nav {
display: block;
}
-
- .pb_carousel_indicators {
+
+ .pb_carousel_indicators {
margin-top: 10px;
height: 10px;
}
-
-
- .pb-content {
+
+
+ .pb-content {
width: 85%;
margin-left: -20px;
}
-
- .pb-content p {
+
+ .pb-content p {
font-size: 15px;
font-weight: 400;
line-height: inherit;
@@ -1487,143 +1551,143 @@ pre {
}
}
-
+
/* iPhone X*/
@media screen and (max-width: 375px) {
-
- .pb-top-text h1 {
+
+ .pb-top-text h1 {
font-size:22px;
}
-
+
.pb-top-text h2 {
font-size:11px;
margin-top: 0px;
}
-
- .pb-panel-title {
+
+ .pb-panel-title {
font-size:12px;
}
-
- .pb-home-links-panel {
+
+ .pb-home-links-panel {
margin-top: -15px;
}
-
- .pb_benefits {
+
+ .pb_benefits {
margin-top: 40px;
}
-
- .pb_home_belowfold_carousel {
+
+ .pb_home_belowfold_carousel {
padding-top: 60px;
}
-
- .pb_carousel_title {
+
+ .pb_carousel_title {
margin-top:-20px;
margin-bottom:0px;
}
- .slide {
+ .slide {
height: 80px;
}
-
- .pb_carousel_indicators {
+
+ .pb_carousel_indicators {
margin-top: 0px;
height: 22px;
}
-
- .carousel-indicators {
+
+ .carousel-indicators {
padding-top: 140px;
}
-
+
}
-
+
/* iPhone 6, 7, 8 Galaxy S5 (different width) */
- @media screen and (max-width: 360px) {
-
- .pb-top-text h1 {
+ @media screen and (max-width: 360px) {
+
+ .pb-top-text h1 {
font-size:18px;
}
-
+
.pb-top-text > h2 {
font-size:9px;
margin-top: 0px;
}
-
- .pb-home-links-outer-panel {
+
+ .pb-home-links-outer-panel {
margin-top:10px;
}
-
- .pb_benefits {
+
+ .pb_benefits {
margin-top: 70px;
}
-
+
}
-
+
/*iPhone 5*/
@media screen and (max-width: 320px) {
-
- .pb-home-links-outer-panel {
+
+ .pb-home-links-outer-panel {
margin-top:3px;
}
-
- .pb_benefits {
+
+ .pb_benefits {
margin-top: 50px;
}
-
+
}
@media screen and (max-width: 768px) {
-
- .col-sm-9 {
+
+ .col-sm-9 {
padding-top: 10px;
}
- .pb-content {
-
+ .pb-content {
+
font-size: 15px;
font-weight: 400;
width: 85%;
margin-left: 0px;
-
+
}
-
- .pb-content p {
+
+ .pb-content p {
font-size: 15px;
font-weight: 400;
line-height: inherit;
width: 85%;
}
-
- .pb-content li {
+
+ .pb-content li {
font-size: 15px;
font-weight: 400;
}
- .pb-content h1 {
+ .pb-content h1 {
font-size: 24px;
}
- .pb-content h2 {
+ .pb-content h2 {
font-size: 20px;
}
- .pb-content h3 {
+ .pb-content h3 {
font-size: 18px;
}
-
- .pb_footer {
+
+ .pb_footer {
display: block;
font-size:15px;
}
-
+
/*Previous @media*/
-
+
#pb-home-demo {
margin-top: 30px;
}
-
+
#pb-home-demo .col-sm-7 .lead {
margin-left: 0;
padding-left: 0;
@@ -1632,11 +1696,11 @@ pre {
.pb-sm-left {
text-align: left;
}
-
+
.pb-sm-center {
text-align: center;
}
-
+
.pb-sm-right {
text-align: right;
}
@@ -1649,7 +1713,7 @@ pre {
margin-bottom: 10px;
}
-
+
.blog-related-posts {
color: #aaa;
margin-top: 40px;
@@ -1691,7 +1755,7 @@ pre {
padding-bottom: 10px;
color: #555;
}
-
+
.docs-sidebar .nav>li>a:hover{
color: #337ab7;
background: transparent;
@@ -1770,7 +1834,7 @@ pre {
.prebid-mobile-notice {
margin-top: 2em;
}
-
+
.pb-lg-img {
width: 85%;
height: 85%;
@@ -1779,16 +1843,16 @@ pre {
.pb-xlg-img {
width: 100%;
}
-
+
.pb-md-img {
width: 60%;
height: 60%;
}
-
+
#pb-home-demo {
margin-top: 30px;
}
-
+
#pb-home-demo .col-sm-7 .lead {
margin-left: 0;
padding-left: 0;
@@ -1797,19 +1861,19 @@ pre {
.pb-sm-left {
text-align: left;
}
-
+
.pb-sm-center {
text-align: center;
}
-
+
.pb-sm-right {
text-align: right;
}
-
+
}
@media screen and (max-width: 414px) {
-
+
#wrapper {
padding-left: 0;
-webkit-transition: all 0.5s ease;
@@ -1817,11 +1881,11 @@ pre {
-o-transition: all 0.5s ease;
transition: all 0.5s ease;
}
-
+
#wrapper.toggled {
padding-left: 250px;
}
-
+
#sidebar-wrapper {
z-index: 1000;
position: fixed;
@@ -1836,11 +1900,11 @@ pre {
-o-transition: all 0.5s ease;
transition: all 0.5s ease;
}
-
+
#wrapper.toggled #sidebar-wrapper {
width: 250px;
}
-
+
.pb-lg-img {
width: 65%;
height: 65%;
@@ -1849,17 +1913,17 @@ pre {
.pb-xlg-img {
width: 100%;
}
-
+
.pb-md-img {
width: 45%;
height: 45%;
}
-
- .pb_footer {
+
+ .pb_footer {
display: block;
font-size:10px;
- }
+ }
}
@@ -2049,22 +2113,22 @@ div.pl-doc-entry{
}
/*******************
- API
+ API
+
+.categoryBox {
-.categoryBox {
-
- display:block;
- float: left;
- margin-right:10px;
- line-height:40px;
- height: 40px;
- padding-left: 15px;
- padding-right: 15px;
- background-color:#f6f8fa;
+ display:block;
+ float: left;
+ margin-right:10px;
+ line-height:40px;
+ height: 40px;
+ padding-left: 15px;
+ padding-right: 15px;
+ background-color:#f6f8fa;
text-align:center;
-
+
}
*/
@@ -2104,18 +2168,3 @@ div.pl-doc-entry{
right: 10px;
left: auto;
}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/assets/css/syntax.css b/assets/css/syntax.css
new file mode 100644
index 0000000000..8c81d8556d
--- /dev/null
+++ b/assets/css/syntax.css
@@ -0,0 +1,208 @@
+.highlight table td { padding: 5px; }
+.highlight table pre { margin: 0; }
+.highlight .c, .highlight .ch, .highlight .cd, .highlight .cpf {
+ color: #5e5d83;
+ font-style: italic;
+}
+.highlight .cm {
+ color: #5e5d83;
+ font-style: italic;
+}
+.highlight .c1 {
+ color: #5e5d83;
+ font-style: italic;
+}
+.highlight .cp {
+ color: #465457;
+ font-weight: bold;
+}
+.highlight .cs {
+ color: #465457;
+ font-weight: bold;
+ font-style: italic;
+}
+.highlight .err {
+ color: #f8f8f2;
+ background-color: #403d3d;
+}
+.highlight .gi {
+ color: #a6e22e;
+}
+.highlight .gd {
+ color: #f92672;
+}
+.highlight .ge {
+ color: #1b1d1e;
+ font-style: italic;
+}
+.highlight .gr {
+ color: #f92672;
+}
+.highlight .gt {
+ color: #f92672;
+}
+.highlight .gh {
+ color: #403d3d;
+}
+.highlight .go {
+ color: #403d3d;
+}
+.highlight .gp {
+ color: #66d9ef;
+}
+.highlight .gs {
+ font-weight: bold;
+}
+.highlight .gu {
+ color: #465457;
+}
+.highlight .k, .highlight .kv {
+ color: #66d9ef;
+ font-weight: bold;
+}
+.highlight .kc {
+ color: #66d9ef;
+ font-weight: bold;
+}
+.highlight .kd {
+ color: #66d9ef;
+ font-weight: bold;
+}
+.highlight .kp {
+ color: #66d9ef;
+ font-weight: bold;
+}
+.highlight .kr {
+ color: #66d9ef;
+ font-weight: bold;
+}
+.highlight .kt {
+ color: #66d9ef;
+ font-weight: bold;
+}
+.highlight .kn {
+ color: #f92672;
+ font-weight: bold;
+}
+.highlight .ow {
+ color: #f92672;
+ font-weight: bold;
+}
+.highlight .o {
+ color: #f92672;
+ font-weight: bold;
+}
+.highlight .mf {
+ color: #af87ff;
+}
+.highlight .mh {
+ color: #af87ff;
+}
+.highlight .il {
+ color: #af87ff;
+}
+.highlight .mi {
+ color: #af87ff;
+}
+.highlight .mo {
+ color: #af87ff;
+}
+.highlight .m, .highlight .mb, .highlight .mx {
+ color: #af87ff;
+}
+.highlight .se {
+ color: #af87ff;
+}
+.highlight .sb {
+ color: #d7d787;
+}
+.highlight .sc {
+ color: #d7d787;
+}
+.highlight .sd {
+ color: #d7d787;
+}
+.highlight .s2 {
+ color: #d7d787;
+}
+.highlight .sh {
+ color: #d7d787;
+}
+.highlight .si {
+ color: #d7d787;
+}
+.highlight .sx {
+ color: #d7d787;
+}
+.highlight .sr {
+ color: #d7d787;
+}
+.highlight .s1 {
+ color: #d7d787;
+}
+.highlight .ss {
+ color: #d7d787;
+}
+.highlight .s, .highlight .sa, .highlight .dl {
+ color: #d7d787;
+}
+.highlight .na {
+ color: #a6e22e;
+}
+.highlight .nc {
+ color: #a6e22e;
+ font-weight: bold;
+}
+.highlight .nd {
+ color: #a6e22e;
+ font-weight: bold;
+}
+.highlight .ne {
+ color: #a6e22e;
+ font-weight: bold;
+}
+.highlight .nf, .highlight .fm {
+ color: #a6e22e;
+ font-weight: bold;
+}
+.highlight .no {
+ color: #66d9ef;
+}
+.highlight .bp {
+ color: #f8f8f2;
+}
+.highlight .nb {
+ color: #f8f8f2;
+}
+.highlight .ni {
+ color: #f8f8f2;
+}
+.highlight .nn {
+ color: #f8f8f2;
+}
+.highlight .vc {
+ color: #f8f8f2;
+}
+.highlight .vg {
+ color: #f8f8f2;
+}
+.highlight .vi {
+ color: #f8f8f2;
+}
+.highlight .nv, .highlight .vm {
+ color: #f8f8f2;
+}
+.highlight .w {
+ color: #f8f8f2;
+}
+.highlight .nl {
+ color: #f8f8f2;
+ font-weight: bold;
+}
+.highlight .nt {
+ color: #f92672;
+}
+.highlight {
+ color: #f8f8f2;
+ background-color: #1b1d1e;
+}
diff --git a/assets/images/ad-ops/dfp-creative-setup/dfp-creative-declaration.png b/assets/images/ad-ops/dfp-creative-setup/dfp-creative-declaration.png
new file mode 100644
index 0000000000..541a28aa21
Binary files /dev/null and b/assets/images/ad-ops/dfp-creative-setup/dfp-creative-declaration.png differ
diff --git a/assets/images/ad-ops/mopub/full/mopub-lineitem-full-adunit.png b/assets/images/ad-ops/mopub/full/mopub-lineitem-full-adunit.png
new file mode 100644
index 0000000000..45485964f3
Binary files /dev/null and b/assets/images/ad-ops/mopub/full/mopub-lineitem-full-adunit.png differ
diff --git a/assets/images/ad-ops/mopub/full/mopub_lineitem_full_vasttag.png b/assets/images/ad-ops/mopub/full/mopub_lineitem_full_vasttag.png
new file mode 100644
index 0000000000..ec952a815c
Binary files /dev/null and b/assets/images/ad-ops/mopub/full/mopub_lineitem_full_vasttag.png differ
diff --git a/assets/images/ad-ops/mopub/rewarded/mopub-lineitem-advanced.png b/assets/images/ad-ops/mopub/rewarded/mopub-lineitem-advanced.png
new file mode 100644
index 0000000000..423d9e4eac
Binary files /dev/null and b/assets/images/ad-ops/mopub/rewarded/mopub-lineitem-advanced.png differ
diff --git a/assets/images/ad-ops/mopub/rewarded/mopub-lineitem-rewarded copy.png b/assets/images/ad-ops/mopub/rewarded/mopub-lineitem-rewarded copy.png
new file mode 100644
index 0000000000..5bf220d953
Binary files /dev/null and b/assets/images/ad-ops/mopub/rewarded/mopub-lineitem-rewarded copy.png differ
diff --git a/assets/images/ad-ops/mopub/rewarded/mopub-lineitem-rewarded.png b/assets/images/ad-ops/mopub/rewarded/mopub-lineitem-rewarded.png
new file mode 100644
index 0000000000..dafdbd7081
Binary files /dev/null and b/assets/images/ad-ops/mopub/rewarded/mopub-lineitem-rewarded.png differ
diff --git a/assets/images/ad-ops/mopub/rewarded/mopub_lineitem_vasttag.png b/assets/images/ad-ops/mopub/rewarded/mopub_lineitem_vasttag.png
new file mode 100644
index 0000000000..cda6243ce5
Binary files /dev/null and b/assets/images/ad-ops/mopub/rewarded/mopub_lineitem_vasttag.png differ
diff --git a/assets/images/ad-ops/mopub/rewarded/mopub_lineitem_vasttag2.png b/assets/images/ad-ops/mopub/rewarded/mopub_lineitem_vasttag2.png
new file mode 100644
index 0000000000..b5eadf1500
Binary files /dev/null and b/assets/images/ad-ops/mopub/rewarded/mopub_lineitem_vasttag2.png differ
diff --git a/assets/images/dev-docs/amp-rtc.png b/assets/images/dev-docs/amp-rtc.png
deleted file mode 100644
index fb35176557..0000000000
Binary files a/assets/images/dev-docs/amp-rtc.png and /dev/null differ
diff --git a/assets/images/docs/home/dark/pb-hp-format-amp.png b/assets/images/docs/home/dark/pb-hp-format-amp.png
new file mode 100644
index 0000000000..0d715263d9
Binary files /dev/null and b/assets/images/docs/home/dark/pb-hp-format-amp.png differ
diff --git a/assets/images/docs/home/dark/pb-hp-format-display.png b/assets/images/docs/home/dark/pb-hp-format-display.png
new file mode 100644
index 0000000000..d7313bc81c
Binary files /dev/null and b/assets/images/docs/home/dark/pb-hp-format-display.png differ
diff --git a/assets/images/docs/home/dark/pb-hp-format-multi.png b/assets/images/docs/home/dark/pb-hp-format-multi.png
new file mode 100644
index 0000000000..3fbd7a0739
Binary files /dev/null and b/assets/images/docs/home/dark/pb-hp-format-multi.png differ
diff --git a/assets/images/docs/home/dark/pb-hp-format-native.png b/assets/images/docs/home/dark/pb-hp-format-native.png
new file mode 100644
index 0000000000..b5eddb7732
Binary files /dev/null and b/assets/images/docs/home/dark/pb-hp-format-native.png differ
diff --git a/assets/images/docs/home/dark/pb-hp-format-video.png b/assets/images/docs/home/dark/pb-hp-format-video.png
new file mode 100644
index 0000000000..aa7b5e902f
Binary files /dev/null and b/assets/images/docs/home/dark/pb-hp-format-video.png differ
diff --git a/assets/images/docs/home/github-icon.png b/assets/images/docs/home/github-icon.png
new file mode 100644
index 0000000000..bd6423b6df
Binary files /dev/null and b/assets/images/docs/home/github-icon.png differ
diff --git a/assets/images/docs/home/old-formats/pb-hp-format-amp.png b/assets/images/docs/home/old-formats/pb-hp-format-amp.png
new file mode 100644
index 0000000000..0f1980c8e2
Binary files /dev/null and b/assets/images/docs/home/old-formats/pb-hp-format-amp.png differ
diff --git a/assets/images/docs/home/old-formats/pb-hp-format-display copy.png b/assets/images/docs/home/old-formats/pb-hp-format-display copy.png
new file mode 100644
index 0000000000..29a3b0b9c1
Binary files /dev/null and b/assets/images/docs/home/old-formats/pb-hp-format-display copy.png differ
diff --git a/assets/images/docs/home/old-formats/pb-hp-format-display.png b/assets/images/docs/home/old-formats/pb-hp-format-display.png
new file mode 100644
index 0000000000..b9fa2e09c5
Binary files /dev/null and b/assets/images/docs/home/old-formats/pb-hp-format-display.png differ
diff --git a/assets/images/docs/home/old-formats/pb-hp-format-multi.png b/assets/images/docs/home/old-formats/pb-hp-format-multi.png
new file mode 100644
index 0000000000..16b943e0ea
Binary files /dev/null and b/assets/images/docs/home/old-formats/pb-hp-format-multi.png differ
diff --git a/assets/images/docs/home/old-formats/pb-hp-format-native.png b/assets/images/docs/home/old-formats/pb-hp-format-native.png
new file mode 100644
index 0000000000..37ce024778
Binary files /dev/null and b/assets/images/docs/home/old-formats/pb-hp-format-native.png differ
diff --git a/assets/images/docs/home/old-formats/pb-hp-format-video.png b/assets/images/docs/home/old-formats/pb-hp-format-video.png
new file mode 100644
index 0000000000..5badf9bdfe
Binary files /dev/null and b/assets/images/docs/home/old-formats/pb-hp-format-video.png differ
diff --git a/assets/images/docs/home/pb-hp-dl-pbjs.png b/assets/images/docs/home/pb-hp-dl-pbjs.png
new file mode 100644
index 0000000000..227ae908eb
Binary files /dev/null and b/assets/images/docs/home/pb-hp-dl-pbjs.png differ
diff --git a/assets/images/docs/home/pb-hp-dl-pbm.png b/assets/images/docs/home/pb-hp-dl-pbm.png
new file mode 100644
index 0000000000..21ba5ada94
Binary files /dev/null and b/assets/images/docs/home/pb-hp-dl-pbm.png differ
diff --git a/assets/images/docs/home/pb-hp-dl-pbs.png b/assets/images/docs/home/pb-hp-dl-pbs.png
new file mode 100644
index 0000000000..8537e3f5c4
Binary files /dev/null and b/assets/images/docs/home/pb-hp-dl-pbs.png differ
diff --git a/assets/images/docs/home/pb-hp-dl.png b/assets/images/docs/home/pb-hp-dl.png
new file mode 100644
index 0000000000..b861ff6d8b
Binary files /dev/null and b/assets/images/docs/home/pb-hp-dl.png differ
diff --git a/assets/images/docs/home/pb-hp-format-amp.png b/assets/images/docs/home/pb-hp-format-amp.png
new file mode 100644
index 0000000000..3f2fdda473
Binary files /dev/null and b/assets/images/docs/home/pb-hp-format-amp.png differ
diff --git a/assets/images/docs/home/pb-hp-format-display.png b/assets/images/docs/home/pb-hp-format-display.png
new file mode 100644
index 0000000000..0334947ea6
Binary files /dev/null and b/assets/images/docs/home/pb-hp-format-display.png differ
diff --git a/assets/images/docs/home/pb-hp-format-multi.png b/assets/images/docs/home/pb-hp-format-multi.png
new file mode 100644
index 0000000000..28f841d158
Binary files /dev/null and b/assets/images/docs/home/pb-hp-format-multi.png differ
diff --git a/assets/images/docs/home/pb-hp-format-native.png b/assets/images/docs/home/pb-hp-format-native.png
new file mode 100644
index 0000000000..0b54c6a0f8
Binary files /dev/null and b/assets/images/docs/home/pb-hp-format-native.png differ
diff --git a/assets/images/docs/home/pb-hp-format-video.png b/assets/images/docs/home/pb-hp-format-video.png
new file mode 100644
index 0000000000..7c217cefb4
Binary files /dev/null and b/assets/images/docs/home/pb-hp-format-video.png differ
diff --git a/assets/images/docs/home/pb-hp-jsgh.png b/assets/images/docs/home/pb-hp-jsgh.png
new file mode 100644
index 0000000000..9f9ca08ab9
Binary files /dev/null and b/assets/images/docs/home/pb-hp-jsgh.png differ
diff --git a/assets/images/docs/home/pb-hp-mgh.png b/assets/images/docs/home/pb-hp-mgh.png
new file mode 100644
index 0000000000..a264d84e23
Binary files /dev/null and b/assets/images/docs/home/pb-hp-mgh.png differ
diff --git a/assets/images/docs/home/pb-hp-pbjs.png b/assets/images/docs/home/pb-hp-pbjs.png
new file mode 100644
index 0000000000..e362c6734a
Binary files /dev/null and b/assets/images/docs/home/pb-hp-pbjs.png differ
diff --git a/assets/images/docs/home/pb-hp-pbm.png b/assets/images/docs/home/pb-hp-pbm.png
new file mode 100644
index 0000000000..f3042f89e6
Binary files /dev/null and b/assets/images/docs/home/pb-hp-pbm.png differ
diff --git a/assets/images/docs/home/pb-hp-pbs.png b/assets/images/docs/home/pb-hp-pbs.png
new file mode 100644
index 0000000000..49e7900e88
Binary files /dev/null and b/assets/images/docs/home/pb-hp-pbs.png differ
diff --git a/assets/images/docs/home/pb-hp-roles-adops.png b/assets/images/docs/home/pb-hp-roles-adops.png
new file mode 100644
index 0000000000..67ed6881bd
Binary files /dev/null and b/assets/images/docs/home/pb-hp-roles-adops.png differ
diff --git a/assets/images/docs/home/pb-hp-roles-dev.png b/assets/images/docs/home/pb-hp-roles-dev.png
new file mode 100644
index 0000000000..2c6ed6198f
Binary files /dev/null and b/assets/images/docs/home/pb-hp-roles-dev.png differ
diff --git a/assets/images/docs/home/pb-hp-sgh.png b/assets/images/docs/home/pb-hp-sgh.png
new file mode 100644
index 0000000000..64f414f120
Binary files /dev/null and b/assets/images/docs/home/pb-hp-sgh.png differ
diff --git a/assets/images/flowcharts/FirstPartyData-Detailed.png b/assets/images/flowcharts/FirstPartyData-Detailed.png
new file mode 100644
index 0000000000..1e4125ffb8
Binary files /dev/null and b/assets/images/flowcharts/FirstPartyData-Detailed.png differ
diff --git a/assets/images/flowcharts/FirstPartyData-Summary.png b/assets/images/flowcharts/FirstPartyData-Summary.png
new file mode 100644
index 0000000000..cd9ac8cd84
Binary files /dev/null and b/assets/images/flowcharts/FirstPartyData-Summary.png differ
diff --git a/assets/images/flowcharts/prebid-server/pbjs-server-flow.png b/assets/images/flowcharts/prebid-server/pbjs-server-flow.png
new file mode 100644
index 0000000000..bbd0cb3fbb
Binary files /dev/null and b/assets/images/flowcharts/prebid-server/pbjs-server-flow.png differ
diff --git a/assets/images/flowcharts/prebid-server/pbjs-video-server-flow.png b/assets/images/flowcharts/prebid-server/pbjs-video-server-flow.png
new file mode 100644
index 0000000000..3f0921872b
Binary files /dev/null and b/assets/images/flowcharts/prebid-server/pbjs-video-server-flow.png differ
diff --git a/assets/images/flowcharts/prebid-server/pbm-flow.png b/assets/images/flowcharts/prebid-server/pbm-flow.png
new file mode 100644
index 0000000000..d89069c37e
Binary files /dev/null and b/assets/images/flowcharts/prebid-server/pbm-flow.png differ
diff --git a/assets/images/flowcharts/prebid-server/pbs-amp-flow.png b/assets/images/flowcharts/prebid-server/pbs-amp-flow.png
new file mode 100644
index 0000000000..450dcbc552
Binary files /dev/null and b/assets/images/flowcharts/prebid-server/pbs-amp-flow.png differ
diff --git a/assets/images/flowcharts/prebid-server/pbs-basic-flow.png b/assets/images/flowcharts/prebid-server/pbs-basic-flow.png
new file mode 100644
index 0000000000..0d5c5b09de
Binary files /dev/null and b/assets/images/flowcharts/prebid-server/pbs-basic-flow.png differ
diff --git a/assets/images/flowcharts/prebid-server/pbs-lfv-flow.png b/assets/images/flowcharts/prebid-server/pbs-lfv-flow.png
new file mode 100644
index 0000000000..8547e8a06a
Binary files /dev/null and b/assets/images/flowcharts/prebid-server/pbs-lfv-flow.png differ
diff --git a/assets/images/icons/icon-check-green.png b/assets/images/icons/icon-check-green.png
new file mode 100644
index 0000000000..a00bf5ef02
Binary files /dev/null and b/assets/images/icons/icon-check-green.png differ
diff --git a/assets/images/logos/magnite-logo-black.svg b/assets/images/logos/magnite-logo-black.svg
new file mode 100644
index 0000000000..6bcc43a5e7
--- /dev/null
+++ b/assets/images/logos/magnite-logo-black.svg
@@ -0,0 +1,19 @@
+
+
+
diff --git a/assets/images/logos/openx.png b/assets/images/logos/openx.png
new file mode 100644
index 0000000000..40368e5bc9
Binary files /dev/null and b/assets/images/logos/openx.png differ
diff --git a/assets/images/logos/prebid_docs.png b/assets/images/logos/prebid_docs.png
new file mode 100644
index 0000000000..b67d0c1117
Binary files /dev/null and b/assets/images/logos/prebid_docs.png differ
diff --git a/assets/images/logos/pubmatic-logo-black.svg b/assets/images/logos/pubmatic-logo-black.svg
new file mode 100644
index 0000000000..3f9bde6ed7
--- /dev/null
+++ b/assets/images/logos/pubmatic-logo-black.svg
@@ -0,0 +1,18 @@
+
+
\ No newline at end of file
diff --git a/assets/images/logos/xandr-logo.svg b/assets/images/logos/xandr-logo.svg
new file mode 100644
index 0000000000..6d75d86c1f
--- /dev/null
+++ b/assets/images/logos/xandr-logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/assets/images/prebid-server/golang-logo.png b/assets/images/prebid-server/golang-logo.png
new file mode 100644
index 0000000000..3410dc3629
Binary files /dev/null and b/assets/images/prebid-server/golang-logo.png differ
diff --git a/assets/images/prebid-server/java-logo.png b/assets/images/prebid-server/java-logo.png
new file mode 100644
index 0000000000..bf3d48d6c0
Binary files /dev/null and b/assets/images/prebid-server/java-logo.png differ
diff --git a/assets/images/prebid-server/pbs-amp-architecture.png b/assets/images/prebid-server/pbs-amp-architecture.png
new file mode 100644
index 0000000000..1b64272007
Binary files /dev/null and b/assets/images/prebid-server/pbs-amp-architecture.png differ
diff --git a/assets/images/prebid-server/pbs-architecture.png b/assets/images/prebid-server/pbs-architecture.png
new file mode 100644
index 0000000000..7d7625a8fb
Binary files /dev/null and b/assets/images/prebid-server/pbs-architecture.png differ
diff --git a/assets/images/prebid-server/pbs-cache-feature.png b/assets/images/prebid-server/pbs-cache-feature.png
new file mode 100644
index 0000000000..7360ab665f
Binary files /dev/null and b/assets/images/prebid-server/pbs-cache-feature.png differ
diff --git a/assets/images/prebid-server/pbs-cookie-sync.png b/assets/images/prebid-server/pbs-cookie-sync.png
new file mode 100644
index 0000000000..a6df58107d
Binary files /dev/null and b/assets/images/prebid-server/pbs-cookie-sync.png differ
diff --git a/assets/images/prebid-server/pbs-hardware-layout.png b/assets/images/prebid-server/pbs-hardware-layout.png
new file mode 100644
index 0000000000..ecbfac6843
Binary files /dev/null and b/assets/images/prebid-server/pbs-hardware-layout.png differ
diff --git a/assets/images/prebid-server/pbs-js-banner-architecture.png b/assets/images/prebid-server/pbs-js-banner-architecture.png
new file mode 100644
index 0000000000..5af5cafbef
Binary files /dev/null and b/assets/images/prebid-server/pbs-js-banner-architecture.png differ
diff --git a/assets/images/prebid-server/pbs-js-video-architecture.png b/assets/images/prebid-server/pbs-js-video-architecture.png
new file mode 100644
index 0000000000..5838600149
Binary files /dev/null and b/assets/images/prebid-server/pbs-js-video-architecture.png differ
diff --git a/assets/images/prebid-server/pbs-sdk-architecture.png b/assets/images/prebid-server/pbs-sdk-architecture.png
new file mode 100644
index 0000000000..c010f1dbcf
Binary files /dev/null and b/assets/images/prebid-server/pbs-sdk-architecture.png differ
diff --git a/assets/js/video/pb-ve-jwplayer-platform-h.js b/assets/js/video/pb-ve-jwplayer-platform-h.js
new file mode 100644
index 0000000000..5c66b7ef33
--- /dev/null
+++ b/assets/js/video/pb-ve-jwplayer-platform-h.js
@@ -0,0 +1,60 @@
+function loadVideoData() {
+
+ var pbjs = pbjs || {};
+ pbjs.que = pbjs.que || [];
+
+ // define invokeVideoPlayer in advance in case we get the bids back from prebid before the entire page loads
+ var tempTag = false;
+ var invokeVideoPlayer = function(url) {
+ tempTag = url;
+ }
+
+ var videoAdUnit = {
+ code: 'video1',
+ mediaTypes: {
+ video: {
+ playerSize: [640, 480],
+ context: 'instream'
+ }
+ },
+ bids: [{
+ bidder: 'appnexus',
+ params: {
+ placementId: 13232361, // Add your own placement id here
+ video: {
+ skipppable: true,
+ playback_method: ['auto_play_sound_off']
+ }
+ }
+ }]
+ };
+
+ pbjs.que.push(function() {
+ pbjs.addAdUnits(videoAdUnit); // add your ad units to the bid request
+
+ pbjs.setConfig({
+ debug: true,
+ cache: {
+ url: 'https://prebid.adnxs.com/pbc/v1/cache'
+ }
+ });
+
+ pbjs.requestBids({
+ bidsBackHandler: function(bids) {
+ var videoUrl = pbjs.adServers.dfp.buildVideoUrl({
+ adUnit: videoAdUnit,
+ params: {
+ iu: '/19968336/prebid_cache_video_adunit',
+ cust_params: {
+ section: 'blog',
+ anotherKey: 'anotherValue'
+ },
+ output: 'vast'
+ }
+ });
+ invokeVideoPlayer(videoUrl);
+ }
+ });
+ });
+
+}
\ No newline at end of file
diff --git a/assets/js/video/pb-ve-jwplayer-platform-m.js b/assets/js/video/pb-ve-jwplayer-platform-m.js
new file mode 100644
index 0000000000..836533e022
--- /dev/null
+++ b/assets/js/video/pb-ve-jwplayer-platform-m.js
@@ -0,0 +1,31 @@
+function loadVideoData {
+
+ alert("loading video");
+
+ var playerInstance = jwplayer('myElement1');
+
+ function invokeVideoPlayer(url) {
+ // this calls setup on the player we initialized
+ // this will use the settings defined in the player we loaded above unless you override them here
+ playerInstance.setup({
+ // this line loads a playlist from your jwplatform account (in either json or rss format)
+ // this can also be a single media file by specifying "file" : "content.jwplatform.com/videos/VIDEOKEY.mp4"
+ // Replace this with the correct url for your playlist
+ "playlist": "https://content.jwplatform.com/feeds/ae4tmw2D.json",
+ "width": 640,
+ "height": 480,
+ // we enable vast advertising for this player
+ "advertising": {
+ "client": "vast",
+ // url is the vast tag url that we passed in when we called invokeVideoPlayer in the header
+ "tag": url,
+ },
+ });
+ }
+
+ if (tempTag) {
+ invokeVideoPlayer(tempTag);
+ tempTag = false;
+ }
+
+}
\ No newline at end of file
diff --git a/deprecated-bidders/152media.md b/deprecated-bidders/152media.md
deleted file mode 100644
index baadfaa803..0000000000
--- a/deprecated-bidders/152media.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-layout: deprecated-bidder
-title: 152Media
-description: Prebid 152Media Bidder Adaptor
-
-top_nav_section: dev_docs
-nav_section: reference
-
-
-
-biddercode: oftmedia
-
-aliasCode : appnexus
-
-
-
----
-
-### Bid Params
-
-{: .table .table-bordered .table-striped }
-| Name | Scope | Description | Example | Type |
-|---------------|----------|-------------|---------|----------|
-| `placementId` | required | | | `string` |
diff --git a/dev-docs/adunit-reference.md b/dev-docs/adunit-reference.md
index a51097482b..a92652534e 100644
--- a/dev-docs/adunit-reference.md
+++ b/dev-docs/adunit-reference.md
@@ -564,4 +564,4 @@ Notes:
[setConfig]: {{site.baseurl}}/dev-docs/publisher-api-reference.html#module_pbjs.setConfig
[configureResponsive]: {{site.baseurl}}/dev-docs/publisher-api-reference.html#setConfig-Configure-Responsive-Ads
[openRTB]: https://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf
-[pbServer]: {{site.baseurl}}/dev-docs/get-started-with-prebid-server.html
+[pbServer]: {{site.baseurl}}/prebid-server/overview/prebid-server-overview.html
diff --git a/dev-docs/bidder-adaptor.md b/dev-docs/bidder-adaptor.md
index eef4fe6664..1ee40082b3 100644
--- a/dev-docs/bidder-adaptor.md
+++ b/dev-docs/bidder-adaptor.md
@@ -1,7 +1,7 @@
---
layout: page_v2
-title: How to Add a New Bidder Adapter
-description: Documentation on how to add a new bidder adapter
+title: How to Add a New Prebid.js Bidder Adapter
+description: Documentation on how to add a Prebid.js new bidder adapter
top_nav_section: dev_docs
nav_section: adapters
sidebarType: 1
@@ -9,7 +9,7 @@ sidebarType: 1
-# How to Add a New Bidder Adapter
+# How to Add a New Prebid.js Bidder Adapter
{:.no_toc}
At a high level, a bidder adapter is responsible for:
@@ -24,35 +24,24 @@ This page has instructions for writing your own bidder adapter. The instruction
## Planning your Adapter
-+ [Required Adapter Conventions](#bidder-adaptor-Required-Adapter-Conventions)
++ [Required Adapter Rules](#bidder-adaptor-Required-Adapter-Conventions)
+ [Required Files](#bidder-adaptor-Required-Files)
+ [Designing your Bid Params](#bidder-adaptor-Designing-your-Bid-Params)
-### Required Adapter Conventions
+### Required Adapter Rules
-In order to provide a fast and safe header bidding environment for publishers, the Prebid.org team reviews all adapters for the following required conventions:
+In order to provide a fast and safe header bidding environment for publishers, the Prebid.org team reviews all adapters for the required bid adapter conventions laid out in the [Module Rules](/dev-docs/module-rules.html). Here are additional details specific to Prebid.js:
-* *Support multiple instances*: All adapters must support the creation of multiple concurrent instances. This means, for example, that adapters cannot rely on mutable global variables.
-* *No loading of external libraries*: All code must be present in the adapter, not loaded at runtime. Exceptions are possible -- see [the full policy](https://github.com/prebid/prebid-js-external-js-template#policy).
-* *Must support HTTPS*: Within a secure page context, the request to the bidder's server must also be secure.
-* *Compressed responses*: All bid responses from the bidder's server must be gzipped.
-* *Bid responses may not use JSONP*: All requests must be AJAX with JSON responses.
-* *All user-sync activity must be registered via the provided functions*: The platform will place all registered syncs in the page after the auction is complete, subject to publisher configuration.
-* *Adapters may not create or trigger any network requests or pixels* outside of the requests that wrapper creates on behalf of the adapter from the return values of `buildRequests()` and `getUserSyncs()` or are included in a winning and rendered creative.
-* *Adapters may not use the `$$PREBID_GLOBAL$$` variable*: Instead, they must load any necessary functions and call them directly.
-* *Adapters may not modify ad slots directly*: e.g. Accessing `googletag.pubads().getSlots()` to modify or set targeting directly on slots is not permitted.
-* *Adapters may not override standard ad server targeting*: Do not override, or set default values for any of the standard targeting variables: hb_adid, hb_bidder, hb_pb, hb_deal, or hb_size, hb_source, hb_format.
+* **No loading of external code**: All code must be present in the adapter, not loaded at runtime. Exceptions are possible -- see [the full policy](https://github.com/prebid/prebid-js-external-js-template#policy).
+* **All user-sync activity must be registered via the provided functions**: The platform will place all registered syncs in the page after the auction is complete, subject to publisher configuration.
+* **Adapters may not create or trigger any network requests or pixels** outside of the requests the wrapper creates on behalf of the adapter (from the return values of `buildRequests()` and `getUserSyncs()`) or that are included in a winning and rendered creative.
+* **Adapters may not modify ad slots directly**: For example, accessing `googletag.pubads().getSlots()` to modify or set targeting directly on slots is not permitted.
+* **All parameter conventions must be followed**: Video params must be read from AdUnit.mediaTypes.video when available; however, bidder config can override the ad unit.
{: .alert.alert-danger :}
-Failure to follow any of the above conventions could lead to delays in approving your adapter for inclusion in Prebid.js.
-
-{: .alert.alert-danger :}
-Pull requests for non-1.0 compatible adapters will not be reviewed or accepted on the legacy branch.
-
-{: .alert.alert-danger :}
-Prebid.org does not support any version of Prebid.js prior to version 1.0.
+The above list is **not** the full list of requirements. Failure to follow any of the required conventions defined in the [Module Rules](/dev-docs/module-rules.html) could lead to delays in approving your adapter for inclusion in Prebid.js. If you'd like to apply for an exception to one of the rules, make your request in a new [Prebid.js issue](https://github.com/prebid/Prebid.js/issues).
@@ -285,22 +274,27 @@ Here is a sample bidderRequest object:
Notes on parameters in the bidderRequest object:
- **auctionID** is unique per call to `requestBids()`, but is the same across ad units.
- **refererInfo** is provided so you don't have to call any utils functions. See below for more information.
-- **gdprConsent** is the object containing data from the [GDPR ConsentManagement](/dev-docs/modules/consentManagement.html) module
+- **gdprConsent** is the object containing data from the [GDPR ConsentManagement](/dev-docs/modules/consentManagement.html) module. For TCF2+, it will contain both the tcfString and the addtlConsent string if the CMP sets the latter as part of the TCData object.
- **uspConsent** is the object containing data from the [US Privacy ConsentManagement](/dev-docs/modules/consentManagementUsp.html) module
-#### Prebid Config
+
+
+#### Prebid Standard Parameter Locations
-There are a number of important values that a publisher can set in the page that your bid adapter may need to take
-into account:
+There are a number of important values that a publisher expects to be handled in a standard way across all Prebid.js adapters:
{: .table .table-bordered .table-striped }
-| Value | Description | Example |
+| Parameter | Description | Example |
| ----- | ------------ | ---------- |
| Ad Server Currency | If your endpoint supports responding in different currencies, read this value. | config.getConfig('currency.adServerCurrency') |
-| Publisher Domain | The page may declare its domain, useful in cross-iframe scenarios. | config.getConfig('publisherDomain') |
| Bidder Timeout | Use if your endpoint needs to know how long the page is allowing the auction to run. | config.getConfig('bidderTimeout'); |
| COPPA | If your endpoint supports the Child Online Privacy Protection Act, you should read this value. | config.getConfig('coppa'); |
-| First Party Data | The publisher may provide first party data (e.g. page type). | config.getConfig('fpd'); |
+| First Party Data | The publisher may provide [first party data](/dev-docs/publisher-api-reference.html#setConfig-fpd) (e.g. page type). | config.getConfig('fpd'); |
+| Floors | Adapters that accept a floor parameter must also support the [floors module](https://docs.prebid.org/dev-docs/modules/floors.html) | [`getFloor()`](/dev-docs/modules/floors.html#bid-adapter-interface) |
+| Page Referrer | Intead of building your own function to find the page referrer, look in the standard bidRequest location. | bidderRequest.refererInfo.referer |
+| Publisher Domain | The page may declare its domain, useful in cross-iframe scenarios. | config.getConfig('publisherDomain') |
+| [Supply Chain](/dev-docs/modules/schain.html) | Adapters cannot accept an schain parameter. Rather, they must look for the schain parameter at bidRequest.schain. | bidRequest.schain |
+| Video Parameters | Video params must be read from AdUnit.mediaType.video when available; however bidder config can override the ad unit. | AdUnit.mediaType.video |
#### Referrers
@@ -562,7 +556,24 @@ If your adapter supports banner and video media types, make sure to include `'ba
### Step 2: Accept video parameters and pass them to your server
-Video parameters are often passed in from the ad unit in a `video` object.
+Video parameters are often passed in from the ad unit in a `video` object. As of Prebid 4.0 the following paramters should be read from the ad unit when available; bidders can accept overrides of the ad unit on their bidder configuration parameters but should read from the ad unit configuration when their bidder parameters are not set. Parameters one should expect on the ad unit include:
+
+| parameter |
+|-|
+| mimes |
+| minduration |
+| maxduration |
+| protocols |
+| startdelay |
+| placement |
+| skip |
+| skipafter |
+| minbitrate |
+| maxbitrate |
+| delivery |
+| playbackmethod |
+| api |
+| linearity |
The design of these parameters may vary depending on what your server-side bidder accepts. If possible, we recommend using the video parameters in the [OpenRTB specification](https://iabtechlab.com/specifications-guidelines/openrtb/).
@@ -773,7 +784,7 @@ function createBid(status, reqBid, response) {
### Deals in Ad Pods
To do deals for long-form video (`adpod` ad unit) just add the `dielTier` integer value to `bid.video.dealTier`. For more details on conducting deals in ad pods see our [ad pod module documentation](/dev-docs/modules/adpod.html).
-
+
## Supporting Native
In order for your bidder to support the native media type:
@@ -988,22 +999,61 @@ registerBidder(spec);
- Create a docs pull request against [prebid.github.io](https://github.com/prebid/prebid.github.io)
- Fork the repo
- Copy a file in [dev-docs/bidders](https://github.com/prebid/prebid.github.io/tree/master/dev-docs/bidders) and modify. Add the following metadata to the header of your .md file:
- - If you support the GDPR consentManagement module and TCF1, add `gdpr_supported: true`
- - If you support the GDPR consentManagement module and TCF2, add `tcf2_supported: true`
- - If you support the US Privacy consentManagementUsp module, add `usp_supported: true`
- - If you support one or more userId modules, add `userId: (list of supported vendors)`
- - If you support video and/or native mediaTypes add `media_types: video, native`. Note that display is added by default. If you don't support display, add "no-display" as the first entry, e.g. `media_types: no-display, native`
- - If you support COPPA, add `coppa_supported: true`
- - If you support SChain, add `schain_supported: true`
- - If your bidder doesn't work well with safeframed creatives, add `safeframes_ok: false`. This will alert publishers to not use safeframed creatives when creating the ad server entries for your bidder.
- - If you're a member of Prebid.org, add `prebid_member: true`
+ - Add `pbjs: true`. If you also have a [Prebid Server bid adapter](/prebid-server/developers/add-new-bidder-go.html), add `pbs: true`. Default is false for both.
+ - If you support the GDPR consentManagement module and TCF1, add `gdpr_supported: true`. Default is false.
+ - If you're on the IAB Global Vendor List, add your ID number in `gvl_id`.
+ - If you support the GDPR consentManagement module and TCF2, add `tcf2_supported: true`. Default is false.
+ - If you have an IAB Global Vendor List ID, add `gvl_id: ID`. There's no default.
+ - If you support the US Privacy consentManagementUsp module, add `usp_supported: true`. Default is false.
+ - If you support one or more userId modules, add `userId: (list of supported vendors)`. No default value.
+ - If you support video and/or native mediaTypes add `media_types: video, native`. Note that display is added by default. If you don't support display, add "no-display" as the first entry, e.g. `media_types: no-display, native`. No default value.
+ - If you support COPPA, add `coppa_supported: true`. Default is false.
+ - If you support the [supply chain](/dev-docs/modules/schain.html) feature, add `schain_supported: true`. Default is false.
+ - If your bidder doesn't work well with safeframed creatives, add `safeframes_ok: false`. This will alert publishers to not use safeframed creatives when creating the ad server entries for your bidder. No default value.
+ - If you support deals, set `bidder_supports_deals: true`. No default value..
+ - If you're a member of Prebid.org, add `prebid_member: true`. Default is false.
- Submit both the code and docs pull requests
+For example:
+```
+---
+layout: bidder
+title: example
+description: Prebid example Bidder Adapter
+biddercode: example
+gdpr_supported: true/false
+tcf2_supported: true/false
+gvl_id: 111
+usp_supported: true/false
+coppa_supported: true/false
+schain_supported: true/false
+userId: (list of supported vendors)
+media_types: banner, video, native
+safeframes_ok: true/false
+bidder_supports_deals: true/false
+pbjs: true/false
+pbs: true/false
+prebid_member: true/false
+gvl_id: none
+---
+### Note:
+
+The Example Bidding adapter requires setup before beginning. Please contact us at setup@example.com
+
+### Bid Params
+
+{: .table .table-bordered .table-striped }
+| Name | Scope | Description | Example | Type |
+|---------------|----------|-----------------------|-----------|-----------|
+| `placement` | required | Placement id | `'11111'` | `string` |
+```
+
Within a few days, the code pull request will be assigned to a developer for review.
Once the inspection passes, the code will be merged and included with the next release. Once released, the documentation pull request will be merged.
-The Prebid.org [download page]({{site.baseurl}}/download.html) will automatically be updated with your adapter once everything's been merged.
+The Prebid.org [download page](/download.html) will automatically be updated with your adapter once everything's been merged.
## Further Reading
-+ [The bidder adapter sources in the repo](https://github.com/prebid/Prebid.js/tree/master/modules)
++ [Prebid.js Repo - Bidder Adapter Sources](https://github.com/prebid/Prebid.js/tree/master/modules)
++ [Module Rules](/dev-docs/module-rules.html)
diff --git a/dev-docs/bidder-data.csv b/dev-docs/bidder-data.csv
new file mode 100644
index 0000000000..8906277e32
--- /dev/null
+++ b/dev-docs/bidder-data.csv
@@ -0,0 +1,7 @@
+---
+layout: none
+search: exclude
+---
+bidder-code,bidder-name,banner,video,native,gdpr-tcf1,gdpr-tcf2,schain,coppa,usp,safeframes,deals,client-adapter,server-adapter,user-ids
+{% assign bidder_pages = site.pages | where: "layout", "bidder" %}{% for page in bidder_pages %}{{ page.biddercode }},{{ page.title }},{% if page.media_types contains 'banner' %}yes{% else %}no{% endif %},{% if page.media_types contains 'video' %}yes{% else %}no{% endif %},{% if page.media_types contains 'native' %}yes{% else %}no{% endif %},{% if page.gdpr_supported == true %}yes{% else %}no{% endif %},{% if page.tcf2_supported == true %}yes{% else %}no{% endif %},{% if page.schain_supported == true %}yes{% else %}no{% endif %},{% if page.coppa_supported == true %}yes{% else %}no{% endif %},{% if page.usp_supported == true %}yes{% else %}no{% endif %},{% if page.safeframes_ok and page.safeframes_ok == false %}no{% elsif page.safeframes_ok and page.safeframes_ok == true %}yes{% else %}check with bidder{% endif %},{% if page.bidder_supports_deals and page.bidder_supports_deals == false %}no{% else %}yes{% endif %},{% if page.pbjs == true %}yes{% else %}no{% endif %},{% if page.pbs == true %}yes{% else %}no{% endif %},{% if page.userIds and page.userIds != '' %}"{{page.userIds}}"{% else %}none{% endif %}
+{% endfor %}
diff --git a/dev-docs/bidders.md b/dev-docs/bidders.md
index 63961e3071..dfa96bd249 100644
--- a/dev-docs/bidders.md
+++ b/dev-docs/bidders.md
@@ -1,35 +1,29 @@
---
layout: page_v2
-title: Bidder Params
+title: Prebid.js Bidder Params
description: Documentation on bidders' params
sidebarType: 1
---
-# Bidder Params
+# Prebid.js Bidder Params
This page contains documentation on the specific parameters required by each supported bidder.
These docs only apply to Prebid.js bidders. For Prebid Server, AMP, or Prebid Mobile, see the
-[Prebid Server Bidders]({{site.baseurl}}/dev-docs/prebid-server-bidders.html) page.
+[Prebid Server Bidders](/dev-docs/pbs-bidders.html) page.
For each bidder listed below, you'll find the following information:
{: .table .table-bordered .table-striped }
-| **Bidder Code** | The unique code Prebid.js uses to identify the bidder |
+| **Features** | A table of features supported by the adapter. |
| **"Send All Bids" Ad Server Keys** | Used for sending all bids to the ad server, as described in [Send All Bids to the Ad Server]({{site.baseurl}}/adops/send-all-bids-adops.html) |
-| **"Default Deal ID" Ad Server Key** | Used for enabling deals using Prebid.js, as described in [Enable Deals in Prebid]({{site.baseurl}}/adops/deals.html) |
| **Bid Params** | Ad request parameters required by a given bidder, such as the tag ID, site ID, or query string parameters |
-In addition to the bidder-specific parameters, there are common parameters that appear in all bid responses.
+You can also download the full CSV data file.
-For information about which bidders support video and native demand, see this list of bidders with video and native demand.
-{% assign bidder_pages = site.pages | where: "layout", "bidder" %}
+{% assign bidder_pages = site.pages | where: "layout", "bidder" | where: "pbjs", true %}
-- [Bidders](#bidders)
-- [Common Bid Response Parameters](#common-bid-response-parameters)
-- [Bidders with Video and Native Demand](#bidders-with-video-and-native-demand)
-
-## Bidders
+## Bidder List
+
-
{% for page in bidder_pages %}
@@ -39,70 +33,24 @@ For information about which bidders support video and native demand, see
-
-
-
- EU GDPR with optional GDPR Enforcement module
- US Privacy (CCPA)
- EU GDPR with optional GDPR Enforcement module
- US Privacy (CCPA)
- +{{ page.title }} + +{% endfor %} +
- You need to work with video or native AdUnits
- The site needs to alter different AdUnits at different screen widths; e.g., the left-nav changes sizes at 600 pixels, but the footer's size behavior changes at 620 pixels.
- The site needs to alter different mediaTypes at different screen widths; e.g., the banner size ranges are 0-400px, 401-700px, and 701+px, but the native ads appear at 500px.
- Some bidders or mediaTypes should be included (or removed) at different overlapping size ranges.
-
-
-
-## Common Bid Response Parameters
-{: .no_toc }
-
-The following parameters in the `bidResponse` object are common across all bidders.
-
-{: .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"` |
-| `adId` | String | Unique identifier of a bid creative. Used by the line item's creative as in [this example]({{site.baseurl}}/adops/send-all-bids-adops.html#step-3-add-a-creative) | `"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"` |
-| `pbHg` | String | High granularity price bucket: 0.01 increment, capped at $20, floored to 2 decimal places (0.01, 0.02, ..., 19.99, 20.00) | `"1.61"` |
-| `size` | String | Size of the bid creative; concatenation of width and height by 'x' | `"300x250"` |
-| `width` | Integer | Width of the bid creative in pixels | `300` |
-| `height` | Integer | Height of the bid creative in pixels | `250` |
-| `adTag` | String | Creative's payload in HTML | `""` |
-
-
-
-
-## Bidders with Video and Native Demand
-{: .no_toc }
-
-{% assign bidder_pages = site.pages | where: "layout", "bidder" %}
-
-
-
+## Bidder Documentation
{% for page in bidder_pages %}
"` |
-
-
-
-
-## Bidders with Video and Native Demand
-{: .no_toc }
-
-{% assign bidder_pages = site.pages | where: "layout", "bidder" %}
-| Bidder | -Supported Media Types | -
|---|---|
| {{page.biddercode}} | {% if page.media_types contains 'video' and page.media_types contains 'native' %} video, native {% elsif page.media_types contains 'native' %} native {% elsif page.media_types contains 'video' %} video {% endif %} |
-
diff --git a/dev-docs/bidders/1ad4good.md b/dev-docs/bidders/1ad4good.md
index 22a1e2e530..fdfc47a99b 100644
--- a/dev-docs/bidders/1ad4good.md
+++ b/dev-docs/bidders/1ad4good.md
@@ -2,7 +2,7 @@
layout: bidder
title: 1ad4good
description: Prebid One Ad for Good(1ad4good.org) Bidder Adaptor
-
+pbjs: true
biddercode: 1ad4good
---
diff --git a/dev-docs/bidders/33across.md b/dev-docs/bidders/33across.md
index 2aa65494de..68e6affa55 100644
--- a/dev-docs/bidders/33across.md
+++ b/dev-docs/bidders/33across.md
@@ -2,7 +2,8 @@
layout: bidder
title: 33Across
description: Prebid 33Across Bidder Adapter
-
+pbjs: true
+pbs: true
biddercode: 33across
gdpr_supported: true
schain_supported: true
diff --git a/dev-docs/bidders/7xbid.md b/dev-docs/bidders/7xbid.md
index fec2616b50..b2ad7fa519 100644
--- a/dev-docs/bidders/7xbid.md
+++ b/dev-docs/bidders/7xbid.md
@@ -2,7 +2,7 @@
layout: bidder
title: 7xbid
description: Prebid 7xbid Bidder Adaptor
-
+pbjs: true
biddercode: 7xbid
media_types: banner, native
---
@@ -13,4 +13,4 @@ media_types: banner, native
| Name | Scope | Description | Example | Type |
|---------------|----------|-------------|---------|----------|
| `placementId` | required | This is placement Id | `1425292` | `integer` |
-| `currency` | optional | 3-letter ISO 4217 code defining the currency of the bid (currently support USD and JPY), default is JPY | `'USD'` | `string` |
\ No newline at end of file
+| `currency` | optional | 3-letter ISO 4217 code defining the currency of the bid (currently support USD and JPY), default is JPY | `'USD'` | `string` |
diff --git a/dev-docs/bidders/9MediaOnline.md b/dev-docs/bidders/9MediaOnline.md
index 89e92fd167..ca093a0c98 100644
--- a/dev-docs/bidders/9MediaOnline.md
+++ b/dev-docs/bidders/9MediaOnline.md
@@ -3,7 +3,7 @@ layout: bidder
title: 9 Media Online
description: Prebid 9 Media Online Bidder Adaptor
biddercode: 9MediaOnline
-
+pbjs: true
media_types: banner, video
gdpr_supported: true
schain_supported: true
diff --git a/dev-docs/bidders/SafeReach.md b/dev-docs/bidders/SafeReach.md
index 09a4fde4bc..1c2ff90c6b 100644
--- a/dev-docs/bidders/SafeReach.md
+++ b/dev-docs/bidders/SafeReach.md
@@ -2,7 +2,7 @@
layout: bidder
title: SafeReach
description: Prebid Safe Reach Bidder Adaptor
-
+pbjs: true
biddercode: safereach
aliasCode : aardvark
---
diff --git a/dev-docs/bidders/a4g.md b/dev-docs/bidders/a4g.md
index 9f6f9324e3..0e6bf6c0dd 100644
--- a/dev-docs/bidders/a4g.md
+++ b/dev-docs/bidders/a4g.md
@@ -2,7 +2,7 @@
layout: bidder
title: A4G
description: Prebid A4G Bidder Adaptor
-
+pbjs: true
biddercode: a4g
gdpr_supported: true
---
diff --git a/dev-docs/bidders/aardvark.md b/dev-docs/bidders/aardvark.md
index c2fbbde224..9bd3a21da0 100644
--- a/dev-docs/bidders/aardvark.md
+++ b/dev-docs/bidders/aardvark.md
@@ -2,13 +2,14 @@
layout: bidder
title: Aardvark
description: Prebid Aardvark Bidder Adaptor
-
+pbjs: true
biddercode: aardvark
gdpr_supported: true
tcf2_supported: true
usp_supported: true
schain_supported: true
userIds: unifiedId
+gvl_id: 52
---
### Bid Params
diff --git a/dev-docs/bidders/ablida.md b/dev-docs/bidders/ablida.md
index 1e92de8192..590cc756df 100644
--- a/dev-docs/bidders/ablida.md
+++ b/dev-docs/bidders/ablida.md
@@ -2,9 +2,10 @@
layout: bidder
title: ablida
description: Prebid ablida Bidder Adaptor
-
-media_types: banner
+pbjs: true
biddercode: ablida
+media_types: banner, native, video
+gdpr_supported: true
---
diff --git a/dev-docs/bidders/adagio.md b/dev-docs/bidders/adagio.md
index d628a0b9eb..287604e16f 100644
--- a/dev-docs/bidders/adagio.md
+++ b/dev-docs/bidders/adagio.md
@@ -2,12 +2,15 @@
layout: bidder
title: Adagio
description: Prebid Adagio Bidder Adaptor
-
+pbjs: true
biddercode: adagio
media_types: banner
gdpr_supported: true
+usp_supported: true
+coppa_supported: true
schain_supported: true
tcf2_supported: true
+gvl_id: 617
---
### Note
diff --git a/dev-docs/bidders/adastaMedia.md b/dev-docs/bidders/adastaMedia.md
index 4e4d6c3167..e69fbeef33 100644
--- a/dev-docs/bidders/adastaMedia.md
+++ b/dev-docs/bidders/adastaMedia.md
@@ -2,7 +2,7 @@
layout: bidder
title: Adasta Media
description: Prebid Adasta Media Bidder Adaptor
-
+pbjs: true
biddercode: adasta
aliasCode : appnexus
---
diff --git a/dev-docs/bidders/adbutler.md b/dev-docs/bidders/adbutler.md
index 6cfe2d661b..950a1258c6 100644
--- a/dev-docs/bidders/adbutler.md
+++ b/dev-docs/bidders/adbutler.md
@@ -2,7 +2,7 @@
layout: bidder
title: AdButler
description: Prebid AdButler Bidder Adaptor
-
+pbjs: true
biddercode: adbutler
---
@@ -10,10 +10,11 @@ biddercode: adbutler
### Bid Params
{: .table .table-bordered .table-striped }
-| Name | Scope | Description | Example | Type |
-|-------------|----------|--------------------------------------|------------------|----------|
-| `accountID` | required | Account ID | `'167283'` | `string` |
-| `zoneID` | required | Zone ID | `'210093'` | `string` |
-| `keyword` | optional | Keyword(s) used for custom targeting | `'green,orange'` | `string` |
-| `minCPM` | optional | Minimum CPM value to accept | `'1.00'` | `string` |
-| `maxCPM` | optional | Maximum CPM value to accept | `'5.00'` | `string` |
+| Name | Scope | Description | Example | Type |
+|-------------|----------|------------------------------------------------------|------------------|----------|
+| `accountID` | required | Account ID | `'167283'` | `string` |
+| `zoneID` | required | Zone ID | `'210093'` | `string` |
+| `keyword` | optional | Keyword(s) used for custom targeting | `'green,orange'` | `string` |
+| `minCPM` | optional | Minimum CPM value to accept | `'1.00'` | `string` |
+| `maxCPM` | optional | Maximum CPM value to accept | `'5.00'` | `string` |
+| `extra` | optional | Pass other AdButler parameters like 'tuid' or 'kw' | `{kw: "green"}` | `object` |
diff --git a/dev-docs/bidders/adfinity.md b/dev-docs/bidders/adfinity.md
index 98b4bd34a5..733b0a7c76 100644
--- a/dev-docs/bidders/adfinity.md
+++ b/dev-docs/bidders/adfinity.md
@@ -2,7 +2,7 @@
layout: bidder
title: Adfinity
description: Prebid Adfinity Bidder Adaptor
-
+pbjs: true
biddercode: adfinity
media_types: banner, video, native
gdpr_supported: true
@@ -14,4 +14,4 @@ gdpr_supported: true
| Name | Scope | Description | Example | Type |
|----------------|----------|----------------------------------------------------------|------------|-----------|
| `placement_id` | required | Placement Id will be generated on Adfinity Platform. | `0` | `integer` |
-| `traffic` | optional | Type traffic | `'banner'` | `string` |
\ No newline at end of file
+| `traffic` | optional | Type traffic | `'banner'` | `string` |
diff --git a/dev-docs/bidders/adform.md b/dev-docs/bidders/adform.md
deleted file mode 100644
index 17186299b9..0000000000
--- a/dev-docs/bidders/adform.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-layout: bidder
-title: Adform
-description: Prebid Adform Bidder Adaptor
-
-biddercode: adform
-media_types: banner, video
-gdpr_supported: true
-usp_supported: true
-tcf2_supported: true
-prebid_member: true
-userIds: britepoolId, criteo, id5Id, identityLink, liveIntentId, netId, parrableId, pubCommonId, sharedId, unifiedId
----
-
-
-### Bid Params
-
-{: .table .table-bordered .table-striped }
-| Name | Scope | Description | Example | Type |
-|-------------|----------|-------------------|--------------------|-----------|
-| `mid` | required | | `12345` | `integer` |
-| `adxDomain` | optional | The Adform domain | `'adx.adform.net'` | `string` |
diff --git a/dev-docs/bidders/adformOpenRTB.md b/dev-docs/bidders/adformOpenRTB.md
index 246fa4a1e7..c6b1d9e458 100644
--- a/dev-docs/bidders/adformOpenRTB.md
+++ b/dev-docs/bidders/adformOpenRTB.md
@@ -2,14 +2,15 @@
layout: bidder
title: AdformOpenRTB
description: Prebid AdformOpenRTB Bidder Adaptor
-
biddercode: adformOpenRTB
media_types: no-display, native
gdpr_supported: true
usp_supported: true
tcf2_supported: true
prebid_member: true
+pbjs: true
userIds: britepoolId, criteo, id5Id, identityLink, liveIntentId, netId, parrableId, pubCommonId, sharedId, unifiedId
+gvl_id: 50
---
### Bid params
diff --git a/dev-docs/bidders/adformPbjs.md b/dev-docs/bidders/adformPbjs.md
new file mode 100644
index 0000000000..a27591e5f6
--- /dev/null
+++ b/dev-docs/bidders/adformPbjs.md
@@ -0,0 +1,48 @@
+---
+layout: bidder
+title: Adform
+description: Prebid.js Adform Bidder Adaptor
+biddercode: adform
+media_types: banner, video
+gdpr_supported: true
+usp_supported: true
+tcf2_supported: true
+prebid_member: true
+pbjs: true
+pbs: false
+userIds: britepoolId, criteo, id5Id, identityLink, liveIntentId, netId, parrableId, pubCommonId, sharedId, unifiedId
+gvl_id: 50
+---
+
+
+### Bid Params
+
+{: .table .table-bordered .table-striped }
+| Name | Scope | Description | Example | Type |
+|-------------|----------|-----------------------------------------------|----------------------------|-----------|
+| `mid` | required | | `12345` | `integer` |
+| `adxDomain` | optional | The Adform domain | `'adx.adform.net'` | `string` |
+| `priceType` | optional | An expected price type (net or gross) of bids | `'net'` | `string` |
+| `mkv` | optional | Comma-separated key-value pairs | `'city:NY'` | `string` |
+| `mkw` | optional | Comma-separated keywords | `'news,sport'` | `string` |
+| `minp` | optional | Minimum CPM price | `2.55` | `number` |
+| `cdims` | optional | Comma-separated creative dimentions | `'300x250'` | `string` |
+| `url` | optional | Custom targeting URL | `'https://some.app/?home'` | `string` |
+
+Note: Spaces are not allowed between comma-separated list values. For example:
+```
+// valid params
+{
+ mid: 12345,
+ mkv: 'city:NY,city:London',
+ mkv: 'news,sport',
+ cdims: '300x250,250x300'
+}
+// invalid params
+{
+ mid: 12345,
+ mkv: 'city:NY, city:London',
+ mkv: 'news, sport',
+ cdims: '300x250, 250x300'
+}
+```
diff --git a/dev-docs/bidders/adformPbs.md b/dev-docs/bidders/adformPbs.md
new file mode 100644
index 0000000000..cdb6b81922
--- /dev/null
+++ b/dev-docs/bidders/adformPbs.md
@@ -0,0 +1,48 @@
+---
+layout: bidder
+title: Adform
+description: Prebid Server Adform Bidder Adaptor
+biddercode: adform
+media_types: banner
+gdpr_supported: true
+usp_supported: true
+tcf2_supported: true
+prebid_member: true
+pbjs: false
+pbs: true
+userIds: britepoolId, criteo, id5Id, identityLink, liveIntentId, netId, parrableId, pubCommonId, sharedId, unifiedId
+gvl_id: 50
+---
+
+
+### Bid Params
+
+{: .table .table-bordered .table-striped }
+| Name | Scope | Description | Example | Type |
+|-------------|----------|-----------------------------------------------|----------------------------|-----------|
+| `mid` | required | | `12345` | `integer` |
+| `adxDomain` | optional | The Adform domain | `'adx.adform.net'` | `string` |
+| `priceType` | optional | An expected price type (net or gross) of bids | `'net'` | `string` |
+| `mkv` | optional | Comma-separated key-value pairs | `'city:NY'` | `string` |
+| `mkw` | optional | Comma-separated keywords | `'news,sport'` | `string` |
+| `minp` | optional | Minimum CPM price | `2.55` | `number` |
+| `cdims` | optional | Comma-separated creative dimentions | `'300x250'` | `string` |
+| `url` | optional | Custom targeting URL | `'https://some.app/?home'` | `string` |
+
+Note: Spaces are not allowed between comma-separated list values. For example:
+```
+// valid params
+{
+ mid: 12345,
+ mkv: 'city:NY,city:London',
+ mkv: 'news,sport',
+ cdims: '300x250,250x300'
+}
+// invalid params
+{
+ mid: 12345,
+ mkv: 'city:NY, city:London',
+ mkv: 'news, sport',
+ cdims: '300x250, 250x300'
+}
+```
diff --git a/dev-docs/bidders/adgeneration.md b/dev-docs/bidders/adgeneration.md
index 6f1dc6c292..8ff03a0902 100644
--- a/dev-docs/bidders/adgeneration.md
+++ b/dev-docs/bidders/adgeneration.md
@@ -2,7 +2,8 @@
layout: bidder
title: Ad Generation
description: Prebid Ad Generation Bidder Adaptor
-
+pbjs: true
+pbs: true
biddercode: adgeneration
media_types: native
---
diff --git a/dev-docs/bidders/adglare.md b/dev-docs/bidders/adglare.md
index 8447f413d5..0824b74adb 100644
--- a/dev-docs/bidders/adglare.md
+++ b/dev-docs/bidders/adglare.md
@@ -2,7 +2,7 @@
layout: bidder
title: AdGlare Ad Server
description: Prebid Adapter for AdGlare Ad Server
-
+pbjs: true
biddercode: adglare
media_types: banner
---
diff --git a/dev-docs/bidders/adhese.md b/dev-docs/bidders/adhese.md
index c4ba88c18e..44cee22d52 100644
--- a/dev-docs/bidders/adhese.md
+++ b/dev-docs/bidders/adhese.md
@@ -2,15 +2,21 @@
layout: bidder
title: Adhese
description: Prebid Adhese Bidder Adaptor
-
+pbjs: true
+pbs: true
biddercode: adhese
media_types: banner, video
gdpr_supported: true
+tcf2_supported: true
userIds: id5Id
+gvl_id: 553
---
-### Note
+### Registration
+
The Adhese bid adapter may require an additional setup from the Adhese team, even for existing Adhese customers. Please reach out to your support team or info@adhese.com for more information.
+
+Prebid Server host companies need to work with Adhese for each additional publisher.
### Bid Params
diff --git a/dev-docs/bidders/adkernel.md b/dev-docs/bidders/adkernel.md
index 190eaa95f1..16e8711114 100644
--- a/dev-docs/bidders/adkernel.md
+++ b/dev-docs/bidders/adkernel.md
@@ -2,7 +2,8 @@
layout: bidder
title: AdKernel
description: Prebid AdKernel Bidder Adaptor
-
+pbjs: true
+pbs: true
biddercode: adkernel
media_types: banner, native, video
gdpr_supported: true
diff --git a/dev-docs/bidders/adkernelAdn.md b/dev-docs/bidders/adkernelAdn.md
index e35c2ff565..262fb805b2 100644
--- a/dev-docs/bidders/adkernelAdn.md
+++ b/dev-docs/bidders/adkernelAdn.md
@@ -2,7 +2,8 @@
layout: bidder
title: AdKernelAdn
description: Prebid AdKernel Ad Delivery Network Bidder Adaptor
-
+pbjs: true
+pbs: true
biddercode: adkernelAdn
media_types: banner, video
gdpr_supported: true
diff --git a/dev-docs/bidders/adlive.md b/dev-docs/bidders/adlive.md
index e1cd803b03..a9c20c6834 100644
--- a/dev-docs/bidders/adlive.md
+++ b/dev-docs/bidders/adlive.md
@@ -2,7 +2,7 @@
layout: bidder
title: Adlive
description: adlive bid adapter
-
+pbjs: true
biddercode: adlive
---
diff --git a/dev-docs/bidders/adman.md b/dev-docs/bidders/adman.md
index 74a95f6624..f576a97602 100644
--- a/dev-docs/bidders/adman.md
+++ b/dev-docs/bidders/adman.md
@@ -2,10 +2,12 @@
layout: bidder
title: ADman Media
description: Prebid Adman Bidder Adapter
-
+pbjs: true
+pbs: true
biddercode: adman
gdpr_supported: true
media_types: banner, video
+tcf2_supported: true
---
### Note:
diff --git a/dev-docs/bidders/admedia.md b/dev-docs/bidders/admedia.md
index 849619152d..6a43c8b45d 100644
--- a/dev-docs/bidders/admedia.md
+++ b/dev-docs/bidders/admedia.md
@@ -2,7 +2,7 @@
layout: bidder
title: AdMedia
description: Prebid AdMedia Bidder Adaptor
-
+pbjs: true
biddercode: admedia
media_types: banner
gdpr_supported: false
diff --git a/dev-docs/bidders/admixer.md b/dev-docs/bidders/admixer.md
index 8f2670d32e..72addab0ec 100644
--- a/dev-docs/bidders/admixer.md
+++ b/dev-docs/bidders/admixer.md
@@ -2,7 +2,8 @@
layout: bidder
title: AdMixer
description: Prebid AdMixer Bidder Adaptor
-
+pbjs: true
+pbs: true
biddercode: admixer
media_types: video
gdpr_supported: true
diff --git a/dev-docs/bidders/adnow.md b/dev-docs/bidders/adnow.md
new file mode 100644
index 0000000000..be7944b160
--- /dev/null
+++ b/dev-docs/bidders/adnow.md
@@ -0,0 +1,17 @@
+---
+layout: bidder
+title: AdNow
+description: Prebid AdNow Bidder Adaptor
+biddercode: adnow
+pbjs: true
+media_types: native, banner
+---
+### Note:
+The Example Bidding adapter requires setup before beginning. Please contact us at support@adnow.com
+
+### Bid Params
+
+{: .table .table-bordered .table-striped }
+| Name | Scope | Description | Example | Type |
+|------------|----------|------------------------|---------|----------|
+| codeId | required | CodeId parameter in AdNow Network | 123456 | number |
diff --git a/dev-docs/bidders/adnuntius.md b/dev-docs/bidders/adnuntius.md
index fb22d3af22..20278812e0 100644
--- a/dev-docs/bidders/adnuntius.md
+++ b/dev-docs/bidders/adnuntius.md
@@ -2,7 +2,7 @@
layout: bidder
title: Adnuntius
description: Prebid Adnuntius Bidder Adaptor
-
+pbjs: true
biddercode: adnuntius
media_types: banner
gdpr_supported: false
@@ -49,4 +49,4 @@ Here's an example of sending targeting information about categories to adnuntius
}
]
}
-```
\ No newline at end of file
+```
diff --git a/dev-docs/bidders/adocean.md b/dev-docs/bidders/adocean.md
index 5c679bc4be..65de51ef14 100644
--- a/dev-docs/bidders/adocean.md
+++ b/dev-docs/bidders/adocean.md
@@ -2,11 +2,16 @@
layout: bidder
title: AdOcean
description: Prebid AdOcean Bidder Adaptor
-
+pbjs: true
+pbs: true
biddercode: adocean
gdpr_supported: true
+tcf2_supported: true
---
+### Note
+The AdOcean bid adapter may require an additional setup from the AdOcean team. Please contact with your local Technical Support team or by visiting [AdOcean website](https://adocean-global.com/en/contact/).
+
### Bid Params
{: .table .table-bordered .table-striped }
diff --git a/dev-docs/bidders/adoppler.md b/dev-docs/bidders/adoppler.md
new file mode 100644
index 0000000000..15fcf99fb2
--- /dev/null
+++ b/dev-docs/bidders/adoppler.md
@@ -0,0 +1,14 @@
+---
+layout: bidder
+title: Adoppler
+pbs: true
+media_types: video
+biddercode: adoppler
+---
+
+### Bid Params
+
+{: .table .table-bordered .table-striped }
+| Name | Scope | Description | Example | Type |
+|------------|----------|------------------------|---------|----------|
+| adunit | required | AdUnit to bid against | 'test' | string |
diff --git a/dev-docs/bidders/adot.md b/dev-docs/bidders/adot.md
index e71b82677d..c84589ec47 100644
--- a/dev-docs/bidders/adot.md
+++ b/dev-docs/bidders/adot.md
@@ -3,32 +3,33 @@ layout: bidder
title: Adot
description: Prebid Adot Bidder Adapter
biddercode: adot
-
+pbjs: true
media_types: banner, video, native
gdpr_supported: true
---
### Table of Contents
-- [Bid Params](#bid-params)
-- [Video Object](#video-object)
+- [Bid Params](#adot-bid-params)
+- [Video Object](#adot-video-object)
-#### Bid Params
+#### Adot Bid Params
{: .table .table-bordered .table-striped }
-| Name | Scope | Description | Example | Type |
-|---------------------|----------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------|------------------|
-| `placementId` | optional | The placement ID from Adot. | `'adot_placement_224521'` | `string` |
-| `position` | optional | Specify the position of the ad as a relative measure of visibility or prominence. Allowed values: Unknown: `0` (default); Above the fold: `1` ; Below the fold: `3`. | `0` | `integer-` |
-| `video` | optional | Object containing video targeting parameters. See [Video Object](#video-object) for details. | `video: { mimes: ['video/mp4'] }` | `object` |
+| Name | Scope | Description | Example | Type |
+|---------------------|-----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------|------------------|
+| `placementId` | optional | The placement ID from Adot. | `'adot_placement_224521'` | `string` |
+| `position` | optional | Specify the position of the ad as a relative measure of visibility or prominence. Allowed values: Unknown: `0` (default); Above the fold: `1` ; Below the fold: `3`. | `0` | `integer-` |
+| `video` | required if the adUnit is a video | Object containing video targeting parameters. See [Video Object](#adot-video-object) for details. | `video: { mimes: ['video/mp4'] }` | `object` |
-#### Video Object
+#### Adot Video Object
{: .table .table-bordered .table-striped }
-| Name | Description | Type |
-|-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------|
-| `mimes` | Array of strings listing the content MIME types supported, e.g., `['video/mp4']`. | `Array{{ page.title }}
+ +{{ page.title }}
-{% if page.s2s_only == true %} -Note:
This is a S2S adapter only. -{% endif %} - -Features
+Features
{: .table .table-bordered .table-striped } | **Bidder Code** | {{ page.biddercode }} | **Prebid.org Member** | {% if page.prebid_member == true %}yes{% else %}no{% endif %} | -| **Media Types** | {% unless page.media_types contains 'no-display' %}display{% endunless %}{% if page.media_types contains 'video' %},{% endif %}{% if page.media_types contains 'video' %} video{% endif %}{% if page.media_types != "no-display, native" and page.media_types contains 'native' %}, native{% endif %}{% if page.media_types == "no-display, native" %}native{% endif %} | **GDPR TCF1 Support** | {% if page.gdpr_supported == true %}yes{% else %}no{% endif %} | +| **Media Types** | {% unless page.media_types contains 'no-display' %}display{% if page.media_types contains 'video' %},{% endif %}{% endunless %}{% if page.media_types contains 'video' %} video{% endif %}{% if page.media_types != "no-display, native" and page.media_types contains 'native' %}, native{% endif %}{% if page.media_types == "no-display, native" %}native{% endif %} | **GDPR TCF1 Support** | {% if page.gdpr_supported == true %}yes{% else %}no{% endif %} | | **User IDs** | {% if page.userIds and page.userIds != '' %}{{page.userIds}}{% else %}none{% endif %} | **GDPR TCF2 Support** | {% if page.tcf2_supported == true %}yes{% else %}no{% endif %} | | **SChain Support** | {% if page.schain_supported == true %}yes{% else %}no{% endif %} | **COPPA Support** | {% if page.coppa_supported == true %}yes{% else %}no{% endif %} | -| **Safeframes OK** | {% if page.safeframes_ok and page.safeframes_ok == false %}no{% elsif page.safeframes_ok and page.safeframes_ok == true %}yes{% else %}check with bidder{% endif %} | **USP/CCPA Support** | {% if page.usp_supported == true %}yes{% else %}no{% endif %} | - +| **Safeframes OK** | {% if page.safeframes_ok == false %}no{% elsif page.safeframes_ok == true %}yes{% else %}check with bidder{% endif %} | **USP/CCPA Support** | {% if page.usp_supported == true %}yes{% else %}no{% endif %} | +| **Supports Deals** | {% if page.bidder_supports_deals == false %}no{% elsif page.bidder_supports_deals == true %}yes{% else %}check with bidder{% endif %} | **Prebid.js Adapter** | yes | +| **IAB GVL ID** | {% if page.gvl_id %}{{page.gvl_id}}{% else %}check with bidder{% endif %} | **Prebid Server Adapter** | {% if page.pbs == true %}yes{% else %}no{% endif %} |"Send All Bids" Ad Server Keys
@@ -112,6 +60,7 @@ The following parameters in the `bidResponse` object are common across all bidde |{{ "hb_pb_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_bidder_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_adid_" | append: page.biddercode | slice: 0,20 }} |
| {{ "hb_size_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_source_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_format_" | append: page.biddercode | slice: 0,20 }} |
| {{ "hb_cache_host_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_cache_id_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_uuid_" | append: page.biddercode | slice: 0,20 }} |
+| {{ "hb_cache_path_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_deal_" | append: page.biddercode | slice: 0,20 }} | |
{% if page.prevBiddercode %}
@@ -119,14 +68,6 @@ This bidder previously had a bidder code of `{{ page.prevBiddercode }}`, but pre
{% endif %}
-{% if page.bidder_supports_deals != false %}
-
-"Deal ID" Ad Server Key
- -{{ "hb_deal_" | append: page.biddercode | slice: 0,20 }}
-
-{% endif %}
-
{{ page.content }}
**WARNING:**
Misuse of this parameter can impact revenue | 2.00 +| `ifa` | optional | String | The ID for advertisers (also referred to as "IDFA") | "XXX-XXX" + +## Example +```javascript +var adUnits = [ + { + code: 'dfp-video-div', + sizes: [[640, 480]], + mediaTypes: { + video: { + playerSize: [[640, 480]], + context: 'instream' + } + }, + bids: [{ + bidder: 'ironsource', + params: { + isOrg: '56f91cd4d3e3660002000033', // Required + floorPrice: 5.00, // Optional + ifa: 'XXX-XXX', // Optional + } + }] + } + ]; +``` + +### Configuration +IronSource recommends setting UserSync by iframe for monetization. + +For Prebid.js v1.15.0 and later: + +pbjs.setConfig({ + userSync: { + filterSettings: { + iframe: { + bidders: '*', // '*' represents all bidders + filter: 'include' + } + } + } +}); + +For Prebid.js v1.14.0 and before: + +pbjs.setConfig({ + userSync: { + iframeEnabled: true, + enabledBidders: ['ironsource'] + } +}); diff --git a/dev-docs/bidders/jcartermarketing.md b/dev-docs/bidders/jcartermarketing.md index d547f04412..a19ec3ce21 100644 --- a/dev-docs/bidders/jcartermarketing.md +++ b/dev-docs/bidders/jcartermarketing.md @@ -2,7 +2,7 @@ layout: bidder title: J Carter Marketing description: Prebid J Carter Marketing Bidder Adaptor - +pbjs: true biddercode: jcm --- diff --git a/dev-docs/bidders/jixie.md b/dev-docs/bidders/jixie.md new file mode 100644 index 0000000000..c3bfec8ea2 --- /dev/null +++ b/dev-docs/bidders/jixie.md @@ -0,0 +1,22 @@ +--- +layout: bidder +title: Jixie +description: Prebid Jixie Bidder Adaptor +pbjs: true +pbs: true +biddercode: jixie +bidder_supports_deals: false +media_types: banner, video +gdpr_supported: false +--- + +### Registration + +To use this bidder you will need an account and a valid unit from us. For further information, please contact contact@jixie.io + +### Bid Params + +{: .table .table-bordered .table-striped } +| Name | Scope | Description | Example | Type | +|-------------------|----------|----------------------------------------------------------------------------------------------------------------------|-----------------------------------------------|------------| +| `unit` | required | The unit from jixie Digital. | `1000012-VyuoGmDF0A` | `string` | diff --git a/dev-docs/bidders/justpremium.md b/dev-docs/bidders/justpremium.md index c5ace3b147..20732ff502 100644 --- a/dev-docs/bidders/justpremium.md +++ b/dev-docs/bidders/justpremium.md @@ -2,7 +2,7 @@ layout: bidder title: Justpremium description: Prebid Justpremium Bidder Adaptor - +pbjs: true biddercode: justpremium gdpr_supported: true usp_supported: true diff --git a/dev-docs/bidders/kargo.md b/dev-docs/bidders/kargo.md index d9e22d6bec..6b142ad2bf 100644 --- a/dev-docs/bidders/kargo.md +++ b/dev-docs/bidders/kargo.md @@ -2,7 +2,7 @@ layout: bidder title: Kargo description: Prebid Kargo Bidder Adaptor - +pbjs: true biddercode: kargo userIds: unifiedId usp_supported: true diff --git a/dev-docs/bidders/kidoz.md b/dev-docs/bidders/kidoz.md new file mode 100644 index 0000000000..884bfa4985 --- /dev/null +++ b/dev-docs/bidders/kidoz.md @@ -0,0 +1,27 @@ +--- +layout: bidder +title: Kidoz +pbs: true +media_types: banner +biddercode: kidoz +gdpr_supported: true +coppa_supported: true +--- + +### Registration + +Kidoz is exclusively for Mobile app COPPA compatible ads, 100% kid relevant and appropriate. + +In order for a company to receive bids from Kidoz, they must first open a publisher account at Kidoz.net +(https://accounts.kidoz.net/publishers/register) and accept the Kidoz Terms and Conditions and Privacy Policy. +Kidoz publishers must confirm that all of their content properties are COPPA and GDPR compliant and perform no monitoring +or tracking of U13 users in their operations. New publishers are provided a Publisher ID and AccessToken, this can also +be used to login to their dashboard at the Kidoz.net portal to monitor their account activity. + +### Bid Params + +{: .table .table-bordered .table-striped } +| Name | Scope | Description | Example | Type | +|------------|----------|------------------------|---------|----------| +| access_token | required | Kidoz access_token | '123abc' | string | +| publisher_id | required | Kidoz publisher_id | '44444' | string | diff --git a/dev-docs/bidders/komoona.md b/dev-docs/bidders/komoona.md index 0d3f6b98d9..00508dfdf7 100644 --- a/dev-docs/bidders/komoona.md +++ b/dev-docs/bidders/komoona.md @@ -2,7 +2,7 @@ layout: bidder title: Komoona description: Prebid Komoona Bidder Adaptor - +pbjs: true biddercode: komoona --- diff --git a/dev-docs/bidders/krushmedia.md b/dev-docs/bidders/krushmedia.md new file mode 100644 index 0000000000..b4b5645313 --- /dev/null +++ b/dev-docs/bidders/krushmedia.md @@ -0,0 +1,19 @@ +--- +layout: bidder +title: Krushmedia +description: Prebid server Krushmedia Adapter +biddercode: krushmedia +usp_supported: true +schain_supported: true +media_types: banner, video, native +gdpr: true +pbjs: false +pbs: true +--- + +### Bid Params + +{: .table .table-bordered .table-striped } +| Name | Scope | Description | Example | Type | +|----------------|----------|----------------------------------------------------------|------------|-----------| +| `key` | required | Unique client id on krushmedia platform | `0` | `string` | diff --git a/dev-docs/bidders/kubient.md b/dev-docs/bidders/kubient.md index 41ae26c5e9..1324c4e39f 100644 --- a/dev-docs/bidders/kubient.md +++ b/dev-docs/bidders/kubient.md @@ -2,7 +2,8 @@ layout: bidder title: Kubient description: Prebid Kubient Bidder Adapter - +pbjs: true +pbs: true schain_supported: true biddercode: kubient aliasCode: fidelity diff --git a/dev-docs/bidders/kumma.md b/dev-docs/bidders/kumma.md index ed1b92de94..841702782a 100644 --- a/dev-docs/bidders/kumma.md +++ b/dev-docs/bidders/kumma.md @@ -2,7 +2,7 @@ layout: bidder title: Kumma description: Prebid Kumma Bidder Adapter - +pbjs: true biddercode: kumma media_types: banner, native, video gdpr_supported: true diff --git a/dev-docs/bidders/lemma.md b/dev-docs/bidders/lemma.md index 72eae2181f..b4b3e71b99 100644 --- a/dev-docs/bidders/lemma.md +++ b/dev-docs/bidders/lemma.md @@ -2,7 +2,7 @@ layout: bidder title: LEMMA description: Prebid Lemma Bidder Adapter - +pbjs: true biddercode: lemma --- diff --git a/dev-docs/bidders/lifestreet.md b/dev-docs/bidders/lifestreet.md index ea664ba29f..d517f8de4b 100644 --- a/dev-docs/bidders/lifestreet.md +++ b/dev-docs/bidders/lifestreet.md @@ -2,7 +2,8 @@ layout: bidder title: Lifestreet description: Prebid Lifestreet Bidder Adaptor - +pbjs: true +pbs: true biddercode: lifestreet media_types: video gdpr_supported: true diff --git a/dev-docs/bidders/livewrapped.md b/dev-docs/bidders/livewrapped.md index 25cdcfa9b7..9832c5fc73 100644 --- a/dev-docs/bidders/livewrapped.md +++ b/dev-docs/bidders/livewrapped.md @@ -3,7 +3,7 @@ layout: bidder title: Livewrapped description: Prebid Livewrapped Bidder Adaptor biddercode: livewrapped - +pbjs: true media_types: banner gdpr_supported: true userIds: id5Id, pubCommonId diff --git a/dev-docs/bidders/lkqd.md b/dev-docs/bidders/lkqd.md index 3850a3c0eb..0dc9b9f3b3 100644 --- a/dev-docs/bidders/lkqd.md +++ b/dev-docs/bidders/lkqd.md @@ -2,7 +2,7 @@ layout: bidder title: LKQD description: Prebid LKQD Bidder Adaptor - +pbjs: true biddercode: lkqd --- diff --git a/dev-docs/bidders/lockerdome.md b/dev-docs/bidders/lockerdome.md index cb5b2a4df7..fbbaf1a056 100644 --- a/dev-docs/bidders/lockerdome.md +++ b/dev-docs/bidders/lockerdome.md @@ -3,7 +3,8 @@ layout: bidder title: LockerDome description: Prebid LockerDome Bidder Adapter biddercode: lockerdome - +pbjs: true +pbs: true gdpr_supported: true usp_supported: true schain_supported: true diff --git a/dev-docs/bidders/logicad.md b/dev-docs/bidders/logicad.md index 0ebc311f7a..aca7dee243 100644 --- a/dev-docs/bidders/logicad.md +++ b/dev-docs/bidders/logicad.md @@ -2,10 +2,11 @@ layout: bidder title: Logicad for Publishers description: Prebid Logicad for Publishers Bidder Adaptor - +pbjs: true +pbs: true biddercode: logicad bidder_supports_deals: false -media_types: banner +media_types: banner, native gdpr_supported: false prebid_member: false --- diff --git a/dev-docs/bidders/loopme.md b/dev-docs/bidders/loopme.md index 48d655c76f..f640ad40e1 100644 --- a/dev-docs/bidders/loopme.md +++ b/dev-docs/bidders/loopme.md @@ -2,7 +2,7 @@ layout: bidder title: LoopMe description: Prebid LoopMe Bidder Adaptor - +pbjs: true biddercode: loopme gdpr_supported: true media_types: banner, video diff --git a/dev-docs/bidders/lunamedia.md b/dev-docs/bidders/lunamedia.md index 6b41ee0b92..f8bbc1cfb4 100644 --- a/dev-docs/bidders/lunamedia.md +++ b/dev-docs/bidders/lunamedia.md @@ -2,7 +2,8 @@ layout: bidder title: Luna Media description: Prebid Luna Media Bidder Adapter - +pbjs: true +pbs: true biddercode: lunamedia --- diff --git a/dev-docs/bidders/luponmedia.md b/dev-docs/bidders/luponmedia.md index a3b8f78b97..3d13033110 100644 --- a/dev-docs/bidders/luponmedia.md +++ b/dev-docs/bidders/luponmedia.md @@ -2,7 +2,7 @@ layout: bidder title: LuponMedia description: LuponMedia Bidder Adapter - +pbjs: true biddercode: luponmedia gdpr_supported: true usp_supported: true diff --git a/dev-docs/bidders/madvertise.md b/dev-docs/bidders/madvertise.md index 79f3a103c6..4d48221e73 100644 --- a/dev-docs/bidders/madvertise.md +++ b/dev-docs/bidders/madvertise.md @@ -2,7 +2,7 @@ layout: bidder title: Madvertise description: Prebid Madvertise Bidder Adaptor - +pbjs: true biddercode: madvertise gdpr_supported: true --- diff --git a/dev-docs/bidders/malltv.md b/dev-docs/bidders/malltv.md new file mode 100644 index 0000000000..94298cb08a --- /dev/null +++ b/dev-docs/bidders/malltv.md @@ -0,0 +1,16 @@ +--- +layout: bidder +title: MallTv +description: Prebid MallTv Bidder Adaptor +pbjs: true +biddercode: malltv +media_types: banner, video +--- + + +### Bid Params + +| Name | Scope | Example | Type | +|---------------|----------|--------------------|-----------| +| `propertyId` | required | `"12345"` | `string` | +| `placementId` | required | `"54321"` | `string` | diff --git a/dev-docs/bidders/mantis.md b/dev-docs/bidders/mantis.md index d100ed1ad1..ba004f27b6 100644 --- a/dev-docs/bidders/mantis.md +++ b/dev-docs/bidders/mantis.md @@ -2,11 +2,11 @@ layout: bidder title: MANTIS Ad Network description: Prebid Mantis Bidder Adaptor - +pbjs: true biddercode: mantis +media_types: native, video usp_supported: true gdpr_supported: true - --- ### Bid Params diff --git a/dev-docs/bidders/marsmedia.md b/dev-docs/bidders/marsmedia.md index 9ae86bee5e..a3cef06641 100644 --- a/dev-docs/bidders/marsmedia.md +++ b/dev-docs/bidders/marsmedia.md @@ -2,7 +2,8 @@ layout: bidder title: Marsmedia description: Prebid Mars Media Group Bidder Adaptor - +pbjs: true +pbs: true biddercode: marsmedia media_types: video, banner gdpr_supported: true diff --git a/dev-docs/bidders/matomy.md b/dev-docs/bidders/matomy.md index 0f2ddf14e4..33cd2b8da7 100644 --- a/dev-docs/bidders/matomy.md +++ b/dev-docs/bidders/matomy.md @@ -2,7 +2,7 @@ layout: bidder title: Matomy description: Prebid Matomy Bidder Adaptor - +pbjs: true biddercode: matomy aliasCode : appnexus --- diff --git a/dev-docs/bidders/meazy.md b/dev-docs/bidders/meazy.md index c833668873..ed3cc5f0bb 100644 --- a/dev-docs/bidders/meazy.md +++ b/dev-docs/bidders/meazy.md @@ -2,7 +2,7 @@ layout: bidder title: Meazy description: Prebid Meazy Bidder Adaptor - +pbjs: true biddercode: meazy --- diff --git a/dev-docs/bidders/mediaforce.md b/dev-docs/bidders/mediaforce.md index c7c5cd4b38..7632e66665 100644 --- a/dev-docs/bidders/mediaforce.md +++ b/dev-docs/bidders/mediaforce.md @@ -2,9 +2,9 @@ layout: bidder title: MediaForce description: MediaForce Prebid Bidder Adapter -media_types: banner +media_types: banner, native biddercode: mediaforce - +pbjs: true gdpr_supported: false --- diff --git a/dev-docs/bidders/mediafuseLift.md b/dev-docs/bidders/mediafuseLift.md index e84af2cf23..fd95ca0f39 100644 --- a/dev-docs/bidders/mediafuseLift.md +++ b/dev-docs/bidders/mediafuseLift.md @@ -4,7 +4,7 @@ title: MediaFuse Lift description: Prebid MediaFuse Lift Bidder Adaptor top_nav_section: dev_docs nav_section: reference - +pbjs: true biddercode: mediafuseLift aliasCode : orbitsoft --- diff --git a/dev-docs/bidders/mediago.md b/dev-docs/bidders/mediago.md new file mode 100644 index 0000000000..f1fd1f7408 --- /dev/null +++ b/dev-docs/bidders/mediago.md @@ -0,0 +1,18 @@ +--- +layout: bidder +title: MediaGo +description: MediaGo Prebid Bidder Adapter +biddercode: mediago +media_types: banner +pbjs: true +--- +### Note: + +The MediaGo Bidding adapter requires setup before beginning. Please contact us at
(Value configured only in the 1st adunit will be passed on.
Values if present in subsequent adunits, will be ignored.) | `'key1=123|key2=345'` | `string` | | `bcat` | optional | Blocked IAB Categories
(Values from all slots will be combined and only unique values will be passed. An array of strings only. Each category should be a string of a length of more than 3 characters.) | `[ 'IAB1-5', 'IAB1-6', 'IAB1-7' ]` | `array of strings` | | `deals` | optional | PMP deals
(Values from each slot will be passed per slot. An array of strings only. Each deal-id should be a string of a length of more than 3 characters.) | `[ 'deal-id-5', 'deal-id-6', 'deal-id-7' ]` | `array of strings` | +| `outstreamAU` | optional | Oustream AdUnit described in Blue BillyWig UI. This field is mandatory if mimeType is described as video and context is outstream (i.e., for outstream videos) | `'renderer_test_pubmatic'` | `string` | ### Configuration @@ -90,16 +94,16 @@ Prebid.js v2.9.0 to v2.12.0: Both formats are supported. Without Size is the recommended option. If you are using Prebid Server, Prebid Server v0.69.0 or higher (Go version) or v1.18.0 or higher (Java version) is required to use Without Size. If you are using a managed service provider for Prebid Server, consult the provider to find out which version of Prebid Server they are using. Both formats will send the ad request with all sizes specified in the Prebid ad unit configuration. -Prebid.js v1.1.18 to v2.8.0: +Prebid.js v1.18.0 to v2.8.0: Both formats are supported. Without Size is the recommended option. If you are using Prebid Server, Prebid Server v0.69.0 or higher (Go version) or v1.18.0 or higher (Java version) is required to use Without Size. If you are using a managed service provider for Prebid Server, consult the provider to find out which version of Prebid Server they are using. Without Size will send the ad request with all sizes specified in the Prebid ad unit configuration. With Size will only request the specified size. Mutli-sized ad units are not supported when using Prebid Server. -Prebid.js v1.1.17 and earlier: +Prebid.js v1.17.0 and earlier: Only With Size is supported. To support multi-size ad units, list the PubMatic bidder entry multiple times, once for each size. Mutli-sized ad units are not supported when using Prebid Server. ### video parameters -The PubMatic adapter supports video as of Prebid 1.16.0 +The PubMatic adapter supports video as of Prebid v1.16.0 {: .table .table-bordered .table-striped } | Name | Scope | Description | Example | @@ -198,4 +202,36 @@ pbjs.setConfig({ } }); ``` + +### Prebid Server Test Request + +The following test parameters can be used to verify that Prebid Server is working properly with the +PubMatic adapter. This example includes an `imp` object with an PubMatic test publisher ID, ad slot, +and sizes that would match with the test creative. + +``` +"imp":[ + { + "id":“"some-impression-id”, + "banner":{ + "format":[ + { + "w":300, + "h":250 + }, + { + "w":300, + "h":600 + } + ] + }, + "ext":{ + "pubmatic":{ + "publisherId":“156276”, + "adSlot":"pubmatic_test" + } + } + } + ] +``` diff --git a/dev-docs/bidders/pubnative.md b/dev-docs/bidders/pubnative.md new file mode 100644 index 0000000000..6a2eb901ea --- /dev/null +++ b/dev-docs/bidders/pubnative.md @@ -0,0 +1,75 @@ +--- +layout: bidder +title: PubNative +pbs: true +media_types: banner, video, native +biddercode: pubnative +gdpr_supported: true +tcf2_supported: true +prebid_member: true +schain_supported: true +coppa_supported: true +usp_supported: true +--- + +### Registration + +Before adding PubNative as a new bidder, there are 3 prerequisites: +- As a Publisher, you need to have Prebid Mobile SDK integrated. +- You need a configured Prebid Server (either self-hosted or hosted by 3rd party). +- You need to be integrated with Ad Server SDK (e.g. Mopub) or internal product which communicates with Prebid Mobile SDK. + +Please see [documentation](https://developers.pubnative.net/docs/prebid-adding-pubnative-as-a-bidder) for more info. + +### Bid Params + +{: .table .table-bordered .table-striped } +| Name | Scope | Description | Example | Type | +|------------|----------|------------------------|---------|----------| +| zone_id | required | The ad zone identifier | 1 | integer | +| app_auth_token | required | The app's authentication token | 'aaaabbbbcccc' | string | + +### Test Parameters + +Please consult with our Account Manager for testing. +We need to confirm that your ad request is correctly received by our system. + +The following test parameters can be used to verify that Prebid Server is working properly with the +Pubnative adapter. + +The following json can be used to do a request to prebid server for verifying its integration with Pubnative adapter. + +```json +{ + "id": "some-impression-id", + "site": { + "page": "https://good.site/url" + }, + "imp": [ + { + "id": "test-imp-id", + "banner": { + "format": [ + { + "w": 300, + "h": 250 + } + ] + }, + "ext": { + "pubnative": { + "zone_id": 1, + "app_auth_token": "b620e282f3c74787beedda34336a4821" + } + } + } + ], + "device": { + "os": "android", + "h": 700, + "w": 375 + }, + "tmax": 500, + "test": 1 +} +``` diff --git a/dev-docs/bidders/pubnx.md b/dev-docs/bidders/pubnx.md index 234608842a..9fb104d64a 100644 --- a/dev-docs/bidders/pubnx.md +++ b/dev-docs/bidders/pubnx.md @@ -2,7 +2,7 @@ layout: bidder title: PubNX description: Prebid PubNX Bidder Adaptor - +pbjs: true biddercode: pubnx --- diff --git a/dev-docs/bidders/pubx.md b/dev-docs/bidders/pubx.md new file mode 100644 index 0000000000..e734c91ed6 --- /dev/null +++ b/dev-docs/bidders/pubx.md @@ -0,0 +1,20 @@ +--- +layout: bidder +title: Pub-X +description: Prebid Pub-X Bidder Adapter +biddercode: pubx +media_types: banner +gdpr_supported: false +coppa_supported: false +usp_supported: false +schain_supported: true +pbjs: true +--- + + +### Bid Params + +{: .table .table-bordered .table-striped } +| Name | Scope | Description | Example | Type | +|-------|----------|---------------------------|----------|----------| +| `sid` | required | The AdUnit ID from Pub-X | `'eDMR'` | `string` | diff --git a/dev-docs/bidders/pulsepoint.md b/dev-docs/bidders/pulsepoint.md index ad353dc59d..bb714993ae 100644 --- a/dev-docs/bidders/pulsepoint.md +++ b/dev-docs/bidders/pulsepoint.md @@ -2,13 +2,15 @@ layout: bidder title: PulsePoint description: Prebid PulsePoint Bidder Adaptor - biddercode: pulsepoint gdpr_supported: true usp_supported: true schain_supported: true media_types: banner, video, native userIds: britepoolId, criteo, id5Id, identityLink, liveIntentId, parrableId, pubCommonId, unifiedId +pbjs: true +pbs: true +gvl_id: 81 --- diff --git a/dev-docs/bidders/pxyz.md b/dev-docs/bidders/pxyz.md index 4503115a48..5155e05408 100644 --- a/dev-docs/bidders/pxyz.md +++ b/dev-docs/bidders/pxyz.md @@ -4,7 +4,7 @@ title: Playground XYZ description: Prebid Playground XYZ Bidder Adapter gdpr_supported: true usp_supported: true - +pbjs: true biddercode: pxyz prevBiddercode: playgroundxyz aliasBiddercode: playgroundxyz diff --git a/dev-docs/bidders/quantcast.md b/dev-docs/bidders/quantcast.md index bacab98361..9db79fbb22 100644 --- a/dev-docs/bidders/quantcast.md +++ b/dev-docs/bidders/quantcast.md @@ -2,7 +2,7 @@ layout: bidder title: Quantcast description: Prebid Quantcast Bidder Adaptor - +pbjs: true biddercode: quantcast media_types: video gdpr_supported: true diff --git a/dev-docs/bidders/quantum.md b/dev-docs/bidders/quantum.md index 86d2892b20..dfab352962 100644 --- a/dev-docs/bidders/quantum.md +++ b/dev-docs/bidders/quantum.md @@ -2,7 +2,7 @@ layout: bidder title: Quantum description: Prebid Quantum Bidder Adaptor - +pbjs: true biddercode: quantum media_types: native --- diff --git a/dev-docs/bidders/quantumdex.md b/dev-docs/bidders/quantumdex.md index b584b73c7d..4e8ae33dac 100644 --- a/dev-docs/bidders/quantumdex.md +++ b/dev-docs/bidders/quantumdex.md @@ -2,10 +2,11 @@ layout: bidder title: Quantumdex description: Prebid Quantum Digital Exchange Bidder Adapter - +pbjs: true biddercode: quantumdex media_types: banner, video gdpr_supported: true +tcf2_supported: true schain_supported: true usp_supported: true --- diff --git a/dev-docs/bidders/rads.md b/dev-docs/bidders/rads.md index d02b0fd2e2..53a3ce3915 100644 --- a/dev-docs/bidders/rads.md +++ b/dev-docs/bidders/rads.md @@ -2,7 +2,7 @@ layout: bidder title: Rads description: Prebid Rads Bidder Adaptor - +pbjs: true biddercode: rads media_types: banner, video gdpr_supported: false diff --git a/dev-docs/bidders/rakuten.md b/dev-docs/bidders/rakuten.md index a6d5398b59..5bb4f254c3 100644 --- a/dev-docs/bidders/rakuten.md +++ b/dev-docs/bidders/rakuten.md @@ -2,7 +2,7 @@ layout: bidder title: Rakuten description: Prebid Rakuten Bidder Adaptor - +pbjs: true biddercode: rakuten prebid_member: true --- diff --git a/dev-docs/bidders/readpeak.md b/dev-docs/bidders/readpeak.md index 7a5be1a72e..4a5936346e 100644 --- a/dev-docs/bidders/readpeak.md +++ b/dev-docs/bidders/readpeak.md @@ -2,7 +2,7 @@ layout: bidder title: Readpeak description: Readpeak Bidder Adaptor - +pbjs: true biddercode: readpeak media_types: native --- diff --git a/dev-docs/bidders/reklamstore.md b/dev-docs/bidders/reklamstore.md index bcdebc64f9..f4e221d69c 100644 --- a/dev-docs/bidders/reklamstore.md +++ b/dev-docs/bidders/reklamstore.md @@ -3,7 +3,7 @@ layout: bidder title: ReklamStore description: Prebid ReklamStore Bidder Adaptor biddercode: reklamstore - +pbjs: true gdpr_supported: true media_types: banner --- diff --git a/dev-docs/bidders/relaido.md b/dev-docs/bidders/relaido.md index 2655c80639..451554d9d4 100644 --- a/dev-docs/bidders/relaido.md +++ b/dev-docs/bidders/relaido.md @@ -3,7 +3,7 @@ layout: bidder title: Relaido description: Prebid Relaido Bidder Adapter biddercode: relaido - +pbjs: true media_types: banner, video --- diff --git a/dev-docs/bidders/reload.md b/dev-docs/bidders/reload.md index 7ffe65aab2..54212e5af2 100644 --- a/dev-docs/bidders/reload.md +++ b/dev-docs/bidders/reload.md @@ -2,7 +2,7 @@ layout: bidder title: Reload description: Reload Prebid Adaptor - +pbjs: true biddercode: reload --- diff --git a/dev-docs/bidders/resultsmedia.md b/dev-docs/bidders/resultsmedia.md index c0491a6884..bca7d3244b 100644 --- a/dev-docs/bidders/resultsmedia.md +++ b/dev-docs/bidders/resultsmedia.md @@ -2,7 +2,7 @@ layout: bidder title: ResultsMedia description: Prebid ResultsMedia Bidder Adaptor - +pbjs: true biddercode: resultsmedia media_types: video, banner gdpr_supported: true diff --git a/dev-docs/bidders/revcontent.md b/dev-docs/bidders/revcontent.md index d57d7605b6..0f3ccc2e90 100644 --- a/dev-docs/bidders/revcontent.md +++ b/dev-docs/bidders/revcontent.md @@ -7,6 +7,7 @@ media_types: native gdpr_supported: true coppa_supported: true usp_supported: true +pbjs: true --- ### Note diff --git a/dev-docs/bidders/rexrtb.md b/dev-docs/bidders/rexrtb.md index 19bdc02568..f712f2b6a9 100644 --- a/dev-docs/bidders/rexrtb.md +++ b/dev-docs/bidders/rexrtb.md @@ -2,7 +2,7 @@ layout: bidder title: REXRTB description: Prebid REXRTB Bidder Adaptor - +pbjs: true biddercode: rexrtb --- diff --git a/dev-docs/bidders/rhythmone.md b/dev-docs/bidders/rhythmone.md index 114e06373f..16938c4ce1 100644 --- a/dev-docs/bidders/rhythmone.md +++ b/dev-docs/bidders/rhythmone.md @@ -2,7 +2,8 @@ layout: bidder title: RhythmOne description: Prebid RhythmOne Bidder Adaptor - +pbjs: true +pbs: true biddercode: rhythmone media_types: video gdpr_supported: true diff --git a/dev-docs/bidders/richaudience.md b/dev-docs/bidders/richaudience.md index d250def49d..0e5cbd084f 100644 --- a/dev-docs/bidders/richaudience.md +++ b/dev-docs/bidders/richaudience.md @@ -2,12 +2,12 @@ layout: bidder title: Rich Audience description: Prebid Rich Audience Bidder Adapter - biddercode: richaudience userIds: criteo, id5Id, identityLink, liveIntentId, pubCommonId, unifiedId media_types: banner, video gdpr_supported: true tcf2_supported: true +pbjs: true --- ### Bid Params diff --git a/dev-docs/bidders/rockyou.md b/dev-docs/bidders/rockyou.md index add3b4ee72..f060d9891d 100644 --- a/dev-docs/bidders/rockyou.md +++ b/dev-docs/bidders/rockyou.md @@ -3,7 +3,7 @@ layout: bidder title: RockYou description: PreBid RockYou Bidder Adapter biddercode: rockyou - +pbjs: true media_types: video --- diff --git a/dev-docs/bidders/rtbdemand.md b/dev-docs/bidders/rtbdemand.md index 799e294ba2..bf429d80c7 100644 --- a/dev-docs/bidders/rtbdemand.md +++ b/dev-docs/bidders/rtbdemand.md @@ -4,7 +4,7 @@ title: Rtbdemand bidder description: Prebid Rtbdemand Media Bidder Adapter top_nav_section: dev_docs nav_section: reference - +pbjs: true biddercode: rtbdemand --- diff --git a/dev-docs/bidders/rtbdemandadk.md b/dev-docs/bidders/rtbdemandadk.md index c888b2f989..76fda18e01 100644 --- a/dev-docs/bidders/rtbdemandadk.md +++ b/dev-docs/bidders/rtbdemandadk.md @@ -2,7 +2,7 @@ layout: bidder title: Rtbdemandadk description: Prebid RtbdemandAdk Bidder Adaptor - +pbjs: true biddercode: rtbdemandadk --- diff --git a/dev-docs/bidders/rtbhouse.md b/dev-docs/bidders/rtbhouse.md index d47b901997..dcdfaae2a8 100644 --- a/dev-docs/bidders/rtbhouse.md +++ b/dev-docs/bidders/rtbhouse.md @@ -3,10 +3,14 @@ layout: bidder title: RTBHouse description: Prebid RTB House Bidder Adapter gdpr_supported: true - +tcf2_supported: true +pbjs: true +pbs: true biddercode: rtbhouse +safeframes_ok: true media_types: banner, native schain_supported: true +userIds: id5Id, identityLink --- diff --git a/dev-docs/bidders/rtbsape.md b/dev-docs/bidders/rtbsape.md new file mode 100644 index 0000000000..de4dcbe73a --- /dev/null +++ b/dev-docs/bidders/rtbsape.md @@ -0,0 +1,53 @@ +--- +layout: bidder +title: RtbSape +description: Prebid RtbSape Bidder Adaptor +pbjs: true +biddercode: rtbsape +media_types: banner, video +--- + +### Note: + +The RtbSape Header Bidding adaptor requires setup and approval before beginning. Please reach out to
`1`: Auto-play sound on
`2`: Auto-play sound off
`3`: Click-to-play sound on
`4`: Mouse-over sound on| `1` | `integer` | +| `maxDuration` | optional | Maximum video ad duration in seconds. | `30` | `integer` | +| `skippable` | optional | Skippability of the inventory. Possible values: `true` - only skippable inventory is allowed, `false` - skippable inventory is not allowed, null/missing - all inventory is allowed (default value). | `true` | `boolean` | + + ### Configuration To maximize revenue efficiency, please enable iframe-based user syncing. This functionality will improve user match rates and will help increasing the bid rate. diff --git a/dev-docs/bidders/unicorn.md b/dev-docs/bidders/unicorn.md index 3e50337c3f..0d3700627f 100644 --- a/dev-docs/bidders/unicorn.md +++ b/dev-docs/bidders/unicorn.md @@ -2,7 +2,7 @@ layout: bidder title: UNICORN description: Prebid UNICORN Bidder Adaptor - +pbjs: true media_types: banner biddercode: unicorn --- diff --git a/dev-docs/bidders/unruly.md b/dev-docs/bidders/unruly.md index 3cf4325385..4d6b0d6ded 100644 --- a/dev-docs/bidders/unruly.md +++ b/dev-docs/bidders/unruly.md @@ -2,10 +2,11 @@ layout: bidder title: Unruly description: Prebid Unruly Bidder Adaptor - biddercode: unruly media_types: native, video gdpr_supported: true +pbjs: true +pbs: true --- ### Bid Params diff --git a/dev-docs/bidders/uol.md b/dev-docs/bidders/uol.md index cd4d7c614a..befa00f86f 100644 --- a/dev-docs/bidders/uol.md +++ b/dev-docs/bidders/uol.md @@ -2,7 +2,7 @@ layout: bidder title: UOL description: Prebid UOL Bidder Adaptor - +pbjs: true biddercode: uol gdpr_supported: false media_types: banner diff --git a/dev-docs/bidders/valueimpression.md b/dev-docs/bidders/valueimpression.md index 6cd3508ccb..b8b8d25e11 100644 --- a/dev-docs/bidders/valueimpression.md +++ b/dev-docs/bidders/valueimpression.md @@ -2,13 +2,15 @@ layout: bidder title: Valueimpression description: Prebid Valueimpression Bidder Adapter - +pbjs: true biddercode: valueimpression aliasCode: quantumdex media_types: banner, video gdpr_supported: true +tcf2_supported: true schain_supported: true usp_supported: true +pbs: true --- diff --git a/dev-docs/bidders/vdoai.md b/dev-docs/bidders/vdoai.md index 44b2049900..a197686572 100644 --- a/dev-docs/bidders/vdoai.md +++ b/dev-docs/bidders/vdoai.md @@ -2,7 +2,7 @@ layout: bidder title: VDO.AI description: Prebid vdo.ai Bidder Adaptor - +pbjs: true biddercode: vdo.ai --- diff --git a/dev-docs/bidders/verizonmedia.md b/dev-docs/bidders/verizonmedia.md new file mode 100644 index 0000000000..9367ee3883 --- /dev/null +++ b/dev-docs/bidders/verizonmedia.md @@ -0,0 +1,16 @@ +--- +layout: bidder +title: VerizonMedia +pbs: true +media_types: banner +biddercode: verizonmedia +prebid_member: true +--- + +### Bid Params + +{: .table .table-bordered .table-striped } +| Name | Scope | Description | Example | Type | +|------------|----------|------------------------|---------|----------| +| dcn | required | Site ID provided by One Mobile | 'site1' | string | +| pos | required | Placement ID | 'placement1' | string | diff --git a/dev-docs/bidders/vertamedia.md b/dev-docs/bidders/vertamedia.md index 0178a1b98c..6c379edef4 100644 --- a/dev-docs/bidders/vertamedia.md +++ b/dev-docs/bidders/vertamedia.md @@ -2,7 +2,7 @@ layout: bidder title: Vertamedia description: Prebid Vertamedia Bidder Adaptor - +pbjs: true biddercode: vertamedia media_types: video --- diff --git a/dev-docs/bidders/vertoz.md b/dev-docs/bidders/vertoz.md index 2e60c877f0..09023bc7cc 100644 --- a/dev-docs/bidders/vertoz.md +++ b/dev-docs/bidders/vertoz.md @@ -2,7 +2,7 @@ layout: bidder title: Vertoz description: Prebid Vertoz Bidder Adaptor - +pbjs: true biddercode: vertoz --- diff --git a/dev-docs/bidders/vi.md b/dev-docs/bidders/vi.md index c406a8f92d..1c344a7ea9 100644 --- a/dev-docs/bidders/vi.md +++ b/dev-docs/bidders/vi.md @@ -2,7 +2,7 @@ layout: bidder title: vi description: vi bid adapter - +pbjs: true biddercode: vi --- diff --git a/dev-docs/bidders/vidazoo.md b/dev-docs/bidders/vidazoo.md index 355ac9b4d2..36ccb01c8d 100644 --- a/dev-docs/bidders/vidazoo.md +++ b/dev-docs/bidders/vidazoo.md @@ -3,10 +3,10 @@ layout: bidder title: Vidazoo description: Prebid Vidazoo Bidder Adaptor biddercode: vidazoo - userIds: britepoolId, criteo, digitrust, id5Id, identityLink, liveIntentId, netId, parrableId, pubCommonId, unifiedId gdpr_supported: true usp_supported: true +pbjs: true --- ### Bid Params diff --git a/dev-docs/bidders/videofy.md b/dev-docs/bidders/videofy.md index 5792e3d6db..79fc9bc0d6 100644 --- a/dev-docs/bidders/videofy.md +++ b/dev-docs/bidders/videofy.md @@ -2,7 +2,7 @@ layout: bidder title: Videofy description: Prebid Videofy Bidder Adaptor - +pbjs: true biddercode: videofy media_types: video gdpr_supported: true diff --git a/dev-docs/bidders/videonow.md b/dev-docs/bidders/videonow.md index 676594d54b..4d22e4c26e 100644 --- a/dev-docs/bidders/videonow.md +++ b/dev-docs/bidders/videonow.md @@ -2,7 +2,7 @@ layout: bidder title: videonow description: Prebid Videonow Bidder Adaptor - +pbjs: true media_types: banner --- diff --git a/dev-docs/bidders/videoreach.md b/dev-docs/bidders/videoreach.md index 0fe9dff7ed..a38870bea6 100644 --- a/dev-docs/bidders/videoreach.md +++ b/dev-docs/bidders/videoreach.md @@ -2,7 +2,7 @@ layout: bidder title: Video Reach description: Video Reach Bidder Adapter for Prebid.js - +pbjs: true biddercode: videoreach media_types: banner, video gdpr_supported: true diff --git a/dev-docs/bidders/viewdeos.md b/dev-docs/bidders/viewdeos.md index 3de083e5a0..9dbbe667db 100644 --- a/dev-docs/bidders/viewdeos.md +++ b/dev-docs/bidders/viewdeos.md @@ -2,7 +2,7 @@ layout: bidder title: Viewdeos description: Prebid Viewdeos Bidder Adaptor - +pbjs: true biddercode: viewdeosDX media_types: banner, video --- diff --git a/dev-docs/bidders/viewdeosDX.md b/dev-docs/bidders/viewdeosDX.md index 90c161a725..035d58f4aa 100644 --- a/dev-docs/bidders/viewdeosDX.md +++ b/dev-docs/bidders/viewdeosDX.md @@ -2,7 +2,7 @@ layout: bidder title: ViewDeos DX description: Prebid ViewDeos Bidder Adaptor - +pbjs: true biddercode: viewdeosDX media_types: banner,video gdpr_supported: true diff --git a/dev-docs/bidders/visx.md b/dev-docs/bidders/visx.md index 346cbe5284..b137ebacc2 100644 --- a/dev-docs/bidders/visx.md +++ b/dev-docs/bidders/visx.md @@ -1,11 +1,13 @@ --- layout: bidder -title: VIS.X -description: Prebid VIS.X Bidder Adaptor - +title: YOC VIS.X +description: Prebid YOC VIS.X Bidder Adapter +pbjs: true +pbs: true biddercode: visx gdpr_supported: true schain_supported: true +tcf2_supported: true userIds: id5Id, unifiedId --- @@ -16,7 +18,7 @@ To be able to use the full bandwidth of VIS.X high impact ad products, we strong If you require SafeFrames to be activated, please reach out to your YOC account manager to obtain further details. -The YOC VIS.X adaptor requires setup and approval from your YOC account manager team, even for existing YOC publishers. +The YOC VIS.X adapter requires setup and approval from your YOC account manager team, even for existing YOC publishers. Please reach out to your account manager to enable Prebid.js for your account. ### Bid params @@ -28,7 +30,7 @@ Please reach out to your account manager to enable Prebid.js for your account. ### Configuration -The VIS.X adaptor has the ability to work in different currencies. Currently this adaptor supports `EUR`, `USD`, +The YOC VIS.X adapter has the ability to work in different currencies. Currently this adapter supports `EUR`, `USD`, `GBP`, `PLN`. Defaults to `EUR`. If your Ad Server uses `EUR`, you don't need any additional currency settings. If you would like to trade with VIS.X in a currency different from `EUR`, you should implement some additional settings. @@ -38,7 +40,7 @@ If you would like to trade with VIS.X in a currency different from `EUR`, you sh 2. Setup the currency in Currency config. -a) If your Ad Server uses the currency from the list of VIS.X supported currencies (e.g. `GPB`), use the following settings: +a) If your Ad Server uses the currency from the list of VIS.X supported currencies (e.g. `GBP`), use the following settings: ```javascript pbjs.setConfig({ @@ -65,6 +67,6 @@ pbjs.setConfig({ ``` Best practices: -- Please make sure that currency module is set up and configured in order to trade with VIS.X in a currency that is not supported by VIS.X bidder. +- Please make sure that currency module is set up and configured in order to trade with YOC in a currency that is not supported by YOC VIS.X bidder. - You should set `EUR` in `bidderCurrencyDefault` parameter if you use unsupported currency for VIS.X. -- Feel free to reach out to your contact at VIS.X if you need additional support setting up Prebid.js and currency config. +- Feel free to reach out to your contact at YOC if you need additional support setting up Prebid.js and currency config. diff --git a/dev-docs/bidders/vmg.md b/dev-docs/bidders/vmg.md index 2e6827d9df..c83169cafd 100644 --- a/dev-docs/bidders/vmg.md +++ b/dev-docs/bidders/vmg.md @@ -2,7 +2,7 @@ layout: bidder title: VMG description: Connects Google Ad Manager to the VMG Predict engine. - +pbjs: true biddercode: vmg --- diff --git a/dev-docs/bidders/vrtcal.md b/dev-docs/bidders/vrtcal.md index c1bf833aa7..6789566346 100644 --- a/dev-docs/bidders/vrtcal.md +++ b/dev-docs/bidders/vrtcal.md @@ -2,7 +2,8 @@ layout: bidder title: VRTCAL Markets, Inc. description: VRTCAL Markets, Inc. Bid Adapter - +pbjs: true +pbs: true media_ytpes: banner gdpr_supported: false biddercode: vrtcal diff --git a/dev-docs/bidders/vuble.md b/dev-docs/bidders/vuble.md index d703e18b02..0242c496a3 100644 --- a/dev-docs/bidders/vuble.md +++ b/dev-docs/bidders/vuble.md @@ -2,7 +2,7 @@ layout: bidder title: Vuble description: Prebid Vuble Bidder Adaptor - +pbjs: true biddercode: vuble media_types: video gdpr_supported: true diff --git a/dev-docs/bidders/waardex.md b/dev-docs/bidders/waardex.md index 31c0e1d3de..ac589537d8 100644 --- a/dev-docs/bidders/waardex.md +++ b/dev-docs/bidders/waardex.md @@ -5,16 +5,16 @@ description: Prebid Waardex Bidder Adaptor hide: true biddercode: waardex media_types: banner +pbjs: true --- ### Bid Params {: .table .table-bordered .table-striped } -| Name | Scope | Description | Example | Type | -|---------------|----------|------------------------------------------------------------------|------------------|----------| -| `pubId` | required | publisher identifier | 1 | `number` | +| Name | Scope | Description | Example | Type | +|---------------|----------|------------------------------------------------------------------|--------------------|----------| +| `zoneId` | required | publisher identifier | 1 | `number` | | `bidId` | required | bid request id | `'22c4871113f461'` | `string` | -| `placementId` | required | placement id | `'dsew53y678jgj1'` | `string` | -| `bidfloor` | required | bid request price | 0.5 | `float` | -| `position` | optional | ad position on the page | 1 | `number` | -| `instl` | optional | 1 when ad is interstitial or full screen, 0 when not interstitial| 0 | `number` | +| `bidfloor` | required | bid request price | 0.5 | `float` | +| `position` | optional | ad position on the page | 1 | `number` | +| `instl` | optional | 1 when ad is interstitial or full screen, 0 when not interstitial| 0 | `number` | diff --git a/dev-docs/bidders/waardex b/dev-docs/bidders/waardexak.md similarity index 100% rename from dev-docs/bidders/waardex rename to dev-docs/bidders/waardexak.md diff --git a/dev-docs/bidders/weborama.md b/dev-docs/bidders/weborama.md index 84d5bafa36..0fa88f3951 100644 --- a/dev-docs/bidders/weborama.md +++ b/dev-docs/bidders/weborama.md @@ -2,7 +2,7 @@ layout: bidder title: Weborama description: Prebid Weborama Bidder Adaptor - +pbjs: true biddercode: weborama --- diff --git a/dev-docs/bidders/welect.md b/dev-docs/bidders/welect.md index e2843e2e18..54d4a82c51 100644 --- a/dev-docs/bidders/welect.md +++ b/dev-docs/bidders/welect.md @@ -2,10 +2,11 @@ layout: bidder title: Welect description: Prebid Welect Bidder Adapter - biddercode: welect media_types: no-display, video -gdpr_supported: true +tcf2_supported: true +gvlid: 282 +pbjs: true --- ### Note: diff --git a/dev-docs/bidders/widespace.md b/dev-docs/bidders/widespace.md index d5187d80f0..b2780e2c27 100644 --- a/dev-docs/bidders/widespace.md +++ b/dev-docs/bidders/widespace.md @@ -2,7 +2,7 @@ layout: bidder title: Widespace description: Prebid Widespace Bidder Adaptor - +pbjs: true biddercode: widespace gdpr_supported: true --- diff --git a/dev-docs/bidders/windtalker.md b/dev-docs/bidders/windtalker.md index 5c3a9ca4d6..538d9246d9 100644 --- a/dev-docs/bidders/windtalker.md +++ b/dev-docs/bidders/windtalker.md @@ -2,7 +2,7 @@ layout: bidder title: Windtalker description: Prebid Windtalker Bidder Adapter - +pbjs: true biddercode: windtalker media_types: native, video gdpr_supported: true diff --git a/dev-docs/bidders/wipes.md b/dev-docs/bidders/wipes.md index 26b212267e..25e1ed80cc 100644 --- a/dev-docs/bidders/wipes.md +++ b/dev-docs/bidders/wipes.md @@ -2,7 +2,7 @@ layout: bidder title: WIPES description: Prebid WIPES Bidder Adaptor - +pbjs: true biddercode: wipes media_types: video --- diff --git a/dev-docs/bidders/xaxis.md b/dev-docs/bidders/xaxis.md index 5900dfebe5..8e4f39f345 100644 --- a/dev-docs/bidders/xaxis.md +++ b/dev-docs/bidders/xaxis.md @@ -3,7 +3,7 @@ layout: bidder title: Xaxis description: Prebid Xaxis Bidder Adaptor biddercode: xhb - +pbjs: true media_types: video, native gdpr_supported: true --- diff --git a/dev-docs/bidders/xendiz.md b/dev-docs/bidders/xendiz.md index e890cf49df..f411b25d22 100644 --- a/dev-docs/bidders/xendiz.md +++ b/dev-docs/bidders/xendiz.md @@ -2,7 +2,7 @@ layout: bidder title: Xendiz description: Prebid Xendiz Bidder Adaptor - +pbjs: true biddercode: xendiz --- diff --git a/dev-docs/bidders/yeahmobi.md b/dev-docs/bidders/yeahmobi.md new file mode 100644 index 0000000000..b04030a855 --- /dev/null +++ b/dev-docs/bidders/yeahmobi.md @@ -0,0 +1,16 @@ +--- +layout: bidder +title: YeahMobi +pbs: true +media_types: native +biddercode: yeahmobi +prebid_member: true +--- + +### Bid Params + +{: .table .table-bordered .table-striped } +| Name | Scope | Description | Example | Type | +|------------|----------|------------------------|---------|----------| +| pubId | required | Publisher ID | 'pub1' | string | +| zoneId | required | Zone Id | 'zone1' | string | diff --git a/dev-docs/bidders/yieldbot.md b/dev-docs/bidders/yieldbot.md index 97c25db316..32a7c17d66 100644 --- a/dev-docs/bidders/yieldbot.md +++ b/dev-docs/bidders/yieldbot.md @@ -2,7 +2,7 @@ layout: bidder title: Yieldbot description: Prebid Yieldbot Bidder Adaptor - +pbjs: true biddercode: yieldbot --- diff --git a/dev-docs/bidders/yieldlab.md b/dev-docs/bidders/yieldlab.md index 8f2cf9293f..6414721b06 100644 --- a/dev-docs/bidders/yieldlab.md +++ b/dev-docs/bidders/yieldlab.md @@ -2,12 +2,15 @@ layout: bidder title: Yieldlab description: Prebid Yieldlab Bidder Adapter - biddercode: yieldlab media_types: video gdpr_supported: true tcf2_supported: true +schain_supported: true userIds: britepoolId, criteo, id5Id, identityLink, liveIntentId, netId, parrableId, pubCommonId, unifiedId +prebid_member: true +pbjs: true +pbs: true --- diff --git a/dev-docs/bidders/yieldlift.md b/dev-docs/bidders/yieldlift.md index 58787be43b..97aa773866 100644 --- a/dev-docs/bidders/yieldlift.md +++ b/dev-docs/bidders/yieldlift.md @@ -2,7 +2,7 @@ layout: bidder title: YieldLift description: Prebid YieldLift Bidder Adaptor - +pbjs: true biddercode: yieldlift media_types: banner gdpr_supported: true diff --git a/dev-docs/bidders/yieldmo.md b/dev-docs/bidders/yieldmo.md index 1287292cba..1ebe78694d 100644 --- a/dev-docs/bidders/yieldmo.md +++ b/dev-docs/bidders/yieldmo.md @@ -2,7 +2,6 @@ layout: bidder title: Yieldmo description: Prebid Yieldmo Bidder Adaptor - biddercode: yieldmo media_types: banner userIds: pubCommonId, unifiedId, criteo @@ -10,6 +9,9 @@ gdpr_supported: true usp_supported: true schain_supported: true tcf2_supported: true +prebid_member: true +pbjs: true +pbs: true --- diff --git a/dev-docs/bidders/yieldnexus.md b/dev-docs/bidders/yieldnexus.md index 7adad0f247..e8a7461bba 100644 --- a/dev-docs/bidders/yieldnexus.md +++ b/dev-docs/bidders/yieldnexus.md @@ -3,7 +3,7 @@ layout: bidder title: Yield Nexus description: Yield Nexus Bidder Adapter biddercode: yieldnexus - +pbjs: true media_types: banner, video gdpr_supported: true --- diff --git a/dev-docs/bidders/yieldone.md b/dev-docs/bidders/yieldone.md index abac620f55..43991a3439 100644 --- a/dev-docs/bidders/yieldone.md +++ b/dev-docs/bidders/yieldone.md @@ -2,7 +2,8 @@ layout: bidder title: YIELDONE description: Prebid YIELDONE Bidder Adaptor - +pbjs: true +pbs: true biddercode: yieldone media_types: banner, video --- diff --git a/dev-docs/bidders/zedo.md b/dev-docs/bidders/zedo.md index 8ebf190e6b..9024188e8d 100644 --- a/dev-docs/bidders/zedo.md +++ b/dev-docs/bidders/zedo.md @@ -2,7 +2,7 @@ layout: bidder title: ZEDO description: Prebid ZEDO Bidder Adapter - +pbjs: true biddercode: zedo --- diff --git a/dev-docs/bidders/zeroclickfraud.md b/dev-docs/bidders/zeroclickfraud.md new file mode 100644 index 0000000000..fd45bea32c --- /dev/null +++ b/dev-docs/bidders/zeroclickfraud.md @@ -0,0 +1,15 @@ +--- +layout: bidder +title: ZeroClickFraud +pbs: true +media_types: banner +biddercode: zeroclickfraud +--- + +### Bid Params + +{: .table .table-bordered .table-striped } +| Name | Scope | Description | Example | Type | +|------------|----------|------------------------|---------|----------| +| sourceId | required | Website Source Id | 111 | integer | +| host | requird | Network Host to request from | 'host1' | string | diff --git a/dev-docs/cmp-best-practices.md b/dev-docs/cmp-best-practices.md new file mode 100644 index 0000000000..c6c6ba8bff --- /dev/null +++ b/dev-docs/cmp-best-practices.md @@ -0,0 +1,75 @@ +--- +layout: page_v2 +title: Prebid.js CMP Best Practices +description: Prebid.js CMP Best Practices +sidebarType: 1 +--- + +# Prebid.js CMP Best Practices + +{: .alert.alert-info :} +**This is a work in progress.** This document is intented to be a repository for the +Prebid.org community to collect best practices regarding the integration +of Prebid.js and Consent Management Platforms. + +## NOT LEGAL ADVICE + +{% capture legalNotice %} + This resource should not be construed as legal advice and Prebid.org makes no guarantees about compliance with any law or regulation. Please note that because every company and its collection, use, and storage of personal data is different, you should seek independent legal advice relating to obligations under European and/or US regulations, including the GDPR, the ePrivacy Directive and CCPA. Only a lawyer can provide you with legal advice specifically tailored to your situation. Nothing in this guide is intended to provide you with, or should be used as a substitute for, legal advice tailored to your business. + {% endcapture %} + +{% include /alerts/alert_important.html content=legalNotice %} + +## General + +Prebid cannot define a standard one-size-fits-all way of integrating with CMPs -- there are too many special cases, custom implementations, and differently +flavored CMPs for that. + +Instead, here are some general guidelines: + +- You can't just automatically turn on the GDPR Enforcement Module when not in GDPR scope. +- You need to understand how your CMP works, how you want to handle the "first page" scenario where the user hasn't yet had time to answer CMP questions, and how your site is laid out geographically. +- We recommend that the page first load a CMP stub synchronously, then asynchronously load the CMP code and the Prebid code + +## The Role & Relations of the CMP/TCF gdprApplies and Prebid gdpr.defaultGdprScope + +### CMP/TCF gdprApplies + +The indicates the determination of whether GDPR applies in this context. The CMP, in most cases, is responsible for this. The publisher provides this value when supplying [static](/dev-docs/modules/consentManagement.html) consent data. + +### Prebid gdpr.defaultGdprScope + +This indicates the behavior of Prebid when the CMP __does not__ provide a value for `gdprApplies`. Critically, the __defaultGdprScope__ is applied if the user times-out in replying to the CMP's questions. While this also can happen if the CMP doesn't set the value in certain cases, or the CMP isn't loaded, the timeout behavior critical to understand. Essentially, the value of this config variable takes the place of the CMP `gdprApplies` when `gdprApplies` value cannot be determined. + +## What does that mean? + +Prebid.js doesn't have a concept of the geographic region where it's running. It's up to the CMP and/or publisher to configure Prebid.js correctly. Here are some options for discussing with with your lawyers, engineers, and CMP provider: + +- If you use a CMP and they __always__ return a proper tcfapi function for all pageviews, even when geo targeting is used, then you should set gdpr.defaultGdprScope to true and let the functionality work as intended. +- If you otherwise remove the CMP from the page based on Geo, then you should align your Prebid config to that and consider removing the `consentManagement` config from the Prebid.js entirely when GDPR does not apply. +- Because of the timeout behavior, gdpr.defaultGdprScope should not be set to false globally. This value could be modified based on Publisher defined logic, but a blanket `false` will result in timeouts in the EEA being treated as GDPR not applying, when it should. + +Here are some approaches where PBJS config can be the same across all geos: + +- The CMP function is always present, it does the geo-detection, and passes 'gdprApplies: true/false' to Prebid.js as appropriate. +- If the CMP is removed in some geos but the CMP creates a `__tcfapi()` function and sets gdprApplies to false, then the page can rely on this function and set a global `consentManagement` config. + +In these approaches, the publisher has to be aware of the geo and tell Prebid.js what to do: + +- When in the EEA, the page sets `consentManagement` config, but when not in the EEA, the page avoids setting the `consentManagement` config, turning off GDPR enforcement. +- When not in the EEA, the page sets `consentManagement` config with defaultGdprScope=false so that if the CMP is slow to respond then enforcement is off. + +## CMP Best Practices + +Community members are welcome to contribute more specific implementation +approaches here. Please do not attempt to extoll the virtues of one CMP +over another -- just help others with interface idiosyncacies. + +### LiveRamp + +LiveRamp has verified that they create the tcfapi functions and set gdprApplies=false when their CMP is removed from a geo. + +## Further Reading + +- [IAB TCF Implementation Guidelines](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/TCF-Implementation-Guidelines.md) +- [GDPR Enforcement Module](/dev-docs/modules/gdprEnforcement.html) diff --git a/dev-docs/conditional-ad-units.md b/dev-docs/conditional-ad-units.md index 855f1677ac..c4073de26f 100644 --- a/dev-docs/conditional-ad-units.md +++ b/dev-docs/conditional-ad-units.md @@ -30,7 +30,7 @@ See the [Publisher API reference]({{site.baseurl}}/dev-docs/publisher-api-refere ## What if some bidders should be skipped for some devices? {: .alert.alert-info :} -See the [Advanced Size Mapping module](/dev-docs/modules/sizeMappingV2.html) for another way to handle this scenario. +See the [Advanced Size Mapping module](/dev-docs/modules/sizeMappingV2.html) for another way to handle this scenario. Note that you must use Advanced Size Mapping for mediaTypes other than banner. Say a particular bidder is focused on mobile phone demand, so it's really not worthwhile to send them requests from display or tablets. @@ -107,7 +107,7 @@ For instance, say that a given bidder wants to define different placements for d | Display | 1111 | | Phones and tablets | 2222 | -### Using the Global sizeConfig Approach +### Using the Global sizeConfig Approach (Banner only) Assuming the same `sizeConfig` as in the first use case above, the AdUnit would contain bids for both placements, but the conditional `labelAny` is added to them both. This will cause the bid to be fired only if one @@ -191,7 +191,7 @@ var AdUnits = [{ ## What if some ad unit auctions should be skipped entirely for some devices? Say there's a responsive page where one of the ad units only supports larger sizes, so it doesn't make sense -on phones. To suppress the ad unit for mobile users, we can apply conditional logic to the entire ad unit. For example: +on phones. To suppress the ad unit for mobile users, we can apply conditional logic to the entire ad unit. Here's an example using the global sizeConfig approach (banner only): {% highlight js %} @@ -219,6 +219,8 @@ var AdUnits = [{ ] }] +See the [Advanced Size Mapping module](/dev-docs/modules/sizeMappingV2.html) if you need to do something like this for video. + {% endhighlight %} ## What if some bid requests apply only to users originating certain from countries? diff --git a/dev-docs/docs-by-format.md b/dev-docs/docs-by-format.md index 9d5413c50f..4113fad6ee 100644 --- a/dev-docs/docs-by-format.md +++ b/dev-docs/docs-by-format.md @@ -24,7 +24,7 @@ For ad ops and other ad server-related information, see [our Ad Ops documentatio |---------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------| | *Multi-Format (banner, native, outstream video all in one ad unit)* | [Show Multi-Format Ads with Prebid.js]({{site.baseurl}}/dev-docs/show-multi-format-ads.html) (Engineering setup) | | | [Setting up Prebid Multi-Format in Google Ad Manager]({{site.baseurl}}/adops/setting-up-prebid-multi-format-in-dfp.html) (Ad ops setup) | -| *AMP* | [How Prebid on AMP Works]({{site.github.url}}/dev-docs/how-prebid-on-amp-works.html) | +| *AMP* | [How Prebid on AMP Works](/prebid-server/use-cases/pbs-amp.html) | | | [Show Prebid Ads on AMP Pages (Alpha)]({{site.github.url}}/dev-docs/show-prebid-ads-on-amp-pages.html) | | *Video* (instream) | [Show Video Ads with a Google Ad Manager Video Tag]({{site.github.url}}/dev-docs/show-video-with-a-dfp-video-tag.html) (With lots of examples) | | | [How to Add a New Video Bidder Adapter]({{site.github.url}}/dev-docs/how-to-add-a-new-video-bidder-adaptor.html) | diff --git a/dev-docs/faq.md b/dev-docs/faq.md index e7c48c1a76..17c4ed7e1f 100644 --- a/dev-docs/faq.md +++ b/dev-docs/faq.md @@ -22,7 +22,7 @@ Nope. The only approval process is a code review. There are separate instruction - [adding a bidder in Prebid.js](/dev-docs/bidder-adaptor.html) - [adding an analytics adapter in Prebid.js](/dev-docs/integrate-with-the-prebid-analytics-api.html) -As for [membership](/partners/partners.html) in Prebid.org, that's entirely optional -- we'd be happy to have you join and participate in the various committees, +As for [membership](https://prebid.org/membership/) in Prebid.org, that's entirely optional -- we'd be happy to have you join and participate in the various committees, but it's not necessary for contributing code as a community member. ## When starting out, what should my timeouts be? @@ -125,7 +125,7 @@ See [the GitHub release schedule](https://github.com/prebid/Prebid.js/blob/maste ## When do I have to upgrade my version of Prebid.js? -Prebid.org does not support any version of Prebid.js prior to version 1.0. If you want continued support through updates and documentation you should upgrade to a newer version. +Prebid.org does not support any version of Prebid.js prior to the previous version. e.g. if the current version is 4.x, we'll help debug 3.x, but not 2.x. If you want continued support through updates and documentation you should upgrade to a newer version. ## How can I change the price granularity for different ad units? @@ -148,6 +148,15 @@ benefits for sending more than one bid. Once you find the right balance for your application, you can specify what's sent to the ad server with [targetingControls.auctionKeyMaxChars](/dev-docs/publisher-api-reference.html#setConfig-targetingControls) and/or [sendBidsControl.bidLimit](/dev-docs/publisher-api-reference.html#setConfig-Send-Bids-Control) +## Can I run multiple different versions of Prebid.js concurrently? + +It's technically possible, but we don't recommend doing this: + +- The code isn't small. For performance reasons you don't want to run two versions if you can help it +- We don't test concurrent versions +- We won't specifically support debugging problems caused by running two concurrent versions. But will take take PRs if someone finds an issue. + +If all this wasn't enough to warn you away from trying, it should work if you name the PBJS global differently for each instance (https://github.com/prebid/Prebid.js/blob/master/package.json#L20) ## Related Reading diff --git a/dev-docs/get-started-with-prebid-server.md b/dev-docs/get-started-with-prebid-server.md deleted file mode 100644 index e5fdc258c6..0000000000 --- a/dev-docs/get-started-with-prebid-server.md +++ /dev/null @@ -1,172 +0,0 @@ ---- -layout: page_v2 -title: Get Started with Prebid Server -description: Get Started with Prebid Server -pid: 27 -top_nav_section: dev_docs -nav_section: prebid-server -sidebarType: 5 - ---- - -
-
-# Get Started with Prebid Server
-{:.no_toc}
-
-Prebid Server improves your page's performance by running the header bidding auction on a server.
-This will improve your page's load time, which should improve your users' experience.
-
-Prebid Server supports different adapters from Prebid.js. For info about Prebid Server adapters, see
-the [Prebid Server Bidders]({{site.baseurl}}/dev-docs/prebid-server-bidders.html) page.
-
-{: .alert.alert-success :}
-**Prebid Server is open source!**
-Prebid Server is an open source project. [The source code is hosted under the Prebid organization on GitHub](https://github.com/prebid/prebid-server).
-
-* TOC
-{:toc}
-
-## Step 1. Choose Your Server Host
-
-- If you plan to host Prebid Server on your own server, please skip to **Step 2** below. If you do *not* have your own server, please choose from one of the Prebid.org members below to get started.
-
-- **AppNexus**
- - Go to the [Prebid Server sign-up page](https://prebid.adnxs.com) and click the button to sign up.
- - Fill out the form details, including your email address.
- - When approved, you will receive an email with your assigned `accountId`. You will need this for configuring Prebid.js to use Prebid Server.
-
-- **Rubicon Project**
- - [Learn more](https://rubiconproject.com/demand-manager-hosted-prebid-server/) about Rubicon Project's Hosted Prebid Server offering.
-
-
-## Step 2. Download Prebid.js with Prebid Server enabled
-
-- Go to [the Prebid.org download page]({{site.baseurl}}/download.html), select all the demand adapters you want to work with, and include "Prebid Server".
- - Some Prebid Server demand adapters may not have a corresponding client-side adapter that's present on the download page. In this case, just ensure to select "Prebid Server" as part of your build and you will be able to interact with these Prebid Server only bidders.
- - We still strongly recommend to select any listed demand adapters in your build. These additional selections will allow any client-side features (such as userSyncs) to function as well as allow you to easily use any of the adapter's currently registered aliases.
-
-- For example, if you want to use AppNexus, Index Exchange, and Rubicon with Prebid Server, select:
- - *AppNexus*
- - *Index Exchange*
- - *Rubicon*
- - *Prebid Server*
-
-- Then, click **Get Custom Prebid.js** and follow the instructions.
-
-## Step 3. Update your site with the new build of Prebid.js
-
-Update your site's hosted copy of Prebid.js to use the new build you just generated. (For example, you may host your copy on your site's servers or using a [CDN](https://en.wikipedia.org/wiki/Content_delivery_network) such as Fastly or Akamai.)
-
-## Step 4. Configure S2S bidder adapters
-
-The Prebid Server settings (defined by the [`pbjs.setConfig`]({{site.baseurl}}/dev-docs/publisher-api-reference.html#module_pbjs.setConfig) method) go in the same anonymous function where you define your ad units. This method must be called before `pbjs.requestBids`.
-
-The code in your Prebid configuration block should look something like the following (unless you want to show video ads, in which case see [Using Prebid Server to show video ads](#prebid-server-video-openrtb) below).
-
-See [The `s2sConfig` object]({{site.baseurl}}/dev-docs/publisher-api-reference.html#setConfig-Server-to-Server) for definitions of the keys in the `s2sConfig` object.
-
-{% highlight js %}
-var pbjs = pbjs || {};
-
-pbjs.que = pbjs.que || [];
-
-pbjs.que.push(function() {
-
- pbjs.setConfig({
- s2sConfig: {
- accountId: '1',
- enabled: true,
- bidders: ['appnexus', 'pubmatic'],
- timeout: 1000,
- adapter: 'prebidServer',
- endpoint: 'https://prebid.adnxs.com/pbs/v1/openrtb2/auction',
- syncEndpoint: 'https://prebid.adnxs.com/pbs/v1/cookie_sync'
- }
- });
-
- var adUnits = [{
- code: '/19968336/header-bid-tag-1',
- sizes: sizes,
- bids: [{
- /* Etc. */
- }]
- }];
-});
-{% endhighlight %}
-
-Optionally, if you chose to use one of the existing Prebid.org members as your server host, you can also use the defaultVendor property. This property represents the vendor's default settings for the s2sConfig. When used, these settings will be automatically populated to the s2sConfig, saving the need to individually list out all data points. Currently 'appnexus' and 'rubicon' are supported values.
-
-These defaults can still be overridden by simply including the property with the value you want in the config. The following example represents the bare minimum configuration required when using the defaultVendor option:
-
-{% highlight js %}
-var pbjs = pbjs || {};
-
-pbjs.que.push(function() {
-
- pbjs.setConfig({
- s2sConfig: {
- accountId: '1',
- bidders: ['appnexus', 'pubmatic'],
- defaultVendor: 'appnexus'
- }
- });
-
- var adUnits = [{
- code: '/19968336/header-bid-tag-1',
- sizes: sizes,
- bids: [{
- /* Etc. */
- }]
- }];
-});
-{% endhighlight %}
-
-{: .alert.alert-info :}
-**OpenRTB Endpoint**
-If your `s2sConfig.endpoint` points to a url containing the path `/openrtb2/`, such as the AppNexus-hosted endpoint https://prebid.adnxs.com/pbs/v1/openrtb2/auction', Prebid will communicate with that endpoint using the OpenRTB protocol.
-
-{: .alert.alert-info :}
-**Aliasing Prebid Server only bidders**
-If you wish to set/use an alias for a Prebid Server only bidder, simply list the alias in your `s2sConfig.bidders` field and call the [`pbjs.aliasBidder` method]({{site.baseurl}}/dev-docs/publisher-api-reference.html#module_pbjs.aliasBidder) in your prebid code (prior to the `pbjs.requestBids`) to register the alias.
-
-
-
-### Using Prebid Server to show video ads
-
-If you are using Prebid Server and you want to show video ads, you must use [OpenRTB video parameters](https://www.iab.com/guidelines/real-time-bidding-rtb-project/) in your Prebid ad unit as shown below.
-
-{: .alert.alert-warning :}
-The `mimes` parameter is required by OpenRTB. For all other parameters, check with your server-side header bidding partner.
-
-```javascript
-var adUnit1 = {
- code: 'videoAdUnit',
- mediaTypes: {
- video: {
- context: 'instream',
- mimes: ['video/mp4'],
- playerSize: [400, 600],
- minduration: 1,
- maxduration: 2,
- protocols: [1, 2],
- w: 1,
- h: 2,
- startdelay: 1,
- placement: 1,
- playbackmethod: [2]
- // other OpenRTB video params
- }
- },
- bids: [
- // ...
- ]
-}
-```
-
-## Related Topics
-
-+ [Prebid.js Developer Docs]({{site.baseurl}}/dev-docs/getting-started.html)
-+ [Add a Bidder Adapter to Prebid Server]({{site.baseurl}}/dev-docs/add-a-prebid-server-adapter.html)
-
-
diff --git a/dev-docs/getting-started.md b/dev-docs/getting-started.md
index 5553a9f736..06a28bc39b 100644
--- a/dev-docs/getting-started.md
+++ b/dev-docs/getting-started.md
@@ -19,14 +19,7 @@ The easiest way to get started with Prebid.js is to use the example code below.
{% include dev-docs/build-from-source-warning.md %}
-
-
-
-
-
+
### Next Steps
diff --git a/dev-docs/how-prebid-on-amp-works.md b/dev-docs/how-prebid-on-amp-works.md
deleted file mode 100644
index e3b95c6dac..0000000000
--- a/dev-docs/how-prebid-on-amp-works.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-layout: page_v2
-title: How Prebid on AMP Works
-description: How Prebid on AMP Works
-pid: 0
-is_top_nav: yeah
-top_nav_section: dev_docs
-nav_section: prebid-amp
----
-
-(Sorry, jsfiddle code examples aren't available with your cookie privacy settings.)
--
-
-# How Prebid on AMP Works
-{: .no_toc}
-
-The diagram below shows how the pieces of an AMP+Prebid solution fit together:
-
-1. AMP runtime calls Prebid Server URL, including macros.
-1. Prebid Server retrieves demand partner configuration.
-1. Prebid Server sends bid requests to demand partners and caches bid responses.
-1. Prebid Server responds to AMP runtime with key-value targeting.
-1. AMP Network constructs ad request URL and Prebid creative is served.
-1. Creative content is retrieved from cache and renders.
-
-{: .pb-lg-img }
-
-## Related Topics
-
-+ [AMP Format Overview]({{site.baseurl}}/formats/amp.html)
-+ [Show Prebid Ads on AMP Pages]({{site.baseurl}}/dev-docs/show-prebid-ads-on-amp-pages.html) (Developers)
-+ [Setting up Prebid for AMP in Google Ad Manager]({{site.baseurl}}/adops/setting-up-prebid-for-amp-in-dfp.html) (Ad Ops)
-
-
-
-
-
-[PBS]: {{site.baseurl}}/dev-docs/get-started-with-prebid-server.html
-[RTC-Overview]: https://github.com/ampproject/amphtml/blob/master/extensions/amp-a4a/rtc-documentation.md
diff --git a/dev-docs/integrate-with-the-prebid-analytics-api.md b/dev-docs/integrate-with-the-prebid-analytics-api.md
index 9980e21b88..318e389f98 100644
--- a/dev-docs/integrate-with-the-prebid-analytics-api.md
+++ b/dev-docs/integrate-with-the-prebid-analytics-api.md
@@ -1,7 +1,7 @@
---
layout: page_v2
-title: How to Add an Analytics Adapter
-description: How to add an analytics adapter
+title: How to Add a Prebid.js Analytics Adapter
+description: How to add a Prebid.js analytics adapter
pid: 28
top_nav_section: dev_docs
nav_section: adapters
@@ -11,7 +11,7 @@ sidebarType: 1
-# How to Add an Analytics Adapter
+# How to Add a Prebid.js Analytics Adapter
{:.no_toc}
The Prebid Analytics API provides a way to get analytics data from `Prebid.js` and send it to the analytics provider of your choice, such as Google Analytics. Because it's an open source API, you can write an adapter to send analytics data to any provider you like. Integrating with the Prebid Analytics API has the following benefits:
@@ -45,9 +45,13 @@ Working with any Prebid project requires using Github. In general, we recommend
4. Open a [pull request](https://help.github.com/en/desktop/contributing-to-projects/creating-a-pull-request) to the appropriate repository's master branch with a good description of the feature/bug fix.
5. If there's something that needs to change on the prebid.org website, follow the above steps for the [website repo](https://github.com/prebid/prebid.github.io).
+{: .alert.alert-warning :}
+Analytics adapters are subject to a number of specific technical rules. Please become familiar
+with the [module rules](/dev-docs/module-rules.html) that apply globally and to analytics adapters in particular.
+
### Step 1: Add a markdown file describing the module
-1. Create a markdown file under `modules` with the name of the bidder suffixed with 'AnalyticsAdapter', e.g., `exAnalyticsAdapter.md`
+Create a markdown file under `modules` with the name of the bidder suffixed with 'AnalyticsAdapter', e.g., `exAnalyticsAdapter.md`
Example markdown file:
{% highlight text %}
@@ -67,7 +71,7 @@ Analytics adapter for Example.com. Contact prebid@example.com for information.
1. Create a JS file under `modules` with the name of the bidder suffixed with 'AnalyticsAdapter', e.g., `exAnalyticsAdapter.js`
-2. Create an analytics adapter to listen for Prebid events and call the analytics library or server. See the existing *AnalyticsAdapter.js files in the repo under [modules](https://github.com/prebid/Prebid.js/tree/master/modules).
+2. Create an analytics adapter to listen for [Prebid events](/dev-docs/publisher-api-reference.html#module_pbjs.onEvent) and call the analytics library or server. See the existing *AnalyticsAdapter.js files in the repo under [modules](https://github.com/prebid/Prebid.js/tree/master/modules).
3. There are two types of analytics adapters. The example here focuses on the 'endpoint' type. See [AnalyticsAdapter.js](https://github.com/prebid/Prebid.js/blob/master/src/AnalyticsAdapter.js) for more info on the 'bundle' type.
@@ -78,7 +82,13 @@ Analytics adapter for Example.com. Contact prebid@example.com for information.
adapter needs to specify an enableAnalytics() function, but it should also call
the base class function to set up the events.
-A basic prototype analytics adapter:
+5. Doing analytics may require user permissions under [GDPR](/dev-docs/modules/consentManagement.html), which means your adapter will need to be linked to your [IAB Global Vendor List](https://iabeurope.eu/vendor-list-tcf-v2-0/) ID. If no GVL ID is found, and Purpose 7 (Measurement) is enforced, your analytics adapter will be blocked unless it is specifically listed under vendorExceptions. Your GVL ID can be added to the `registerAnalyticsAdapter()` call.
+
+#### Basic prototype analytics adapter
+
+The best way to get started is to look at some of the existing AnalyticsAdapter.js files in [the repository](https://github.com/prebid/Prebid.js/tree/master/modules).
+
+Here's a skeleton outline:
{% highlight js %}
import {ajax} from 'src/ajax';
@@ -104,11 +114,32 @@ exAnalytics.enableAnalytics = function (config) {
adaptermanager.registerAnalyticsAdapter({
adapter: exAnalytics,
- code: 'exAnalytic'
+ code: 'exAnalytics',
+ gvlid: 1
});
+
+export default exAnalytics;
{% endhighlight %}
-Analytics adapter best practices:
+#### Reading TCF2 enforcement actions
+
+Analytics adapters can learn what happened with regards to GDPR TCF2 enforcement by listening to the tcf2Enforcement event.
+
+The callback will receive an object with the following attributes:
+
+```
+{
+ storageBlocked: ['moduleA', 'moduleB'],
+ biddersBlocked: ['moduleB'],
+ analyticsBlocked: ['moduleC']
+}
+```
+
+#### Listening for errors
+
+There are two error events analytics modules may wish to listen for: auctionDebug and adRenderFailed. The former is any error that would be normally logged to console and there can be a great many. The latter may happen for the following reasons: (PREVENT_WRITING_ON_MAIN_DOCUMENT, NO_AD, CANNOT_FIND_AD, EXCEPTION, MISSING_DOC_OR_ADID)
+
+#### Analytics adapter best practices
+ listen only to the events required
+ batch up calls to the backend for post-auction logging rather than calling immediately after each event.
@@ -125,7 +156,7 @@ Once everything looks good, submit the code, tests, and markdown as a pull reque
### Step 5: Website pull request
-There are two files that need to be updated to list your new analytics adapter.
+There are two files that need to be updated to list your new analytics adapter.
1. Create a fork of the [website repo](https://github.com/prebid/prebid.github.io) and a branch for your new adapter. (e.g. feature/exAnalyticsAdapter)
@@ -138,11 +169,10 @@ st of other analytics adapters.
### Step 6: Wait for Prebid volunteers to review
-We sometimes get pretty busy, so it can take a couple of weeks for the review process to complete, so while you're waiting, consider [joining Prebid.org](/partners/partners.html) to help us out with code reviews. (!)
+We sometimes get pretty busy, so it can take a couple of weeks for the review process to complete, so while you're waiting, consider [joining Prebid.org](https://prebid.org/membership/) to help us out with code reviews. (!)
## Further Reading
-- [Analytics for Prebid]({{site.baseurl}}/overview/analytics.html) (Overview and list of analytics providers)
-- [Integrate with the Prebid Analytics API]({{site.baseurl}}/dev-docs/integrate-with-the-prebid-analytics-api.html) (For developers)
-
-
+- [Analytics for Prebid](/overview/analytics.html) (Overview and list of analytics providers)
+- [Module Rules](/dev-docs/module-rules.html)
+- [Instream Video Ads Tracking](/dev-docs/modules/instreamTracking.html)
diff --git a/dev-docs/module-rules.md b/dev-docs/module-rules.md
new file mode 100644
index 0000000000..b009e446cc
--- /dev/null
+++ b/dev-docs/module-rules.md
@@ -0,0 +1,138 @@
+---
+layout: page_v2
+title: Module Rules
+description: Technical Module Rules for Prebid.js and Prebid Server
+sidebarType: 0
+---
+
+# Prebid.js and Prebid Server Module Rules
+{:.no_toc}
+
+* TOC
+{:toc}
+
+"Modules" are optional features that extend Prebid's functionality. There are
+several kinds of modules built by the community to enhance header bidding:
+
+{: .table .table-bordered .table-striped }
+| Module Type | Description | Scope |
+|-------------|-------------|-------|
+| Bid Adapter | Obtains Open Market or Private Market bids for the current ad request. | Prebid.js, Prebid Server |
+| Analytics Adapter | Listens to auction events and reports to an analytics system. | Prebid.js, Prebid Server |
+| User ID Sub-Module | Obtains an ID for this user and makes that ID available to other types of modules. | Prebid.js |
+| Real Time Data Sub-Module | Obtains data for the current user's context that may be of interest to advertisers. | Prebid.js |
+| Other | Modules that don't fall into one of the other categories. | Prebid.js |
+
+## Prebid.org Core Values
+
+Specific technical rules are needed to govern the development and review of modules in order to assure that they conform to Prebid's Core Values. The main objective of Prebid.org is to make great header bidding technology available for web publishers and mobile app developers. We believe great technology is:
+
+- **Efficient** - Products offered by Prebid.org should not burden a user device, the network, or a company server.
+- **Secure** - Prebid.org software should not open doors to security risks, including electronic attack, denial of service, fraud, or data leakage.
+- **Transparent** - Our products are built in the open with community review. Changes to Prebid software and modules must be open to inspection before and after release.
+- **Fair** - The Prebid.org platform doesn’t favor any one entity over another. No entity can be favored over another in technical ordering or status as a default value. No entity can gain information about another entity without approval.
+- **Collaborative** - Human interactions in Prebid.org forums and events must be courteous.
+- **Privacy Sensitive** - Our products are built for publishers to support users’ privacy concerns and comply with industry standards.
+
+## Module Rules
+
+Bid adapters, user ID adapters, analytics adapters, and other modules will be reviewed for conformity to the Core Values of Prebid.org.
+
+This set of module rules applies to both Prebid.js and Prebid Server. However, these rules don’t necessarily apply to tools or the Prebid Mobile SDK. Rules and guidelines for those products will be determined by their respective committees as required.
+
+The use of the terms "must" and "should" in this document is deliberate. However, some of the rules are "aspirational," in that we know there are existing exceptions to the rule that will need to get sorted out over time. These are marked with an asterisk (*). The goal is:
+
+- Every new module adheres to all required rules.
+- Even grandfathered modules must adhere to all required rules by Prebid.js 5.0.
+
+### Global Module Rules
+
+1. Modules must(*) not load outside code files unless those libraries are approved and open source.
+ 1. External modules may be used at build-time at the discretion of the relevant Prebid committee. Build-time modules must be locked to a particular version so that any upgrades must be done via Prebid pull request.
+ 1. Exceptions may be made in the following cases:
+ - When the publisher has control over whether the file is loaded and which version, the base module should be able to work without the auxiliary file.
+ - If run-time code is not needed for the auction, it should support a deferred load. E.g. User ID modules.
+ - The file loaded must be locked to a particular version so that any upgrades must be done via Prebid pull request.
+ - A prominent disclosure must be made about the loading of the file and why they need the file, and a size warning provided if it’s greater than 10KB.
+ 1. If a functionality is supported by Prebid core or an existing module, Prebid modules must prefer the Prebid version of that functionality rather than an externally coded version.
+ 1. The build-time or run-time loading of required or optional external files must be disclosed. (See the disclosure section below.)
+ 1. Modules must not import other Prebid modules at build time.
+1. Modules must not(*) add any pixel, iframe, cookie or local storage directly onto the page. Rather, they must use wrapper-provided mechanisms for usersyncs, cookies, and local storage.
+1. Modules must use the communication functions provided by the Prebid core (both Prebid.js and Prebid Server) for external communication.
+1. Prebid.js modules must not use the $$PREBID_GLOBAL$$ variable nor otherwise obtain a pointer to the global PBJS object. This preserves data integrity.
+1. All modules must support the creation of multiple concurrent instances. This means, for example, they cannot rely on mutable global variables.
+ - Writing to the global window object must be non-intrusive, disclosed, and done in a way that supports multiple instances.
+1. All modules and any external code references must disclose their support of privacy regulations such as GDPR, CCPA, COPPA, etc. (See the disclosure section below.)
+1. Responses to auction or data requests should be compressed as long as the client supports that functionality (e.g. gzip, compress, deflate).
+1. Prebid.js requests and responses must be secure HTTPS. Prebid Server requests should be HTTPS.
+1. Endpoints should use HTTP/2 with keepalives so that connections don’t need to be re-created.
+1. In order to be listed on the Prebid.org website, a module must be in a Prebid open source repository.
+1. Each module must include maintainer information with a group email address for Prebid.org to contact for support or maintenance.
+1. Modules must not include polyfills or override standard or Prebid JavaScript functions.
+
+### Bidder Adapter Rules
+
+1. All global rules apply.
+1. Bid adapters must(*) be able to bid. If they cannot return an auction bid, they should consider integration as a Real-Time Data or other module type.
+1. Creative rendering scripts must(*) load from the creative frame and not directly in the page. In other words, creative rendering JavaScript cannot be used to bypass the “no external code” rule.
+1. Bidder modules must not(*) make requests to endpoints for functionality other than auctions without:
+ 1. Disclosure
+ 1. Ability for the publisher to control the additional functionality.
+ 1. Ensuring auctions are still operable if the publisher turns off the additional functionality; i.e., bid adapters may log certain analytics events, but if a publisher turns it off, the auction should still happen.
+ 1. Building a Real-Time Data sub-module that obtains data in a way that can be utilized by other bidders as well if a bidder would like to incorporate an external data fetch that would influence the auction.
+1. Bidder modules must not obtain bid information from or about any other party in the auction. E.g., they cannot listen to ad server events and forward information naming other bidders back to their endpoint - that is the job of an analytics module.
+1. Bidder modules must not(*) cache bids from previous auctions. That functionality is reserved for Prebid core.
+1. Bidders must(*) accept parameters in the conventional location in preference to bidder-specific parameters. The list of these parameters is in the [bidder adapter documentation](/dev-docs/bidder-adaptor.html#std-param-location).
+1. Bidders must not override the standard ad server targeting values: hb_adid, hb_bidder, hb_pb, hb_deal, or hb_size, hb_source, hb_format.
+1. If bid adapters are reporting multiple media types in the hb_format as ‘banner’, they must(*) indicate the actual mediatype in the metadata object. One use case for this is that it allows publishers to manage which creatives support safeframes.
+1. Bidder modules should supply buyer metadata - including advertiser, advertiser domain, network, actual mediatype, and others defined in the Prebid documentation.
+1. Creatives returned must be fully HTTPS.
+
+### Analytics Adapter Rules
+
+1. All global rules apply.
+1. Analytics adapters must not bid or supply any parameters to the auction.
+1. Analytics adapters must be neutral to the bid adapters -- not favoring any particular bidder in any way.
+1. Analytics adapters should minimize the number of times they call their endpoints by batching auction and event data.
+
+### User ID Sub-Module Rules
+
+1. All global rules apply.
+1. ID sub-modules must not gather any information from the page except for publisher-approved ID data for this user.
+1. ID sub-modules must not report analytics information back to their endpoints, including use of other user IDs, auction information, bidders, bids won, etc. This is the job of an analytics module.
+1. ID sub-modules must be neutral to the bid adapters -- each bidder must have the same opportunity to utilize each user ID.
+
+### Real Time Data Module Rules
+
+1. All global rules apply.
+1. Real Time Data (RTD) modules must not bid. That functionality is reserved for bid adapters.
+1. RTD modules must not supply privacy-sensitive user information (including IDs) into the auction. That functionality is reserved for User ID modules.
+1. RTD modules should make data available in a cross-bidder way when possible. For example, passing data through existing mechanisms like First Party Data.
+1. RTD modules may cache bid metadata for analytics and optimization purposes. They may use those bids to optimize future auctions for which bidders and adunits take place. They must not re-use specific past bids in an auction -- that functionality is restricted to Prebid core.
+
+### Other modules
+
+Any other type of module will be evaluated on a case-by-case basis. Examples of other modules include Currency, Video ad serving, Consent management, etc. These modules must all follow the global rules.
+
+## Disclosure
+
+There are already exceptions to these rules, and we recognize there will likely be more. Any module doing something that needs to be disclosed will receive a label on their prebid.org documentation like:
+
+- Disclosure: this bidder adapter loads external JavaScript to render creatives.
+- Disclosure: this bidder records win and loss events with a pixel call.
+- Disclosure: this bidder listens directly to Google Ad Manager events.
+- Disclosure: this bidder reports timeout events.
+
+Ideally, the disclosures should be of a limited number of standard types so they can be managed.
+
+To manage this, we plan to:
+
+1. Document a distinct set of disclosures with guidance for reviewers on how to determine which disclosures are needed.
+1. Create a process for generating new types of disclosures and which modules received a given disclosure/exception on which date.
+1. Make sure that disclosures are applied to all existing and new adapter aliases.
+
+
+# Further Reading
+
+- Adding a bid adapter: [Prebid.js](/dev-docs/bidder-adaptor.html), [Prebid Server](/prebid-server/developers/add-new-bidder-go.html)
+- Adding an analytics adapter: [Prebid.js](/dev-docs/integrate-with-the-prebid-analytics-api.html), [Prebid Server](/prebid-server/developers/pbs-build-an-analytics-adapter.html)
diff --git a/dev-docs/modules/consentManagement.md b/dev-docs/modules/consentManagement.md
index 7ea89ec138..b95e62f309 100644
--- a/dev-docs/modules/consentManagement.md
+++ b/dev-docs/modules/consentManagement.md
@@ -36,13 +36,13 @@ Prebid functionality created to address regulatory requirements does not replace
This base EU GDPR consent management module performs these actions:
-1. Fetch the user's GDPR consent data from the CMP.
+1. Fetch the user's GDPR & Google additional consent data from the CMP.
2. Incorporate this data into the auction objects for adapters to collect.
The optional [GDPR enforcement module](/dev-docs/modules/gdprEnforcement.html) adds on these actions:
3. Allows the page to define which activities should be enforced at the Prebid.js level.
-4. Actively enforces those activities based on user consent data.
+4. Actively enforces those activities based on user consent data (in the TCF string, not the AC string).
In the case of a new user, CMPs will generally respond only after there is consent information available (i.e., the user has made their consent choices).
Making these selections can take some time for the average user, so the module provides timeout settings.
@@ -54,9 +54,11 @@ If the timeout period expires or an error from the CMP is thrown, one of these a
## Page Integration
-To utilize this module, a Consent Management Platform (CMP) compatible with the [IAB TCF v1.1 spec](https://iabeurope.eu/tcf-v1/) or [IAB TCF v2.0 spec](https://iabeurope.eu/tcf-2-0/) needs to be implemented on the site to interact with the user and obtain their consent choices.
+Please start by understanding the IAB's [TCF Implementation Guide](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/TCF-Implementation-Guidelines.md).
-Though implementation details for the CMP are not covered by Prebid.org, we do recommend to that you place the CMP code before the Prebid.js code in the head of the page in order to ensure the CMP's framework is loaded before the Prebid code executes.
+To utilize this module, a Consent Management Platform (CMP) compatible with the [IAB TCF v1.1 spec](https://iabeurope.eu/all-news/the-iab-europe-transparency-consent-framework-tcf-steering-group-votes-to-extend-technical-support-for-tcf-v1-1/) or [IAB TCF v2.0 spec](https://iabeurope.eu/tcf-2-0/) needs to be implemented on the site to interact with the user and obtain their consent choices. It's important to understand the details of how the CMP works before integrating it with Prebid.js
+
+In general, implementation details for CMPs are not covered by Prebid.org, but we do recommend to that you place the CMP code before the Prebid.js code in the head of the page in order to ensure the CMP's framework is loaded before the Prebid code executes. In addition, the community is collecting a set of [CMP best practices](/dev-docs/cmp-best-practices.html).
Once the CMP is implemented, simply include this module into your build and add a `consentManagement` object in the `setConfig()` call. Adapters that support this feature will then be able to retrieve the consent information and incorporate it in their requests.
@@ -76,7 +78,12 @@ but we recommend migrating to the new config structure as soon as possible.
| gdpr.allowAuctionWithoutConsent | `boolean` | (TCF v1.1 only) Determines what will happen if obtaining consent information from the CMP fails; either allow the auction to proceed (`true`) or cancel the auction (`false`). Default is `true` | `true` |
| gdpr.consentData | `Object` | An object representing the GDPR consent data being passed directly; only used when cmpApi is 'static'. Default is `undefined`. | |
| gdpr.consentData.getTCData.tcString | `string` | (TCF v2.0 only) Base64url-encoded TCF v2.0 string with segments. | |
+| gdpr.consentData.getTCData.addtlConsent | `string` | (TCF v2.0 only) Additional consent string if available from the cmp TCData object | |
| gdpr.consentData.getTCData.gdprApplies | `boolean` | (TCF v2.0 only) Defines whether or not this pageview is in GDPR scope. | |
+| gdpr.consentData.getTCData.purpose.consents | `Object` | (TCF v2.0 only) An object representing the user's consent status for specific purpose IDs. | |
+| gdpr.consentData.getTCData.purpose.legitimateInterests | `Object` | (TCF v2.0 only) An object representing the user's legitimate interest status for specific purpose IDs. | |
+| gdpr.consentData.getTCData.vendor.consents | `Object` | (TCF v2.0 only) An object representing the user's consent status for specific vendor IDs. | |
+| gdpr.consentData.getTCData.vendor.legitimateInterests | `Object` | (TCF v2.0 only) An object representing the user's legitimate interest status for specific vendors IDs. | |
| gdpr.consentData.getConsentData.gdprApplies | `boolean` | (TCF v1.1 only) Defines whether or not this pageview is in GDPR scope. | |
| gdpr.consentData.getConsentData.hasGlobalScope | `boolean` | (TCF v1.1 only) True if consent data is global, false if it's publisher specific. | |
| gdpr.consentData.getConsentData.consentData | `string` | (TCF v1.1 only) Encoded TCF v1.1 string. | |
@@ -85,6 +92,9 @@ but we recommend migrating to the new config structure as soon as possible.
{: .alert.alert-info :}
NOTE: The `allowAuctionWithoutConsent` parameter supported for TCF v1.1 refers to the entire consent string, not to any individual consent option. Prebid.js does not parse the GDPR consent string, so it doesn't know if the user has consented to any particular action.
+{: .alert.alert-info :}
+NOTE: The `purpose` and `vendor` objects are required if you are using the `gdprEnforcement` module. If the data is not included, your bid adpaters, analytics adapters, and/or userId systems will likely be excluded from the auction as Prebid will assume the user has not given consent for these entities.
+
A related parameter is `deviceAccess`, which is at the global level of Prebid.js configuration because it can be used GDPR, CCPA, or custom privacy implementations:
{: .table .table-bordered .table-striped }
@@ -124,10 +134,30 @@ Example 2: Static CMP using custom data passing.
gdpr: {
cmpApi: 'static',
consentData: {
- getTCData: {
- tcString: 'COwK6gaOwK6gaFmAAAENAPCAAAAAAAAAAAAAAAAAAAAA.IFoEUQQgAIQwgIwQABAEAAAAOIAACAIAAAAQAIAgEAACEAAAAAgAQBAAAAAAAGBAAgAAAAAAAFAAECAAAgAAQARAEQAAAAAJAAIAAgAAAYQEAAAQmAgBC3ZAYzUw',
- gdprApplies: true
- }
+ getTCData: {
+ tcString: 'COwK6gaOwK6gaFmAAAENAPCAAAAAAAAAAAAAAAAAAAAA.IFoEUQQgAIQwgIwQABAEAAAAOIAACAIAAAAQAIAgEAACEAAAAAgAQBAAAAAAAGBAAgAAAAAAAFAAECAAAgAAQARAEQAAAAAJAAIAAgAAAYQEAAAQmAgBC3ZAYzUw',
+ gdprApplies: true,
+ purpose: {
+ consents: {
+ 0: true,
+ ...
+ },
+ legitimateInterests: {
+ 0: true,
+ ...
+ }
+ },
+ vendor: {
+ consents: {
+ 00: true,
+ ...
+ },
+ legitimateInterests: {
+ 0: true,
+ ...
+ }
+ }
+ }
}
}
}
@@ -226,6 +256,10 @@ Here is a sample of how the data is structured in the `bidderRequest` object:
This field contains the user's choices on consent, represented as an encoded string value. In certain scenarios, this field might come to you with an `undefined` value; normally this happens when there was an error during the CMP interaction and the publisher had the config option `allowAuctionWithoutConsent` set to `true`. If you don't want to pass `undefined` to your system, you can check for this value and replace it with a valid consent string. See the *consent_required* code in the example below (under "gdprApplies") for a possible approach to checking and replacing values.
+**_addtlConsent_**
+
+If the CMP responds with additional consent data as proposed at https://support.google.com/admanager/answer/9681920?hl=en then the corresponding string is stored here.
+
**_vendorData_**
This field contains the raw vendor data in relation to the user's choices on consent. This object will hold a map of all available vendors for any potential adapters that want to read the data directly. One use-case for reading from this field would be when an adapter wants to be omitted from a request where they were not given consent. Adapters are able to read through the object to find their appropriate information.
@@ -439,5 +473,7 @@ var idx_gdpr=0;
## Further Reading
- [GDPR Enforcement Module](/dev-docs/modules/gdprEnforcement.html)
+- [IAB TCF Implementation Guide](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/TCF-Implementation-Guidelines.md)
- [IAB Transparancy and Consent Framework Policies](https://iabeurope.eu/iab-europe-transparency-consent-framework-policies/)
- [Prebid Consent Management - US Privacy Module](/dev-docs/modules/consentManagementUsp.html)
+- [CMP Best Practices](https://docs.prebid.org/dev-docs/cmp-best-practices.html)
diff --git a/dev-docs/modules/currency.md b/dev-docs/modules/currency.md
index 85e10be1ee..94a79fb63d 100644
--- a/dev-docs/modules/currency.md
+++ b/dev-docs/modules/currency.md
@@ -21,7 +21,7 @@ by using [BidderSettings.bidCpmAdjustment]({{site.baseurl}}/dev-docs/publisher-a
the web development team makes a manual update.
Publishers may continue to use the bidCpmAdjustment approach, or may begin using this optional module, gaining automatic updates as currency exchange rates fluctuate. Here's how it works at a high level:
-
+
1. A Prebid.js package is built that contains the extra currency module code
1. Config in the page defines the currency used by the Publisher's ad server and other configuration parameters.
1. The existence of this configuration causes the Prebid platform to load a
@@ -126,7 +126,7 @@ low granularity bucket hb_pb=162.
### 5. Ad Request and Decision
Finally, the scaled and quantized bids are sent to the ad server, where they will match
-the line items set up initially.
+the line items set up initially.
{: .alert.alert-success :}
No other part of the Prebid process has changed due to currency support: creation of AdUnits, creative display, analytics, etc.
@@ -216,18 +216,18 @@ pbjs.setConfig({
### Step 1: Bundle the module code
Follow the basic build instructions on the Gihub repo's main README. To include the module, an additional option must be added to the the gulp build command:
-
+
{% highlight js %}
gulp build --modules=currency,exampleBidAdapter
{% endhighlight %}
-
+
This command will build the following files:
-
+
- build/dist/prebid-core.js - the base Prebid code
- build/dist/currency.js - additional code for the currency feature
- build/dist/exampleBidAdapter.js - a specified bidder adapter
- build/dist/prebid.js - a combined file with the base Prebid core code, bidder adapter code, and the currency module code.
-
+
### Step 2: Publish the package(s) to the CDN
After testing, get your javascript file(s) out to your Content Delivery Network (CDN) as normal.
@@ -317,5 +317,3 @@ If there's a currency conversion you need that's not included, there are several
1. Use the 'defaultRates` feature
1. Build and host a currency conversion file that includes the desired currencies
1. Find a reliable, free, no-strings source of conversation data that we can integrate into our hosted file, then post an issue on the github forum.
-
-
diff --git a/dev-docs/modules/floors.md b/dev-docs/modules/floors.md
index 0706ff0c1d..498ce08abf 100644
--- a/dev-docs/modules/floors.md
+++ b/dev-docs/modules/floors.md
@@ -249,6 +249,7 @@ pbjs.setConfig({
url: 'https://floorprovider.com/a1001-mysite.json'
},
data: { // default if endpoint doesn't return in time
+ floorProvider: 'floorProviderName',
currency: 'USD',
skipRate: 5,
modelVersion: ‘new model 1.0’
@@ -277,7 +278,9 @@ Schema 1 restricts floors providers or publishers to applying only one data grou
{: .table .table-bordered .table-striped }
| Param | Type | Description | Default |
|---+---+---+---+---|
+| floorProvider | string | Optional atribute (as of prebid version 4.1) used to signal to the Floor Provider's Analytics adapter their floors are being applied. They can opt to log only floors that are applied when they are the provider. If floorProvider is supplied in both the top level of the floors object and within the data object, the data object's configuration shall prevail.| - |
| enforcement | object | Controls the enforcement behavior within the Floors Module.| - |
+| skipRate | integer | skipRate is a random function whose input value is any integer 0 through 100 to determine when to skip all floor logic, where 0 is always use floor data and 100 is always skip floor data. The use case is for publishers or floor providers to learn bid behavior when floors are applied or skipped. Analytics adapters will have access to model version (if defined) when skipped is true to signal the Floors Module is in floors mode. If skipRate is supplied in both the root level of the floors object and within the data object, the skipRate configuration within the data object shall prevail. | 0 |
| enforcement.enforceJS | boolean | If set to true, the floors module will provide floors to bid adapters for bid request matched rules and suppress any bids not exceeding a matching floor. If set to false, the prebid floors module will still provide floors for bid adapters, there will be no floor enforcement.| true |
| enforcement.enforcePBS | boolean | If set to true, the Prebid.js floors module will signal to Prebid Server to pass floors to it’s bid adapters and enforce floors. If set to false, the pbjs should still pass matched bid request floor data to PBS, however no enforcement will take place. | false |
| enforcement.floorDeals | boolean | Enforce floors for deal bid requests. | false |
@@ -285,8 +288,9 @@ Schema 1 restricts floors providers or publishers to applying only one data grou
| endpoint | object | Controls behavior for dynamically retrieving floors. | - |
| endpoint.url | string | URL of endpoint to retrieve dynamic floor data. | - |
| data | object (required) | Floor data used by the Floors Module to pass floor data to bidders and floor enforcement. | - |
+| data.floorProvider | string | Optional atribute (as of prebid version 4.2) used to signal to the Floor Provider's Analytics adapter their floors are being applied. They can opt to log only floors that are applied when they are the provider. If floorProvider is supplied in both the top level of the floors object and within the data object, the data object's configuration shall prevail.| - |
| data.currency | string | Currency of floor data. Floor Module will convert currency where necessary. See Currency section for more details. | 'USD' |
-| data.skipRate | integer | skipRate is a random function whose input value is any integer 0 through 100 to determine when to skip all floor logic, where 0 is always use floor data and 100 is always skip floor data. The use case is for publishers or floor providers to learn bid behavior when floors are applied or skipped. Analytics adapters will have access to model version (if defined) when skipped is true to signal the Floors Module is in floors mode. | 0 |
+| data.skipRate | integer | skipRate is a random function whose input value is any integer 0 through 100 to determine when to skip all floor logic, where 0 is always use floor data and 100 is always skip floor data. The use case is for publishers or floor providers to learn bid behavior when floors are applied or skipped. Analytics adapters will have access to model version (if defined) when skipped is true to signal the Floors Module is in floors mode. If skipRate is supplied in both the root level of the floors object and within the data object, the skipRate configuration within the data object shall prevail. | 0 |
| data.floorsSchemaVersion | string | The Floors Module supports two versions of the data schema. Version 1 allows for only one model to be applied in a given data set, whereas Version 2 allows you to sample multiple models selected by supplied weights. If no schema version is provided, the Floors Module will assume version 1 for the sake of backwards compatiblity. For schema version 2 see the next section. | 1 |
| data.modelVersion | string | Used by floor providers to train on model version performance. The expectation is a floor provider’s analytics adapter will pass the model verson back for algorithm training. | - |
| data.schema | object |allows for flexible definition of how floor data is formatted. | - |
@@ -320,7 +324,9 @@ While some attributes are common in both schema versions, for completeness, all
{: .table .table-bordered .table-striped }
| Param | Type | Description | Default |
|---+---+---+---+---|
+| floorProvider | string | Optional atribute (as of prebid version 4.1) used to signal to the Floor Provider's Analytics adapter their floors are being applied. They can opt to log only floors that are applied when they are the provider. If floorProvider is supplied in both the top level of the floors object and within the data object, the data object's configuration shall prevail.| - |
| enforcement | object | Controls the enforcement behavior within the Floors Module.| - |
+| skipRate | integer | skipRate is a random function whose input value is any integer 0 through 100 to determine when to skip all floor logic, where 0 is always use floor data and 100 is always skip floor data. The use case is for publishers or floor providers to learn bid behavior when floors are applied or skipped. Analytics adapters will have access to model version (if defined) when skipped is true to signal the Floors Module is in floors mode. If skipRate is supplied in both the root level of the floors object and within the data object, the skipRate configuration within the data object shall prevail. | 0 |
| enforcement.enforceJS | boolean | If set to true, the floors module will provide floors to bid adapters for bid request matched rules and suppress any bids not exceeding a matching floor. If set to false, the prebid floors module will still provide floors for bid adapters, but there will be no floor enforcement.| true |
| enforcement.enforcePBS | boolean | If set to true, the Prebid.js floors module will signal to Prebid Server to pass floors to it’s bid adapters and enforce floors. If set to false, Prebid.js should still pass matched bid request floor data to Prebid Server, however no enforcement will take place. | false |
| enforcement.floorDeals | boolean | Enforce floors for deal bid requests. | false |
@@ -328,8 +334,9 @@ While some attributes are common in both schema versions, for completeness, all
| endpoint | object | Controls behavior for dynamically retrieving floors. | - |
| endpoint.url | string | URL of endpoint to retrieve dynamic floor data. | - |
| data | object (required) | Floor data used by the Floors Module to pass floor data to bidders and floor enforcement. | - |
+| data.floorProvider | string | Optional atribute (as of prebid version 4.2) used to signal to the Floor Provider's Analytics adapter their floors are being applied. They can opt to log only floors that are applied when they are the provider. If floorProvider is supplied in both the top level of the floors object and within the data object, the data object's configuration shall prevail.| - |
| data.currency | string | Currency of floor data. Floors Module will convert currency where necessary. See Currency section for more details. | 'USD' |
-| data.skipRate | integer | skipRate is a random function whose input value is any integer 0 through 100 to determine when to skip all floor logic, where 0 is always use floor data and 100 is always skip floor data. The use case is for publishers or floor providers to learn bid behavior when floors are applied or skipped. Analytics adapters will have access to model version (if defined) when skipped is true to signal the Floors Module is in floors mode. | 0 |
+| data.skipRate | integer | skipRate is a random function whose input value is any integer 0 through 100 to determine when to skip all floor logic, where 0 is always use floor data and 100 is always skip floor data. The use case is for publishers or floor providers to learn bid behavior when floors are applied or skipped. Analytics adapters will have access to model version (if defined) when skipped is true to signal the Floors Module is in floors mode. If skipRate is supplied in both the root level of the floors object and within the data object, the skipRate configuration within the data object shall prevail.| 0 |
| data.floorsSchemaVersion | string | The Floors Module supports two version of the data schema. Version 1 allows for only one model to be applied in a given data set, whereas Version 2 allows you to sample multiple models selected by supplied weights. If no schema version is provided, the Floors Module will assume version 1 for the sake of backwards compatiblity.| 1 |
| data.modelGroups | array of objects | Array of model objects to be used for A/B sampling multiple models. This field is only used when data.floorsSchemaVersion = 2 | - |
| data.modelGroups[].currency | string | Currency of floor data. Floor Module will convert currency where necessary. See Currency section for more details. | 'USD' |
@@ -780,8 +787,9 @@ floor determined by AdUnit code and Media Type:
{% highlight js %}
{
+ floorProvider: 'floorProviderName',
currency: 'USD',
- skipRate: 5,
+ skipRate: 5,
modelVersion: ‘new model 1.0’
schema: {
fields: [ 'gptSlot', 'mediaType' ]
@@ -1024,7 +1032,7 @@ The price floors module will do this by leveraging the already existing implemen
|---+---+---+---+---|
| skipped | Boolean | Whether the skipRate resolved to be true or false| true |
| modelVersion | String | The name of the model| ‘floor-model-4.3’ |
-| location | String | Where the Floors Module derived the rule set. Values are one of 'adUnit', 'setConfig' or 'fetch' | ‘fetch’ |
+| location | String | Where the Floors Module derived the rule set. Values are one of 'adUnit', 'setConfig', 'fetch' or 'noData'. If the Floors Module code is invoked and no floors object is able to be found (either by error or other condition) the floorsModule will set location to 'noData'. When on data is found, it is up to the analtyics adapter to decide what to log. All available values will be provided in teh bidRequest object. | ‘fetch’ |
| fetchStatus | String | Provides details on the status of a fetch for a JSON floors file when fetches are attempted. Valid values are: 'success' (when fetch returns an http 200 status), 'timeout' (when fetch results not returned before either auction delay or prebid timeout) or 'error' (any http status other than 200 or other error condition). To determine if fetch succeeds but returns invalid floors data, refer to the location field to infer invalid data if 'fetch' is not resultant value. | ‘success’ |
| skipRate | integer | skipRate will be populated when a skip rate is configured in the Prebid Floors Module, even if the skipRate is evaluated to false. Skip Rate is used to determine when to skip all floors logic. | 15 |
@@ -1137,3 +1145,11 @@ Below is a chart explaining the behavior of currency conversion, if necessary, w
| USD | Undefined (currency module possibly not included) | EUR | Bid.cpm is converted to EUR then compared with floor. Bid.cpm is compared to floor. If bid meets or exceeds the floor, bid.originalCpm is sent to the ad server. |
If the currency function is unable to derive the correct cpm in any of the scenarios above where a conversion is needed, then the associated bidResponse will just pass through into the auction as if a matching floor was not found.
+
+
+## Floors Providers
+
+{: .table }
+| Partners| Contact |
+| 
| Contact Magnite (Formerly Rubicon Project) support at [globalsupport@mangite.com](mailto:globalsupport@magnite.com) to use Magnite as a floor provider. |
+| pubx.ai | Reach out to PubX at [hello@pubx.ai](mailto:hello@pubx.ai) to learn more about our AI-powered dynamic floor optimization. |
\ No newline at end of file
diff --git a/dev-docs/modules/gdprEnforcement.md b/dev-docs/modules/gdprEnforcement.md
index ab4207b0e3..12f6c21bdc 100644
--- a/dev-docs/modules/gdprEnforcement.md
+++ b/dev-docs/modules/gdprEnforcement.md
@@ -22,17 +22,17 @@ sidebarType : 1
{% include /alerts/alert_important.html content=legalNotice %}
{: .alert.alert-warning :}
-This module requires the [EU GDPR consent management module](/dev-docs/modules/consentManagement.html), which reads consent values from the Consent Management Platform (CMP). The GDPR enforcement module
-will then enforce the results. See the base module page for general background, usage, and legal disclaimers.
+This module requires the [EU GDPR consent management module](/dev-docs/modules/consentManagement.html) (the base consent module), which reads consent values from the Consent Management Platform (CMP). The GDPR Enforcement Module
+will then enforce the results. See the [base module page](/dev-docs/modules/consentManagement.html) for general background, usage, and legal disclaimers.
## Overview
-The base [EU GDPR consent management module](/dev-docs/modules/consentManagement.html) performs the following actions:
+The [base consent module](/dev-docs/modules/consentManagement.html) performs the following actions:
-1. Fetch the user's GDPR consent data from the CMP.
-2. Incorporate this data into the auction objects for adapters to collect.
+1. Fetches the user's GDPR consent data from the CMP.
+2. Incorporates this data into the auction objects for adapters to collect.
-This GDPR enforcement module adds the following:
+The GDPR Enforcement Module adds the following:
3. Allows the page to define which activities should be enforced at the Prebid.js level.
4. Actively enforces those activities based on user consent data.
@@ -40,13 +40,13 @@ This GDPR enforcement module adds the following:
The following table details the Prebid.js activities that fall under the [Transparency and Consent Framework (TCF)](https://iabeurope.eu/iab-europe-transparency-consent-framework-policies/) scope:
{: .table .table-bordered .table-striped }
-| TCF Purpose | In-Scope Activity | Enforcement Activity | Optional Controls |
+| In-Scope Activity | TCF Legal Basis Required | Enforcement Activity | Prebid.js Version |
| --- | --- | --- | --- |
-| Purpose 1 - Store and/or access information on a device | usersync pixels | May prevent one or more vendor usersyncs. | Do not enforce Purpose 1. Do not enforce Purpose 1 vendor signals. Do not enforce Purpose 1 for vendor V. |
-| Purpose 1 - Store and/or access information on a device | user ID modules | May prevent one or more UserID modules from activating. | Do not enforce Purpose 1. Do not enforce Purpose 1 vendor signals. Do not enforce Purpose 1 for vendor V. |
-| Purpose 1 - Store and/or access information on a device | device storage | May prevent one or more adapters or modules from being able to read or write cookies or localstorage in the user's browser. | Do not enforce Purpose 1. Do not enforce Purpose 1 vendor signals. Do not enforce Purpose 1 for vendor V. |
-
-There are plans to add more TCF Purposes and activities in future releases.
+| Invoke usersync pixels | Purpose 1 - Store and/or access information on a device | May prevent one or more vendor usersyncs. | 3.14+ |
+| Invoke user ID modules | Purpose 1 - Store and/or access information on a device | May prevent one or more UserID modules from activating. | 3.14+ |
+| Read and write data to device | Purpose 1 - Store and/or access information on a device | May prevent one or more adapters or modules from being able to read or write cookies or localstorage in the user's browser. | 3.14+ |
+| Perform header bidding auction | Purpose 2 - Basic ads | May prevent one or more bid adapters from participating in the auction. | 4.0+ |
+| Invoke analytics adapters | Purpose 7 - Measurement | May prevent one or more analytics adapters from participating in the auction. | 4.x+ |
## Page Integration
@@ -55,73 +55,82 @@ A page needs to define configuration rules about how Prebid.js should enforce ea
{: .alert.alert-warning :}
**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.
-These are the fields related to GDPR enforcment that are supported in the [`consentManagement.gdpr`](/dev-docs/modules/consentManagement.html) object:
+{: .alert.alert-info :}
+To turn on Prebid.js enforcement you must:
+1) Include the gdprEnforcement module in the Prebid.js build
+and 2) setConfig `consentManagement.gdpr.cmp` to either 'iab' or 'static'
+
+The following fields related to GDPR enforcement are supported in the [`consentManagement.gdpr`](/dev-docs/modules/consentManagement.html) object:
{: .table .table-bordered .table-striped }
| Param | Type | Description | Example |
| --- | --- | --- | --- |
| gdpr.rules | `Array of Objects` | Lets the publisher override the default behavior. | |
-| gdpr.rules[].purpose | `String` | The only currently supported value is "storage", corresponding to TCF Purpose 1. | "storage" |
-| gdpr.rules[].enforcePurpose | `Boolean` | Determines whether to enforce the purpose consent or not. The default in Prebid.js 3.x is not to enforce purposes. The plan for Prebid.js 4.0 is to enforce consent for Purpose 1 and no others. | true |
-| gdpr.rules[].enforceVendor | `Boolean` | Determines whether to enforce vendor signals for this purpose or not. The default in Prebid.js 3.x is not to enforce vendor signals. The plan for Prebid.js 4.0 to enforce signals for Purpose 1 and no others. | true |
+| gdpr.rules[].purpose | `String` | Supported values: "storage" (Purpose 1), "basicAds" (Purpose 2), "measurement" (Purpose 7) | "storage" |
+| gdpr.rules[].enforcePurpose | `Boolean` | Determines whether to enforce the purpose consent. The default in Prebid.js 3.x is not to enforce purposes. Prebid.js 4.0 enforces legal basis for Purposes 1 and 2 by default. | true |
+| gdpr.rules[].enforceVendor | `Boolean` | Determines whether to enforce vendor signals for this purpose. The default in Prebid.js 3.x is not to enforce vendor signals. Prebid.js 4.0 enforces legal basis for Purposes 1 and 2 by default. | true |
| gdpr.rules[].vendorExceptions | `Array of Strings` | Defines a list of biddercodes or module names that are exempt from the enforcement of this Purpose. | ["bidderA", "userID-module-B"] |
Note:
-- The vendorExceptions list is based on Prebid.js biddercodes instead of Global Vendor List (GVL) IDs, i.e. "rubicon" instead of "52". This was done to accomodate Prebid.js modules and adapters that don't have GVL IDs.
+- To accomodate Prebid.js modules and adapters that don't have GVL IDs, the vendorExceptions list is based on Prebid.js biddercodes instead of Global Vendor List (GVL) IDs (i.e. "rubicon" instead of "52").
### Examples
-The following examples cover a range of use cases and how Prebid.js supports
+The following examples cover a range of use cases and show how Prebid.js supports
configuration of different business rules.
-1) Enforce that the user consents to DeviceAccess as an activity and consider their per-vendor selection.
+1) Enforce device access activity and basic ads. These are the default values (in Prebid.js 4.0) if the module is included in the build.
```
pbjs.setConfig({
consentManagement: {
gdpr: {
- ...
- rules: [{
+ cmpApi: 'iab', // activates the enforcement module
+ defaultGdprScope: true,
+ rules: [{ // these are the default values
purpose: "storage",
enforcePurpose: true,
enforceVendor: true
+ },{
+ purpose: "basicAds",
+ enforcePurpose: true,
+ enforceVendor: true
+ },{
+ purpose: "measurement",
+ enforcePurpose: true,
+ enforceVendor: true
}]
}
}
});
```
-2) Enforce that the user consents to DeviceAccess as an activity and consider their per-vendor selection. However, BidderA is a special case - the publisher has entrusted BidderA for this activity.
+2) Enforce that the user consents to DeviceAccess as an activity and consider their per-vendor selection. However, idSystemA is a special case - the publisher has confirmed that this system obtains a user ID every auction and does not write to the local device.
...
rules: [{
purpose: "storage",
enforcePurpose: true,
enforceVendor: true,
- vendorExceptions: ["bidderA"]
- }]
-
-3) Enforce that the user consents to DeviceAccess as an activity, but don't consider their per-vendor selection.
-
- ...
- rules: [{
- purpose: "storage",
- enforcePurpose: true,
- enforceVendor: false,
+ vendorExceptions: ["idSystemA"]
}]
-4) Enforce that the user consents to DeviceAccess as an activity, but don't consider their per-vendor selection. BidderA is entrusted to enforce the rules on their own.
+3) Enforce legal basis for both storage and basicAds, with the exception of "firstPartyBidder", which is always allowed to run an auction. Assumes the publisher has special legal basis for this entity.
...
rules: [{
purpose: "storage",
enforcePurpose: true,
- enforceVendor: false,
- vendorExceptions: ["bidderA"]
+ enforceVendor: true
+ },{
+ purpose: "basicAds",
+ enforcePurpose: true,
+ enforceVendor: true,
+ vendorExceptions: ["firstPartyBidder"]
}]
-5) Turn off enforcement of Purpose 1: don't enforce either the user's DeviceAccess consent or their per-vendor selection.
+4) Turn off enforcement of Purpose 1: don't enforce either the user's DeviceAccess consent or their per-vendor selection.
...
rules: [{
@@ -130,45 +139,67 @@ pbjs.setConfig({
enforceVendor: false
}]
-6) Don't enforce the user's DeviceAccess consent, but do consider their per-vendor selection.
-
- ...
- rules: [{
- purpose: "storage",
- enforcePurpose: false,
- enforceVendor: true
- }]
-
-7) Don't enforce the user's DeviceAccess consent, but do consider their per-vendor selection except for BidderA.
+5) Allow the user to suppress analtyics provider A, but make an exception for analytics provider B.
...
rules: [{
- purpose: "storage",
- enforcePurpose: false,
+ purpose: "measurement",
+ enforcePurpose: true,
enforceVendor: true,
- vendorExceptions: ["bidderA"]
+ vendorExceptions: ["analyticsB"]
}]
## Basic Enforcement
Prebid.js does not have access to the Global Vendor List (GVL), so it implements
-a "basic" form of TCF validation using the supplied consent string.
+a "basic" form of TCF 'legal basis' validation using the supplied consent string.
A goal of basic enforcement is to confirm that there's enough evidence of consent to pass data on to vendors who do have access to the GVL and can fully parse and enforce.
Before allowing an activity tied to a TCF-protected Purpose for a given vendor, one of these scenarios must be true:
- Configuration rules enforce both consent and vendor signals and either:
- - we have the user’s purpose consent and the user’s vendor consent, or
- - (for Purpose 2 only) we've confirmed the user’s LI (Legitimate Interest) Transparency is established for this purpose
+ - Prebid.js has the user’s purpose consent and the user’s vendor consent, or
+ - (for Purpose 2 only) we've confirmed the user’s Legitimate Interest (LI) Transparency is established for this purpose
- Configuration rules enforce only purpose consent and either:
- - we have the user’s purpose consent, or
- - (for Purpose only) we confirmed the user’s LI Transparency is established for this purpose.
+ - Prebid.js has the user’s purpose consent, or
+ - (for Purpose 2 only) we confirmed the user’s LI Transparency is established for this purpose.
- Configuration rules enforce only vendor signals and we have the user’s vendor consent
- Configuration rules enforce neither purpose consent nor vendor signal.
See the [IAB TCF Consent String Format](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20Consent%20string%20and%20vendor%20list%20formats%20v2.md) for details.
+## Modules that Support GVL ID
+
+The GDPR Enforcement module requires the GVL ID for a module to be specified. If no GVL ID is found the module will be blocked by default unless it is specifically listed under `vendorExceptions`. The following modules have listed their GVL IDs.
+
+{% assign bidder_pages = site.pages | where: "layout", "bidder" %}
+
+| Module Type | +Module | +
|---|---|
| Bid Adapter | +{{page.title}} | +
| Analytics Adapter | +AppNexus | +
| User ID | +ID5 | +
-
+{% for page in bidder_pages %}
+
+
+
+
+{% endfor %}
diff --git a/dev-docs/prebid-server-bidders.md b/dev-docs/prebid-server-bidders.md
deleted file mode 100644
index 80f020dcfe..0000000000
--- a/dev-docs/prebid-server-bidders.md
+++ /dev/null
@@ -1,167 +0,0 @@
----
-layout: page_v2
-title: Prebid Server Bidders
-description: Get Started with Prebid Server
-pid: 28
-top_nav_section: dev_docs
-nav_section: prebid-server
----
-
-
-{{ page.title }}
+ +Features
+ +{: .table .table-bordered .table-striped } +| **Bidder Code** | {{ page.biddercode }} | **Prebid.org Member** | {% if page.prebid_member == true %}yes{% else %}no{% endif %} | +| **Media Types** | {% unless page.media_types contains 'no-display' %}display{% endunless %}{% if page.media_types contains 'video' %},{% endif %}{% if page.media_types contains 'video' %} video{% endif %}{% if page.media_types != "no-display, native" and page.media_types contains 'native' %}, native{% endif %}{% if page.media_types == "no-display, native" %}native{% endif %} | **GDPR TCF1 Support** | {% if page.gdpr_supported == true %}yes{% else %}no{% endif %} | +| **User IDs** | {% if page.userIds and page.userIds != '' %}{{page.userIds}}{% else %}none{% endif %} | **GDPR TCF2 Support** | {% if page.tcf2_supported == true %}yes{% else %}no{% endif %} | +| **SChain Support** | {% if page.schain_supported == true %}yes{% else %}no{% endif %} | **COPPA Support** | {% if page.coppa_supported == true %}yes{% else %}no{% endif %} | +| **Safeframes OK** | {% if page.safeframes_ok and page.safeframes_ok == false %}no{% elsif page.safeframes_ok and page.safeframes_ok == true %}yes{% else %}check with bidder{% endif %} | **USP/CCPA Support** | {% if page.usp_supported == true %}yes{% else %}no{% endif %} | +| **Supports Deals** | {% if page.bidder_supports_deals and page.bidder_supports_deals == false %}no{% else %}yes{% endif %} | **Prebid.js Adapter** | {% if page.pbjs == true %}yes{% else %}no{% endif %} | +| | | **Prebid Server Adapter** | yes | + + +"Send All Bids" Ad Server Keys
+ +These are the bidder-specific keys that would be targeted within GAM in a Send-All-Bids scenario. GAM truncates keys to 20 characters. + +{: .table .table-bordered .table-striped } +|{{ "hb_pb_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_bidder_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_adid_" | append: page.biddercode | slice: 0,20 }} |
+| {{ "hb_size_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_source_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_format_" | append: page.biddercode | slice: 0,20 }} |
+| {{ "hb_cache_host_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_cache_id_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_uuid_" | append: page.biddercode | slice: 0,20 }} |
+| {{ "hb_cache_path_" | append: page.biddercode | slice: 0,20 }} | {{ "hb_deal_" | append: page.biddercode | slice: 0,20 }} | |
+
+{% if page.prevBiddercode %}
+
+This bidder previously had a bidder code of `{{ page.prevBiddercode }}`, but prefers new configurations to use `{{ page.biddercode }}`.
+
+{% endif %}
+
+{{ page.content }}
+
+
-
-# Prebid Server Bidders
-
-Prebid Server adapters aren't javascript, so not all Prebid.js adapters are available in Prebid Server, and vice versa. See [the docs](https://github.com/prebid/prebid-server/blob/master/docs/developers/add-new-bidder.md) for how to build a Prebid Server adapter.
-
-All the Prebid Server bidders are listed below. Select one, and then choose an option for more details.
-
-
-
-Then select the option which applies to you...
-
-I want to
-
-
-
-
-
diff --git a/dev-docs/publisher-api-reference.md b/dev-docs/publisher-api-reference.md
index 7cf8fb41f3..4269d8dd94 100644
--- a/dev-docs/publisher-api-reference.md
+++ b/dev-docs/publisher-api-reference.md
@@ -24,6 +24,7 @@ This page has documentation for the public API methods of Prebid.js.
* [.getAdserverTargetingForAdUnitCode([adUnitCode])](#module_pbjs.getAdserverTargetingForAdUnitCode)
* [.getBidResponses()](#module_pbjs.getBidResponses)
* [.getBidResponsesForAdUnitCode(adUnitCode)](#module_pbjs.getBidResponsesForAdUnitCode)
+ * [.getEvents()](#module_pbjs.onEvent)
* [.getHighestCpmBids([adUnitCode])](#module_pbjs.getHighestCpmBids)
* [.getAllWinningBids()](#module_pbjs.getAllWinningBids)
* [.getAllPrebidWinningBids()](#module_pbjs.getAllPrebidWinningBids)
@@ -51,6 +52,7 @@ This page has documentation for the public API methods of Prebid.js.
* [enableSendAllBids](#setConfig-Send-All-Bids)
* [sendBidsControl](#setConfig-Send-Bids-Control)
* [useBidCache](#setConfig-Use-Bid-Cache)
+ * [pageUrl](#setConfig-Page-URL)
* [publisherDomain](#setConfig-Publisher-Domain)
* [priceGranularity](#setConfig-Price-Granularity)
* [mediaTypePriceGranularity](#setConfig-MediaType-Price-Granularity)
@@ -62,6 +64,7 @@ This page has documentation for the public API methods of Prebid.js.
* [COPPA](#setConfig-coppa)
* [first party data](#setConfig-fpd)
* [cache](#setConfig-vast-cache)
+ * [instreamTracking](#setConfig-instream-tracking) - requires [Instream Tracking Module](/dev-docs/modules/instreamTracking.html)
* [site](#setConfig-site)
* [Generic Configuration](#setConfig-Generic-Configuration)
* [Troubleshooting your config](#setConfig-Troubleshooting-your-configuration)
@@ -671,10 +674,31 @@ Request bids. When `adUnits` or `adUnitCodes` are not specified, request bids fo
| requestObj.adUnitCodes | Optional | `Array of strings` | adUnit codes to request. Use this or `requestObj.adUnits`. Default to all `adUnitCodes` if empty. |
| requestObj.adUnits | Optional | `Array of objects` | AdUnitObjects to request. Use this or `requestObj.adUnitCodes`. Default to all `adUnits` if empty. |
| requestObj.timeout | Optional | `Integer` | Timeout for requesting the bids specified in milliseconds |
-| requestObj.bidsBackHandler | Optional | `function` | Callback to execute when all the bid responses are back or the timeout hits. Callback will be passed two parameters, the bids themselves and `timedOut`, which will be true if any bidders timed out. |
+| requestObj.bidsBackHandler | Optional | `function` | Callback to execute when all the bid responses are back or the timeout hits. Callback will be passed three parameters, the [bidResponses](#module_pbjs.getBidResponses) themselves, a `timedOut` flag (true if any bidders timed out) and the `auctionId`. |
| requestObj.labels | Optional | `Array of strings` | Defines [labels](#labels) that may be matched on ad unit targeting conditions. |
| requestObj.auctionId | Optional | `String` | Defines an auction ID to be used rather than having the system generate one. This can be useful if there are multiple wrappers on a page and a single auction ID is desired to tie them together in analytics. |
+Example call
+```
+pbjs.requestBids({
+ bidsBackHandler: sendAdserverRequest,
+ timeout: 1000,
+ labels: ["custom1"]
+});
+```
+
+Example parameters sent to the bidsBackHandler:
+```
+function sendAdserverRequest(bids, timedOut, auctionId) {
+ // bids
+ // {"test-div":{"bids":[{"bidderCode":"bidderA", ...}]}}
+ // See [getBidResponses function](#module_pbjs.getBidResponses) for details
+ // timedOut=false
+ // auctionId="130aad5e-eb1a-4b7d-8939-0663ba251887"
+ ...
+}
+```
+
@@ -1157,8 +1181,12 @@ If a custom adServerTargeting function can return an empty value, this boolean f ### pbjs.offEvent(event, handler, id) +### pbjs.getEvents() ⇒ `Array` + The methods `onEvent` and `offEvent` are provided for you to register -a callback to handle a Prebid.js event. +a callback to handle a Prebid.js event. + +The `getEvents` method returns a copy of all emitted events. The optional `id` parameter provides more finely-grained event callback registration. This makes it possible to register callback @@ -1189,7 +1217,9 @@ The available events are: | requestBids | Bids have been requested from adapters (i.e. pbjs.requestBids() was called) | None | | addAdUnits | Ad units have been added to the auction | None | | adRenderFailed| Ad rendering failed | Object containing 'reason' and 'message' | +| auctionDebug | An error was logged to the console | Object containing 'type' and 'arguments' | | bidderDone | A bidder has signaled they are done responding | Bid request object | +| tcf2Enforcement | There was a TCF2 enforcement action taken | `{ storageBlocked: ['moduleA', 'moduleB'], biddersBlocked: ['moduleB'], analyticsBlocked: ['moduleC'] }` | The examples below show how these events can be used. @@ -1248,6 +1278,16 @@ Events example 3: Dynamically modify the auction pbjs.onEvent('beforeRequestBids', bidderFilter); {% endhighlight %} +Events example 4: Log errors and render fails to your own endpoint +{% highlight js %} + pbjs.onEvent('adRenderFailed', function () { + // pub-specific logic to call their own endpoint + }); + pbjs.onEvent('auctionDebug', function () { + // pub-specific logic to call their own endpoint + }); +{% endhighlight %} +
@@ -1311,6 +1351,7 @@ Core config: + [Configure send bids control](#setConfig-Send-Bids-Control) + [Bid cache](#setConfig-Use-Bid-Cache) + [Set the order in which bidders are called](#setConfig-Bidder-Order) ++ [Set the page URL](#setConfig-Page-URL) + [Set the publisher's domain](#setConfig-Publisher-Domain) + [Set a delay before requesting cookie sync](#setConfig-Cookie-Sync-Delay) + [Set price granularity](#setConfig-Price-Granularity) @@ -1543,6 +1584,16 @@ Set the order in which bidders are called: pbjs.setConfig({ bidderSequence: "fixed" }) /* default is "random" */ {% endhighlight %} + + +#### Page URL + +Override the Prebid.js page referrer algorithm. + +a{% highlight js %} +pbjs.setConfig({ pageUrl: "https://example.com/index.html" ) +{% endhighlight %} + #### Publisher Domain @@ -1686,7 +1737,7 @@ a price granularity override. If it doesn't find 'video-outstream' defined, it w #### Server to Server -Prebid.js can be configured to connect to one or more [Prebid Servers](/dev-docs/get-started-with-prebid-server.html) for one or more bidders. +Prebid.js can be configured to connect to one or more [Prebid Servers](/prebid-server/overview/prebid-server-overview.html) for one or more bidders. Example config: @@ -2042,13 +2093,14 @@ As of Prebid.js 3.11.0, the [Advanced SizeMapping module](/dev-docs/modules/size You should consider using that module if any of these scenarios are true: {::nomarkdown}
-
+
{:/} -If, on the other hand, the AdUnits, bidders, and mediaTypes all change behavior together at the same viewport width, then the built-in sizeConfig feature is appropriate. +If, on the other hand, you're only working with the banner mediaType and the AdUnits all change behavior together at the same viewport width, then the built-in sizeConfig feature is appropriate. {% endcapture %} {% include alerts/alert_tip.html content=tip-choosing %} @@ -2058,7 +2110,7 @@ If, on the other hand, the AdUnits, bidders, and mediaTypes all change behavior -##### How it Works +##### How Size Config Works for Banners - Before `requestBids` sends bid requests to adapters, it will evaluate and pick the appropriate label(s) based on the `sizeConfig.mediaQuery` and device properties. Once it determines the active label(s), it will then filter the `adUnit.bids` array based on the `labels` defined and whether the `banner` mediaType was included. Ad units that include a `banner` mediaType that don't match the label definition are dropped. - The required `sizeConfig.mediaQuery` property allows [CSS media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries). The queries are tested using the [`window.matchMedia`](https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia) API. @@ -2232,14 +2284,13 @@ pbjs.setConfig({coppa: true}); #### First Party Data -A number of adapters support taking key/value pairs as arguments, but they're all different. For example: +Historically, a number of adapters supported taking key/value pairs as arguments, but they were all different. For example: -- RubiconProject takes `keywords`, `inventory` and `visitor` parameters -- AppNexus takes `keywords` and `user` -- OpenX takes `customParams` +- RubiconProject took `keywords`, `inventory` and `visitor` parameters +- AppNexus took `keywords` and `user` +- OpenX took `customParams` -This feature allows publishers a way to specify key/value data in one place where each compatible bid adapter -can read it. +First party data allows publishers to specify key/value data in one place where each compatible bid adapter can read it. {: .alert.alert-warning :} Not all bid adapters currently support reading first party data in this way, but support should increase over time. @@ -2306,6 +2357,8 @@ pbjs.setBidderConfig({ +See [Prebid Server First Party Data](/prebid-server/features/pbs-fpd.html) for details about passing data server-side. + #### Client-side Caching of VAST XML When serving video ads, VAST XML creatives must be cached on the network so the @@ -2352,6 +2405,36 @@ Setting the `vasttrack` parameter to `true` supplies the POST made to the `/vtra Prebid Server endpoint with a couple of additional parameters needed by the analytics system to join the event to the original auction request. + + +#### Instream tracking + +{: .alert.alert-info :} +To enable this tracking, include the `instreamTracking` module in your Prebid.js build. + +This configuration will allow Analytics Adapters and Bid Adapters to track `BID_WON` events for Instream video bids. + +{: .table .table-bordered .table-striped } +| Field | Scope | Type | Description | +|----------+---------+--------+---------------------------------------------------------------------------------------| +| `instreamTracking` | Required | Object | Configuration object for instream tracking | +| `instreamTracking.enabled` | Required | Boolean | Enable/disable the instream tracking feature. Default: `false`. | +| `instreamTracking.maxWindow` | Optional | Integer | The time in ms after which polling for instream delivery stops. Default: `60000` i.e. 60 seconds | +| `instreamTracking.pollingFreq` | Optional | Integer |The frequency of polling. Default: `500`ms | +| `instreamTracking.urlPattern` | Optional | RegExp | Regex for cache url patterns, to avoid false positives. | + +#### Example + +{% highlight js %} +pbjs.setConfig({ + 'instreamTracking': { + enabled: true, + } +}); +{% endhighlight %} + +More examples [here](/dev-docs/modules/instreamTracking.html#example-with-urlpattern). + #### Site Configuration diff --git a/dev-docs/show-outstream-video-ads.md b/dev-docs/show-outstream-video-ads.md index 45baeb3b20..450a8cc999 100644 --- a/dev-docs/show-outstream-video-ads.md +++ b/dev-docs/show-outstream-video-ads.md @@ -67,16 +67,17 @@ To display an outstream video, two things are needed: Prebid.js will select the `renderer` used to display the outstream video in the following way: -1. If a `renderer` is associated with the Prebid adUnit, it will be used to display any outstream demand associated with that adUnit. Below, we will provide an example of an adUnit with an associated `renderer`. -2. If no `renderer` is specified on the Prebid adUnit, Prebid will invoke the renderer associated with the winning (or selected) demand partner video bid. +1. If a `renderer` is associated with the Prebid adUnit, it will be used to display any outstream demand associated with that adUnit. Below, we will provide an example of an adUnit with an associated `renderer`. If that renderer is specified as backup only, it will only be used when no other renderer is found. +2. If no `renderer` is specified on the Prebid adUnit, Prebid will invoke the renderer associated with the winning (or selected) demand partner video bid. Choosing a backup only renderer allows publishers to access demand with or without an attached renderer. {: .alert.alert-warning :} At this time, since not all demand partners return a renderer with their video bid responses, we recommend that publishers associate a `renderer` with their Prebid video adUnits, if possible. By doing so, any Prebid adapter that supports video will be able to provide demand for a given outstream slot. -Renderers are associated with adUnits through the `adUnit.renderer` object. This object contains two fields: +Renderers are associated with adUnits through the `adUnit.renderer` object. This object contains three fields: 1. `url` -- Points to a file containing the renderer script. 2. `render` -- A function that tells Prebid.js how to invoke the renderer script. +3. `backupOnly` -- Optional field, if set to true, buyer or adapter renderer will be preferred {% highlight js %} @@ -90,14 +91,26 @@ pbjs.addAdUnit({ }, renderer: { url: 'https://acdn.adnxs.com/video/outstream/ANOutstreamVideo.js', + backupOnly: true, // prefer demand renderer render: function (bid) { - ANOutstreamVideo.renderAd({ - targetId: bid.adUnitCode, - adResponse: bid.adResponse, + adResponse = { + ad: { + video: { + content: bid.vastXml, + player_height: bid.playerHeight, + player_width: bid.playerWidth + } + } + } + // push to render queue because ANOutstreamVideo may not be loaded yet. + bid.renderer.push(() => { + ANOutstreamVideo.renderAd({ + targetId: bid.adUnitCode, // target div id to render video. + adResponse: adResponse + }); }); } - }, - ... + } }); {% endhighlight %} diff --git a/dev-docs/show-prebid-ads-on-amp-pages.md b/dev-docs/show-prebid-ads-on-amp-pages.md index a67f238882..0b3403897e 100644 --- a/dev-docs/show-prebid-ads-on-amp-pages.md +++ b/dev-docs/show-prebid-ads-on-amp-pages.md @@ -5,8 +5,6 @@ description: Show Prebid Ads using Prebid Server and AMP RTC sidebarType: 2 --- - - # Prebid AMP Implementation Guide {: .no_toc} @@ -16,10 +14,10 @@ Through this implementation, [Prebid Server][PBS] fetches demand and returns key For more information about AMP RTC, see: -+ [How Prebid on AMP Works]({{site.baseurl}}/dev-docs/how-prebid-on-amp-works.html) -+ [Prebid Server AMP Endpoint](https://github.com/prebid/prebid-server/blob/master/docs/endpoints/openrtb2/amp.md) ++ [Prebid Server and AMP](/prebid-server/use-cases/pbs-amp.html) ++ [Prebid Server AMP Endpoint Technical Documentation](/prebid-server/endpoints/openrtb2/pbs-endpoint-amp.html) + [Prebid Server Stored Bid Requests](https://github.com/prebid/prebid-server/blob/master/docs/developers/stored-requests.md#stored-bidrequests) -+ [AMP RTC Overview][RTC-Overview] ++ [AMP RTC Overview](https://github.com/ampproject/amphtml/blob/master/extensions/amp-a4a/rtc-documentation.md) + [AMP RTC Publisher Integration Guide](https://github.com/ampproject/amphtml/blob/master/extensions/amp-a4a/rtc-publisher-implementation-guide.md) {% capture tipNote %} @@ -37,7 +35,7 @@ To set up Prebid to serve ads into your AMP pages, you'll need: + An account with a [Prebid Server][PBS] instance + One or more Prebid Server Stored Bid Requests. A Stored Bid Request is a partial OpenRTB JSON request which: - + Specifies properties like timeout and price granularity + + Specifies properties like currency, schain, price granularity, etc. + Contains a list of demand partners and their respective parameters + An AMP page containing at least one amp-ad element for an AMP ad network that supports Fast Fetch and AMP RTC @@ -52,19 +50,38 @@ To set up Prebid to serve ads into your AMP pages, you'll need: You will have to create at least one Stored Request for Prebid Server. Valid Stored Requests for AMP pages must contain an `imp` array with exactly one element. It is not necessary to include a `tmax` field in the Stored Request, as Prebid Server will always use the smaller of the AMP default timeout (1000ms) and the value passed via the `timeoutMillis` field of the `amp-ad.rtc-config` attribute (explained in the next section). -An example Stored Request is given below: +An example Stored Request is given below. You'll see that the Stored Request contains some important info +that doesn't come from /amp parameters: + +- cur +- schain +- ext.prebid.cache.bids - needed to let Prebid Server know that you want it to store the result in PBC +- ext.prebid.targeting.pricegranularity - needed to let Prebid Server know how to calculate the price bucket +- ext.prebid.aliases +- bidders and their parameters ```html { "id": "some-request-id", + "cur": ["USD"], + "source": { + "ext": { + "schain": { + ... + } + } + }, "site": { - "page": "prebid.org" + "page": "prebid.org" // will be overridden by the 'curl' parameter on /amp endpoint }, "ext": { "prebid": { + "cache": { + "bids": {} + }, "targeting": { - "pricegranularity": { // This is equivalent to the deprecated "pricegranularity": "medium" + "pricegranularity": { // This is equivalent to "pricegranularity": "medium" "precision": 2, "ranges": [{ "max": 20.00, @@ -86,10 +103,10 @@ An example Stored Request is given below: ] }, "ext": { - "appnexus": { + "bidderA": { // Insert parameters here }, - "rubicon": { + "bidderB": { // Insert parameters here } } @@ -98,6 +115,7 @@ An example Stored Request is given below: } ``` +This basic OpenRTB record will be enhanced by the parameters from the call to the [/amp endpoint](/prebid-server/endpoints/openrtb2/pbs-endpoint-amp.html). ### AMP content page @@ -227,7 +245,7 @@ If you're using AppNexus' managed service, you would enter something like this: ``` -See the AppNexus bidder parameters page [for more details](/). +See the AppNexus bidder parameters page [for more details](/). If you are utilizing Rubicon Project's managed service, there's an extra parameter: ```html @@ -268,19 +286,13 @@ To review that Prebid on AMP is working properly the following aspects can be lo + Look for the network call from the Ad Server to ensure that key values are being passed. (For Google Ad Manager these are in the `scp` query string parameter in the network request) + Most of the debugging information is omitted from the Prebid Server response unless the `debug=1` parameter is present in the Prebid Server query string. AMP won't add this parameter, so you'll need to grab the Prebid Server URL and manually add it to see the additional information provided. -## Related Topics - -+ [How Prebid on AMP Works]({{site.github.url}}/dev-docs/how-prebid-on-amp-works.html) -+ [Prebid Server AMP Endpoint](https://github.com/prebid/prebid-server/blob/master/docs/endpoints/openrtb2/amp.md) -+ [Prebid Server Stored Bid Requests](https://github.com/prebid/prebid-server/blob/master/docs/developers/stored-requests.md#stored-bidrequests) -+ [Setting up Prebid for AMP in Google Ad Manager]({{site.github.url}}/adops/setting-up-prebid-for-amp-in-dfp.html) (Ad Ops Setup) -+ [AMP RTC Overview][RTC-Overview] -+ [AMP RTC Publisher Integration Guide](https://github.com/ampproject/amphtml/blob/master/extensions/amp-a4a/rtc-publisher-implementation-guide.md) +## Further Reading -
+
+
+
+
+
-
+
-
+
-
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
+
+
+
+
+
+
+
+
+ {{ page.title }}
+{{page.description }}
+
+
+
+ Important: + This example uses a test version of Prebid.js hosted on our CDN that is not recommended for production + use. It includes all available adapters. Production implementations should build from source or + customize the build using the Download page to make sure only the necessary bidder adapters are + included.
+
+
+
+
+
+
+
+
+
+
+ Warning: + Do not forget to exchange the placementId in the code examples with your own placementId!
+
+
+
+
+ Place this code in the page header.
++<script async src="//acdn.adnxs.com/prebid/not-for-prod/prebid.js"></script>+ +
+<script type="text/javascript" src="https://amp.akamaized.net/hosted/1.x/player?apikey=sample"></script> +<script> + var pbjs = pbjs || {}; + pbjs.que = pbjs.que || []; + var tempTag = false; + var invokeVideoPlayer = function(url) { + tempTag = url; + } + + var videoAdUnit = { + code: 'video1', + mediaTypes: { + video: { + playerSize: [640, 480], + context: 'instream' + } + }, + bids: [{ + bidder: 'appnexus', + params: { + placementId: 13232361, /* Add own placement id */ + video: { + skipppable: true, + playback_method: ['auto_play_sound_off'] + } + } + }] + }; + + pbjs.que.push(function() { + pbjs.addAdUnits(videoAdUnit); + pbjs.setConfig({ + debug: true, + cache: { + url: 'https://prebid.adnxs.com/pbc/v1/cache' + } + }); + + pbjs.requestBids({ + bidsBackHandler: function(bids) { + var videoUrl = pbjs.adServers.dfp.buildVideoUrl({ + adUnit: videoAdUnit, + params: { + iu: '/19968336/prebid_cache_video_adunit', + cust_params: { + section: 'blog', + anotherKey: 'anotherValue' + }, + output: 'vast' + } + }); + invokeVideoPlayer(videoUrl); + } + }); + }); + +</script> +
+
+
+ Place this code in the page body.
+
+<!--player container-->
+<div style="width:604px; height:341px;">
+ <div id="akamai-player" </div>
+</div>
+<script type="text/javascript">
+ invokeVideoPlayer = function(url) {
+ var config = {
+ plugins: {
+ ima: {
+ resources: [
+ { src: "//imasdk.googleapis.com/js/sdkloader/ima3.js", type: "text/javascript", async: true },
+ { src: "${paths.plugins}ima/Ima.min.js", type: "text/javascript", async: true }
+ ],
+ adTagUrl: url
+ }
+ },
+ autoplay: 'muted',
+ media: {
+ src: "https://mdtp-a.akamaihd.net/customers/akamai/video/VfE.mp4"
+ }
+ }
+
+ akamai.amp.AMP.create('#akamai-player', config)
+ };
+
+ if (tempTag) {
+ invokeVideoPlayer(tempTag);
+ tempTag = false;
+ }
+ </script>
+
+
+
+
+
+
+
+
diff --git a/examples/video/outstream/pb-ve-outstream-no-server.html b/examples/video/outstream/pb-ve-outstream-no-server.html
index e18e31ec81..28f793f34a 100644
--- a/examples/video/outstream/pb-ve-outstream-no-server.html
+++ b/examples/video/outstream/pb-ve-outstream-no-server.html
@@ -1,7 +1,7 @@
---
layout: video_sample
-title: Prebid Video | Video Outstream Example with No Ad Server
-description: An example of an outstream video with a pre-roll ad using Prebid.js and no ad server.
+title: Prebid Video | Video Outstream Example with No Ad Server
+description: An example of an outstream video with a pre-roll ad using Prebid.js and no ad server.
videoType: pb-os-nas
isVideo: true
sidebarType: 4
@@ -15,40 +15,40 @@
Using Prebid Plugin for AMP
+As an alternative an adUnit can be passed within the built-int prebid plugin for AMP. The prebid bid request will be handled by prebid plugin automatically just before the ad request takes place.
The plugin can be implemented by providing a prebid object to the player config as follows
+
+ <head>
+ <script type="text/javascript" src="https://amp.akamaized.net/hosted/1.x/player?apikey=sample"></script>
+ </head>
+ <body>
+ <!--player container-->
+ <div style="width:604px; height:341px;">
+ <div id="akamai-player"/div> </div>
+ </div>
+ <script type="text/javascript">
+ var config = {
+ plugins: {
+ prebid: {
+ adServer: {
+ name: "dfp"
+ },
+ resources: [
+ { src: "https://acdn.adnxs.com/prebid/not-for-prod/1/prebid.js", type: "text/javascript", async: true },
+ { src: "${paths.plugins}prebid/Prebid.min.js", type: "text/javascript", async: true }
+ ],
+ adUnits: {
+ code: "video-1",
+ mediaTypes: {
+ video: {
+ playerSize: [640, 480],
+ context: 'instream',
+ mimes: ['video/mp4'],
+ protocols: [1, 2, 3, 4, 5, 6, 7, 8],
+ playbackmethod: [2]
+ }
+ },
+ bids: [
+ {
+ bidder: "appnexus",
+ params: {
+ placementId: 13232361, /* Test placementId not for prod */
+ video: {
+ skippable: true,
+ playback_method: ["auto_play_sound_off"]
+ }
+ }
+ }
+ ]
+ },
+ options: {
+ cache: {
+ url: "https://prebid.adnxs.com/pbc/v1/cache"
+ },
+ enableSendAllBids: true
+ }
+ },
+ ima: {
+ resources: [
+ { src: "//imasdk.googleapis.com/js/sdkloader/ima3.js", type: "text/javascript", async: true },
+ { src: "${paths.plugins}ima/Ima.min.js", type: "text/javascript", async: true }
+ ],
+ adTagUrl: {
+ params: {
+ sz: "640x480",
+ iu: "/19968336/prebid_cache_video_adunit",
+ output: "vast",
+ correlator: "#{now}"
+ }
+ }
+ }
+ },
+ autoplay: 'muted',
+ media: {
+ src: "https://mdtp-a.akamaihd.net/customers/akamai/video/VfE.mp4"
+ }
+ };
+
+ akamai.amp.AMP.create('#akamai-player', config)
+ </script>
+ </body>
+
+{{ page.title }}
{{page.description }}
Important: This example uses a test version of Prebid.js hosted on our CDN that is not recommended for production use. It includes all available adapters. Production implementations should build from source or customize the build using the Download page to make sure only the necessary bidder adapters are included.
-
+
-
+
-
-
-
+
-
+
-
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Prebid Outstream Video Ad
Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?
Warning: Do not forget to exchange the placementId in the code examples with your own placementId!
Place this code in the page header.
@@ -93,7 +93,7 @@Place this code in the page header.
Place this code in the page body.
@@ -104,11 +104,13 @@Place this code in the page body.
</div>;
+
-
\ No newline at end of file
diff --git a/faq/faq.md b/faq/faq.md
index db5e22e002..de57ee611b 100644
--- a/faq/faq.md
+++ b/faq/faq.md
@@ -24,5 +24,5 @@ Check out the [Prebid.js FAQ](/dev-docs/faq.html). If you don't find what you ne
If you don't find answers to your questions in the [Prebid Server FAQ](/faq/prebid-server-faq.html), you can learn more here:
- [Troubleshooting](/troubleshooting/troubleshooting.html)
-- [Prebid Server Overview](/prebid-server/prebid-server-overview)
+- [Prebid Server Overview](/prebid-server/overview/prebid-server-overview.html)
- [Resources](/support/index.html)
diff --git a/faq/prebid-server-faq.md b/faq/prebid-server-faq.md
index 46063c8bc7..326b22aa11 100644
--- a/faq/prebid-server-faq.md
+++ b/faq/prebid-server-faq.md
@@ -20,7 +20,7 @@ Nope. The only approval process is a code review. There are separate instruction
- [Prebid Server - Go](https://github.com/prebid/prebid-server/blob/master/docs/developers/add-new-bidder.md)
- [Prebid Server - Java](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/developers/add-new-bidder.md)
-As for [membership](/partners/partners.html) in Prebid.org, that's entirely optional -- we'd be happy to have you join and participate in the various committees,
+As for [membership](https://prebid.org/membership/) in Prebid.org, that's entirely optional -- we'd be happy to have you join and participate in the various committees,
but it's not necessary for contributing code as a community member.
## How can I debug Prebid Server requests?
@@ -70,108 +70,39 @@ pbjs.setConfig({
```
## How do user ID cookies and ID syncing work in Prebid Server?
-There are 3 answers here. The easy answer is for requests coming into Prebid Server from the Prebid SDK - there's no concept of cookies there, so no syncing takes place in that scenario. ID in mobile is based on IDFA.
+For Prebid SDK there's no concept of cookies, so no syncing takes place in that scenario. ID in mobile is based on IDFA.
-For other scenarios, Prebid Server sets up and manages a multi-vendor ID match table in the `uids` cookie in the host company's
-domain. i.e. adnxs.com, rubiconproject.com, or whichever Prebid Server vendor you're utilizing. When the user has a `uids` cookie,
-Prebid Server parses it and passes the vendor-specific IDs to the relevant server-side bid adapters.
+For Prebid.js and AMP, see [Prebid Server User ID sync](/prebid-server/developers/pbs-cookie-sync.html)
-Syncing in the AMP scenario uses the [load-cookie.html](/dev-docs/show-prebid-ads-on-amp-pages.html#user-sync) file that's part of
-the Prebid Universal Creative package. When placed into an AMP-iframe, this file will call /cookie-sync and initiate a sync that
-creates or updates the `uids` cookie.
+## How does Prebid Server support privacy signals?
-The most common source of requests for Prebid Server is from Prebid.js in a scenario where the user doesn't have any cookies for the Prebid Server domain.
-1. The user loads a page with Prebid.js that's going to call Prebid Server -- i.e. the pub has set up s2sConfig.
-2. Immediately after confirming that s2sConfig is setup, Prebid.js calls Prebid Server's /cookie-sync endpoint to initiate syncing
-3. Prebid Server determines there is no `uids` cookie and responds to the browser with a list of pixel syncs for bidders that need to be synced.
-4. Prebid.js places all of the pixels on the page and initiates the auction.
-5. Because the syncs haven't completed, the auction call to Prebid Server will not contain the uids cookie.
-6. The first auction occurs without IDs
-7. At some point later, the pixels come back to Prebid Server through a /setuid redirect, setting (or updating) the uids cookie.
-8. The second page view will have the IDs available.
+See the [Prebid Server Privacy Feature Page](/prebid-server/features/pbs-privacy.html)
+## Do you have any best practices and/or tips to increase the user-match rate?
+For Prebid.js-initated server requests, we've found that cookie match rates are about what can be expected given the constraints:
-{: .alert.alert-info :}
-Note: the company that's hosting Prebid Server can configure it to read and utilize their exchange's
-native cookie. i.e. if you're using Rubicon Project's Prebid Server, it can read their 'khaos' cookie, and if you're using
-AppNexus' Prebid Server, it can read their 'uuid2' cookie. In other words, if the host company is an exchange and the user
-has the exchange cookie, the host company will have an ID one page-view sooner than the other bidders. This gives a slight edge to
-the hosting company in some scenarios, but it's technically unavoidable and better for both buyers and sellers to have one ID available rather than zero.
+- The [/cookie_sync](/prebid-server/developers/pbs-cookie-sync.html) process is initiated by Prebid.js the moment the [s2sConfig](https://docs.prebid.org/dev-docs/publisher-api-reference.html#setConfig-Server-to-Server) is parsed.
+- A limited number of bidders will be synced at once. PBS-Go will sync all the bidders listed in the `bidders` array. PBS-Java will sync all of them and possibly additional bidders. Publishers can change the number of syncs by specifying `userSyncLimit` on the s2sConfig.
+- Privacy settings (e.g. GDPR) can affect sync rate. e.g. If a lot of your traffic is in the EEA, it's going to be harder to set cookies.
-## How does Prebid Server support privay signals?
+[AMP](/prebid-server/use-cases/pbs-amp.html) is a different story. There are several things you should check:
-### Mobile 'Limit Ad Tracking' flag
+- First, the page has to include the [usersync amp-iframe](/dev-docs/show-prebid-ads-on-amp-pages.html#user-sync). This amp-iframe loads `load-cookie.html`.
+- Then AMP has to run this iframe. There are limitations as to where this amp-iframe can be on the page and possible how many amp-iframes there are on the page.
+- The [/cookie_sync](/prebid-server/developers/pbs-cookie-sync.html) call is initiated from `load-cookie.html`, but there are many adapters on the server side, and a limited number of them will be synced at once. Consider setting `max_sync_count` higher to get all bidders synced faster,
+- In a GDPR context, AMP doesn't supply the `gdprApplies` field. Prebid Server will determine for itself whether it can sync cookies, but it will not tell bidders whether the request is in GDPR-scope, so each bidder will have to determine scope for itself.
-If PBS receives 'device.lmt' flag in the OpenRTB request, it does the following anonymization:
+## How does the Notice URL work for Prebid Server?
-- Mask take off the last byte of the IPv4 address and the last 2 bytes of IPv6 addresses
-- Removes user.id and user.buyeruid
-- Removes the request.device.ifa attribute
-- Rounds the request.device.geo. {lat,lon} to two decimal places
+**Banner**
-### GDPR
+If a bidder adapter supplies 'nurl' in the bidResponse object, there are two paths:
-Prebid Server host companies and publishers have the ability to control the enforcement
-activities that take place.
+1) If it's cached in Prebid Cache (e.g. AMP and App), then the 'nurl' is cached along with the 'adm' and utilized by the Prebid Universal Creative.
+2) If it's not cached, the Prebid.js PrebidServerBidAdapter will append the 'nurl' to the bottom of the creative in a new div.
-The enforcement strategy changed significantly between TCF 1.1 and TCF 2.0. [TCF2](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20Consent%20string%20and%20vendor%20list%20formats%20v2.md) is a
-more nuanced and stricter policy.
-
-#### TCF 1.1
-
-If Prebid Server determines that the user is in GDPR scope and doesn't consent
-to *all* of the vendor's 'purposes' as declared in the Global Vendor List, it 'anonymizes'
-the request to the adapters:
-
-- Mask take off the last byte of the IPv4 address and the last 2 bytes of IPv6 addresses
-- Removes user.id and user.buyeruid
-- Removes the request.device.ifa attribute
-- Rounds the request.device.geo. {lat,lon} to two decimal places
-
-Full details are available [here](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/developers/PrebidServerJava_GDPR_Requirements.pdf).
-
-#### TCF 2.0
-
-If Prebid server determines the user is in GDPR scope, then consent is independently tested
-for each 'Purpose' with different consequences for each:
-
-{: .table .table-bordered .table-striped }
-| TCF Purpose | Consequence of Not Obtaining Consent |
-| ----------- | ------------------------------------ |
-| 1 - Device Access | Prevents one or more usersync activities for one or more vendors. |
-| 2 - Basic Ads | May result in skipping one or more bid adapters in the auction. |
-| 4 - Personalized Ads | May result in removing the userIds before calling one or more bid adapters. |
-| 7 - Measure Ad Performance | May result in skipping one or more analytics adapters. |
-| Special Feature 1 - Use precise geolocation data | May result in rounding lat/long values and IP address before sending to server-side adapters. |
-
-{: .alert.alert-danger :}
-Note: Support for TCF purposes other than Device Access is still under development and is
-expected to be released in May 2020.
-
-More details are available [here](https://docs.google.com/document/d/1fBRaodKifv1pYsWY3ia-9K96VHUjd8kKvxZlOsozm8E/edit#).
-
-### COPPA
-
-The [Children's Online Privacy Protection Act (COPPA)](https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/childrens-online-privacy-protection-rule) is a law in the US which imposes certain requirements on operators of websites or online services directed to children under 13 years of age, and on operators of other websites or online services that have actual knowledge that they are collecting personal information online from a child under 13 years of age.
-If `regs.coppa` is set to '1' on the OpenRTB request, the following anonymization actions take place before going to the adapters:
-
-- Removes all ID fields: device.ifa, device.macsha1, device.macmd5, device.dpidsha1, device.dpidmd5, device.didsha1, device.didmd5
-- Truncate ip field - remove lowest 8 bits.
-- Truncate ipv6 field - remove lowest 32 bits.
-- Remove geo.lat, geo.lon. geo.metro, geo.city, and geo.zip
-- Remove user.id, user.buyeruid, user.yob, and user.gender
-
-### CCPA / US-Privacy
-
-The [California Consumer Privacy Act (CCPA)](https://oag.ca.gov/privacy/ccpa) is a law in the US. which covers consumer rights relating to the access to, deletion of, and sharing of personal information that is collected by businesses.
-The IAB has generalized
-this state-specific rule into a [US Privacy](https://iabtechlab.com/standards/ccpa/) compliance framework.
-If `regs.ext.us_privacy` is parsed to find that the user has opted-out of a "sale",
-the following anonymization steps are taken:
-
-- Mask the last byte of the IPv4 address and the last 2 bytes of IPv6 addresses
-- Removes user.id and user.buyeruid
-- Removes the request.device.ifa attribute
-- Rounds the request.device.geo. {lat,lon} to two decimal places
+**Video**
+If a bidder adapter supplies 'nurl' in the bidResponse object instead of 'adm',
+this URL will be treated as the location of the VAST XML.
diff --git a/features/firstPartyData.md b/features/firstPartyData.md
new file mode 100644
index 0000000000..c1786fbfa2
--- /dev/null
+++ b/features/firstPartyData.md
@@ -0,0 +1,160 @@
+---
+layout: page_v2
+title: Prebid.js First Party Data
+description: First Party Data - Prebid.js
+sidebarType: 1
+---
+
+# First Party Data - Prebid.js
+{: .no_toc}
+
+* TOC
+{:toc}
+
+Prebid allows publishers to supply attributes related to their content
+and users, and to apply permissions so only certain bidders are allowed
+to access those attributes.
+
+{: .alert.alert-warning :}
+These conventions aren't implemented by all adapters. Please
+check with each of your bidders to make sure they're reading first
+party data from the standard Prebid locations.
+
+## How It Works
+
+Here's a summary of how first party data (FPD) works:
+
+{: .pb-lg-img :}
+
+This diagram shows a page that can provide:
+
+- Global context (site) data that applies to all AdUnits and all bidders
+- Global user data that applies to all AdUnits and all bidders
+- AdUnit-specific data that applies to all bidders
+- Bidder-specific context data that applies to all AdUnits
+- Bidder-specific user data that applies to all AdUnits
+
+## In-Page Examples
+
+The Prebid First Party Data JSON structure reflects the OpenRTB standard.
+Arbitrary values should go in fpd.context.data or fpd.user.data. Fields
+that are meant to be standard [OpenRTB 2.5](https://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf) values should be in fpd.context or fpd.user. Specfically, the standard values for `site` are: name, domain, cat, sectioncat, pagecat, page, ref, search, keywords. For `user` these are: yob, gender, keywords.
+
+{: .alert.alert-info :}
+'Context' corresponds to the OpenRTB 'site' object.
+
+### Supplying Global Data
+
+Here's how a publisher can let all bid adapters have access
+to first party data that might be useful in ad targeting:
+{% highlight js %}
+pbjs.setConfig({
+ fpd: {
+ context: {
+ keywords: "power tools", // keywords is a standard OpenRTB field
+ search: "drill", // same with search and content
+ content: { userrating: 4 },
+ data: {
+ pageType: "article",
+ category: "tools"
+ }
+ },
+ user: {
+ keywords: "a,b", // keywords is a standard OpenRTB field
+ data: {
+ registered: true,
+ interests: ["cars"]
+ }
+ }
+ }
+});
+{% endhighlight %}
+
+{: .alert.alert-warning :}
+Note that supplying first party **user** data may require special
+consent in certain regions. Prebid does **not** police the passing
+of user data as part of its GDPR or CCPA modules.
+
+### Supplying AdUnit-Specific Data
+
+If an attribute is specific to an AdUnit, it can be passed this way:
+
+{% highlight js %}
+pbjs.addAdUnits({
+ code: "test-div",
+ mediaTypes: {
+ banner: {
+ sizes: [[300,250]]
+ }
+ },
+ fpd: {
+ context: {
+ pbAdSlot: "homepage-top-rect",
+ adUnitSpecificContextAttribute: "123"
+ }
+ },
+ ...
+});
+{% endhighlight %}
+
+{: .alert.alert-info :}
+Prebid does not support AdUnit-Specific **user** data.
+
+### Supplying Bidder-Specific Data
+
+Use the [`setBidderConfig()`](/dev-docs/publisher-api-reference.html#module_pbjs.setBidderConfig) function to supply bidder-specific data. In this example, only bidderA and bidderB will get access to the supplied
+global data.
+
+{% highlight js %}
+pbjs.setBidderConfig({
+ bidders: ['bidderA', 'bidderB'],
+ config: {
+ fpd: {
+ context: {
+ data: {
+ pageType: "article",
+ category: "tools"
+ }
+ },
+ user: {
+ data: {
+ registered: true,
+ interests: ["cars"]
+ }
+ }
+ }
+ }
+});
+
+pbjs.setBidderConfig({ // different bidders can receive different data
+ bidders: ['bidderC'],
+ config: {
+ fpd: { ... }
+ }
+});
+{% endhighlight %}
+
+{: .alert.alert-info :}
+Applying permissions to AdUnit-specific First Party Data has
+to be done manually by using an event handler -- [pbjs.onEvent('beforeRequestBids', function())](/dev-docs/publisher-api-reference.html#module_pbjs.onEvent)
+
+## How Bid Adapters Should Read First Party Data
+
+To access global data, a Prebid.js bid adapter needs only to call [`getConfig()`](/dev-docs/publisher-api-reference.html#module_pbjs.getConfig), like this:
+
+{% highlight js %}
+config.getConfig('fpd.context'))
+config.getConfig('fpd.user'))
+{% endhighlight %}
+
+AdUnit-specific values must be parsed out of the AdUnit object.
+
+The assumption is that bid adapters will copy the values to the appropriate protocol location for their endpoint.
+
+See [Prebid Server First Party Data](/prebid-server/features/pbs-fpd.html) for a discussion of this feature for Prebid Server bid adapters.
+
+## Further Reading
+
+- The [Prebid.js Publisher API](/dev-docs/publisher-api-reference.html)
+- The [AdUnit Reference](/dev-docs/adunit-reference.html)
+- [Prebid Server First Party Data support](/prebid-server/features/pbs-fpd.html)
diff --git a/features/pbAdSlot.md b/features/pbAdSlot.md
index 8f891ee77f..8b72ebb6a7 100644
--- a/features/pbAdSlot.md
+++ b/features/pbAdSlot.md
@@ -34,7 +34,7 @@ Example page function:
// Use adunit.fpd.context.pbAdSlot if it exists. Otherwise, if the
// the adunit.code is a div ID, then look for a data-adslotid attribute, then look a matching slot in GPT
// Otherwise, just use the AdUnit.code
-var setPbAdSlot = function setPbAdSlot(adunits) {
+var setPbAdSlot = function setPbAdSlot(adUnits) {
// set pbAdSlot for all ad units
adUnits.forEach(function (adUnit) {
if (!adUnit.fpd) {
@@ -100,7 +100,7 @@ Some scenarios that could be supported:
## Prebid Server
-The OpenRTB location for the Prebid Ad Slot is `imp[].ext.context.data.adslot`:
+The OpenRTB location for the Prebid Ad Slot is `imp[].ext.context.data.pbadslot`:
- The Prebid SDK will place the value there.
- AMP Stored Requests should place the value there if desired.
diff --git a/formats/amp.md b/formats/amp.md
index 303e5abf83..484b14b34c 100644
--- a/formats/amp.md
+++ b/formats/amp.md
@@ -26,7 +26,7 @@ At a high level, setting up AMP pages for header bidding with Prebid has these s
## Developers
-+ [How Prebid on AMP works]({{site.baseurl}}/dev-docs/how-prebid-on-amp-works.html)
-+ [Prebid AMP Implementation Guide]({{site.baseurl}}/dev-docs/show-prebid-ads-on-amp-pages.html)
-+ [Prebid Server AMP endpoint documentation]({{site.baseurl}}/prebid-server/endpoints/openrtb2/amp.html)
++ [How Prebid on AMP works](/prebid-server/use-cases/pbs-amp.html)
++ [Prebid AMP Implementation Guide](/dev-docs/show-prebid-ads-on-amp-pages.html)
++ [Prebid Server AMP endpoint documentation](/prebid-server/endpoints/openrtb2/pbs-endpoint-amp.html)
diff --git a/formats/video.md b/formats/video.md
index 7ae5f3295d..8316a7a702 100644
--- a/formats/video.md
+++ b/formats/video.md
@@ -10,7 +10,7 @@ sidebarType: 6
# Prebid Video Ads
{:.no_toc}
-Video ads are supported by Prebid.js. Prebid Server support is coming soon.
+Video ads are supported by both Prebid.js and Prebid Server.
## Prebid.js
@@ -23,6 +23,8 @@ Video ads are supported by Prebid.js. Prebid Server support is coming soon.
- [Getting started with video](/prebid-video/video-getting-started.html)
- [Outstream video ads](/dev-docs/show-outstream-video-ads.html)
+- [Prebid Server video ads](/use-cases/pbs-pbjs.html)
+- [Prebid Server Long Form Video](r/use-cases/pbs-lfv.html)
### Prebid.js bid adapters that support instream and outstream video ads
diff --git a/guide.md b/guide.md
index 35e8d5a788..0cf5e9e7da 100644
--- a/guide.md
+++ b/guide.md
@@ -16,39 +16,39 @@ Sept 7, 2019
## Core Technologies
-The Prebid website is developed using [Jekyll](https://jekyllrb.com/), a static site generator which uses the following technology to create and style HTML pages.
+The Prebid website is developed using [Jekyll](https://jekyllrb.com/), a static site generator which uses the following technology to create and style HTML pages.
-**Markdown**: The majority of the content is written in Markdown language. Jekyll transform this into raw HTML.
+**Markdown**: The majority of the content is written in Markdown language. Jekyll transform this into raw HTML.
Learn more about Markdown](https://www.markdownguide.org/)
-**Bootstrap**: A CSS template for responsive site design. Bootstrap provides the base formatting for the site.
+**Bootstrap**: A CSS template for responsive site design. Bootstrap provides the base formatting for the site.
Learn more about [Bootstrap](https://getbootstrap.com/docs/4.1/getting-started/introduction/_)
-**Liquid**: A language created by Shopify to enable dynamic HTML creation.
+**Liquid**: A language created by Shopify to enable dynamic HTML creation.
Learn more about [Liquid](https://help.shopify.com/en/themes/liquid/basics)
-**Javascript**: A combination of Javascript libraries are utilized for the Prebid site to include [JQuery](https://jquery.com/) and [BootstrapJS](https://getbootstrap.com/docs/3.3/javascript/) as well as custom code.
+**Javascript**: A combination of Javascript libraries are utilized for the Prebid site to include [JQuery](https://jquery.com/) and [BootstrapJS](https://getbootstrap.com/docs/3.3/javascript/) as well as custom code.
-**CSS**: The site builds on the base Bootstrap template with custom CSS stored in the style.css file.
+**CSS**: The site builds on the base Bootstrap template with custom CSS stored in the style.css file.
***
## Site Config
-The _config.yml file (note underscore prefix) sets the base configuration for the site. Refer to [Jekyll](https://jekyllrb.com/docs/configuration/) documentation on which properties can be set in the _congig.yml file.
+The _config.yml file (note underscore prefix) sets the base configuration for the site. Refer to [Jekyll](https://jekyllrb.com/docs/configuration/) documentation on which properties can be set in the _congig.yml file.
***
## Directory Structure
-Jekyll requires adherence to a certain directory structure to generate the site. Directories prefixed with an underscore contain files used to construct the html files of the site.
+Jekyll requires adherence to a certain directory structure to generate the site. Directories prefixed with an underscore contain files used to construct the html files of the site.
### File Construction
-For the Prebid.org site the following directories are used:
+For the Prebid.org site the following directories are used:
**_data**
Jekyll was originally designed specifically for creation of blogging websites and not for dynamic, data-driven sites. However, by including the _data directory we can mimic a database structure to create a more robust site. Files in this directory can be saved in either *json*, *yml* or *csv* format. For Prebid.org they have been saved in *yml*.
@@ -67,32 +67,32 @@ The contents of these files are used throughout the Prebid.org site for dynamica
**_layouts**
-The layout directory contains HTML files that, in conjunction with CSS and JS files, format the layout of pages throughout the site.
+The layout directory contains HTML files that, in conjunction with CSS and JS files, format the layout of pages throughout the site.
**_includes**
-The includes directory contains HTML files that can be included within files, such as a file for the header and footer.
+The includes directory contains HTML files that can be included within files, such as a file for the header and footer.
**_posts**
-The posts directory contains the files that make up the content of the blog section of the site. Unlike the layouts and includes directories, the posts files are written in Markdown. A blog.html file in the layout directory provides the formatting for these Markdown files.
+The posts directory contains the files that make up the content of the blog section of the site. Unlike the layouts and includes directories, the posts files are written in Markdown. A blog.html file in the layout directory provides the formatting for these Markdown files.
-**_bidders**
+**_bidders**
-The bidders directory is not a standard part of Jekyll; it’s a special use directory specifically for the Prebid.org site. The files in this directory are used to construct the table of partners on the partners/partners.html page.
+The bidders directory is not a standard part of Jekyll; it’s a special use directory specifically for the Prebid.org site. The files in this directory are used to construct the table of partners on the partners/partners.html page.
**_sites**
-The sites directory is created by Jekyll. It contains the live site generated from the collected files and data listed above, combined with the CSS, JS and image assets and the Markdown files for individual pages.
+The sites directory is created by Jekyll. It contains the live site generated from the collected files and data listed above, combined with the CSS, JS and image assets and the Markdown files for individual pages.
***
## Assets
-The assets directory contains the CSS, Javascript, images and other assets used to create the site.
+The assets directory contains the CSS, Javascript, images and other assets used to create the site.
-The base CSS file used is Bootstrap (version 3.7.1) Custom CSS and modifications to Bootstrap classes are contained in the style.css file.
+The base CSS file used is Bootstrap (version 3.7.1) Custom CSS and modifications to Bootstrap classes are contained in the style.css file.
The JS directory contains the Javascript files required for the Prebid.org site. It includes JQuery and Bootstrap javascript frameworks as well as other third party libraries and custom javascript written specifically for the Prebid site. For JQuery and Bootstrap both the expanded and minified versions of the javascript files are included but only the minified files are linked from the site header.
@@ -104,34 +104,34 @@ The JS directory contains the Javascript files required for the Prebid.org site.
This file contains custom CSS classes and modifications to Bootstrap classes. The file is broken up into the various sections relating to navigaton, homepage and content pages.
*Navbar*
-The navbar class is a Bootstrap class. It controls the formatting of the top level navigation. Portions of it have been modified specifically for Prebid formatting.
+The navbar class is a Bootstrap class. It controls the formatting of the top level navigation. Portions of it have been modified specifically for Prebid formatting.
*Dropdown*
The dropdown class is a Boostrap class. It controls the formatting and functionality of the dropdown items of the top navigation. Portions of it have been modified specifically for Prebid formatting.
*Sidebar*
-The sidebar class is a Boostrap class. It controls the formatting and functionality of the dropdown items of the top navigation. Portions of it have been modified specifically for Prebid formatting. Additional custom classes have been created for specific formatting or functionality required by Prebid.
+The sidebar class is a Boostrap class. It controls the formatting and functionality of the dropdown items of the top navigation. Portions of it have been modified specifically for Prebid formatting. Additional custom classes have been created for specific formatting or functionality required by Prebid.
*Homepage*
-The classes in the homepage secton are custom classes created to format the top portion of the Prebid website homepage.
+The classes in the homepage secton are custom classes created to format the top portion of the Prebid website homepage.
*Container*
-A custom container class created for the Prebid website.
+A custom container class created for the Prebid website.
*Hover Effect*
-A custom series of classes created to control the formatting functionalty of the icon buttons on the Prebid website homepage.
+A custom series of classes created to control the formatting functionalty of the icon buttons on the Prebid website homepage.
*Message*
-A custom series of classes created to control the formatting of the message box on the Prebid website homepage.
+A custom series of classes created to control the formatting of the message box on the Prebid website homepage.
*Benfits*
-A custom series of classes created to control the formatting of the Benefits section of the Prebid website homepage.
+A custom series of classes created to control the formatting of the Benefits section of the Prebid website homepage.
*Carousel*
-The carousel class is a Bootstrap class. It controls the formatting and functionality of the carousel displayed on the homepage. Portions of it have been modified specifically for Prebid formatting. Additional custom classes have been created for specific formatting or functionality required by Prebid.
+The carousel class is a Bootstrap class. It controls the formatting and functionality of the carousel displayed on the homepage. Portions of it have been modified specifically for Prebid formatting. Additional custom classes have been created for specific formatting or functionality required by Prebid.
*Partners*
-A custom series of classes created to control the formatting of the [partners](/partners/partners.html) page.
+A custom series of classes created to control the formatting of the [partners](/partners/partners.html) page.
*Blog*
A custom series of classes created to control the formatting of the blog pages.
@@ -146,8 +146,8 @@ A custom class created to control the formatting of the footer.
The CSS file has multiple @media sections that handle the formatting of the website pages at specific screen widths. Those widths (in pixels) are:
-| Width | Device |
-| --- | --- |
+| Width | Device |
+| --- | --- |
| 1300 | Small browsers |
| 1024 | Large tablets e.g. iPadPro |
| 768 | Regular tablets e.g. iPads |
@@ -161,21 +161,21 @@ The CSS file has multiple @media sections that handle the formatting of the webs
## Data Models
-The data files are stored in the __data directory.
+The data files are stored in the __data directory.
-
+
### Partners
There are three locations important for adding a new partner onto the [Partners Page](/partners/partners.html)
@@ -346,7 +346,7 @@ The attributes in the Jekyll 'front matter' drive various behaviors and dynamic
| userIds | no | comma-separated list of supported user id modules | For display. |
| prebid_member | no | true or false, whether this company is a prebid.org member | For display. |
-The bidderCode, aliasCode, and prevBiddercode parameters bear some description.
+The bidderCode, aliasCode, and prevBiddercode parameters bear some description.
Some adapters have a longer bidderCode and a shorter bidderCode -- their adapter supports both (with the `alias` feature) but
there's only one documentation file and of course one PBJS adapter file. An relatively common scenario is when the company started off with a
long bidderCode, but found it awkward to set up ad server targeting variables because GAM limits you to 20 chars, which is easy to exceed
diff --git a/overview/analytics.md b/overview/analytics.md
index 87eadbe24b..022a2dbc77 100644
--- a/overview/analytics.md
+++ b/overview/analytics.md
@@ -30,6 +30,7 @@ There are several analytics adapter plugins available to track header bidding pe
| Media.net | Contact vendor| [Website](https://media.net) |
| PrebidAnalytics by Roxot | [Paid]( http://prebidanalytics.roxot.com/) | [Website](http://prebidanalytics.roxot.com/) |
| [Prebid Manager](https://prebidmanager.com/) | Free trial and free up to a certain volume. See [pricing](http://prebidmanager.com/#pricing) | [Website](http://prebidmanager.com/) |
+| [Pubperf](https://www.pubperf.com/) | Free trial. See [pricing](https://www.pubperf.com/pricing) | [Website](http://www.pubperf.com/) |
| [Pubstack](https://pubstack.io?source=prebid.org-analytics) ~ Real Time Analytics For Prebid and GAM | Start a free trial / Talk to the Sales Team | [Website](https://pubstack.io?source=prebid.org-analytics) |
| PubWise | Free & Paid, see [pricing](https://pubwise.io/pricing/) | [Website](https://www.pubwise.io/) |
| PulsePoint | Contact vendor | [Website](https://www.pulsepoint.com/) |
@@ -44,7 +45,7 @@ There are several analytics adapter plugins available to track header bidding pe
| Tercept Analytics | Contact vendor | [Website](https://www.tercept.com/)|
| ucfunnel | Contact vendor | [Website](https://www.ucfunnel.com/)|
| Yieldone | Contact vendor | [Website](https://www.platform-one.co.jp/) |
-| YuktaMedia Analytics | Contact vendor | [Website](https://yuktamedia.com/publishers/prebid/) |
+| YuktaOne Analytics by YuktaMedia | Freemium \| Contact vendor | [Website](https://yuktamedia.com/prebid/) |
None of these analytics options are endorsed or supported by Prebid.org.
diff --git a/overview/intro.md b/overview/intro.md
index dd4eb22fa0..5f623d4ff8 100644
--- a/overview/intro.md
+++ b/overview/intro.md
@@ -12,6 +12,9 @@ sidebarType: 0
## Overview
+{: .alert.alert-info :}
+If you're looking for a more high-level overview of Prebid.org, including product features, membership, events, and so on, visit [Prebid.org](https://prebid.org/).
+
Prebid is more than a product; it's a product suite, a community, and an organization.
- **Product Suite:** A free and open source suite of software products designed to enable publishers to implement header bidding on their websites and from within their apps. Our product line includes:
@@ -19,7 +22,7 @@ Prebid is more than a product; it's a product suite, a community, and an organiz
- **Prebid Server:** Provides a hosted or custom server-side solution for header bidding. Utilizing Prebid Server can reduce latency between bid request and ad selection, and speed the presentation of your site and ads.
- **Prebid Mobile:** Our native iOS and Android solutions to enable header bidding within a mobile app.
- **Community:** The developers that maintain and improve our products.
-- **Organization:** A collection of leaders within the ad tech industry that promotes our products, works with the ad tech community to expand the solutions our products can provide, and encourages the development of the platform.
+- **Organization:** A collection of leaders within the ad tech industry that promotes our products, works with the ad tech community to expand the solutions our products can provide, and encourages the development of the platform. For more about the organization, see the [Prebid.org](https://prebid.org/) website.
{% include alerts/alert_note.html content="Our flagship product, Prebid.js, is sometimes referred to as simply *Prebid*, but please be aware that the Prebid product line supports header bidding for web, AMP, and mobile apps, using both client- and server-side project components." %}
@@ -77,7 +80,7 @@ A simple Prebid.js process follows these steps:
Prebid Server provides a server-side solution to header bidding. Built on the same core principles as Prebid.js, our server solution can reduce latency and improve page load time.
Several Prebid.org members provide hosted solutions, enabling publishers to receive the benefits of server-side header bidding without the need to implement and manage the process themselves.
-If a publisher would prefer to implement their own solution, [source code](https://github.com/prebid/prebid-server) is available from our Github page and detailed instructions for configuring, deploying and testing your implementation can be found in the [Prebid Server section](/prebid-server/prebid-server-overview.html) of this site.
+If a publisher would prefer to implement their own solution, [source code](https://github.com/prebid/prebid-server) is available from our Github page and detailed instructions for configuring, deploying and testing your implementation can be found in the [Prebid Server section](/prebid-server/overview/prebid-server-overview.html) of this site.
**Prebid Server process**
@@ -112,7 +115,7 @@ The PBM header bidding process follows these steps:
## Further Reading
-+ [Prebid.js]({{site.baseurl}}/prebid/prebidjs.html)
-+ [Prebid Server]({{site.baseurl}}/dev-docs/get-started-with-prebid-server.html)
-+ [Prebid Mobile]({{site.baseurl}}/prebid-mobile/prebid-mobile.html)
-+ [Managed Prebid Solutions](/prebid/managed.html)
++ [Prebid.js](/prebid/prebidjs.html)
++ [Prebid Server](/prebid-server/overview/prebid-server-overview.html)
++ [Prebid Mobile](/prebid-mobile/prebid-mobile.html)
++ [Managed Prebid Solutions](https://prebid.org/product-suite/managed-services/)
diff --git a/overview/prebid-universal-creative.md b/overview/prebid-universal-creative.md
index 11f52b9084..77e1a99d17 100644
--- a/overview/prebid-universal-creative.md
+++ b/overview/prebid-universal-creative.md
@@ -8,24 +8,23 @@ nav_section: intro
Prebid Outstream Video Ad
+
-# Prebid Universal Creative Overview
+# Prebid Universal Creative
{:.no_toc}
The Prebid Universal Creative makes it easier for publishers to configure Prebid in their ad server. The Prebid Universal Creative provides a single creative configuration that can be used across many formats, platforms, devices, and ad servers.
-## Where to Use Prebid Universal Creative
+Specifically, you need to use the Universal Creative in these scenarios:
-The Prebid Universal Creative supports the following formats:
+- AMP and Prebid SDK (these require loading creatives from cache)
+- when you need to support safeframes
+- when you need to support native
-- Banner
-- Outstream video
-- SafeFrame/Non-SafeFrame
+If you only ever need to display non-safeframed banner and outstream-video creatives, you may use
+the original simple approach of just calling the Prebid.js `renderAd` function directly:
-The Prebid Universal Creative supports the following channels:
-
-- Web/mobile web
-- Mobile app
-- AMP pages
+```
+
+```
## How to Implement
diff --git a/overview/what-is-prebid-org.md b/overview/what-is-prebid-org.md
index 5a20989c39..f3577affc8 100644
--- a/overview/what-is-prebid-org.md
+++ b/overview/what-is-prebid-org.md
@@ -5,8 +5,6 @@ description: An overview of Prebid.org, the organization behind Prebid, and what
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.
@@ -15,10 +13,37 @@ Formed in September of 2017, Prebid.org is an independent organization designed
Prebid.org is open to all companies who are part of the programmatic ecosystem, from ad tech vendors to publishers and others. We believe strongly that by working together, we can do some great things in the industry.
-[Learn more](/partners/partners.html) about becoming a member of Prebid.org.
+[Learn more](https://prebid.org/membership/) about becoming a member of Prebid.org.
+
+## Operations
+Managed through Product Management Committees (PMCs)
+- Each PMC has a Chair and Members.
+- The Chair manages the PMC process and facilitates how the members contribute.
+- PMCs drive open source software development as well as events and activities.
+- To obtain more information about becoming a member of Prebid.org, email membership@prebid.org.
+
+## Focus on Value
+We focus on providing value-add to publishers and encourage the industry to deploy fair and efficient wrappers.
+Prebid takes two approaches to accomplish this:
+
+### Wrapper Code of Conduct
+Prebid members must agree to support the [Wrapper Code of Conduct](http://prebid.org/wrapper_code_of_conduct.html
+). This ensures that all wrapper providers are operating within the same principles.
+
+### Trademark
+We support wrappers based on Prebid technology with rights to the **Powered by Prebid** brand.
+
+## Current Projects
+All Prebid projects are open source and licensed under Apache License 2.0.
+- [Prebid.js](/prebid/prebidjs.html), including [Prebid Video](/prebid-video/video-overview.html) and [Prebid Native](/dev-docs/examples/native-ad-example.html): Header bidding on desktop and mobile web.
+- [Prebid Server](/prebid-server/overview/prebid-server-overview.html): Server-to-server header bidding.
+- [Prebid Mobile](/prebid-mobile/prebid-mobile.html): SDK for mobile app header bidding on iOS and Android. Works in conjunction with Prebid Server.
+- Continuing work on our tools, website, and documentation.
+Prebid welcomes any contribution on these projects!
+
Read more here:
-* [Prebid.org Members and Partners](/partners/partners.html)
+* [Prebid.org Members and Partners](https://prebid.org/membership/)
* [The Drum reporting on Prebid.org](https://www.thedrum.com/news/2017/09/11/appnexus-and-rubicon-project-launch-prebidorg-hailing-open-source-approach-header)
-* [Current members of Prebid.org]({{site.baseurl}}/partners/partners.html)
+* [Current members of Prebid.org](https://prebid.org/membership/member-directory/)
diff --git a/prebid-mobile/adops-line-item-setup-mopub.md b/prebid-mobile/adops-line-item-setup-mopub.md
index b8923eb326..cd5d578c87 100644
--- a/prebid-mobile/adops-line-item-setup-mopub.md
+++ b/prebid-mobile/adops-line-item-setup-mopub.md
@@ -11,12 +11,12 @@ sidebarType: 3
-# Step by Step Line Item Setup for MoPub
+# Step-by-Step Line Item Setup for MoPub
* TOC
{:toc }
-This page describes step by step how to set up Prebid Mobile line items for MoPub to serve ads on app with the Prebid SDK. It is using the Universal Prebid Creative.
+This page provides step-by-step instructions to set up Prebid Mobile line items for MoPub to serve ads on app with the Prebid SDK. It is using the Universal Prebid Creative.
## Step 1. Add a line item
diff --git a/prebid-mobile/adops-native-setup.md b/prebid-mobile/adops-native-setup.md
index b7f969488a..0c274fbb58 100644
--- a/prebid-mobile/adops-native-setup.md
+++ b/prebid-mobile/adops-native-setup.md
@@ -10,21 +10,19 @@ sidebarType: 3
Prebid Mobile enables publishers to display native ads within their apps. This page provides instructions for setting up ad ops for both Google Ad Manager and MoPub.
-* TOC
-{:toc }
## Google Ad Manager
-Follow these instructions to set up a Native ad with HTML and CSS. For more detailed information refer to the [Google Ad Manager documentation](https://support.google.com/admanager/answer/7661907).
+The following instructions are for setting up a Native ad with HTML and CSS. For more detailed information refer to the [Google Ad Manager documentation.](https://support.google.com/admanager/answer/7661907)
1. Sign in to your Google Ad Manager account.
-2. Click **Delivery > Native**.
-3. Click **New Native Ad**.
-4. Click **Select** in the "HTML & CSS editor" box. The *Define ad settings* page will appear. On this page, do the following to create your native ad template:
+2. Click Delivery > Native.
+3. Click New Native Ad.
+4. Click Select in the "HTML & CSS editor" box. The *Define ad settings* page will appear.
- a. Select an ad size of `fluid`. This tells Ad Manager to automatically size the ad to match available space.
+ a. Select an ad size of `fluid`. With the Fluid size, Ad Manager will automatically size the ad to match available space.
b. Select an existing format or create a new one. (Formats are the variables that make up the content of your ad.)
- c. Style your ad with HTML and CSS. (See the code sample below.)
+ c. Style your ad with HTML and CSS. (See code sample below)
Add your styles in the CSS tab in Ad Manager.
A native ad is made up of assets, image URL, titles, descriptions, icons, etc. that are plugged into the template we've just created. The template includes placeholder macros for those assets, and may be styled to match the form of the surrounding page.
@@ -35,8 +33,8 @@ Follow these instructions to set up a Native ad with HTML and CSS. For more deta
d. Set the targeting to default and save.
-5. [Create a line item](/prebid-mobile/adops-line-item-setup-dfp.html) targeting this ad unit and an `hb_pb price`; for expected creatives, put in the ad format you specified in step 4.b.
-6. Create a native creative using the native styles (and the ad format created/used with the native styles), associating it with the line item.
+5. [Create a line item](/prebid-mobile/adops-line-item-setup-dfp.html) targeting this ad unit and a `hb_pb price`, for expected creatives, put in the ad format in step 4.b.
+6. Create a native creative using the native styles (and the ad format created/used with the native styles), associating it with the line item
**Example** @@ -61,10 +59,10 @@ Follow these instructions to set up a Native ad with HTML and CSS. For more deta ## MoPub -These instructions describe how to add a Native ad with the MoPub SDK. For more detailed information review the MoPub Native ad documentation for [iOS](https://developers.mopub.com/publishers/ios/native/) and [Android](https://developers.mopub.com/publishers/android/native/). +The instructions below describe how to add a Native ad with the MoPub SDK. For more detailed information review the MoPub Native ad documentation for [iOS](https://developers.mopub.com/publishers/ios/native/) and [Android](https://developers.mopub.com/publishers/android/native/). - 1. Create a `Medium rectangle` Ad Unit. - 2. Create a non-guaranteed line item targeting this ad unit and an `hb_pb price`. + 1. Create a `Medium rectangle` Ad Unit + 2. Create a non-guaranteed line item targeting this ad unit and a `hb_pb price` 3. Create a creative with 300x250 Medium Rectangle format, choose HTML and put in the following code: ```html @@ -86,7 +84,7 @@ These instructions describe how to add a Native ad with the MoPub SDK. For more ``` {% capture noteAlert %} -Do not to check Mraid ad.z. +Note not to check Mraid ad.z {% endcapture %} {% include alerts/alert_note.html content=noteAlert %} diff --git a/prebid-mobile/adops-price-granularity.md b/prebid-mobile/adops-price-granularity.md index 1358b82b25..4d883ba8ff 100644 --- a/prebid-mobile/adops-price-granularity.md +++ b/prebid-mobile/adops-price-granularity.md @@ -1,26 +1,24 @@ --- layout: page_v2 -title: Price Granularity -description: Price granularity -pid: 2 -top_nav_section: prebid-mobile -nav_section: prebid-mobile-adops +title: Mobile Price Granularity +description: Mobile Price granularity sidebarType: 3 --- -# Price Granularity +# Prebid Mobile Price Granularity -With Prebid Mobile, you’ll need to setup line items to tell your ad server how much money the “bidder” demand is worth to you. This process is done via key-values. +With Prebid Mobile, you’ll need to setup line items to tell your ad server how much money the “bidder” demand is worth to you. This process is done with an ad server key-value pair: `hb_pb`, which stands for "header bidding price bucket". Example: - * Prebid Mobile is going to call Prebid Server which calls your bidders for their price, then passes it into your ad server on the query-string. You want to target this bid price with a line item that earns you the same amount if it serves. * If you had 1-line item for every bid at a penny granularity of $0.01, $0.02, $0.03, ..., 1.23, ..., $4.56 you’d need 1,000 line items just to represent bids from $0-$10. We call this the “Exact” granularity option. * Creating 1,000 line items can be a hassle, so publishers typically use price buckets to represent price ranges that matter. For example, you could group bids into 10 cent increments, so bids of $1.06 or $1.02 would be rounded down into a single price bucket of $1.00. +The SDK itself doesn't deal with granularity. Instead, these details are set up in Prebid Server and your ad server. The specific details about how to set up the price granularity will differ for each Prebid Mobile managed service company -- check with your provider to get details for their system. + ## Accepted values for price granularity + `"low"`: $0.50 increments, capped at $5 CPM @@ -28,6 +26,12 @@ Example: + `"high"`: $0.01 increments, capped at $20 CPM + `"auto"`: Applies a sliding scale to determine granularity as shown in the [Auto Granularity](#autoGranularityBucket) table below. + `"dense"`: Like `"auto"`, but the bid price granularity uses smaller increments, especially at lower CPMs. For details, see the [Dense Granularity](#denseGranularityBucket) table below. ++ `"custom"`: If none of the above apply, your service provider should provide a way to establish arbitrary price buckets. + +Notes: +- Banner and outstream video generally share the same ad server line items. +- PBS-Java support the "mediatypepricegranularity" enhancement, which lets you define different +granularities for banner and video @@ -54,10 +58,8 @@ Example: | CPM > $20 | Caps the price bucket at $20 | $24.82 floored to $20.00 | -{: .alert.alert-success :} -**Action Item:** Once you have decided the price granularity, go to Prebid Server [account page](https://prebid.adnxs.com/account/) to set the price granularity setting for your account. - +Please contact your Prebid Mobile host company for details about how to implement granularity. -The below screenshot is taken from the Prebid Server account page where you can choose your price granularity setting from the options. +## Further Reading -{: .pb-md-img :} +- [Prebid.js MediaTypePriceGranularity](/dev-docs/publisher-api-reference.html#setConfig-MediaType-Price-Granularity) diff --git a/prebid-mobile/adops-setup-full-screen-video-mopub.md b/prebid-mobile/adops-setup-full-screen-video-mopub.md new file mode 100644 index 0000000000..429c0488d3 --- /dev/null +++ b/prebid-mobile/adops-setup-full-screen-video-mopub.md @@ -0,0 +1,57 @@ +--- +layout: page_v2 +title: Setup Rewarded Video for MoPub +description: Setup Full Screen Video for MoPub +pid: 1 +top_nav_section: prebid-mobile +nav_section: prebid-mobile-adops +sidebarType: 3 +--- + +# Step-by-Step Line Item Setup for Full-screen Video on MoPub + +* TOC +{:toc } + +This page provides step-by-step instructions to set up full-screen video line items on MoPub to be used with the Prebid Mobile SDK. + +## Step 1. Create full screen adUnit +
+
+## Step 2. Add a line item
+In the *Add a Line Item* section:
+1. For the *Type and Priority* settings, select *Non-Guaranteed* as the type and set the priority to *12*. This ensures the line item will compete with all other demand.
+2. Set the Rate to the price you want to target.
+
+3. In the *Advanced Targeting* section, set the target for *Keywords* to `hb_pb:0.50`
+
+
+For each level of pricing granularity required, one line item/creative pairing will need to be set up.
+
+Line items must be set up to target custom keywords that include bid price information. The bid price keywords will contain how much the buyer bid on the impression.
+
+Prebid Mobile, by default, will send the highest bid price to MoPub using the keyword `hb_pb` but will also submit the key `hb_pb_BIDDERCODE` for each bidder. You can decide to create one set of line items for all bidders or one set of line items for each bidder.
+
+## Step 3. Add creatives to your line item
+Full-screen video creatives must have a *VAST tag* with the *Format* set to *Fullscreen* that includes the code below:
+```
+
+
+
+ MoPub
+
+
+
+```
+
+
+
+The `hb_uuid` variable value is the cache id that will load the ad markup from the bid stored in Prebid Cache. Within each line item, for each ad unit size, there should be one creative with this content.
+
+The XML can be constructed by providing the VAST tag URL as:
+`https://%%KEYWORD:hb_cache_host%%%%KEYWORD:hb_cache_path%%?uuid=%%KEYWORD:hb_uuid%%`
+
+## Step 4. Duplicate line items
+Duplicate your line items according to your [price granularity](/prebid-mobile/adops-price-granularity.html) setting.
diff --git a/prebid-mobile/adops-setup-rewarded-video-mopub.md b/prebid-mobile/adops-setup-rewarded-video-mopub.md
new file mode 100644
index 0000000000..839a8593e7
--- /dev/null
+++ b/prebid-mobile/adops-setup-rewarded-video-mopub.md
@@ -0,0 +1,55 @@
+---
+layout: page_v2
+title: Setup Rewarded Video for MoPub
+description: Setup Rewarded Video for MoPub
+pid: 1
+top_nav_section: prebid-mobile
+nav_section: prebid-mobile-adops
+sidebarType: 3
+---
+
+# Step-by-Step Line Item Setup for Rewarded Video on MoPub
+
+* TOC
+{:toc }
+
+This page provides step-by-step instructions to set up rewarded-video line items on MoPub to be used with the Prebid Mobile SDK.
+
+## Step 1. Add a line item
+
+ In the *Add a Line Item* section:
+ 1. For the *Type and Priority* settings, select *Non-Guaranteed* as the type and set the priority to *12*. This ensures the line item will compete with all other demand.
+ 2. Set the Rate to the price you want to target.
+
+ 3. In the *Advanced Targeting* section, set the target for *Keywords* to `hb_pb:0.50`
+
+
+For each level of pricing granularity required, one line item/creative pairing will need to be set up.
+
+Line items must be set up to target custom keywords that include bid price information. The bid price keywords will contain how much the buyer bid on the impression.
+
+Prebid Mobile, by default, will send the highest bid price to MoPub using the keyword `hb_pb` but will also submit the key `hb_pb_BIDDERCODE` for each bidder. You can decide to create one set of line items for all bidders or one set of line items for each bidder.
+
+## Step 2. Add creatives to your line item
+Rewarded video creatives must have a *VAST tag* with the *Format* set to *Rewarded Video* that includes the code below:
+
+```
+
+
+
+ MoPub
+
+
+
+```
+
+
+
+The `hb_uuid` variable value is the cache id that will load the ad markup from the bid stored in Prebid Cache. Within each line item, for each ad unit size, there should be one creative with this content.
+
+The XML can be constructed by providing the VAST tag URL as:
+`https://%%KEYWORD:hb_cache_host%%%%KEYWORD:hb_cache_path%%?uuid=%%KEYWORD:hb_uuid%%`
+
+## Step 3. Duplicate line items
+Duplicate your line items according to your [price granularity](/prebid-mobile/adops-price-granularity.html) setting.
diff --git a/prebid-mobile/dr-prebid.md b/prebid-mobile/dr-prebid.md
index d672e5b846..799f8dab86 100644
--- a/prebid-mobile/dr-prebid.md
+++ b/prebid-mobile/dr-prebid.md
@@ -55,6 +55,8 @@ The type of ad you want to test. This will be the ad type that is associated wit
Select from:
- *Banner*
- *Interstitial*
+- *Native*
+- *Video*
**Ad Size**
@@ -94,6 +96,10 @@ Select your Prebid Server host:
- *AppNexus*
- *Rubicon*
+- *Custom*
+
+**Custom Server Host**
+Provide the url of the custom hosted prebid server
**Account ID**
diff --git a/prebid-mobile/pbm-api/android/pbm-adunit-android.md b/prebid-mobile/pbm-api/android/pbm-adunit-android.md
index 5a2acdc87d..5bdddecf88 100755
--- a/prebid-mobile/pbm-api/android/pbm-adunit-android.md
+++ b/prebid-mobile/pbm-api/android/pbm-adunit-android.md
@@ -47,12 +47,62 @@ PB Ad Slot is an identifier tied to the placement the ad will be delivered in. T
Trigger a call to Prebid Server to retrieve demand for this Prebid Mobile ad unit.
+#### Mopub or GAM
+
+By default, Prebid SDK uses inflection to determine the publisher ad server, one of Mopub or Google Ad Manager (GAM), to convert Prebid's targeting keys (PBS bid keys, host and cache key) to trigger targeted line items. To render ads in ad servers other than Mopub or GAM, follow the instructions in the 3rd party ad server below.
+
+
**Parameters**
- `adObj`: This is the ad server request object (for [Google Ad Manager](https://developers.google.com/android/reference/com/google/android/gms/ads/doubleclick/PublisherAdRequest) and for [Mopub](https://developers.mopub.com/publishers/reference/android/MoPubView/)). If you do not wish to add any additional /custom key values to the ad server after the Prebid auction, pass `adObj` to the fetchDemand function, where Prebid SDK will set all the Prebid targeting keys as well as any keys added prior to auction
- As of Prebid SDK 1.7, a publisher can optionally pass the Google Ad Manager `builder` object of the [Google Ad Manager Mobile Ads SDK](https://developers.google.com/android/reference/com/google/android/gms/ads/doubleclick/PublisherAdRequest.Builder) to pass custom keys to Google Ad Manager after the Prebid Auction
- `onCompleteListener`: listener object
+#### 3rd Party Ad Server
+
+The default ad servers for Prebid's Mobile SDK are MoPub and GAM. The SDK can be expanded to include support for 3rd party ad servers through the fetchDemand function. This function returns the Prebid Server bidder key/values (targeting keys), which can then be passed to the ad server of choice.
+
+In this mode, the publisher will be responsible for the following actions:
+* Call fetchDemand with extended targetingDict callback
+* Retrieve targeting keys from extended fetchDemand function
+* Convert targeting keys into the format for your ad server
+* Pass converted keys to your ad server
+* Render ad with Prebid Universal Creative or custom renderer
+
+
+**Function Callbacks**
+
+* `ResultCode`: enum [result codes](https://docs.prebid.org/prebid-mobile/pbm-api/android/pbm-api-result-codes-android.html)
+* `unmodifiableMap`: [Prebid Server Response targeting keys](https://docs.prebid.org/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#targeting)
+
+
+```
+func fetchDemand(completion: @escaping(_ result: ResultCode, _ kvResultDict: [String : String]?) -> Void)
+```
+
+{: .alert.alert-warning :}
+unmodifiableMap is an immutable object. Attempting to modify at runtime will throw an UnsupportedOperationException error. This is to prevent accidental changes to the Prebid targeting keys. If there is a desire to update, create or remove a key, making a copy of unmodifiableMap is recommended before passing to the ad server.
+
+
+Example:
+
+```java
+func loadMPRewardedVideo() {
+private void loadMPRewardedVideo() {
+
+ adUnit.fetchDemand(new OnCompleteListener2() {
+ @Override
+ public void onComplete(ResultCode resultCode, Map unmodifiableMap) {
+ //copy of unmodifiableMap. It is an extra step to avoid runtime exception during changing unmodifiableMap
+ Map kvMap = new HashMap<>(unmodifiableMap);
+ String mpKeywords = Util.convertMapToMoPubKeywords(kvMap);
+ adServerRewardedVideoManager.RequestParameters parameters = new adServerRewardedVideoManager.RequestParameters(mpKeywords);
+ adServerObject.loadRewardedVideo(ADUNITID_REWARDED, parameters);
+ }
+ });
+
+}
+```
diff --git a/prebid-mobile/pbm-api/android/pbm-targeting-params-android.md b/prebid-mobile/pbm-api/android/pbm-targeting-params-android.md
index 57bd5862e7..f299f4ad67 100755
--- a/prebid-mobile/pbm-api/android/pbm-targeting-params-android.md
+++ b/prebid-mobile/pbm-api/android/pbm-targeting-params-android.md
@@ -113,6 +113,66 @@ storeUrl = TargetingParams.getStoreUrl();
TargetingParams.setStoreUrl(storeUrl);
```
+
+### Open Measurment SDK (OMSDK)
+
+OMSDK is designed to facilitate 3rd party viewability and verification measurement for ads served in mobile app enviroments. Prebid SDK will provide the signaling component to Bid Adapters, by way of Prebid Server, indicating the impression is elligible for OMSDK support. Prebid SDK does not currently integrate with OMSDK itself, instead it will rely on a publisher ad server to render viewability and verification measurement code.
+
+There three components to signaling support for OMSDK:
+* Partner Name
+* Partner Version
+* API code
+
+**Partner Name**
+
+This will be the [IAB OMSDK compliant partner name](https://complianceomsdkapi.iabtechlab.com/compliance/latest) responsible for integrating with the OMSDK spec. See below for configuration and examples
+
+#### omidPartnerName
+Open Measurement partner name.
+
+```
+TargetingParams.setOmidPartnerName()
+```
+
+Examples:
+
+Java
+```java
+TargetingParams.setOmidPartnerName("Google")
+```
+
+**Partner Version**
+
+The OMSDK version number the partner integrated with. See below for configuration and examples.
+
+
+#### omidPartnerVersion
+Partner's OMSDK version number implementation
+```
+TargetingParams.setOmidPartnerVersion();
+```
+
+Examples:
+
+Java
+```java
+TargetingParams.setOmidPartnerVersion("1.0");
+```
+
+**API Code**
+
+Per OpenRTB 2.5, support for OMSDK is signaled using the imp.[media type].api field represented in Prebid SDK withing each ad format type under the parameters object. Refer to the documentation of the respective ad unit class.
+
+Example:
+```
+BannerAdUnit bannerAdUnit = new BannerAdUnit("PREBID_SERVER_CONFIGURATION_ID", 300, 250);
+bannerAdUnit.setUserKeyword("my_key", "my_value");
+BannerBaseAdUnit.Parameters parameters = new BannerBaseAdUnit.Parameters();
+parameters.setApi(Arrays.asList(new Signals.Api(6, 7)));
+```
+
+
+
### Inventory (Context) Keywords
Context Keywords are a list of keywords about the app as referenced in OpenRTB 2.5 as app.keywords. Any keyword passed in the context keyword field may be passed to the buyer for targeting.
diff --git a/prebid-mobile/pbm-api/ios/pbm-adunit-ios.md b/prebid-mobile/pbm-api/ios/pbm-adunit-ios.md
index db5aea1f42..91c656bb60 100755
--- a/prebid-mobile/pbm-api/ios/pbm-adunit-ios.md
+++ b/prebid-mobile/pbm-api/ios/pbm-adunit-ios.md
@@ -53,14 +53,88 @@ PB Ad Slot is an identifier tied to the placement the ad will be delivered in. T
Trigger a call to Prebid Server to retrieve demand for this Prebid Mobile ad unit.
+#### Mopub or GAM
+
+By default, Prebid SDK uses inflection to determine the publisher ad server, one of Mopub or Google Ad Manager (GAM), to convert Prebid's targeting keys (PBS bid keys, host and cache key) to trigger targeted line items. To render ads in ad servers other than Mopub or GAM, use the next section's 3rd party ad server support feature.
+
**Parameters**
`adObject`: adServer object to which the Prebid keys need to be attached.
`completion`: Closure which receives one argument, the enum `ResultCode`. There is no return value.
-{% include alerts/alert_warning.html content="Ad Unit *User* keywords will be deprecated in favor of [targeting keywords](pbm-targeting-ios#user-keywords) for Prebid versions 1.2+. Support will continue for Ad Unit User Keywords as users migrate to targeting user keywords." %}
+#### 3rd Party Ad Server
+
+The default ad servers for Prebid's Mobile SDK are MoPub and GAM. The SDK can be expanded to include support for 3rd party ad servers through the fetchDemand function. This function returns the Prebid Server bidder key/values (targeting keys), which can then be passed to the ad server of choice.
+
+In this mode, the publisher will be responsible for the following actions:
+* Call fetchDemand with extended targetingDict callback
+* Retrieve targeting keys from extended fetchDemand function
+* Convert targeting keys into the format for your ad server
+* Pass converted keys to your ad server
+* Render ad with Prebid Universal Creative or custom renderer
+
+
+**Function callbacks**
+
+* `ResultCode`: enum [result codes](https://docs.prebid.org/prebid-mobile/pbm-api/ios/pbm-api-result-codes-ios.html)
+* `targetingDict`: [Prebid Server Response targeting keys](https://docs.prebid.org/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#targeting)
+
+
+```
+func fetchDemand(completion: @escaping(_ result: ResultCode, _ kvResultDict: [String : String]?) -> Void)
+```
+
+Examples:
+
+Swift
+```swift
+func loadBanner() {
+
+ //adUnit is BannerAdUnit type
+ adUnit.fetchDemand { [weak self] (resultCode: ResultCode, targetingDict: [String : String]?) in
+
+ self?.adServerRequest.customTargeting = targetingDict
+ self?.adServerBanner.load(self?.adServerRequest)
+ }
+}
+
+
+func loadRewardedVideo() {
+ let adUnit = RewardedVideoAdUnit(configId: "1001-1")
+ adUnit.fetchDemand { [weak self] (resultCode: ResultCode, targetingDict: [String : String]?) in
+
+ //Publisher should provide support for converting keys into format of 3rd party ad server and loading ads
+ let keywords = convertDictToAdServerKeywords(dict: targetingDict)
+ AdServerLoadAds.loadAd(withAdUnitID: "46d2ebb3ccd340b38580b5d3581c6434", keywords: keywords)
+ }
+}
+```
+
+Objective-C
+```objective-C
+-(void) loadAdServerBanner {
+
+ //adUnit is BannerAdUnit Type
+ [self.adUnit fetchDemandWithCompletion:^(enum ResultCode resultCode, NSDictionary * _Nullable targetingDict) {
+
+ [self.request setCustomTargeting:targetingDict];
+ [self.adServerView loadRequest:self.request];
+ }];
+}
+
+-(void) loadAdServerRewardedVideo {
+
+ //adUnit is RewardedVideoAdUnit Type
+ [adUnit fetchDemandWithCompletion:^(enum ResultCode resultCode, NSDictionary * _Nullable targetingDict) {
+
+ NSString *keywords = [Utils.shared convertDictToMoPubKeywordsWithDict:targetingDict];
+ [adServerRewardedVideo loadRewardedVideoAdWithAdUnitID:@"46d2ebb3ccd340b38580b5d3581c6434" keywords:keywords ];
+
+ }];
+}
+```
### addUserKeyword
diff --git a/prebid-mobile/pbm-api/ios/pbm-targeting-ios.md b/prebid-mobile/pbm-api/ios/pbm-targeting-ios.md
index deb7bbfa52..334587b370 100644
--- a/prebid-mobile/pbm-api/ios/pbm-targeting-ios.md
+++ b/prebid-mobile/pbm-api/ios/pbm-targeting-ios.md
@@ -151,6 +151,77 @@ Targeting.shared.itunesID
Targeting.shared.itunesID = itunesID
```
+### Open Measurment SDK (OMSDK)
+
+OMSDK is designed to facilitate 3rd party viewability and verification measurement for ads served in mobile app enviroments. Prebid SDK will provide the signaling component to Bid Adapters, by way of Prebid Server, indicating the impression is elligible for OMSDK support. Prebid SDK does not currently integrate with OMSDK itself, instead it will rely on a publisher ad server to render viewability and verification measurement code.
+
+There three components to signaling support for OMSDK:
+* Partner Name
+* Partner Version
+* API code
+
+**Partner Name**
+
+This will be the [IAB OMSDK compliant partner name](https://complianceomsdkapi.iabtechlab.com/compliance/latest) responsible for integrating with the OMSDK spec. See below for configuration and examples
+
+#### omidPartnerName
+Open Measurement partner name.
+
+```
+Targeting.shared.omidPartnerName
+```
+
+Examples:
+
+Swift
+```swift
+Targeting.shared.omidPartnerName = "Google"
+```
+
+Objective C
+```objective_c
+Targeting.shared.omidPartnerName = @"Google";
+```
+
+
+**Partner Version**
+
+The OMSDK version number the partner integrated with. See below for configuration and examples.
+
+
+#### omidPartnerVersion
+Partner's OMSDK version number implementation
+```
+Targeting.shared.omidPartnerVersion
+```
+
+Examples:
+
+Swift
+```swift
+Targeting.shared.omidPartnerVersion = "1.0"
+```
+
+Objective C
+```objective_c
+Targeting.shared.omidPartnerVersion = @"1.0";
+```
+
+**API Code**
+
+Per OpenRTB 2.5, support for OMSDK is signaled using the imp.[media type].api field represented in Prebid SDK withing each ad format type under the parameters object. Refer to the documentation of the respective ad unit class.
+
+Example:
+```
+let bannerUnit = BannerAdUnit(configId: "6ace8c7d-88c0-4623-8117-75bc3f0a2e45", size: CGSize(width: 300, height: 250))
+let parameters = BannerAdUnit.Parameters()
+parameters.api = [Signals.Api(7)]
+adUnit.setParameters(parameters);
+```
+
+
+
+
## Inventory (Context) Keywords
Context Keywords are a list of keywords about the app as referenced in OpenRTB 2.5 as app.keywords. Any keyword passed in the context keyword field may be passed to the buyer for targeting.
diff --git a/prebid-mobile/prebid-mobile-pbs.md b/prebid-mobile/prebid-mobile-pbs.md
index 976200eafc..2d1c97708e 100644
--- a/prebid-mobile/prebid-mobile-pbs.md
+++ b/prebid-mobile/prebid-mobile-pbs.md
@@ -26,7 +26,7 @@ If this is your first time working with header bidding, we recommend that you re
Before you begin using Prebid Mobile in your apps, you need to prepare your end-to-end system. The first step is to set up your Prebid Server host. Prebid Mobile works in conjunction with Prebid Server to request and receive bids. Here are the options:
-- Register with a [Prebid.org member that hosts Prebid Server](/prebid-server/hosted-servers.html). While you're waiting for your account, you can continue with the steps below.
+- Register with a [Prebid.org member that hosts Prebid Server](https://prebid.org/product-suite/managed-services/). While you're waiting for your account, you can continue with the steps below.
- Set up your own Prebid Server host
### Implement Your Own Prebid Server Host
@@ -50,7 +50,7 @@ After you've registered with your chosen Prebid Server host, you need to create
]
```
-The preceding is an example structure using AppNexus as the bidder. The parameters you need to set differ for each bidder. See [Bidder Parameters]({{site.github.url}}/dev-docs/prebid-server-bidders.html) for a full list of parameters for available Prebid Server bidders.
+The preceding is an example structure using AppNexus as the bidder. The parameters you need to set differ for each bidder. See [Bidder Parameters]({{site.github.url}}/prebid-server/developers/add-new-bidder-go.html) for a full list of parameters for available Prebid Server bidders.
## Developers - Using the SDK
diff --git a/prebid-mobile/privacy-regulation.md b/prebid-mobile/privacy-regulation.md
index d5f4d30669..c98333cf3c 100644
--- a/prebid-mobile/privacy-regulation.md
+++ b/prebid-mobile/privacy-regulation.md
@@ -36,12 +36,12 @@ sidebarType: 2
### Framework APIs
-Prebid Mobile provides two APIs for app publishers to use with the Framework. These APIs allow you to:
+Prebid Mobile provides three APIs for app publishers to use with the Framework. These APIs allow you to:
-- Define whether European privacy regulations should apply
+- Define whether the user is located in the European Economic Area (the "EEA") and if European privacy regulations should apply
- Set the [IAB Europe](https://www.iabeurope.eu/) (IAB) consent string
-This information will be persisted by Prebid Mobile and will be added to each ad call. Publishers/Consent Management Platforms (CMPs) are free to store these values in an `NSUserDefaults/SharedPreferences` interface (as defined by [Mobile In-App CMP API v1.0: Transparency & Consent Framework](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/Mobile%20In-App%20Consent%20APIs%20v1.0%20Final.md)) instead of passing them via the new APIs, and Prebid Mobile will read the values as a fallback.
+This information will be persisted by Prebid Mobile and will be added to each ad call to the demand partners. Publishers/Consent Management Platforms (CMPs) are free to store these values in an `NSUserDefaults/SharedPreferences` interface (as defined by [Mobile In-App CMP API v1.0: Transparency & Consent Framework](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/Mobile%20In-App%20Consent%20APIs%20v1.0%20Final.md)) instead of passing them via the new APIs, and Prebid Mobile will read the values as a fallback. The consent API's will check for TCF2.0 params (`IABTCF_gdprApplies` and `IABTCF_TCString`). If the parameters are not available they will fall back to TCF1.1 parameters (`IABConsent_SubjectToGDPR` and `IABConsent_ConsentString`)
Publishers are responsible for providing notice, transparency and choice and collecting consent from their users in accordance with [the Framework policies](https://www.iab.com/topics/consumer-privacy/gdpr/), either using their own CMP or working with a vendor.
@@ -53,6 +53,93 @@ All vendor SDKs (including mediation SDKs) are responsible for looking up approv
- [iOS - Targeting Parameters](/prebid-mobile/pbm-api/ios/pbm-targeting-ios.html)
- [Android - Targeting Parameters](/prebid-mobile/pbm-api/android/pbm-targeting-params-android.html)
+## Sending Device Information
+
+To ensure proper monetization and relevant targeting, the SDK should be enabled to send the device information. Setting the consentRequired and purposeConsents flag correctly will help ensure proper device information is sent. The table below provides information on:
+
+- Determining whether the device details will be passed or not.
+- Describing the actions taken for the different purposeConsents values in combination with consentRequired values.
+
+{: .table .table-bordered .table-striped }
+| | deviceAccessConsent= true | deviceAccessConsent= false | deviceAccessConsent= undefined |
+|---------------------|------------------------------|--------------------------------|---------------------------------------|
+|consentRequired=false
(gdprApplies = false)|The SDK will read and pass IDFA/AAID info to server. |The SDK will **not** read and pass IDFA/AAID info to server. | The SDK will read and pass IDFA/AAID info to server.| +|consentRequired=true
(gdprApplies = true)|The SDK will read and pass IDFA/AAID info to server. |The SDK will **not** read and pass IDFA/AAID info to server. | The SDK will **not** read and pass IDFA/AAID info to server.| +|consentRequired=undefined
(gdprApplies = undefined)|The SDK will read and pass IDFA/AAID info to server. |The SDK will **not** read and pass IDFA/AAID info to server. | The SDK will read and pass IDFA/AAID info to server.| + +{% capture codeNote %} + Publishers set the value of `gdprApplies` in `Targeting.shared.subjectToGDPR` and `purposeConsent` in `Targeting.shared.purposeConsents`. + + {% endcapture %} + +{% include /alerts/alert_important.html content=codeNote %} + +## Code Samples + +### iOS + + interface and provides a default implementation of its methods.
+
+This class provides a fixed algorithm with number of certain access points(so called hook-methods) that
+could be overridden to change the defaults to implement bidder-specific transformations.
+You can check what "hooks" are available and their description at the OpenrtbBidder class.
+
+NOTE: this model is not universal "all-in-one" solution as it encapsulates only the simple bidders' behaviour
+in order to ease the creation of lightweight bidders and get rid of boilerplate code.
+Bidders with a complicated request transformation logic would have to implement a Bidder interface and
+define their structure from scratch.
+
+#### Can Your Bidder use the OpenrtbBidder model?
+
+If your bidder is the one that:
+
+1. Send out a single request i.e. ones that just modify an incoming request and pass it on("one-to-one") OR
+send out one request per incoming request impression. Other "one-to-many" scenarios are nto supported;
+2. Have a constant endpoint url (no additional or optional path parameters or request parameters);
+3. Require a basic set of headers, which is "Content-type" : "application/json;charset=utf-8" and "Accept" : "application/json"
+4. Apply static changes to the outgoing request, e.g., setting a specific constant value or removing a certain request field;
+5. Modify impression or request values in a way that could be expressed by transformation mapping;
+6. Returns all bids present in Bid Response;
+7. Bid type and currency could by derived from bid itself and its corresponding impression;
+
+#### What Does the OpenRTB Bidder Implement?
+
+Constructing outgoing http request/s from incoming bid request:
+
+1. Validate incoming bid request, request impressions and impression extensions;
+2. Apply necessary changes or transformations to request and its impressions;
+3. Encode and return the modified outgoing request/s.
+
+Bidder response processing:
+
+1. Extract bids from response;
+2. Set each bid type and currency;
+
+### Bid Request Standards
+
+Prebid clients ([Prebid.js](/use-cases/pbs-pbjs.html), [Prebid SDK](/use-cases/pbs-sdk.html), and [AMP](/use-cases/pbs-amp.html)) pass a number of parameters
+that bid adapters should take into account:
+
+- Currency: The publisher's desired bid currency is in the OpenRTB `cur` field. I
+f your bid is in a different currency, you must set the bid currency in the respo
+nse.
+- Bid Floor: `imp[].bidfloor` and `imp[].bidfloorcur` - please make use of this v
+alue before responding with a bid.
+- First Party Data: bidders should look in these locations for first party data: `imp[].ext.context.data.*`, `site.ext.data.*`, `app.ext.data.*`, and `user.ext.data.*`.
+- Supply Chain: `source.ext.schain`
+- GDPR: `regs.ext.gdpr` and `user.ext.consent`
+- CCPA: `regs.ext.us_privacy`
+- COPPA: `regs.coppa`
+- Test: Bidders should be aware that the OpenRTB `test` flag indicates non-production traffic.
+
+### Bid Response Metadata
+
+In addition to the standard OpenRTB2.5 response fields, Prebid encourages bidders to
+provide additional metadata in their bid response:
+
+{% highlight js %}
+{
+ "seatbid": [{
+ "bid": [{
+ ...
+ "ext": {
+ "prebid": {
+ "meta": {
+ "networkId": NETWORK_ID,
+ "networkName": NETWORK_NAME
+ "agencyId": AGENCY_ID,
+ "agencyName": AGENCY_NAME,
+ "advertiserId": ADVERTISER_ID,
+ "advertiserName": ADVERTISER_NAME,
+ "advertiserDomains": [ARRAY_OF_ADVERTISER_DOMAINS]
+ "brandId": BRAND_ID,
+ "brandName": BRAND_NAME,
+ "primaryCatId": IAB_CATEGORY,
+ "secondaryCatIds": [ARRAY_OF_IAB_CATEGORIES],
+ }
+ }
+ }
+ }]
+ }]
+}
+{% endhighlight %}
+
+Notes:
+
+- `advertiserDomains` is the same as the OpenRTB 2.5 `bid.adomain` field but replicated here for downstream convenience
+- See the [Prebid.js Bidder Adapter](/dev-docs/bidder-adaptor.html) page for details about the requested values for each field.
+
+{: .alert.alert-info :}
+Please provide as much information as possible in the meta object. Publishers use this data for tracking down bad creatives and ad blocking. The advertiserDomains field is particularly useful. Some of these fields may become required in a future release.
+
+### BidResponse Requirements
+
+**Note**: In order to be part of the auction, all bids must include:
+
+- An ID
+- An ImpID which matches one of the `Imp[i].ID`s from the incoming `BidRequest`
+- A positive `Bid.Price`
+- A `Bid.CrID` which uniquely identifies the Creative in the bid.
+
+Bids which don't satisfy these standards will be filtered out before Prebid Server responds.
+
+## Integration
+
+After implementation you should integrate the Bidder with file:
+- `src/main/java/org/prebid/server/spring/config/bidder/{bidder}Configuration.java`
+
+It should be public class with Spring `@Configuration` annotation so that framework could pick it up.
+
+This file consists of three main parts:
+- the constant `BIDDER_NAME` with the name of your Bidder.
+- injected configuration properties (like `endpoint`, `usersyncUrl`, etc) needed for the Bidder's implementation.
+- declaration of `BidderDeps` bean combining _bidder name_, _Usersyncer_, _Adapter_ and _BidderRequester_ in one place as a single point-of-truth for using it in application.
+
+Also, you can add `@ConditionalOnProperty` annotation on configuration if bidder has no default properties.
+See `src/main/java/org/prebid/server/spring/config/bidder/FacebookConfiguration.java` as an example.
+
+## Test Your Bidder
+
+### Automated Tests
+
+Assume common rules to write unit tests from [here](unit-tests.md).
+
+Bidder tests live in the next files:
+- `src/test/java/org/prebid/server/bidder/{bidder}/{bidder}BidderTest.java`: unit tests for your Bidder implementation.
+- `src/test/java/org/prebid/server/bidder/{bidder}/{bidder}AdapterTest.java`: unit tests for your Adapter implementation.
+- `src/test/java/org/prebid/server/bidder/{bidder}/{bidder}UsersyncerTest.java`: unit tests for your Usersyncer implementation.
+
+Commonly you should write tests for covering:
+- creation of your Adapter/Bidder/Usersyncer implementations.
+- correct Bidder's params filling.
+- JSON parser errors handling.
+- specific cases for composing requests to exchange.
+- specific cases for processing responses from exchange.
+
+Do not forget to add your Bidder to `ApplicationTest.java` tests.
+
+We expect to see at least 90% code coverage on each bidder.
+
+### Manual Tests
+
+[Configure](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/config.md), [build](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/build.md) and [start](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/run.md) your server.
+
+Then `POST` an OpenRTB Request to `http://localhost:8000/openrtb2/auction`.
+
+If at least one `request.imp[i].ext.{bidder}` is defined in your Request, then your bidder should be called.
+
+To test user syncs, [call /setuid](/prebid-server/endpoints/pbs-endpoint-setuid.html) using the FamilyName of your Bidder.
+The next time you use `/openrtb2/auction`, the OpenRTB request sent to your Bidder should have
+`BidRequest.User.BuyerUID` with the value you saved.
+
+## Document your bidder
+
+There are two documents required before we’ll accept your pull request:
+
+1. Repo metadata - create a new file https://github.com/prebid/prebid-server/blob/master/static/bidder-info/BIDDERCODE.yaml based on one of the other ones there. Note that you must provide an email that’s not a single individual – we need robust maintainer contact info read by multiple people like “support@example.com”.
+1. User documentation - required to appear in the [Prebid Server adapters page](/dev-docs/pbs-bidders.html). If you already have one of these files from having a PBS-Go adapter, you're done. Otherwise, see [that page](/prebid-server/developers/add-new-bidder-go.html#document-your-adapter) for details.
+
+## Contribute
+
+Finally, [Contribute](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/contributing.md) your Bidder to the project.
diff --git a/prebid-server/developers/add-new-bidder.md b/prebid-server/developers/add-new-bidder.md
deleted file mode 100644
index 6784fce9e1..0000000000
--- a/prebid-server/developers/add-new-bidder.md
+++ /dev/null
@@ -1,166 +0,0 @@
----
-layout: page_v2
-sidebarType: 5
-title: Prebid Server | Developers | Adding a New Bidder
-
----
-
-# Adding a New Bidder
-
-{: .no_toc}
-
-* TOC
-{:toc }
-
-This document describes how to add a new Bidder to Prebid Server. Bidders are responsible for reaching out to your Server to fetch Bids.
-
-**NOTE**: To make everyone's lives easier, Bidders are expected to make Net bids (e.g. "If this ad wins, what will the publisher make?), not Gross ones.
-Publishers can correct for Gross bids anyway by setting [Bid Adjustments](../endpoints/openrtb2/auction.html#bid-adjustments) to account for fees.
-
-## Choose a Bidder Name
-
-This name must be unique. Existing BidderNames can be found [here](https://github.com/prebid/prebid-server/blob/master/openrtb_ext/bidders.go).
-
-Throughout the rest of this document, substitute `{bidder}` with the name you've chosen.
-
-## Define Your Bidder Params
-
-Bidders may define their own APIs for Publishers pass custom values. It is _strongly encouraged_ that these not
-duplicate values already present in the [OpenRTB 2.5 spec](https://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf).
-
-Publishers will send values for these parameters in `request.imp[i].ext.{bidder}` of
-[the Auction endpoint](../endpoints/openrtb2/auction.html). Prebid Server will preprocess these so that
-your bidder will access them at `request.imp[i].ext.bidder`--regardless of what your `{bidder}` name is.
-
-## Implement Your Bidder
-
-Bidder implementations are scattered throughout several files.
-
-- `adapters/{bidder}/{bidder}.go`: contains an implementation of [the Bidder interface](https://github.com/prebid/prebid-server/blob/master/adapters/bidder.go).
-- `openrtb_ext/imp_{bidder}.go`: contract classes for your Bidder's params.
-- `usersync/usersyncers/{bidder}.go`: A [Usersyncer](https://github.com/prebid/prebid-server/blob/master/usersync/usersync.go) which returns cookie sync info for your bidder.
-- `usersync/usersyncers/{bidder}_test.go`: Unit tests for your Usersyncer
-- `static/bidder-params/{bidder}.json`: A [draft-4 json-schema](https://spacetelescope.github.io/understanding-json-schema/) which [validates your Bidder's params](https://www.jsonschemavalidator.net/).
-- `static/bidder-info/{bidder}.yaml`: contains metadata (e.g. contact email, platform & media type support) about the adapter
-
-Bidder implementations may assume that any params have already been validated against the defined json-schema.
-
-### Bid Response Metadata
-
-In addition to the standard OpenRTB2.5 response fields, Prebid encourages bidders to
-provide additional metadata in their bid response:
-
-{% highlight js %}
-{
- "seatbid": [{
- "bid": [{
- ...
- "ext": {
- "prebid": {
- "meta": {
- "networkId": NETWORK_ID,
- "networkName": NETWORK_NAME
- "agencyId": AGENCY_ID,
- "agencyName": AGENCY_NAME,
- "advertiserId": ADVERTISER_ID,
- "advertiserName": ADVERTISER_NAME,
- "advertiserDomains": [ARRAY_OF_ADVERTISER_DOMAINS]
- "brandId": BRAND_ID,
- "brandName": BRAND_NAME,
- "primaryCatId": IAB_CATEGORY,
- "secondaryCatIds": [ARRAY_OF_IAB_CATEGORIES],
- }
- }
- }
- }]
- }]
-}
-{% endhighlight %}
-
-Notes:
-
-- `advertiserDomains` is the same as the OpenRTB 2.5 `bid.adomain` field but replicated here for downstream convenience
-- See the [Prebid.js Bidder Adapter](/dev-docs/bidder-adaptor.html) page for details about the requested values for each field.
-
-{: .alert.alert-info :}
-Please provide as much information as possible in the meta object. Publishers use this data for tracking down bad creatives and ad blocking. The advertiserDomains field is particularly useful. Some of these fields may become required in a future release.
-
-
-
-## Long-Form Video Support
-If long-form video will be supported ensure the bidder has the following:
-
-{: .table .table-bordered .table-striped }
-|Field |Type |Description
-|----------------|-------------------------------|-----------------------------|
-|bid.bidVideo.PrimaryCategory | string | The category for the bid. This should be able to be translated to Primary ad server format|
-|TypedBid.bid.Cat | []string | The category for the bid. Should be an array with length 1 containing the value in IAB format|
-|TypedBid.BidVideo.Duration | int | Ad duration in seconds|
-|TypedBid.bid.Price | float | Bid price|
-
-{% capture alertNote %}
-`bid.bidVideo.PrimaryCategory` or `TypedBid.bid.Cat` should be specified.
-{% endcapture %}
-
-{% include alerts/alert_note.html content=alertNote %}
-To learn more about IAB categories, refer site provided by adtagmacros.com: [IAB categories](https://adtagmacros.com/list-of-iab-categories-for-advertisement/)
-
-## Test Your Bidder
-
-### Automated Tests
-
-Bidder tests live in two files:
-
-- `adapters/{bidder}/{bidder}_test.go`: contains unit tests for your Bidder implementation.
-- `adapters/{bidder}/params_test.go`: contains unit tests for your Bidder's JSON Schema params.
-
-Since most Bidders communicate through HTTP using JSON bodies, you should
-use the [JSON-test utilities](https://github.com/prebid/prebid-server/blob/master/adapters/adapterstest/test_json.go).
-This comes with several benefits, which are described in the source code docs.
-
-If your HTTP requests don't use JSON, you'll need to write your tests in the code.
-We expect to see at least 90% code coverage on each Bidder.
-
-Bidders should also define an `adapters/{bidder}/{bidder}test/params/race/{mediaType}.json` file for any supported
-Media Types (banner, video, audio, or native). These files should contain a JSON object with all the bidder params
-(required & optional) which are expected in supporting that video type. This will be used in automated tests which
-check for race conditions across Bidders.
-
-### Manual Tests
-
-Build and start your server:
-
-```bash
-go build .
-./prebid-server
-```
-
-Then `POST` an OpenRTB Request to `https://localhost:8000/openrtb2/auction`.
-
-If at least one `request.imp[i].ext.{bidder}` is defined in your Request,
-then your bidder should be called.
-
-To test user syncs, [save a UID](../endpoints/setuid.html) using the FamilyName of your Usersyncer.
-The next time you use `/openrtb2/auction`, the OpenRTB request sent to your Bidder should have
-`BidRequest.User.BuyerUID` with the value you saved.
-
-## Add your Bidder to the Exchange
-
-Add a new [BidderName constant](https://github.com/prebid/prebid-server/blob/master/openrtb_ext/bidders.go) for your {bidder}.
-Update the [newAdapterMap function](https://github.com/prebid/prebid-server/blob/master/exchange/adapter_map.go) to make your Bidder available in [auctions](../endpoints/openrtb2/auction.html).
-Update the [NewSyncerMap function](https://github.com/prebid/prebid-server/blob/master/usersync/usersync.go) to make your Bidder available for [usersyncs](../endpoints/setuid.html).
-
-## Contribute
-
-Finally, [Contribute](https://github.com/prebid/prebid-server/blob/master/docs/developers/contributing.md) your Bidder to the project.
-
-## Server requirements
-
-**Note**: In order to be part of the auction, all bids must include:
-
-- An ID
-- An ImpID which matches one of the `Imp[i].ID`s from the incoming `BidRequest`
-- A positive `Bid.Price`
-- A `Bid.CrID` which uniquely identifies the Creative in the bid.
-
-Bids which don't satisfy these standards will be filtered out before Prebid Server responds.
diff --git a/prebid-server/developers/code-reviews.md b/prebid-server/developers/code-reviews.md
new file mode 100644
index 0000000000..10202d468a
--- /dev/null
+++ b/prebid-server/developers/code-reviews.md
@@ -0,0 +1,52 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Developers | Code Reviews
+
+---
+
+# Prebid Server Code Reviews
+
+## Standards
+Anyone is free to review and comment on any [open pull requests](https://github.com/prebid/prebid-server/pulls).
+for either [PBS-Go](https://github.com/prebid/prebid-server/pulls) or [PBS-Java](https://github.com/rubicon-project/prebid-server-java/pulls)
+
+All pull requests must be reviewed and approved by at least one core member before merge.
+
+Very small pull requests may be merged with just one review if they:
+
+1. Do not change the public API.
+2. Have low risk of bugs, in the opinion of the reviewer.
+3. Introduce no new features, or impact the code architecture.
+
+Larger pull requests must meet at least one of the following two additional requirements.
+
+1. Have a second approval from a core member
+2. Be open for 5 business days with no new changes requested.
+
+## Process
+
+New pull requests should be [assigned](https://help.github.com/articles/assigning-issues-and-pull-requests-to-other-github-users/) to a core member for review within 3 business days of being opened.
+That person should either approve the changes or request changes within 4 business days of being assigned.
+If they're too busy, they should assign it to someone else who can review it within that timeframe.
+
+If the changes are small, that member can merge the PR once the changes are complete. Otherwise, they should
+assign the pull request to another member for a second review.
+
+The pull request can then be merged whenever the second reviewer approves, or if 5 business days pass with no farther
+changes requested by anybody, whichever comes first.
+
+
+## Priorities
+
+Code reviews should focus on things which cannot be validated by machines.
+
+Some examples include:
+
+- Can we improve the user's experience in any way?
+- Have the relevant [docs](..) been added or updated? If not, add the `needs docs` label.
+- Do you believe that the code works by looking at the unit tests? If not, suggest more tests until you do!
+- Is the motivation behind these changes clear? If not, there must be [an issue](https://github.com/prebid/prebid-server/issues) explaining it. Are there better ways to achieve those goals?
+- Does the code use any global, mutable state? [Inject dependencies](https://en.wikipedia.org/wiki/Dependency_injection) instead!
+- Can the code be organized into smaller, more modular pieces?
+- Is there dead code which can be deleted? Or TODO comments which should be resolved?
diff --git a/prebid-server/developers/cookie-syncs.md b/prebid-server/developers/cookie-syncs.md
deleted file mode 100644
index 6067c1165e..0000000000
--- a/prebid-server/developers/cookie-syncs.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-layout: page_v2
-sidebarType: 5
-title: Prebid Server | Developers | Cookie Sync Technical Details
-
----
-# Cookie Sync Technical Details
-
-This document describes the mechancis of a Prebid Server cookie sync.
-
-## Motivation
-
-Many Bidders track users through Cookies. Since Bidders will generally serve ads from a different domain
-than where Prebid Server is hosted, those cookies must be consolidated under the Prebid Server domain so
-that they can be sent to each demand source in [/openrtb2/auction](../endpoints/openrtb2/auction.md) calls.
-
-## How to do it?
-
-Start by calling [`/cookie_sync`](../endpoints/cookieSync.md). For each element of `response.bidder_status`,
-call `GET element.usersync.url`. That endpoint should respond with a redirect which will complete the cookie sync.
-
-## Mechanics
-
-Bidders who support cookie syncs must implement an endpoint under their domain which accepts
-an encoded URI for redirects. For example:
-
-> GET some-bidder-domain.com/usersync-url?redirectUri=www.prebid-domain.com/setuid?bidder=somebidder&uid=$UID
-
-This example endpoint would URL-decode the `redirectUri` param to get `www.prebid-domain.com/setuid?bidder=somebidder&uid=$UID`.
-It would then replace the `$UID` macro with the user's ID from their cookie. Supposing this user's ID was "132",
-it would then return a redirect to `www.prebid-domain.com/setuid?bidder=somebidder&uid=132`.
-
-Prebid Server would then save this ID mapping of `somebidder: 132` under the cookie at `prebid-domain.com`.
-
-When the client then calls `www.prebid-domain.com/openrtb2/auction`, the ID for `somebidder` will be available in the Cookie.
-Prebid Server will then stick this into `request.user.buyeruid` in the OpenRTB request it sends to `somebidder`'s Bidder.
diff --git a/prebid-server/developers/coppa.md b/prebid-server/developers/coppa.md
deleted file mode 100644
index 6f3014da24..0000000000
--- a/prebid-server/developers/coppa.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-layout: page_v2
-sidebarType: 5
-title: Prebid Server | Developers | COPPA Support
-
----
-
-# COPPA Support
-
-The [Children's Online Privacy Protection Act (COPPA)](https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/childrens-online-privacy-protection-rule) is a law created to protect the privacy of children under 13. The Act was passed by the U.S. Congress in 1998 and took effect in April 2000. COPPA is managed by the Federal Trade Commission (FTC).
-
-Prebid-Server supports COPPA compliance by enabling developers to set a flag in the bid request. Developers can do so by setting:
-```javascript
- `request.regs.coppa`
-```
-Once the flag is set the bid request object is modified and the following changes occur:
-
-- All Device ID fields are removed: `device.ifa`, `device.macsha1`, `device.macmd5`, `device.dpidsha1`, `device.dpidmd5`, `device.didsha1`, `device.didmd5`
-- Truncate `device.ip` field - remove lowest 8 bits.
-- Truncate `device.ipv6` field - remove lowest 32 bits.
-- Remove `geo.lat`, `geo.lon`, `geo.metro`, `geo.city`, and `geo.zip`
-- Remove `user.id`, `user.buyeruid`, `user.yob`, and `user.gender`
-
-## Further Reading
-
-- [Prebid Server Overview](/prebid-server/prebid-server-overview.html)
-- [Prebid Server Default Request](/prebid-server/developers/default-request.html)
diff --git a/prebid-server/developers/currency-converter.md b/prebid-server/developers/currency-converter.md
deleted file mode 100644
index ca8c180e1b..0000000000
--- a/prebid-server/developers/currency-converter.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-layout: page_v2
-sidebarType: 5
-title: Prebid Server | Developers | Currency Converter
-
----
-
-**For the time being, currency conversion is not enabled, feature is still under dev (check #280).**
-
-# Currency Converter Mechanics
-
-Prebid server supports currency conversions when receiving bids.
-
-## Default currency
-
-The default currency is `USD`. It means that any bids coming without an explicit currency will be interpreted as being `USD`.
-
-## Setup
-
-By default, the currency converter uses https://cdn.jsdelivr.net/gh/prebid/currency-file@1/latest.json for currency conversion. This data is updated every 24 hours on prebid.org side.
-By default, currency conversions are updated from the endpoint every 30 minutes in prebid server.
-
-Default configuration:
-```
-v.SetDefault("currency_converter.fetch_url", "https://cdn.jsdelivr.net/gh/prebid/currency-file@1/latest.json")
-v.SetDefault("currency_converter.fetch_interval_seconds", 1800) // 30 minutes
-```
-
-This configuration can be changed:
-- currency_converter.fetch_url can be any URL exposing currency using the following JSON schema:
- ```
- {
- "dataAsOf":"2018-09-12",
- "conversions":{
- "USD":{
- "GBP":0.77208
- },
- "GBP":{
- "USD":1.2952
- }
- }
- }
- ```
-- currency_converter.fetch_interval_seconds can be anything from 0 to max int.
- **The currency conversion mechanism can be disable by setting it to 0, in this case, there will be no currency conversions at all and all bidders will need to provide bids as `USD`**
-
- ## Examples
-
- Here are couple examples showing the logic behind the currency converter:
-
-| Bidder bid price | Currency | Rate to USD | Rate converter is active | Converted bid price (USD) | Valid bid |
-| :--------------- | :------------ |:--------------| :------------------------| :-------------------------|:----------|
-| 1 | USD | 1 | YES | 1 | YES |
-| 1 | N/A | 1 | YES | 1 | YES |
-| 1 | USD | 1 | NO | 1 | YES |
-| 1 | EUR | 1.13 | YES | 1.13 | YES |
-| 1 | EUR | N/A | YES | N/A | NO |
-| 1 | EUR | 1.13 | NO | N/A | NO |
\ No newline at end of file
diff --git a/prebid-server/developers/gdpr.md b/prebid-server/developers/gdpr.md
deleted file mode 100644
index d2f2de8943..0000000000
--- a/prebid-server/developers/gdpr.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-layout: page_v2
-sidebarType: 5
-title: Prebid Server | Developers | GDPR Mechanics
-
----
-# GDPR Mechanics
-
-Within the framework of [GDPR](https://gdpr.eu/), Prebid Server behaves like a [data processor](https://gdpr.eu/recital-81-the-use-of-processors/).
-[Cookie syncs](/prebid-server/developers/cookie-syncs.html) save the user ID for each Bidder in the cookie, and each Bidder's ID is sent back to that Bidder during the [auction](/prebid-server/endpoints/openrtb2/auction.html).
-Prebid Server does not use this ID for any other reason.
-
-## IDs during Auction
-
-The [`/openrtb2/auction`](../endpoints/openrtb2/auction.md#gdpr) endpoint accepts `user.regs.gdpr` and `user.ext.consent` fields,
-[as recommended by the IAB](https://iabtechlab.com/wp-content/uploads/2018/02/OpenRTB_Advisory_GDPR_2018-02.pdf).
-
-## IDs during Cookie Syncs
-
-The [`POST /cookie_sync`](../endpoints/cookieSync.md) endpoint accepts `gdpr` and `gdpr_consent` properties in the request body.
-
-If the Prebid Server host company does not have consent to read/write cookies, `/cookie_sync` will return an empty response with no syncs.
-Otherwise, it will return a response limited to syncs for Bidders that have consent to read/write cookies.
-This limitation is in place for performance reasons; it results in fewer syncs called on the page, and their
-sync endpoints will almost certainly read from the cookie anyway.
-
-The [`/setuid`](../endpoints/setuid.md) endpoint accepts `gdpr` and `gdpr_consent` query params. This endpoint
-will no-op if the Prebid Server host company does not have consent to read/write cookies.
-
-## Handling the params
-
-For all endpoints, `gdpr` should be `1` if GDPR is in effect, `0` if not, and omitted if the caller isn't sure.
-`gdpr_consent` should be an [unpadded base64-URL](https://tools.ietf.org/html/rfc4648#page-7) encoded [Vendor Consent String](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/Consent%20string%20and%20vendor%20list%20formats%20v1.1%20Final.md#vendor-consent-string-format-).
-
-`gdpr_consent` is required if `gdpr` is `1` and ignored if `gdpr` is `0`. If `gdpr` is omitted, the Prebid Server
-host company can decide whether it behaves like a `1` or `0` through the [app configuration](https://github.com/prebid/prebid-server/blob/master/docs/developers/configuration.md).
-Callers are encouraged to send the `gdpr_consent` param if `gdpr` is omitted.
diff --git a/prebid-server/developers/installing-go.md b/prebid-server/developers/installing-go.md
new file mode 100644
index 0000000000..9531c00b72
--- /dev/null
+++ b/prebid-server/developers/installing-go.md
@@ -0,0 +1,66 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Versions | Go | Installing
+
+---
+
+# Installing PBS-Go
+
+## Installation
+
+First install [Go](https://golang.org/doc/install) version 1.13 or newer.
+
+Note that prebid-server is using [Go modules](https://blog.golang.org/using-go-modules).
+We officially support the most recent two major versions of the Go runtime. However, if you'd like to use a version <1.13 and are inside GOPATH `GO111MODULE` needs to be set to `GO111MODULE=on`.
+
+Download and prepare Prebid Server:
+
+```bash
+cd YOUR_DIRECTORY
+git clone https://github.com/prebid/prebid-server src/github.com/prebid/prebid-server
+cd src/github.com/prebid/prebid-server
+```
+
+Run the automated tests:
+
+```bash
+./validate.sh
+```
+
+Or just run the server locally:
+
+```bash
+go build .
+./prebid-server
+```
+
+Load the landing page in your browser at `http://localhost:8000/`.
+For the [full API reference](/prebid-server/endpoints/pbs-endpoint-overview.html)
+
+## Packaging
+
+Prebid Server is [packaged with Docker](https://www.docker.com/what-docker) and
+optimized to create [lightweight containers](https://blog.codeship.com/building-minimal-docker-containers-for-go-applications/).
+
+[Install Docker](https://www.docker.com/community-edition#/download) and build a container:
+
+```bash
+docker build -t prebid-server .
+```
+
+Test locally with:
+
+```bash
+docker run -p 8000:8000 -t prebid-server
+```
+
+The server can be reached at `http://localhost:8000`.
+
+## Contributing
+
+Want to [add a bidding adapter](https://github.com/prebid/prebid-server/blob/master/docs/developers/add-new-bidder.md)?
+
+Report bugs, request features, and suggest improvements [on Github](https://github.com/prebid/prebid-server/issues).
+
+Or better yet, [open a pull request](https://github.com/prebid/prebid-server/compare) with the changes you'd like to see.
diff --git a/prebid-server/developers/installing-java.md b/prebid-server/developers/installing-java.md
new file mode 100644
index 0000000000..c061e34204
--- /dev/null
+++ b/prebid-server/developers/installing-java.md
@@ -0,0 +1,31 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Versions | Java | Installing
+
+---
+
+# Installing PBS-Java
+
+## Development
+
+This project is built upon [Vert.x](http://vertx.io) to achieve high request throughput.
+We use [Maven](https://maven.apache.org) and attempt to introduce minimal dependencies.
+
+## Getting Started
+
+To start the Prebid Server you need to do the following steps:
+- Build all-in-one JAR file from sources as described in the [build documentation](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/build.md).
+- Check minimal needed configuration file `sample/prebid-config.yaml`.
+- Also, check the Data Cache settings file `sample/sample-app-settings.yaml`.
+For more information how to configure the server follow the [config documentation](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/config.md).
+
+- Run your server with:
+```
+java -jar target/prebid-server.jar --spring.config.additional-location=sample/prebid-config.yaml
+```
+For more information how to start the server follow the [run documentation](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/run.md).
+
+- To verify everything is OK go to `http://localhost:8080/status` and check response status is `200 OK`.
+
+More detailed project documentation can be found [here](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/TOC.md).
diff --git a/prebid-server/developers/pbs-bidder-info.md b/prebid-server/developers/pbs-bidder-info.md
deleted file mode 100644
index cb2db50152..0000000000
--- a/prebid-server/developers/pbs-bidder-info.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-layout: page_v2
-title: Prebid Server Bidders - Additional Info
-description: Additonal Information about Prebid Server Bidders
-pid: 1
-top_nav_section: prebid-server
-nav_section: prebid-server
-sidebarType: 5
----
-
-# Additional Bidder Information
-{:.no_toc}
-
-Some Prebid Server bidders require additional information for integration. For basic information and an up-to-date list of all Prebid Server bidders, see [Prebid Server Bidders]({{site.baseurl}}/dev-docs/prebid-server-bidders.html).
-
-* TOC
-{:toc}
-
-## AppNexus
-
-### Using Keywords
-
-The `keywords` [bidder param](https://github.com/prebid/prebid-server/blob/master/static/bidder-params/appnexus.json) will only work if
-it's enabled for your Account with AppNexus.
-
-**This permission is _distinct_ from the keywords feature used by Prebid.js.**
-
-If you want to enable AppNexus keywords, contact your account manager.
-
-## Audience Network
-
-### Mobile Bids
-
-Audience Network will not bid on requests made from device simulators. When testing for Mobile bids, you must make bid requests using a real device.
-
-## Beachfront
-
-To use the beachfront bidder you will need an appId from an exchange account on [https://platform.beachfront.io](https://platform.beachfront.io). For further information, please contact [adops@beachfront.com](mailto:adops@beachfront.com).
-
-## Rubicon
-
-Contact your Rubicon Project account manager to get set up with a login and cookie-sync URL to run your own Prebid Server.
-
-You will be given instructions, including the available endpoints.
-
-## Sovrn
-
-Sovrn supports two parameters to be present in the `ext` object of impressions sent to it:
-
-- `tagid`: A string containing the sovrn-specific id(s) for the publisher's ad tag(s) they would like to bid with. This is a required field.
-
-- `bidfloor`: The minimum acceptable bid, in CPM, using US Dollars. This is an optional field.
diff --git a/prebid-server/developers/pbs-build-an-analytics-adapter.md b/prebid-server/developers/pbs-build-an-analytics-adapter.md
new file mode 100644
index 0000000000..364b486b58
--- /dev/null
+++ b/prebid-server/developers/pbs-build-an-analytics-adapter.md
@@ -0,0 +1,75 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Developer | Build An Analytics Adapter
+
+---
+
+# Prebid Server - Building an Analytics Adapter
+{: .no_toc}
+
+There aren't any open sourced analytics adapters for Prebid Server,
+but there is an internal interface that host companies can use to
+integrate their own modules.
+
+Below is an outline of how it's done for both versions of the server.
+
+{: .alert.alert-warning :}
+Analytics adapters are subject to a number of specific technical rules. Please become familiar
+with the [module rules](/dev-docs/module-rules.html) that apply globally and to analytics adapters in particular.
+
+* TOC
+{:toc }
+
+## Adding an Analytics Adapter in PBS-Go
+
+1. Define config params
+
+Analytics modules are enabled through Viper [configuration](https://github.com/prebid/prebid-server/blob/master/docs/developers/configuration.md).
+You'll need to define any properties in config/config.go which are required for your module.
+
+2. Implement your module
+Your new module belongs in the analytics/{moduleName} package. It should implement the `PBSAnalyticsModule` interface from analytics/core.go
+
+3. Connect your Config to the Implementation
+The `NewPBSAnalytics()` function inside analytics/config/config.go instantiates Analytics modules using the app config. You'll need to update this to recognize your new module.
+
+### Example
+{:.no_toc}
+
+A simple [filesystem](https://github.com/prebid/prebid-server/tree/master/analytics/filesystem) analytics module is provided as an example. This module will log dummy messages to a file.
+
+It can be configured with:
+
+```
+analytics:
+ file:
+ filename: "path/to/file.log
+```
+Prebid Server will then write sample log messages to the file you provided.
+
+## Adding an Analytics Adapter in PBS-Java
+
+1. Define config params
+Analytics modules are enabled through the [Configuration](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/config.md).
+
+2. Implement your module
+Your new module org.prebid.server.analytics.{module}AnalyticsReporter needs to implement the org.prebid.server.analytics.AnalyticsReporter interface.
+
+3. Add your implementation to Spring Context
+In order to make Prebid Server aware of the new analytics module it needs to be added to the Spring Context in org.prebid.server.spring.config.AnalyticsConfiguration as a bean.
+
+### Example
+{:.no_toc}
+
+The [log module](https://github.com/rubicon-project/prebid-server-java/blob/master/src/main/java/org/prebid/server/analytics/LogAnalyticsReporter.java) is provided as an example. This module will write dummy messages to a log.
+
+It can be configured with:
+
+```
+analytics:
+ log:
+ enabled: true
+```
+
+Prebid Server will then write sample log messages to the log.
diff --git a/prebid-server/developers/pbs-cookie-sync.md b/prebid-server/developers/pbs-cookie-sync.md
new file mode 100644
index 0000000000..5f7de31627
--- /dev/null
+++ b/prebid-server/developers/pbs-cookie-sync.md
@@ -0,0 +1,116 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Developer | User ID Sync
+
+---
+
+# Prebid Server User ID Sync
+{: .no_toc}
+
+* TOC
+{:toc}
+
+## Motivation
+
+Many bidders track their bidder-specific user IDs through cookies. Since bidders will generally serve ads from a different domain
+than where Prebid Server is hosted, those cookies must be consolidated under the Prebid Server domain so
+that they can be sent to each demand source as part of auction calls.
+
+## How it Works
+
+Prebid Server stores bidder IDs in the `uids` cookie in the host domain. For example:
+
+```
+{"uids":{},"tempUIDs":{"adnxs":{"uid":"4722255122219375043","expires":"2020-07-30T22:10:28.961Z"},"triplelift":{"uid":"9328941297032053459","expires":"2020-07-30T22:10:33.496Z"},"yieldone":{"uid":"8c41c3b1-ce22-44fd-9bd7-454cd79e3c91","expires":"2020-07-30T22:10:33.229Z"},"ix":{"uid":"XlV6w9HM6LYAAHx2YJ4AAACZ&476","expires":"2020-07-30T22:10:31.916Z"},"yieldmo":{"uid":"ge515bd6c7da71cdc98a","expires":"2020-07-30T22:10:32.569Z"},"adform":{"uid":"1707054018971720697","expires":"2020-07-30T22:10:30.453Z"},"brightroll":{"uid":"y-S8Fq5QZ1lwWKPeXdoZ9vSeZx47maINFrJeY53pDtokA2FlaPmwvrJg--","expires":"2020-07-30T22:10:29.867Z"},"consumable":{"uid":"ue1-sb1-aa634f4b-d618-4378-b8c3-9baa56dcb91a","expires":"2020-07-30T22:10:28.07Z"},"pubmatic":{"uid":"2ECE1904-7EB2-4C38-98A4-38E97535AA9C","expires":"2020-07-30T22:10:27.559Z"},"rubicon":{"uid":"KACWYIER-P-59CH","expires":"2020-07-30T22:22:42.432Z"},"pulsepoint":{"uid":"dcxvyKqDV5VV","expires":"2020-07-30T22:10:26.915Z"},"sovrn":{"uid":"bad97f98b08c9204fe6b9826","expires":"2020-07-30T22:10:25.588Z"},"openx":{"uid":"f1f4ac13-99f8-46da-82f8-b52c29b378e0","expires":"2020-07-30T22:10:25.93Z"}},"bday":"2020-05-18T20:01:18.934Z"}
+```
+
+## Setting the uids Cookie
+
+### Setting the uids cookie from Prebid.js
+
+Here's how these IDs get placed in the cookie from Prebid.js:
+
+{:class="pb-lg-img"}
+
+
+1) Prebid.js starts by calling the Prebid Server [`/cookie_sync`](/prebid-server/endpoints/pbs-endpoint-cookieSync.html), letting it know which server-side bidders will be participating in the header bidding auction.
+
+```
+POST https://prebid-server.example.com/cookie_sync
+
+{"bidders":["bidderA","bidderB"], "gdpr":1, "gdpr_consent":"...", "us_privacy": "..."}
+```
+
+2) If privacy regulations allow, Prebid Server will look at the `uids` cookie in the host domain and determine whether any bidders are missing or need to be refreshed. It responds with an array of pixel syncs. e.g.
+
+```
+{"status":"ok","bidder_status":[{"bidder":"bidderA","no_cookie":true,"usersync":{"url":"//biddera.com/getuid?https%3A%2F%2Fprebid-server.example.com%2Fsetuid%3Fbidder%3DbidderA%26gdpr%3D%26gdpr_consent%3D%26us_privacy%3D%26uid%3D%24UID","type":"redirect","supportCORS":false}},{"bidder":"bidderB","no_cookie":true,"usersync":{"url":"https://bidderB.com/u/match?gdpr=&euconsent=&us_privacy=&redir=https%3A%2F%2Fprebid-server.example.com%2Fsetuid%3Fbidder%3DbidderB%26gdpr%3D%26gdpr_consent%3D%26us_privacy%3D%26uid%3D","type":"redirect","supportCORS":false}}]}
+```
+
+3) When it receives the response, Prebid.js loops through each element of `bidder_status[]`, dropping a pixel for each `bidder_status[].usersync.url`.
+
+4) The bidder-specific endpoints read the users's cookie for the bidder's domain and respond with a redirect back to Prebid Server's [`/setuid` endpoint](/prebid-server/endpoints/pbs-endpoint-setuid.html)
+
+5) When the browser receives this redirect, it contacts Prebid Server, which will once again check the privacy settings and will update the `uids` cookie if allowed.
+
+### Setting the uids cookie from AMP
+
+Cookie sync for AMP works in a way quite similar to Prebid.js.
+
+1) The Prebid Server hosting company places a modified version of the `load-cookie` script onto a CDN. This script is part of the [Prebid Universal Creative](https://github.com/prebid/prebid-universal-creative/blob/master/src/cookieSync.js) repo.
+
+Note that the only two values currently valid for 'endpoint' are 'appnexus' and 'rubicon' -- other host companies should update their copy to include their endpoint.
+
+
+2) The publisher places the 'load-cookie' script into the page:
+
+```
+
+
+```
+
+3) At runtime, the `load-cookie` script just calls the Prebid Server /cookie_sync endpoint. The rest works the same as described for Prebid.js above.
+
+
+## Bidder Instructions for Building a Sync Endpoint
+
+Bidders must implement an endpoint under their domain which accepts an encoded URI for redirects.
+This URL should be able to accept privacy parameters:
+
+- gdpr: if 0, declares this request isn't in GDPR scope. If 1, declares it is in scope. Otherwise indeterminate.
+- gdpr_consent: the TCF1 or TCF2 consent string. This is unpadded base64-URL encoded.
+- us_privacy: the IAB US Privacy string
+
+These values will be passed to your usersync endpoint. For example:
+
+Here's an example that shows the privacy macros used by PBS-Go:
+```
+GET some-bidder-domain.com/usersync-url?gdpr={%raw%}{{.GDPR}}&gdpr_consent={{.GDPRConsent}}&us_privacy={{.USPrivacy}}{%endraw%}&redirectUri=prebid-server.example.com%2Fsetuid%3Fbidder%3Dsomebidder%26uid%3D%24UID
+```
+PBS-Java uses slightly different macros:
+```
+GET some-bidder-domain.com/usersync-url?gdpr={%raw%}{{gdpr}}&gdpr_consent={{gdpr_consent}}&us_privacy={{us_privacy}}{%endraw%}&redirectUri=prebid-server.example.com%2Fsetuid%3Fbidder%3Dsomebidder%26uid%3D%24UID
+```
+In either case, you can receive the values on whatever query string parameters you'd like -- these are
+the macros you can use to define the values.
+
+This example endpoint would URL-decode the `redirectUri` param to get `prebid-server.example.com/setuid?bidder=somebidder&uid=$UID`.
+It would then replace the `$UID` macro with the user's ID from their cookie. Supposing this user's ID was "132",
+it would then return a redirect to `prebid-server.example.com/setuid?bidder=somebidder&uid=132`.
+
+Prebid Server would then save this ID mapping of `somebidder: 132` under the cookie at `prebid-domain.com`.
+
+When the client then calls `www.prebid-domain.com/openrtb2/auction`, the ID for `somebidder` will be available in the Cookie.
+Prebid Server will then stick this into `request.user.buyeruid` in the OpenRTB request it sends to `somebidder`'s Bidder.
+
+## Further Reading
+
+- [Prebid Server Overview](/prebid-server/overview/prebid-server-overview.html)
+- [Prebid.js s2sConfig](/dev-docs/publisher-api-reference.html#setConfig-Server-to-Server)
+- [Prebid AMP Implementation Guide](/dev-docs/show-prebid-ads-on-amp-pages.html)
diff --git a/prebid-server/endpoints/bidders/params.md b/prebid-server/endpoints/bidders/params.md
deleted file mode 100644
index 381dde8aca..0000000000
--- a/prebid-server/endpoints/bidders/params.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-layout: page_v2
-sidebarType: 5
-title: Prebid Server | Endpoints | Params
-
----
-
-## GET /bidders/params
-
-This endpoint gets information about all the custom bidders params that Prebid Server supports.
-
-### Returns
-
-A JSON object whose keys are bidder codes, and values are Draft 4 JSON schemas which describe that bidders' params.
-
-For example:
-
-```
-{
- "appnexus": { /* A json-schema describing AppNexus' bidder params */ },
- "rubicon": { /* A json-schema describing Rubicon's bidder params */ }
- ... all other bidders will have similar keys & values here ...
-}
-```
-
-The exact contents of the json-schema values can be found [here](https://github.com/prebid/prebid-server/tree/master/static).
-
-### See also
-
-- [JSON schema homepage](https://json-schema.org/specification-links.html#draft-4)
-- [Understanding JSON schema](https://spacetelescope.github.io/understanding-json-schema/)
diff --git a/prebid-server/endpoints/info/bidders.md b/prebid-server/endpoints/info/bidders.md
deleted file mode 100644
index 336d214f35..0000000000
--- a/prebid-server/endpoints/info/bidders.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-layout: page_v2
-sidebarType: 5
-title: Prebid Server | Endpoints | Get/info/bidders
-
----
-
-# Prebid Server Bidder List
-
-## `GET /info/bidders`
-
-This endpoint returns a list of Bidders supported by Prebid Server.
-These are the core values allowed to be used as `request.imp[i].ext.{bidder}`
-keys in [Auction](../openrtb2/auction.html) requests.
-
-For detailed info about a specific Bidder, use [`/info/bidders/{bidderName}`](./bidders/bidderName.html)
-
-### Sample Response
-
-This endpoint returns JSON like:
-
-```
-[
- "appnexus",
- "audienceNetwork",
- "pubmatic",
- "rubicon",
- "other-bidders-here"
-]
-```
diff --git a/prebid-server/endpoints/info/bidders/bidderName.md b/prebid-server/endpoints/info/bidders/bidderName.md
deleted file mode 100644
index 9472761981..0000000000
--- a/prebid-server/endpoints/info/bidders/bidderName.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-layout: page_v2
-sidebarType: 5
-title: Prebid Server | Endpoints | Bidder Name
-
----
-
-# Prebid Server Bidders
-
-## `GET /info/bidders/{bidderName}`
-
-This endpoint returns some metadata about the Bidder whose name is `{bidderName}`.
-Legal values for `{bidderName}` can be retrieved from the [/info/bidders](../bidders.html) endpoint.
-
-### Sample Response
-
-This endpoint returns JSON like:
-
-```
-{
- "maintainer": {
- "email": "info@prebid.org"
- },
- "capabilities": {
- "app": {
- "mediaTypes": [
- "banner",
- "native"
- ]
- },
- "site": {
- "mediaTypes": [
- "banner",
- "video",
- "native"
- ]
- }
- }
-}
-```
-
-The fields hold the following information:
-
-- `maintainer.email`: A contact email for the Bidder's maintainer. In general, Bidder bugs should be logged as [issues](https://github.com/prebid/prebid-server/issues)... but this contact email may be useful in case of emergency.
-- `capabilities.app.mediaTypes`: A list of media types this Bidder supports from Mobile Apps.
-- `capabilities.site.mediaTypes`: A list of media types this Bidder supports from Web pages.
-
-If `capabilities.app` or `capabilities.site` do not exist, then this Bidder does not support that platform.
-OpenRTB Requests which define a `request.app` or `request.site` property will fail if a
-`request.imp[i].ext.{bidderName}` exists for a Bidder which doesn't support them.
diff --git a/prebid-server/endpoints/info/pbs-endpoint-info.md b/prebid-server/endpoints/info/pbs-endpoint-info.md
new file mode 100644
index 0000000000..0b98700936
--- /dev/null
+++ b/prebid-server/endpoints/info/pbs-endpoint-info.md
@@ -0,0 +1,99 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Endpoints | Info
+
+---
+
+# Prebid Server | Endpoints | /info
+{:.no_toc}
+
+* TOC
+{:toc}
+
+## GET /info/bidders
+
+This endpoint returns a list of Bidders supported by Prebid Server.
+These are the core values allowed to be used as `request.imp[i].ext.{bidder}`
+keys in [Auction](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html) requests.
+
+For detailed info about a specific Bidder, use [`/info/bidders/{bidderName}`](./bidders/bidderName.html)
+
+### Sample Response
+{:.no_toc}
+
+This endpoint returns JSON like:
+
+```
+[
+ "appnexus",
+ "audienceNetwork",
+ "pubmatic",
+ "rubicon",
+ "other-bidders-here"
+]
+```
+
+## GET /info/bidders/{bidderName}
+
+This endpoint returns some metadata about the Bidder whose name is `{bidderName}`.
+Legal values for `{bidderName}` can be retrieved from the [/info/bidders](../bidders.html) endpoint.
+
+### Sample Response
+{:.no_toc}
+
+This endpoint returns JSON like:
+
+```
+{
+ "maintainer": {
+ "email": "info@prebid.org"
+ },
+ "capabilities": {
+ "app": {
+ "mediaTypes": [
+ "banner",
+ "native"
+ ]
+ },
+ "site": {
+ "mediaTypes": [
+ "banner",
+ "video",
+ "native"
+ ]
+ }
+ }
+}
+```
+
+The fields hold the following information:
+
+- `maintainer.email`: A contact email for the Bidder's maintainer. In general, Bidder bugs should be logged as [issues](https://github.com/prebid/prebid-server/issues)... but this contact email may be useful in case of emergency.
+- `capabilities.app.mediaTypes`: A list of media types this Bidder supports from Mobile Apps.
+- `capabilities.site.mediaTypes`: A list of media types this Bidder supports from Web pages.
+
+If `capabilities.app` or `capabilities.site` do not exist, then this Bidder does not support that platform.
+OpenRTB Requests which define a `request.app` or `request.site` property will fail if a
+`request.
+
+## GET /bidders/params
+
+This endpoint gets information about all the custom bidders params that Prebid Server supports.
+
+### Returns
+{:.no_toc}
+
+A JSON object whose keys are bidder codes, and values are Draft 4 JSON schemas which describe that bidders' params.
+
+For example:
+
+```
+{
+ "appnexus": { /* A json-schema describing AppNexus' bidder params */ },
+ "rubicon": { /* A json-schema describing Rubicon's bidder params */ }
+ ... all other bidders will have similar keys & values here ...
+}
+```
+
+The exact contents of the json-schema values can be found at [https://github.com/prebid/prebid-server/tree/master/static/bidder-params](https://github.com/prebid/prebid-server/tree/master/static/bidder-params)
diff --git a/prebid-server/endpoints/openrtb2/adpod/video.md b/prebid-server/endpoints/openrtb2/adpod/video.md
deleted file mode 100644
index f7c511e022..0000000000
--- a/prebid-server/endpoints/openrtb2/adpod/video.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-layout: page_v2
-sidebarType: 5
-title: Prebid Server | Endpoints | Video
-
----
-
-# Prebid Server Video Endpoint
-
-This document describes the behavior of the Prebid Server video endpoint in detail.
-
-## Video Endpoint
-
- `GET /openrtb2/video`
-
- **Parameters**
\ No newline at end of file
diff --git a/prebid-server/endpoints/openrtb2/auction.md b/prebid-server/endpoints/openrtb2/auction.md
deleted file mode 100644
index 80fb190d46..0000000000
--- a/prebid-server/endpoints/openrtb2/auction.md
+++ /dev/null
@@ -1,380 +0,0 @@
----
-layout: page_v2
-sidebarType: 5
-title: Prebid Server | Endpoints | Auction
-
----
-
-# Prebid Server Auction Endpoint
-
-This document describes the behavior of the Prebid Server auction endpoint, including:
-
-- Request/response formats
-- OpenRTB extensions
-- Debugging and performance tips
-- How user syncing works
-- Departures from OpenRTB
-
-## `POST /openrtb2/auction`
-
-This endpoint runs an auction with the given OpenRTB 2.5 bid request.
-
-### Sample request
-
-The [Prebid sample ad](/dev-docs/examples/basic-example.html) can be loaded from the JSON found in the [prebid-test-ad.json](https://github.com/prebid/prebid-server/blob/master/endpoints/openrtb2/sample-requests/valid-whole/exemplary/prebid-test-ad.json) file on the Prebid Server Github page. Other examples can be found in the [exemplary directory](https://github.com/prebid/prebid-server/blob/master/endpoints/openrtb2/sample-requests/valid-whole/exemplary) in the same Github repo.
-
-### Sample Response
-
-This endpoint will respond with either:
-
-- An OpenRTB 2.5 BidResponse, or
-- An HTTP 400 status code if the request is malformed
-
-A "hello world" response from the prebid sample ad request is shown below.
-
-```
-{
- "id": "some-request-id",
- "seatbid": [
- {
- "seat": "appnexus"
- "bid": [
- {
- "id": "4625436751433509010",
- "impid": "some-impression-id",
- "price": 0.5,
- "adm": "",
- "adid": "29681110",
- "adomain": [
- "appnexus.com"
- ],
- "iurl": "http://nym1-ib.adnxs.com/cr?id=29681110",
- "cid": "958",
- "crid": "29681110",
- "w": 300,
- "h": 250,
- "ext": {
- "bidder": {
- "appnexus": {
- "brand_id": 1,
- "auction_id": 6127490747252133000,
- "bidder_id": 2
- }
- }
- }
- }
- ]
- }
- ]
-}
-```
-
-### OpenRTB Extensions
-
-#### Conventions
-
-OpenRTB 2.5 permits exchanges to define their own extensions to any object from the spec.
-These fall under the `ext` property of JSON objects.
-
-If `ext` is defined on an object, Prebid Server uses the following conventions:
-
-1. `ext` in "Request objects" uses `ext.prebid` and/or `ext.{anyBidderCode}`.
-2. `ext` on "Response objects" uses `ext.prebid` and/or `ext.bidder`.
-The only exception here is the top-level `BidResponse`, because it's bidder-independent.
-
-`ext.{anyBidderCode}` and `ext.bidder` extensions are defined by bidders.
-`ext.prebid` extensions are defined by Prebid Server.
-
-Exceptions are made for DigiTrust and GDPR, so that we define `ext` according to the official recommendations.
-
-#### Bid Adjustments
-
-Bidders are encouraged to make [Net bids](../../developers/add-new-bidder.html). However, there's no way for Prebid to enforce this.
-If you find that some bidders use Gross bids, publishers can adjust for it with `request.ext.prebid.bidadjustmentfactors`:
-
-```
-{
- "appnexus: 0.8,
- "rubicon": 0.7
-}
-```
-
-This may also be useful for publishers who want to account for different discrepancies with different bidders.
-
-#### Targeting
-
-[Targeting]({{site.baseurl}}/overview/intro.html#how-does-prebid-work) refers to strings which are sent to the adserver to
-make header bidding possible.
-
-`request.ext.prebid.targeting` is an optional property which causes Prebid Server
-to set these params on the response at `response.seatbid[i].bid[j].ext.prebid.targeting`.
-
-**Request format** (optional param `request.ext.prebid.targeting`)
-
-```
-{
- "pricegranularity": {
- "precision": 2,
- "ranges": [
- {
- "max":20.00,
- "increment":0.10 // This is equivalent to the deprecated "pricegranularity": "medium"
- }
- ]
- },
- "includewinners": false // Optional param defaulting to true
- "includebidderkeys": false // Optional param defaulting to true
-}
-```
-The list of price granularity ranges must be given in order of increasing `max` values. If `precision` is omitted, it will default to `2`. The minimum of a range will be 0 or the previous `max`. Any cmp above the largest `max` will go in the `max` pricebucket.
-
-For backwards compatibility the following strings will also be allowed as price granularity definitions. There is no guarantee that these will be honored in the future. "One of ['low', 'med', 'high', 'auto', 'dense']" See [price granularity definitions]({{site.baseurl}}/prebid-mobile/adops-price-granularity.html)
-
-One of "includewinners" or "includebidderkeys" must be true (both default to true if unset). If both were false, then no targeting keys would be set, which is better configured by omitting targeting altogether.
-
-**Response format** (returned in `bid.ext.prebid.targeting`)
-
-```
-{
- "hb_bidder_{bidderName}": "The seatbid.seat which contains this bid",
- "hb_size_{bidderName}": "A string like '300x250' using bid.w and bid.h for this bid",
- "hb_pb_{bidderName}": "The bid.cpm, rounded down based on the price granularity."
-}
-```
-
-The winning bid for each `request.imp[i]` will also contain `hb_bidder`, `hb_size`, and `hb_pb`
-(with _no_ {bidderName} suffix). To prevent these keys, set `request.ext.prebid.targeting.includeWinners` to false.
-
-**NOTE**: Targeting keys are limited to 20 characters. If {bidderName} is too long, the returned key
-will be truncated to only include the first 20 characters.
-
-#### Cookie syncs
-
-Each Bidder should receive their own ID in the `request.user.buyeruid` property.
-Prebid Server has three ways to popualte this field. In order of priority:
-
-1. If the request payload contains `request.user.buyeruid`, then that value will be sent to all Bidders.
-In most cases, this is probably a bad idea.
-
-2. The request payload can store a `buyeruid` for each Bidder by defining `request.user.ext.prebid.buyeruids` like so:
-
-```
-{
- "appnexus": "some-appnexus-id",
- "rubicon": "some-rubicon-id"
-}
-```
-
-Prebid Server's core logic will preprocess the request so that each Bidder sees their own value in the `request.user.buyeruid` field.
-
-3. Prebid Server will use its Cookie to map IDs for each Bidder.
-
-If you're using [Prebid.js](https://github.com/prebid/Prebid.js), this is happening automatically.
-
-If you're using another client, you can populate the Cookie of the Prebid Server host with User IDs
-for each Bidder by using the `/cookie_sync` endpoint, and calling the URLs that it returns in the response.
-
-#### Native Request
-
-For each native request, the `assets` objects's `id` field must not be defined. Prebid Server will set this automatically, using the index of the asset in the array as the ID.
-
-
-#### Bidder Aliases
-
-Requests can define Bidder aliases if they want to refer to a Bidder by a separate name.
-This can be used to request bids from the same Bidder with different params. For example:
-
-```
-{
- "imp": [
- {
- "id": "some-impression-id",
- "video": {
- "mimes": ["video/mp4"]
- },
- "ext": {
- "appnexus: {
- "placementId": 123
- },
- "districtm": {
- "placementId": 456
- }
- }
- }
- ],
- "ext": {
- "prebid": {
- "aliases": {
- "districtm": "appnexus"
- }
- }
- }
-}
-```
-
-For all intents and purposes, the alias will be treated as another Bidder. This new Bidder will behave exactly
-like the original, except that the Response will contain seprate SeatBids, and any Targeting keys
-will be formed using the alias' name.
-
-If an alias overlaps with a core Bidder's name, then the alias will take precedence.
-This prevents breaking API changes as new Bidders are added to the project.
-
-For example, if the Request defines an alias like this:
-
-```
-{
- "aliases": {
- "appnexus": "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.
-
-#### Bidder Response Times
-
-`response.ext.responsetimemillis.{bidderName}` tells how long each bidder took to respond.
-These can help quantify the performance impact of "the slowest bidder."
-
-#### Bidder Errors
-
-`response.ext.errors.{bidderName}` contains messages which describe why a request may be "suboptimal".
-For example, suppose a `banner` and a `video` impression are offered to a bidder
-which only supports `banner`.
-
-In cases like these, the bidder can ignore the `video` impression and bid on the `banner` one.
-However, the publisher can improve performance by only offering impressions which the bidder supports.
-
-For example, a request may return this in `response.ext`
-
-```
-{
- "errors": {
- "appnexus": [
- {
- "code": 2,
- "message": "A hybrid Banner/Audio Imp was offered, but Appnexus doesn't support Audio."
- }
- ],
- "rubicon": [
- {
- "code": 1,
- "message": "The request exceeded the timeout allocated"
- }
- ]
- }
-}
-```
-
-The codes currently defined are:
-
-```
-0 NoErrorCode
-1 TimeoutCode
-2 BadInputCode
-3 BadServerResponseCode
-999 UnknownErrorCode
-```
-
-#### Debugging
-
-`response.ext.debug.httpcalls.{bidder}` will be populated **only if** `request.test` **was set to 1**.
-
-This contains info about every request and response sent by the bidder to its server.
-It is only returned on `test` bids for performance reasons, but may be useful during debugging.
-
-`response.ext.debug.resolvedrequest` will be populated **only if** `request.test` **was set to 1**.
-
-This contains the request after the resolution of stored requests and implicit information (e.g. site domain, device user agent).
-
-#### Stored Requests
-
-`request.imp[i].ext.prebid.storedrequest` incorporates a [Stored Request](../../developers/stored-requests.html) from the server.
-
-A typical `storedrequest` value looks like this:
-
-```
-{
- "id": "some-id"
-}
-```
-
-For more information, see the docs for [Stored Requests](../../developers/stored-requests.html).
-
-#### Cache bids
-
-Bids can be temporarily cached on the server by sending the following data as `request.ext.prebid.cache`:
-
-```
-{
- "bids": {},
- "vastxml": {}
-}
-```
-
-Both `bids` and `vastxml` are optional, but one of the two is required for cache to function.
-This property will have no effect unless `request.ext.prebid.targeting` is also set in the request.
-
-If `bids` is present, Prebid Server will make a _best effort_ to include these extra
-`bid.ext.prebid.targeting` keys:
-
-- `hb_cache_id`: On the highest overall Bid in each Imp.
-- `hb_cache_id_{bidderName}`: On the highest Bid from {bidderName} in each Imp.
-
-Clients _should not assume_ that these keys will exist, just because they were requested, though.
-If they exist, the value will be a UUID which can be used to fetch Bid JSON from [Prebid Cache](https://github.com/prebid/prebid-cache).
-They may not exist if the host company's cache is full, having connection problems, or other issues like that.
-
-If `vastxml` is present, PBS will try to add analogous keys `hb_uuid` and `hb_uuid_{bidderName}`.
-In addition to the caveats above, these will exist _only if the relevant Bids are for Video_.
-If they exist, the values can be used to fetch the bid's VAST XML from Prebid Cache directly.
-
-These options are mainly intended for certain limited Prebid Mobile setups, where bids cannot be cached client-side.
-
-#### GDPR
-
-Prebid Server supports the IAB's GDPR recommendations, which can be found [here](https://iabtechlab.com/wp-content/uploads/2018/02/OpenRTB_Advisory_GDPR_2018-02.pdf).
-
-This adds two optional properties:
-
-- `request.user.ext.consent`: Is the consent string required by the IAB standards.
-- `request.regs.ext.gdpr`: Is 0 if the caller believes that the user is *not* under GDPR, 1 if the user *is* under GDPR, and undefined if we're not certain.
-
-These fields will be forwarded to each Bidder, so they can decide how to process them.
-
-### OpenRTB Differences
-
-This section describes the ways in which Prebid Server **breaks** the OpenRTB spec.
-
-#### Allowed Bidders
-
-Prebid Server returns a 400 on requests which define `wseat` or `bseat`.
-We may add support for these in the future, if there's compelling need.
-
-Instead, an impression is only offered to a bidder if `bidrequest.imp[i].ext.{bidderName}` exists.
-
-This supports publishers who want to sell different impressions to different bidders.
-
-#### Deprecated Properties
-
-This endpoint returns a 400 if the request contains deprecated properties (e.g. `imp.wmin`, `imp.hmax`).
-
-The error message in the response should describe how to "fix" the request to make it legal.
-If the message is unclear, please [log an issue](https://github.com/prebid/prebid-server/issues)
-or [submit a pull request](https://github.com/prebid/prebid-server/pulls) to improve it.
-
-#### Determining Bid Security (http/https)
-
-In the OpenRTB spec, `request.imp[i].secure` says:
-
-> Flag to indicate if the impression requires secure HTTPS URL creative assets and markup,
-> where 0 = non-secure, 1 = secure. If omitted, the secure state is unknown, but non-secure
-> HTTP support can be assumed.
-
-In Prebid Server, an `https` request which does not define `secure` will be forwarded to Bidders with a `1`.
-Publishers who run `https` sites and want insecure ads can still set this to `0` explicitly.
-
-### See also
-
-- [The OpenRTB 2.5 spec](https://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf)
diff --git a/prebid-server/endpoints/openrtb2/amp.md b/prebid-server/endpoints/openrtb2/pbs-endpoint-amp.md
similarity index 61%
rename from prebid-server/endpoints/openrtb2/amp.md
rename to prebid-server/endpoints/openrtb2/pbs-endpoint-amp.md
index c20521725e..6dd89dfe28 100644
--- a/prebid-server/endpoints/openrtb2/amp.md
+++ b/prebid-server/endpoints/openrtb2/pbs-endpoint-amp.md
@@ -1,28 +1,38 @@
---
layout: page_v2
sidebarType: 5
-title: Prebid Server | Endpoints | AMP
+title: Prebid Server | Endpoints | OpenRTB2 | AMP
---
-# Prebid Server AMP Endpoint
+# Prebid Server | Endpoints | /openrtb2/amp
This document describes the behavior of the Prebid Server AMP endpoint in detail.
For a more general reference, see the [Prebid AMP Implementation Guide
]({{site.baseurl}}/dev-docs/show-prebid-ads-on-amp-pages.html).
-## AMP Endpoint
-
- `GET /openrtb2/amp?tag_id={ID}`
+## GET /openrtb2/amp
**Parameters**
{: .table .table-bordered .table-striped }
| Param | Scope | Type | Description |
| --- | --- | --- | --- |
-| tag_id | Required | `String` | The `tag_id` ID must reference a [Stored BidRequest]({{site.baseurl}}/prebid-server/developers/stored-requests.html). For a thorough description of bid request JSON, see the [/openrtb2/auction](./auction.html) docs. |
-
-To be compatible with AMP, this endpoint behaves slightly different from normal `/openrtb2/auction` requests.
+| tag_id | Required | `String` | The `tag_id` ID must reference a [Stored BidRequest]({{site.baseurl}}/prebid-server/features/pbs-storedreqs.html). For a thorough description of bid request JSON, see the [/openrtb2/auction](./auction.html) docs. |
+| w | recommended | `String` | Comes from the amp-ad.width attribute. The stored request may contain width already, but this parameter reflects what's actually in the page. It replaces imp.banner.format[0].w |
+| h | recommended | `String` | Comes from the amp-ad.height attribute. The stored request may contain height already, but this parameter reflects what's actually in the page. It replaces imp.banner.format[0].h |
+| ms | optional | `String` | Comes from the amp-ad.data-multi-size attribute. e.g. "970x90, 728x90". Sizes are parsed and added to imp.banner.format |
+| oh | optional | `String` | Comes from the amp-ad.data-override-height attribute. See below for details on size calculation. |
+| ow | optional | `String` | Comes from the amp-ad.data-override-width attribute. See below for details on size calculation. |
+| curl | optional | `String` | Added to OpenRTB request as site.page |
+| slot | optional | `String` | Added to OpenRTB request as imp[0].tagid |
+| timeout | optional | `String` | Added to OpenRTB request as tmax |
+| targeting | optional | `String` | First Party Data (PBS-Java only) |
+| gdpr_consent | optional | `String` | Consent string passed from CMP. Note this is used for both GDPR and CCPA. |
+| account | optional | `String` | Can be used to pass the Prebid-Server specific account ID. This is useful if `tag_id` parameters aren't unique across accounts. |
+| debug | optional | `integer` | If 1, returns additional debug info. |
+
+To be compatible with AMP, this endpoint behaves different from normal `/openrtb2/auction` requests.
1. The Stored `request.imp` data must have exactly one element.
2. `request.imp[0].secure` will be always be set to `1`, because AMP requires all content to be `https`.
@@ -70,6 +80,84 @@ An example Stored Request is given below:
}
```
+#### First Party Data
+
+(Currently only supported in PBS-Java)
+
+You can send first party data into an AMP request by encoding a JSON
+targeting block like this:
+
+```
+GET /openrtb2/amp?tag_id=7470-Eater_AMP_ROS_ATF&w=300&h=250&ow=&oh=&ms=&slot=%2F172968584%2Feater%2Fgoogle%2Famp_med_rec_02&targeting=%7B%22site%22%3A%7B%22keywords%22%3A%22article%2C%20las%20vegas%22%2C%22cat%22%3A%7B%22blah%22%3A%221%22%7D%2C%22other-attribute%22%3A%22other-value%22%2C%22ext%22%3A%7B%22data%22%3A%7B%22entry_group%22%3A%5B%22front-page%22%2C%22featured-stories%22%5D%2C%22page_type%22%3A%22AMP%22%7D%7D%7D%2C%22user%22%3A%7B%22gender%22%3A%22m%22%7D%2C%22bidders%22%3A%5B%22rubicon%22%2C%22appnexus%22%5D%2C%22keywords%22%3A%22las%20vegas%20hospitality%20employees%22%2C%22foo%22%3A%7B%22bar%22%3A%22baz%22%7D%7D...
+```
+
+Prebid Server will expand the targeting value and merge the data into
+the resulting OpenRTB JSON for the appropriate bidders.
+
+For example, if this AMP targeting is provided:
+```
+{
+ "site": {
+ "keywords": "article, las vegas", // (1)
+ "cat": { "blah": "1" }, // invalid data type, will be dropped
+ "other-attribute": "other-value", // not openrtb2, remove
+ "ext": {
+ "data": {
+ "entry_group": ["front-page","featured-stories"], // (4)
+ "page_type": "AMP" // (5)
+ }
+ }
+ },
+ "user": {
+ "gender": "m", // (2)
+ },
+ "bidders": ["rubicon","appnexus"], // (3)
+ "keywords": "las vegas hospitality employees", // (6)
+ "foo": { // (7)
+ "bar": "baz"
+ }
+}
+```
+The numbered elements from the raw targeting data above are merged into the resulting OpenRTB like this:
+```
+{
+ "imp": [...],
+ "site": {
+ "publisher": { … },
+ "keywords": "article, las vegas" // (1)
+ "ext":{
+ "data": {
+ "entry_group": ["front-page","featured-stories"], // (4)
+ "page_type": "AMP" // (5)
+ }
+ }
+ },
+ "user": {
+ "gender": "m" // (2)
+ },
+ "ext": {
+ "prebid": {
+ "data": {
+ "bidders": ["rubicon",appnexus"], // (3)
+ }
+ }
+ },
+ "imp": [
+ ...
+ "ext": {
+ "context": {
+ "data": {
+ "keywords": "las vegas hospitality employees", // (6)
+ "foo": { // (7)
+ "bar": "baz"
+ }
+ }
+ }
+ }
+ ]
+}
+```
+
### Response
A sample response payload looks like this:
@@ -113,7 +201,7 @@ If any errors were generated they will appear within `response.ext.errors.{bidd
999 UnknownErrorCode
```
-See the [/openrtb2/auction endpoint](/prebid-server/endpoints/openrtb2/auction.html) for a description of some common OpenRTB errors. The following is a list of AMP specific errors that could be returned:
+See the [/openrtb2/auction endpoint](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html) for a description of some common OpenRTB errors. The following is a list of AMP specific errors that could be returned:
{: .table .table-bordered .table-striped }
| Task | Code | Message | Action |
@@ -138,19 +226,9 @@ The following errors can occur when loading a stored OpenRTB request for an inco
-### Query Parameters
+### Query Parameter Details
-This endpoint supports the following query parameters:
-
-1. `h` - `amp-ad` `height`
-2. `w` - `amp-ad` `width`
-3. `oh` - `amp-ad` `data-override-height`
-4. `ow` - `amp-ad` `data-override-width`
-5. `ms` - `amp-ad` `data-multi-size`
-6. `curl` - the canonical URL of the page
-7. `timeout` - the publisher-specified timeout for the RTC callout
- A configuration option `amp_timeout_adjustment_ms` may be set to account for estimated latency so that Prebid Server can handle timeouts from adapters and respond to the AMP RTC request before it times out.
-8. `debug` - When set to `1`, the respones will contain extra info for debugging.
Ensure that the amp-ad component was imported in the header.
@@ -158,24 +236,22 @@ Ensure that the amp-ad component was imported in the header.
```
-This script provides code libraries that will convert the `` properties to the endpoint query parameters. In the most basic usage pass `width` and `height` as well as `type` and a `rtc-config`. The `type` value is the ad network you will be using. The `rtc-config` is used to pass JSON configuration to the Prebid Server, which handles the communication with [AMP RTC](https://medium.com/ampfuel/better-than-header-bidding-amp-rtc-fc54e80f3999). Vendors is an object that defines any vendors that will be receiving the RTC callout. In this example, the required parameter `tag_id` will receive the `PLACEMENT_ID` value.
+This script provides code libraries that will convert the `` properties to the endpoint query parameters. In the most basic usage pass `width` and `height` as well as `type` and a `rtc-config`. The `type` value is the ad network you will be using. The `rtc-config` is used to pass JSON configuration to the Prebid Server, which handles the communication with [AMP RTC](https://medium.com/ampfuel/better-than-header-bidding-amp-rtc-fc54e80f3999). Vendors is an object that defines any vendors that will be receiving the RTC callout. In this example, the required parameter `tag_id` will receive the `PLACEMENT_ID` (or `REQUEST_ID`) value.
```html
rtc-config='{"vendors": {"prebidappnexus": {"PLACEMENT_ID": "ef8299d0-cc32-46cf-abcd-41cebe8b4b85"}}, "timeoutMillis": 500}'
```
-The endpoint is rewritten as:
+Here's a simplified URL:
```
/openrtb2/amp?tag_id='ef8299d0-cc32-46cf-abcd-41cebe8b4b85'&w=300&h=250&timeout=500
```
-
-If any of the enpoint parameters are present, they will override parts of your Stored Request.
+Some endpoint parameters will override parts of the Stored Request.
1. `ow`, `oh`, `w`, `h`, and/or `ms` will be used to set `request.imp[0].banner.format` if `request.imp[0].banner` is present.
2. `curl` will be used to set `request.site.page`
@@ -196,3 +272,8 @@ Specifically:
5. If `w` and `h` exist, `request.imp[0].banner.format` will be a single element with `w: w` and `h: h`
6. If `w` _or_ `h` exist, it will be used to override _one_ of the dimensions inside each element of `request.imp[0].banner.format`
7. If none of these exist then the Stored Request values for `request.imp[0].banner.format` will be used without modification.
+
+## Further Reading
+- [Prebid and AMP](/formats/amp.html)
+- [Prebid Server AMP Use Case Overview](/prebid-server/use-cases/pbs-amp.html)
+- [Prebid Server First Party Data](/prebid-server/features/pbs-fpd.html)
diff --git a/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.md b/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.md
new file mode 100644
index 0000000000..7100f4f584
--- /dev/null
+++ b/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.md
@@ -0,0 +1,867 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Endpoints | OpenRTB2 | Auction
+---
+
+# Prebid Server | Endpoints | /openrtb2/auction
+{:.no_toc}
+
+## POST /openrtb2/auction
+{:.no_toc}
+
+* TOC
+{:toc }
+
+This endpoint runs an auction with the given OpenRTB 2.5 bid request.
+
+### Sample Request
+
+This is a sample OpenRTB 2.5 bid request:
+
+```
+{
+ "id": "some-request-id",
+ "test": 1,
+ "site": {
+ "page": "prebid.org"
+ },
+ "imp": [{
+ "id": "some-impression-id",
+ "banner": {
+ "format": [{
+ "w": 600,
+ "h": 500
+ }, {
+ "w": 300,
+ "h": 600
+ }]
+ },
+ "ext": {
+ "appnexus": {
+ "placementId": 12883451
+ }
+ }
+ }],
+ "tmax": 500
+}
+```
+
+Additional examples can be found in [endpoints/openrtb2/sample-requests/valid-whole](https://github.com/prebid/prebid-server/tree/master/endpoints/openrtb2/sample-requests/valid-whole).
+
+### Sample Response
+
+This endpoint will respond with either:
+
+- An OpenRTB 2.5 bid response, or
+- HTTP 400 if the request is malformed, or
+- HTTP 503 if the account or app specified in the request is blacklisted
+
+This is the corresponding response to the above sample OpenRTB 2.5 bid request, with the `ext.debug` field removed and the `seatbid.bid.adm` field simplified.
+
+```
+{
+ "id": "some-request-id",
+ "seatbid": [{
+ "seat": "appnexus",
+ "bid": [{
+ "id": "145556724130495288",
+ "impid": "some-impression-id",
+ "price": 0.01,
+ "adm": "",
+ "adid": "107987536",
+ "adomain": [
+ "appnexus.com"
+ ],
+ "iurl": "https://nym1-ib.adnxs.com/cr?id=107987536",
+ "cid": "3532",
+ "crid": "107987536",
+ "w": 600,
+ "h": 500,
+ "ext": {
+ "prebid": {
+ "type": "banner",
+ "video": {
+ "duration": 0,
+ "primary_category": ""
+ }
+ },
+ "bidder": {
+ "appnexus": {
+ "brand_id": 1,
+ "auction_id": 7311907164510136364,
+ "bidder_id": 2,
+ "bid_ad_type": 0
+ }
+ }
+ }
+ }]
+ }],
+ "cur": "USD",
+ "ext": {
+ "responsetimemillis": {
+ "appnexus": 10
+ },
+ "tmaxrequest": 500
+ }
+}
+```
+### OpenRTB Fields
+
+Prebid Server recognizes several standard OpenRTB2.5 fields.
+
+#### Currency
+
+The `cur` field is read and the first element of the array is taken to be the
+"Ad Server Currency" for purposes of [currency conversion](/prebid-server/features/pbs-currency.html).
+
+#### Expiration
+
+The OpenRTB2.5 `imp[].exp` field is an "Advisory as to the number of seconds that may elapse
+between the auction and the actual impression."
+
+This field is used in slightly different ways by PBS-Go and PBS-Java:
+
+##### PBS-Go
+{:.no_toc}
+
+How long an item is stored in Prebid Cache is determined by:
+
+1. bidResponse.seatbid[].bid[].exp + 60: as set by the bidder's adapter
+2. request.imp[].exp + 60: as set by the incoming request
+
+A 60-second buffer is added to make sure cache retrievals work towards the end of the
+cache period.
+
+##### PBS-Java
+{:.no_toc}
+
+How long an item is stored in Prebid Cache is determined by this hunt path:
+
+1. bidResponse.seatbid[].bid[].exp: set by the bidder's adapter
+2. request.imp[].exp: set by the incoming request
+3. request.ext.prebid.cache.{bids,vastxml}.ttlseconds
+4. account config: {banner,video}-cache-ttl
+5. global config: cache.{banner,video}-ttl-seconds
+
+#### Test
+
+This flag triggers Prebid Server to dump additional debug info into the OpenRTB response. e.g.
+
+```
+ "ext": {
+ "debug": {
+ "httpcalls": {
+ "bidderA": [
+ ...
+ ]
+ },
+ "resolvedrequest": {
+ ...
+ },
+ "responsetimemillis": {
+ ...
+ }
+ ...
+```
+
+#### Privacy fields
+
+Prebid Server reads the OpenRTB privacy fields:
+
+- regs.coppa
+- regs.ext.gdpr
+- regs.ext.us_privacy
+- user.ext.consent
+- device.lmt
+
+#### Other OpenRTB Fields
+
+Prebid Server doesn't do any special processing on any other fields, but passes them
+all to the bid and analytics adapters.
+
+### OpenRTB Extensions
+
+#### Conventions
+
+OpenRTB 2.5 permits exchanges to define their own extensions to any object from the spec.
+These fall under the `ext` field of JSON objects.
+
+If `ext` is defined on an object, Prebid Server uses the following conventions:
+
+1. `ext` in "request objects" uses `ext.prebid` and/or `ext.{anyBidderCode}`.
+2. `ext` on "response objects" uses `ext.prebid` and/or `ext.bidder`.
+The only exception here is the top-level `BidResponse`, because it's bidder-independent.
+
+`ext.{anyBidderCode}` and `ext.bidder` extensions are defined by bidders.
+`ext.prebid` extensions are defined by Prebid Server.
+
+Exceptions are made for extensions with "standard" recommendations:
+
+- `request.regs.ext.gdpr` and `request.user.ext.consent` -- To support GDPR
+- `request.regs.ext.us_privacy` -- To support CCPA
+- `request.site.ext.amp` -- To identify AMP as the request source
+- `request.app.ext.source` and `request.app.ext.version` -- To support identifying the displaymanager/SDK in mobile apps. If given, we expect these to be strings.
+
+#### Bid Adjustments
+
+Bidders [are encouraged](/prebid-server/bidders/pbs-build-a-bid-adapter.html) to make Net bids. However, there's no way for Prebid to enforce this.
+If you find that some bidders use Gross bids, publishers can adjust for it with `request.ext.prebid.bidadjustmentfactors`:
+
+```
+{
+ "ext": {
+ "prebid": {
+ "bidadjustmentfactors": {
+ "appnexus": 0.8,
+ "rubicon": 0.7
+ }
+ }
+ }
+}
+```
+
+This may also be useful for publishers who want to account for different discrepancies with different bidders.
+
+#### Targeting
+
+Targeting refers to strings which are sent to the adserver to
+[make header bidding possible](/overview/intro.html#how-does-prebid-work).
+
+`request.ext.prebid.targeting` is an optional property which causes Prebid Server
+to set these params on the response at `response.seatbid[i].bid[j].ext.prebid.targeting`.
+
+**Request format** (optional param `request.ext.prebid.targeting`)
+
+```
+{
+ "ext": {
+ "prebid": {
+ "targeting": {
+ "pricegranularity": {
+ "precision": 2,
+ "ranges": [{
+ "max": 20.00,
+ "increment": 0.10 // This is equivalent to the deprecated "pricegranularity": "medium"
+ }]
+ },
+ "includewinners": false, // Optional param defaulting to true
+ "includebidderkeys": false // Optional param defaulting to true
+ "includeformat": false // Optional param defaulting to false
+ }
+ }
+ }
+}
+```
+The list of price granularity ranges must be given in order of increasing `max` values. If `precision` is omitted, it will default to `2`. The minimum of a range will be 0 or the previous `max`. Any cmp above the largest `max` will go in the `max` pricebucket.
+
+For backwards compatibility the following strings will also be allowed as price granularity definitions. There is no guarantee that these will be honored in the future. "One of ['low', 'med', 'high', 'auto', 'dense']" See [price granularity definitions](/prebid-mobile/adops-price-granularity.html)
+
+One of "includewinners" or "includebidderkeys" must be true (both default to true if unset). If both were false, then no targeting keys would be set, which is better configured by omitting targeting altogether.
+
+The parameter "includeformat" indicates the type of the bid (banner, video, etc) for multiformat requests. It will add the key `hb_format` and/or `hb_format_{bidderName}` as per "includewinners" and "includebidderkeys" above.
+
+MediaType PriceGranularity (PBS-Java only) - when a single OpenRTB request contains multiple impressions with different mediatypes, or a single impression supports multiple formats, the different mediatypes may need different price granularities. If `mediatypepricegranularity` is present, `pricegranularity` would only be used for any mediatypes not specified.
+
+```
+{
+ "ext": {
+ "prebid": {
+ "targeting": {
+ "mediatypepricegranularity": {
+ "banner": {
+ "ranges": [
+ {"max": 20, "increment": 0.5}
+ ]
+ },
+ "video": {
+ "ranges": [
+ {"max": 10, "increment": 1},
+ {"max": 20, "increment": 2},
+ {"max": 50, "increment": 5}
+ ]
+ }
+ }
+ },
+ "includewinners": true
+ }
+ }
+}
+```
+
+**Response format** (returned in `bid.ext.prebid.targeting`)
+
+```
+{
+ "seatbid": [{
+ "bid": [{
+ ...
+ "ext": {
+ "prebid": {
+ "targeting": {
+ "hb_bidder_{bidderName}": "The seatbid.seat which contains this bid",
+ "hb_size_{bidderName}": "A string like '300x250' using bid.w and bid.h for this bid",
+ "hb_pb_{bidderName}": "The bid.cpm, rounded down based on the price granularity."
+ }
+ }
+ }
+ }]
+ }]
+}
+```
+
+The winning bid for each `request.imp[i]` will also contain `hb_bidder`, `hb_size`, and `hb_pb`
+(with _no_ {bidderName} suffix). To prevent these keys, set `request.ext.prebid.targeting.includeWinners` to false.
+
+**NOTE**: Targeting keys are limited to 20 characters. If {bidderName} is too long, the returned key
+will be truncated to only include the first 20 characters.
+
+#### Cookie syncs
+
+Each Bidder should receive their own ID in the `request.user.buyeruid` property.
+Prebid Server has three ways to populate this field. In order of priority:
+
+1. If the request payload contains `request.user.buyeruid`, then that value will be sent to all Bidders.
+In most cases, this is probably a bad idea.
+
+2. The request payload can store a `buyeruid` for each Bidder by defining `request.user.ext.prebid.buyeruids` like so:
+
+```
+{
+ "user": {
+ "ext": {
+ "prebid": {
+ "buyeruids": {
+ "appnexus": "some-appnexus-id",
+ "rubicon": "some-rubicon-id"
+ }
+ }
+ }
+ }
+}
+```
+
+Prebid Server's core logic will preprocess the request so that each Bidder sees their own value in the `request.user.buyeruid` field.
+
+3. Prebid Server will use its Cookie to map IDs for each Bidder.
+
+If you're using [Prebid.js](https://github.com/prebid/Prebid.js), this is happening automatically.
+
+If you're using another client, you can populate the Cookie of the Prebid Server host with User IDs
+for each Bidder by using the `/cookie_sync` endpoint, and calling the URLs that it returns in the response.
+
+#### Native Request
+
+For each native request, the `assets` object's `id` field must not be defined. Prebid Server will set this automatically, using the index of the asset in the array as the ID.
+
+
+#### Bidder Aliases
+
+Requests can define Bidder aliases if they want to refer to a Bidder by a separate name.
+This can be used to request bids from the same Bidder with different params. For example:
+
+```
+{
+ "imp": [{
+ "id": "some-impression-id",
+ "video": {
+ "mimes": ["video/mp4"]
+ },
+ "ext": {
+ "appnexus": {
+ "placementId": 123
+ },
+ "districtm": {
+ "placementId": 456
+ }
+ }
+ }],
+ "ext": {
+ "prebid": {
+ "aliases": {
+ "districtm": "appnexus"
+ }
+ }
+ }
+}
+```
+
+For all intents and purposes, the alias will be treated as another Bidder. This new Bidder will behave exactly
+like the original, except that the Response will contain separate SeatBids, and any Targeting keys
+will be formed using the alias' name.
+
+If an alias overlaps with a core Bidder's name, then the alias will take precedence.
+This prevents breaking API changes as new Bidders are added to the project.
+
+For example, if the Request defines an alias like this:
+
+```
+ "aliases": {
+ "appnexus": "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.
+
+#### Bidder Response Times
+
+`response.ext.responsetimemillis.{bidderName}` tells how long each bidder took to respond.
+These can help quantify the performance impact of "the slowest bidder."
+
+#### Bidder Errors
+
+`response.ext.errors.{bidderName}` contains messages which describe why a request may be "suboptimal".
+For example, suppose a `banner` and a `video` impression are offered to a bidder
+which only supports `banner`.
+
+In cases like these, the bidder can ignore the `video` impression and bid on the `banner` one.
+However, the publisher can improve performance by only offering impressions which the bidder supports.
+
+For example, a request may return this in `response.ext`
+
+```
+{
+ "ext": {
+ "errors": {
+ "appnexus": [{
+ "code": 2,
+ "message": "A hybrid Banner/Audio Imp was offered, but Appnexus doesn't support Audio."
+ }],
+ "rubicon": [{
+ "code": 1,
+ "message": "The request exceeded the timeout allocated"
+ }]
+ }
+ }
+}
+```
+
+The codes currently defined are:
+
+```
+0 NoErrorCode
+1 TimeoutCode
+2 BadInputCode
+3 BadServerResponseCode
+999 UnknownErrorCode
+```
+
+#### Debugging
+
+`response.ext.debug.httpcalls.{bidder}` will be populated **only if** `request.test` **was set to 1**.
+
+This contains info about every request and response sent by the bidder to its server.
+It is only returned on `test` bids for performance reasons, but may be useful during debugging.
+
+`response.ext.debug.resolvedrequest` will be populated **only if** `request.test` **was set to 1**.
+
+This contains the request after the resolution of stored requests and implicit information (e.g. site domain, device user agent).
+
+#### Stored Requests
+
+`request.imp[i].ext.prebid.storedrequest` incorporates a [Stored Request](/prebid-server/features/pbs-storedreqs.html) from the server.
+
+A typical `storedrequest` value looks like this:
+
+```
+{
+ "imp": [{
+ "ext": {
+ "prebid": {
+ "storedrequest": {
+ "id": "some-id"
+ }
+ }
+ }
+ }]
+}
+```
+
+For more information, see the docs for [Stored Requests](/prebid-server/features/pbs-storedreqs.html).
+
+#### Cache bids
+
+Bids can be temporarily cached on the server by sending instructions in `request.ext.prebid.cache`:
+
+```
+{
+ "ext": {
+ "prebid": {
+ "cache": {
+ "bids": {},
+ "vastxml": {}
+ }
+ }
+ }
+}
+```
+
+Both `bids` and `vastxml` are optional, but one of the two is required if you want to cache bids. This property will have no effect
+unless `request.ext.prebid.targeting` is also set in the request.
+
+If `bids` is present, Prebid Server will make a _best effort_ to include these extra
+`bid.ext.prebid.targeting` keys:
+
+- `hb_cache_id`: On the highest overall Bid in each Imp.
+- `hb_cache_id_{bidderName}`: On the highest Bid from {bidderName} in each Imp.
+
+Clients _should not assume_ that these keys will exist, just because they were requested, though.
+If they exist, the value will be a UUID which can be used to fetch Bid JSON from [Prebid Cache](https://github.com/prebid/prebid-cache).
+They may not exist if the host company's cache is full, having connection problems, or other issues like that.
+
+If `vastxml` is present, PBS will try to add analogous keys `hb_uuid` and `hb_uuid_{bidderName}`.
+In addition to the caveats above, these will exist _only if the relevant Bids are for Video_.
+If they exist, the values can be used to fetch the bid's VAST XML from Prebid Cache directly.
+
+These options are mainly intended for certain limited Prebid Mobile setups, where bids cannot be cached client-side.
+
+#### GDPR
+
+Prebid Server supports the IAB's GDPR recommendations, which can be found [here](https://iabtechlab.com/wp-content/uploads/2018/02/OpenRTB_Advisory_GDPR_2018-02.pdf).
+
+This adds two optional properties:
+
+- `request.user.ext.consent`: Is the consent string required by the IAB standards.
+- `request.regs.ext.gdpr`: Is 0 if the caller believes that the user is *not* under GDPR, 1 if the user *is* under GDPR, and undefined if we're not certain.
+
+These fields will be forwarded to each Bidder, so they can decide how to process them.
+
+#### Interstitial support
+Additional support for interstitials is enabled through the addition of two fields to the request:
+device.ext.prebid.interstitial.minwidthperc and device.ext.interstial.minheightperc
+The values will be numbers that indicate the minimum allowed size for the ad, as a percentage of the base side. For example, a width of 600 and "minwidthperc": 60 would allow ads with widths from 360 to 600 pixels inclusive.
+
+Example:
+```
+{
+ "imp": [{
+ ...
+ "banner": {
+ ...
+ }
+ "instl": 1,
+ ...
+ }]
+ "device": {
+ ...
+ "h": 640,
+ "w": 320,
+ "ext": {
+ "prebid": {
+ "interstitial": {
+ "minwidthperc": 60,
+ "minheightperc": 60
+ }
+ }
+ }
+ }
+}
+```
+
+PBS receiving a request for an interstitial imp and these parameters set, it will rewrite the format object within the interstitial imp. If the format array's first object is a size, PBS will take it as the max size for the interstitial. If that size is 1x1, it will look up the device's size and use that as the max size. If the format is not present, it will also use the device size as the max size. (1x1 support so that you don't have to omit the format object to use the device size)
+PBS with interstitial support will come preconfigured with a list of common ad sizes. Preferentially organized by weighing the larger and more common sizes first. But no guarantees to the ordering will be made. PBS will generate a new format list for the interstitial imp by traversing this list and picking the first 10 sizes that fall within the imp's max size and minimum percentage size. There will be no attempt to favor aspect ratios closer to the original size's aspect ratio. The limit of 10 is enforced to ensure we don't overload bidders with an overlong list. All the interstitial parameters will still be passed to the bidders, so they may recognize them and use their own size matching algorithms if they prefer.
+
+#### Currency Support
+
+To set the desired 'ad server currency', use the standard OpenRTB `cur` attribute. Note that Prebid Server only looks at the first currency in the array.
+
+```
+ "cur": ["USD"]
+```
+
+If you want or need to define currency conversion rates (e.g. for currencies that your Prebid Server doesn't support),
+define ext.prebid.currency.rates. (Currently supported in PBS-Java only)
+
+```
+"ext": {
+ "prebid": {
+ "currency": {
+ "rates": {
+ "USD": { "UAH": 24.47, "ETB": 32.04 }
+ }
+ }
+ }
+}
+```
+
+If it exists, a rate defined in ext.prebid.currency.rates has the highest priority.
+If a currency rate doesn't exist in the request, the external file will be used.
+
+#### Supply Chain Support
+
+
+Basic supply chains are passed to Prebid Server on `source.ext.schain` and passed through to bid adapters. Prebid Server does not currently offer the ability to add a node to the supply chain.
+
+Bidder-specific schains (PBS-Java only):
+
+```
+ext.prebid.schains: [
+ { bidders: ["bidderA"], schain: { SCHAIN OBJECT 1}},
+ { bidders: ["*"], schain: { SCHAIN OBJECT 2}}
+]
+```
+In this scenario, Prebid Server sends the first schain object to `bidderA` and the second schain object to everyone else.
+
+If there's already an source.ext.schain and a bidder is named in ext.prebid.schains (or covered by the wildcard condition), ext.prebid.schains takes precedent.
+
+#### Rewarded Video (PBS-Java only)
+
+Rewarded video is a way to incentivize users to watch ads by giving them 'points' for viewing an ad. A Prebid Server
+client can declare a given adunit as eligible for rewards by declaring `imp.ext.prebid.is_rewarded_inventory:1`.
+
+#### Debug Flag (PBS-Java only)
+
+The OpenRTB `test` flag has a special meaning that bidders may react to: they may not perform a normal auction, or may not pay for test requests.
+
+You can turn on the extra Prebid Server debug log without the formal `test` behavior by instead setting `ext.prebid.debug:1`.
+
+#### Stored Responses (PBS-Java only)
+
+While testing SDK and video integrations, it's important, but often difficult, to get consistent responses back from bidders that cover a range of scenarios like different CPM values, deals, etc. Prebid Server supports a debugging workflow in two ways:
+
+- a stored-auction-response that covers multiple bidder responses
+- multiple stored-bid-responses at the bidder adapter level
+
+**Single Stored Auction Response ID**
+
+When a storedauctionresponse ID is specified:
+
+- the rest of the ext.prebid block is irrelevant and ignored
+- nothing is sent to any bidder adapter for that imp
+- the response retrieved from the stored-response-id is assumed to be the entire contents of the seatbid object corresponding to that impression.
+
+This request:
+```
+{
+ "test":1,
+ "tmax":500,
+ "id": "test-auction-id",
+ "app": { ... },
+ "ext": {
+ "prebid": {
+ "targeting": {},
+ "cache": { "bids": {} }
+ }
+ },
+ "imp": [
+ {
+ "id": "a",
+ "ext": { "prebid": { "storedauctionresponse": { "id": "1111111111" } } }
+ },
+ {
+ "id": "b",
+ "ext": { "prebid": { "storedauctionresponse": { "id": "22222222222" } } }
+ }
+ ]
+}
+```
+
+Will result in this response, assuming that the ids exist in the appropriate DB table read by Prebid Server:
+```
+{
+ "id": "test-auction-id",
+ "seatbid": [
+ {
+ // BidderA bids from storedauctionresponse=1111111111
+ // BidderA bids from storedauctionresponse=22222222
+ },
+ {
+ // BidderB bids from storedauctionresponse=1111111111
+ // BidderB bids from storedauctionresponse=22222222
+ }
+ ]
+}
+```
+
+**Multiple Stored Bid Response IDs**
+
+In contrast to what's outlined above, this approach lets some real auctions take place while some bidders have test responses that still exercise bidder code. For example, this request:
+
+```
+{
+ "test":1,
+ "tmax":500,
+ "id": "test-auction-id",
+ "app": { ... },
+ "ext": {
+ "prebid": {
+ "targeting": {},
+ "cache": { "bids": {} }
+ }
+ },
+ "imp": [
+ {
+ "id": "a",
+ "ext": {
+ "prebid": {
+ "storedbidresponse": [
+ { "bidder": "BidderA", "id": "333333" },
+ { "bidder": "BidderB", "id": "444444" },
+ ]
+ }
+ }
+ },
+ {
+ "id": "b",
+ "ext": {
+ "prebid": {
+ "storedbidresponse": [
+ { "bidder": "BidderA", "id": "5555555" },
+ { "bidder": "BidderB", "id": "6666666" },
+ ]
+ }
+ }
+ }
+ ]
+}
+```
+Could result in this response:
+
+```
+{
+ "id": "test-auction-id",
+ "seatbid": [
+ {
+ "bid": [
+ // contents of storedbidresponse=3333333 as parsed by bidderA adapter
+ // contents of storedbidresponse=5555555 as parsed by bidderA adapter
+ ]
+ },
+ {
+ // contents of storedbidresponse=4444444 as parsed by bidderB adapter
+ // contents of storedbidresponse=6666666 as parsed by bidderB adapter
+ }
+ ]
+}
+```
+
+Setting up the storedresponse DB entries is the responsibility of each Prebid Server host company.
+
+See Prebid.org troubleshooting pages for how to utilize this feature within the context of the browser.
+
+
+#### User IDs
+
+Prebid Server adapters can support the [Prebid.js User ID modules](http://prebid.org/dev-docs/modules/userId.html) by reading the following extensions and passing them through to their server endpoints:
+
+```
+{
+ "user": {
+ "ext": {
+ "eids": [{
+ "source": "adserver.org",
+ "uids": [{
+ "id": "111111111111",
+ "ext": {
+ "rtiPartner": "TDID"
+ }
+ }]
+ },
+ {
+ "source": "pubcommon",
+ "id":"11111111"
+ }
+ ],
+ "digitrust": {
+ "id": "11111111111",
+ "keyv": 4
+ }
+ }
+ }
+}
+```
+
+#### First Party Data Support (PBS-Java only)
+
+This is the Prebid Server version of the Prebid.js First Party Data feature. It's a standard way for the page (or app) to supply first party data and control which bidders have access to it.
+
+It specifies where in the OpenRTB request non-standard attributes should be passed. For example:
+
+```
+{
+ "ext": {
+ "prebid": {
+ "data": { "bidders": [ "rubicon", "appnexus" ] } // these are the bidders allowed to see protected data
+ }
+ },
+ "site": {
+ "keywords": "",
+ "search": "",
+ "ext": {
+ data: { GLOBAL CONTEXT DATA } // only seen by bidders named in ext.prebid.data.bidders[]
+ }
+ },
+ "user": {
+ "keywords": "",
+ "gender": "",
+ "yob": 1999,
+ "geo": {},
+ "ext": {
+ data: { GLOBAL USER DATA } // only seen by bidders named in ext.prebid.data.bidders[]
+ }
+ },
+ "imp": [
+ "ext": {
+ "context": {
+ "keywords": "",
+ "search": "",
+ "data": { ADUNIT SPECFIC CONTEXT DATA } // can be seen by all bidders
+ }
+ }
+ ]
+```
+
+Prebid Server enforces the data permissioning. So before passing the values to the bidder adapters, the PBS core will:
+
+1. check for ext.prebid.data.bidders
+1. if it exists, store it locally, but remove it from the OpenRTB before being sent to the adapters
+1. As the OpenRTB request is being sent to each adapter:
+ 1. if ext.prebid.data.bidders exists in the original request, and this bidder is on the list then copy site.ext.data, app.ext.data, and user.ext.data to their bidder request -- otherwise don't copy those blocks
+ 1. copy other objects as normal
+
+Each adapter must be coded to read the values from these locations and pass it to their endpoints appropriately.
+
+### OpenRTB Ambiguities
+
+This section describes the ways in which Prebid Server **implements** OpenRTB spec ambiguous parts.
+
+- `request.cur`: If `request.cur` is not specified in the bid request, Prebid Server will consider it as being `USD` whereas OpenRTB spec doesn't mention any default currency for bid request.
+```request.cur: ['USD'] // Default value if not set```
+
+
+### OpenRTB Differences
+
+This section describes the ways in which Prebid Server **breaks** the OpenRTB spec.
+
+#### Allowed Bidders
+
+Prebid Server returns a 400 on requests which define `wseat` or `bseat`.
+We may add support for these in the future, if there's compelling need.
+
+Instead, an impression is only offered to a bidder if `bidrequest.imp[i].ext.{bidderName}` exists.
+
+This supports publishers who want to sell different impressions to different bidders.
+
+#### Deprecated Properties
+
+This endpoint returns a 400 if the request contains deprecated properties (e.g. `imp.wmin`, `imp.hmax`).
+
+The error message in the response should describe how to "fix" the request to make it legal.
+If the message is unclear, please [log an issue](https://github.com/prebid/prebid-server/issues)
+or [submit a pull request](https://github.com/prebid/prebid-server/pulls) to improve it.
+
+#### Determining Bid Security (http/https)
+
+In the OpenRTB spec, `request.imp[i].secure` says:
+
+> Flag to indicate if the impression requires secure HTTPS URL creative assets and markup,
+> where 0 = non-secure, 1 = secure. If omitted, the secure state is unknown, but non-secure
+> HTTP support can be assumed.
+
+In Prebid Server, an `https` request which does not define `secure` will be forwarded to Bidders with a `1`.
+Publishers who run `https` sites and want insecure ads can still set this to `0` explicitly.
+
+### Further Reading
+
+- [The OpenRTB 2.5 spec](https://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf)
diff --git a/prebid-server/endpoints/openrtb2/video.md b/prebid-server/endpoints/openrtb2/pbs-endpoint-video.md
similarity index 97%
rename from prebid-server/endpoints/openrtb2/video.md
rename to prebid-server/endpoints/openrtb2/pbs-endpoint-video.md
index 8ee8afd5f4..259056b01e 100644
--- a/prebid-server/endpoints/openrtb2/video.md
+++ b/prebid-server/endpoints/openrtb2/pbs-endpoint-video.md
@@ -1,21 +1,18 @@
---
layout: page_v2
sidebarType: 5
-title: Prebid Server | Endpoints | Video
+title: Prebid Server | Endpoints | OpenRTB2 | Video
---
-# Prebid Server Video Endpoint
+# Prebid Server | Endpoints | /openrtb2/video
{: .no_toc }
This document describes the behavior of the Prebid Server `video` endpoint in detail.
* TOC
{:toc}
-## Video Endpoint
- `POST /openrtb2/video`
-
-
+## POST /openrtb2/video
## Overview
@@ -355,8 +352,8 @@ The SSAI should take the key-values from the response `adPods.[].targeting.[]${k
## Further Reading:
-[Prebid Server overview](/prebid-server/prebid-server-overview.html)
-[OpenRTB auction endpoint ](/prebid-server/endpoints/openrtb2/auction.html)
-[Category Translation module](/dev-docs/modules/categoryTranslation.html)
-[Freewheel module](/dev-docs/modules/freewheel.html)
-[Ad Pod module](/dev-docs/modules/adpod.html)
+- [Prebid Server overview](/prebid-server/overview/prebid-server-overview.html)
+- [OpenRTB auction endpoint ](/prebid-server/endpoints/openrtb2/auction.html)
+- [Category Translation module](/dev-docs/modules/categoryTranslation.html)
+- [Freewheel module](/dev-docs/modules/freewheel.html)
+- [Ad Pod module](/dev-docs/modules/adpod.html)
diff --git a/prebid-server/endpoints/pbs-endpoint-admin.md b/prebid-server/endpoints/pbs-endpoint-admin.md
new file mode 100644
index 0000000000..15f77672ab
--- /dev/null
+++ b/prebid-server/endpoints/pbs-endpoint-admin.md
@@ -0,0 +1,151 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Admin Endpoints
+
+---
+
+# Prebid Server | Admin Endpoints
+{: .no_toc}
+
+There are several endpoints on the special `admin` port that a host company may utilize that aren't available to external users. This port defaults to 8060, but can be set in the `admin.port` config.
+
+* TOC
+{:toc}
+
+## GET /currency/rates
+
+This endpoint exposes active currency rate converter information in the server.
+Information are:
+- `info.active`: true if currency converter is active
+- `info.source`: URL from which rates are fetched
+- `info.fetchingIntervalNs`: Fetching interval from source in nanoseconds
+- `info.lastUpdated`: Datetime when the rates where updated
+- `info.rates`: Internal rates values
+
+### Sample responses
+#### Rate converter active
+```json
+{
+ "active": true,
+ "info": {
+ "source": "https://cdn.jsdelivr.net/gh/prebid/currency-file@1/latest.json",
+ "fetchingIntervalNs": 60000000000,
+ "lastUpdated": "2019-03-02T14:18:41.221063+01:00",
+ "rates": {
+ "GBP": {
+ "AUD": 1.8611576401,
+ "BGN": 2.2750325703,
+ "BRL": 5.0061650847,
+ "CAD": 1.7414619393,
+ "CHF": 1.3217708915,
+ "CNY": 8.8791178113,
+ "CZK": 29.8203982877,
+ "DKK": 8.6791596873,
+ "EUR": 1.163223525,
+ "GBP": 1,
+ "HKD": 10.3927042621,
+ "HRK": 8.645077238,
+ "HUF": 367.6484273218,
+ "IDR": 18689.5123766983,
+ "ILS": 4.8077191513,
+ "INR": 93.8663223525,
+ "ISK": 158.0820770519,
+ "JPY": 148.1365159129,
+ "KRW": 1491.3921459148,
+ "MXN": 25.5839382096,
+ "MYR": 5.394332775,
+ "NOK": 11.3144425833,
+ "NZD": 1.9374651033,
+ "PHP": 68.6139028476,
+ "PLN": 5.0130281035,
+ "RON": 5.5172855016,
+ "RUB": 87.2333891681,
+ "SEK": 12.2141959799,
+ "SGD": 1.7908989391,
+ "THB": 42.0074911595,
+ "TRY": 7.1224176438,
+ "USD": 1.3240973385,
+ "ZAR": 18.7774520752
+ },
+ "USD": {
+ "AUD": 1.4056048493,
+ "BGN": 1.7181762277,
+ "BRL": 3.7808134938,
+ "CAD": 1.3152068875,
+ "CHF": 0.9982429939,
+ "CNY": 6.705789335,
+ "CZK": 22.5213036985,
+ "DKK": 6.554774664,
+ "EUR": 0.8785030308,
+ "GBP": 0.7552314855,
+ "HKD": 7.8488974787,
+ "HRK": 6.5290345252,
+ "HUF": 277.6596679259,
+ "IDR": 14114.9081964333,
+ "ILS": 3.6309408767,
+ "INR": 70.8908020733,
+ "ISK": 119.3885618905,
+ "JPY": 111.8773609769,
+ "KRW": 1126.3463058948,
+ "MXN": 19.3217956602,
+ "MYR": 4.0739699552,
+ "NOK": 8.5450232803,
+ "NZD": 1.4632346482,
+ "PHP": 51.8193797769,
+ "PLN": 3.7859966617,
+ "RON": 4.1668277256,
+ "RUB": 65.8814020908,
+ "SEK": 9.2245453747,
+ "SGD": 1.3525432663,
+ "THB": 31.7253799526,
+ "TRY": 5.3790740578,
+ "USD": 1,
+ "ZAR": 14.1813230256
+ }
+ }
+ }
+}
+```
+
+#### Rate converter set with constant rates
+```json
+{
+ "active": true,
+ "source": "",
+ "fetchingIntervalNs": 0,
+ "lastUpdated": "0001-01-01T00:00:00Z"
+}
+```
+
+#### Rate converter not set
+```json
+{
+ "active": false
+}
+```
+
+## /logging/httpinteraction
+
+(PBS-Java only)
+
+This endpoint turns on temporary logging of raw HTTP requests and responses, mainly for troubleshooting production issues.
+
+Interaction is logged at INFO level using http-interaction logback logger so make sure this logger has at least INFO or more verbose level set (logback configuration bundled in JAR file sets this logger to INFO level).
+
+Query Params
+- endpoint - endpoint to be affected; valid values: auction, amp; if omitted all valid endpoints will be affected
+- statusCode - specifies that only interactions resulting in this response status code should be logged; valid values: >=200 and <=500
+- account - specifies that only interactions involving this account should be logged
+- limit - number of interactions to log; there is an upper threshold for this value set in configuration
+
+## /logging/changelevel
+
+(PBS-Java only)
+
+This endpoint allows changing org.prebid.server logger level temporarily, mainly for troubleshooting production issues.
+
+Query Params
+- level - desired logging level to set; must be one of error, warn, info, debug
+- duration - for how long (in milliseconds) to change level before it gets reset to original; there is an upper threshold for this value set in configuration
+
diff --git a/prebid-server/endpoints/cookieSync.md b/prebid-server/endpoints/pbs-endpoint-cookieSync.md
similarity index 87%
rename from prebid-server/endpoints/cookieSync.md
rename to prebid-server/endpoints/pbs-endpoint-cookieSync.md
index 282017862e..91f9642b3d 100644
--- a/prebid-server/endpoints/cookieSync.md
+++ b/prebid-server/endpoints/pbs-endpoint-cookieSync.md
@@ -1,14 +1,14 @@
---
layout: page_v2
sidebarType: 5
-title: Prebid Server | Endpoints | Starting Cookie Syncs
+title: Prebid Server | Endpoints | /cookie_sync
---
-# Starting Cookie Syncs
+# Prebid Server | Endpoints | /cookie_sync
-This endpoint is used during cookie syncs. For technical details, see the
-[Cookie Sync developer docs](../developers/cookie-syncs.html).
+This endpoint is used to initiate cookie syncs. For technical details, see the
+[Cookie Sync developer docs](/prebid-server/developers/pbs-cookie-sync.html).
## POST /cookie_sync
diff --git a/prebid-server/endpoints/pbs-endpoint-event.md b/prebid-server/endpoints/pbs-endpoint-event.md
new file mode 100644
index 0000000000..320a4008fd
--- /dev/null
+++ b/prebid-server/endpoints/pbs-endpoint-event.md
@@ -0,0 +1,87 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Endpoints | Events
+
+---
+
+# Prebid Server | Endpoints | Events (Java-only)
+
+PBS-Java supports events as described in these GitHub issues:
+
+- [Prebid Server Event Notification proposal](https://github.com/prebid/prebid-server/issues/800)
+- [Prebid Server Event Updates](https://github.com/prebid/prebid-server/issues/1202)
+- [PBS video impression tracking](https://github.com/prebid/prebid-server/issues/1015)
+
+## GET /event
+
+This endpoint alerts Prebid Server to process the event. Most of the time this just means informing the analytics adapter. But it's also used in the Programmatic Guaranteed context to affect line item pacing.
+
+### Query Params
+
+{: .table .table-bordered .table-striped }
+| Query Parameter | Required? | Description |
+|-----------------+-----------+-------------|
+| a| y | Account ID |
+| t| y | Type of the event. Allowed values: `win` or `imp` |
+| b| y | Bid ID, expected to be unique so this event can be joined to the auction analytics. |
+| bidder| y | Bidder code |
+| f| n | Format of the PBS response. Values: `b` is blank, just return HTTP 200 with an empty body. `i` is image, return HTTP 200 with a blank PNG body |
+| ts| n | Auction timestamp |
+| x| n | Disables or enables analytics. Allowed values: `1` to enable analytics or `0` to disable. `1` is default. |
+
+### Sample request
+
+```
+GET http://prebid.site.com/event?t=win&b=1234567890&bidder=rubicon&f=i
+```
+
+## `POST /vtrack`
+
+This endpoint covers there scenario where VAST XML is returned in the response from a client-side adapter. Prebid.js forwards the XML to PBS on a new endpoint that instructs PBS to update the XML and cache it
+
+If the bidder allows PBS to modify their VAST, the server then injects an tag into the VAST, referring to a prebid server event string, then caches the modified results. It forwards the response from Prebid Cache.
+
+The contents of the tag are pulled from a new event.url-template property that has macros that need to be resolved. e.g.
+
+```
+event:
+ url-template: "/event?t=imp&b=%s&f=b&a=%s"
+```
+where b=BIDID, a=ACCOUNT
+
+The algorithm for inserting the tag is simple -- search for an existing tag and add another underneath it. If there isn't an existing tag, no modifications are made.
+
+
+### Query Params
+
+{: .table .table-bordered .table-striped }
+| Query Parameter | Required? | Description |
+|-----------------+-----------+-------------|
+| a | yes | Account id |
+
+### POST Body Params
+
+{: .table .table-bordered .table-striped }
+| Query Parameter | Required? | Description |
+|-----------------+-----------+-------------|
+| bidid | y | Will enable offline analytics join this impression event to the original auction event |
+| bidder | y | Prebid bidder code |
+| timestamp | n | Auction timestamp as generated by Prebid.js. Useful in offline joins |
+| type | y | Always "xml" |
+| value | y | VAST XML |
+| ttlseconds | n | How long this VAST should be cached |
+
+### Sample request
+
+`POST https://prebid-server.rubiconproject.com/vtrack?a=ACCOUNT`
+
+```json
+{"puts":[{
+ "bidid": "BIDID",
+ "bidder": "BIDDER",
+ "type":"xml",
+ "value":"",
+ "ttlseconds":3600
+}]}
+```
diff --git a/prebid-server/endpoints/getuids.md b/prebid-server/endpoints/pbs-endpoint-getuids.md
similarity index 83%
rename from prebid-server/endpoints/getuids.md
rename to prebid-server/endpoints/pbs-endpoint-getuids.md
index 077e21fb84..0043f6ceff 100644
--- a/prebid-server/endpoints/getuids.md
+++ b/prebid-server/endpoints/pbs-endpoint-getuids.md
@@ -1,14 +1,15 @@
---
layout: page_v2
sidebarType: 5
-title: Prebid Server | Endpoints | Get/getuids
+title: Prebid Server | Endpoints | /getuids
---
-# Getting the existing user syncs
-This endpoint is used to get the existing user syncs of an user.
+# Prebid Server | Endpoints | /getuids
-## `GET /getuids`
+This endpoint is used to get the existing user IDs stored in the browser.
+
+## GET /getuids
This endpoint parses the PBS cookie and returns the existing UserIDs for each bidder. This information can be used by publishers in server to server requests where the originating server doesn't have access to the PBS cookie.
diff --git a/prebid-server/endpoints/pbs-endpoint-overview.md b/prebid-server/endpoints/pbs-endpoint-overview.md
new file mode 100644
index 0000000000..502dcfe7b1
--- /dev/null
+++ b/prebid-server/endpoints/pbs-endpoint-overview.md
@@ -0,0 +1,37 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Endpoints | Overview
+
+---
+
+# Prebid Server Endpoints Overview
+
+## Prebid Server
+
+The API endpoints recognized by Prebid Server:
+
+{: .table .table-bordered .table-striped }
+| Endpoint | Purpose |
+|----------+---------|
+| [POST /openrtb2/auction](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html) | The main header bidding auction endpoint |
+| [GET /openrtb2/amp](/prebid-server/endpoints/openrtb2/pbs-endpoint-amp.html) | The [AMP](/prebid-server/use-cases/pbs-amp.html) endpoint |
+| [POST /openrtb2/video](/prebid-server/endpoints/openrtb2/pbs-endpoint-video.html) | Supports long-form video requests |
+| [POST /cookie_sync](/prebid-server/endpoints/pbs-endpoint-cookieSync.html) | Responds with an array of pixels the client can use to initiate cookie-matching requests. |
+| [GET /setuid](/prebid-server/endpoints/pbs-endpoint-setuid.html) | The other side of /cookie_sync, this is what actually updates the `uids` cookie. |
+| [GET /getuids](/prebid-server/endpoints/pbs-endpoint-getuids.html) | Parses the `uids` cookie and returns JSON. |
+| [GET /status](/prebid-server/endpoints/pbs-endpoint-status.html) | A health check. |
+| [GET /info](/prebid-server/endpoints/info/pbs-endpoint-info.html) | Returns various information about how the server is configured. |
+| [GET /event](/prebid-server/endpoints/pbs-endpoint-event.html) | (PBS-Java only) Alerts Prebid Server to process an event. |
+| [POST /vtrack](/prebid-server/endpoints/pbs-endpoint-event.html) | (PBS-Java only) Cache VAST XML after inserting tracking string. |
+| [/currency/rates](/prebid-server/endpoints/pbs-endpoint-admin.html) | (Admin port only) Retrieves the server's current currency conversion rates. |
+
+## Prebid Cache
+
+The API endpoints recognized by the [Prebid Cache](/prebid-server/features/pbs-caching.html) Server:
+
+{: .table .table-bordered .table-striped }
+| Endpoint | Purpose |
+|----------+---------|
+| [POST /cache](/prebid-server/endpoints/pbs-endpoints-pbc.html) | Store a creative or bid in Prebid Cache |
+| [GET /cache](/prebid-server/endpoints/pbs-endpoints-pbc.html#get-cache) | Retrieve a creative or bid from Prebid Cache |
diff --git a/prebid-server/endpoints/setuid.md b/prebid-server/endpoints/pbs-endpoint-setuid.md
similarity index 82%
rename from prebid-server/endpoints/setuid.md
rename to prebid-server/endpoints/pbs-endpoint-setuid.md
index 95c24af065..eaf27a1bb8 100644
--- a/prebid-server/endpoints/setuid.md
+++ b/prebid-server/endpoints/pbs-endpoint-setuid.md
@@ -1,16 +1,16 @@
---
layout: page_v2
sidebarType: 5
-title: Prebid Server | Endpoints | Saving User Syncs
+title: Prebid Server | Endpoints | /setuid
---
-# Saving User Syncs
+# Prebid Server | Endpoints | /setuid
-This endpoint is used during cookie syncs. For technical details, see the
-[Cookie Sync developer docs](../developers/cookie-syncs.html).
+This endpoint is used during cookie syncs to save the results in the Prebid Server `uids` cookie. For technical details, see the
+[Cookie Sync developer docs](/prebid-server/developers/pbs-cookie-sync.html).
-## `GET /setuid`
+## GET /setuid
This endpoint saves a UserID for a Bidder in the Cookie. Saved IDs will be recognized for 7 days before being considered "stale" and being re-synced.
diff --git a/prebid-server/endpoints/pbs-endpoint-status.md b/prebid-server/endpoints/pbs-endpoint-status.md
new file mode 100644
index 0000000000..0d8fd5ce67
--- /dev/null
+++ b/prebid-server/endpoints/pbs-endpoint-status.md
@@ -0,0 +1,18 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Endpoints | /status
+
+---
+
+# Prebid Server | Endpoints | /status
+
+## GET /status
+
+This endpoint will return a 2xx response whenever Prebid Server is ready to serve requests.
+Its exact response can be configured with the `status_response`
+config option. For eample, in `pbs.yaml`:
+
+```yaml
+status_response: "ok"
+```
diff --git a/prebid-server/endpoints/pbs-endpoints-pbc.md b/prebid-server/endpoints/pbs-endpoints-pbc.md
new file mode 100644
index 0000000000..b472d66348
--- /dev/null
+++ b/prebid-server/endpoints/pbs-endpoints-pbc.md
@@ -0,0 +1,124 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Cache Endpoints
+
+---
+
+# Prebid Cache Endpoints
+{: .no_toc}
+
+The Prebid Cache server has a fairly simple API structure: one endpoint to write
+to cache, and one endpoint to read from cache.
+
+* TOC
+{:toc}
+
+## POST /cache
+
+Adds one or more values to the cache. Values can be given as either JSON or XML. A sample request is below.
+
+```json
+{
+ "puts": [
+ {
+ "type": "xml",
+ "ttlseconds": 60,
+ "value": "Your XML content goes here. "
+ },
+ {
+ "type": "json",
+ "ttlseconds": 300,
+ "value": [1, true, "JSON value of any type can go here."]
+ }
+ ]
+}
+```
+
+If any of the `puts` are invalid, then it responds with a **400** none of the values will be retrievable.
+Assuming that all of the values are well-formed, then the server will respond with IDs which can be used to
+fetch the values later.
+
+**Note**: `ttlseconds` is optional, and will only be honored on a _best effort_ basis.
+Callers should never _assume_ that the data will stay in the cache for that long.
+
+```json
+{
+ "responses": [
+ {"uuid": "279971e4-70f0-4b18-bd65-5c6e7aa75d40"},
+ {"uuid": "147c9934-894b-4c1f-9a32-e7bb9cd15376"}
+ ]
+}
+```
+
+In order to support cross-datacenter caching, an optional parameter `key` has been added that a particular install of prebid cache may or may not support (as a config option).
+If the server does not support specifying `key`s, then any supplied keys will be ignored and requests will be processed as
+above. If the server supports key, then the put can optionally use it as:
+
+```json
+{
+ "puts": [
+ {
+ "type": "xml",
+ "ttlseconds": 60,
+ "value": "Your XML content goes here. ",
+ "key": "ArbitraryKeyValueHere"
+ },
+ {
+ "type": "json",
+ "ttlseconds": 300,
+ "value": [1, true, "JSON value of any type can go here."]
+ }
+ ]
+}
+
+This will result in the response
+
+```json
+{
+ "responses": [
+ {"uuid": "ArbitraryKeyValueHere"},
+ {"uuid": "147c9934-894b-4c1f-9a32-e7bb9cd15376"}
+ ]
+}
+```
+
+If an entry already exists for "ArbitraryKeyValueHere", it will not be overwitten,
+and "" will be returned for the `uuid` value of that entry. This is to prevent bad actors from trying to overwrite legitimate caches with
+malicious content, or a poorly coded app overwriting its own cache with new values, generating uncertainty what is actually stored under a
+particular key. Note that this is the only case where only a subset of caches will be stored, as this is the only case where a put will fail
+due to no fault of the requester yet the other puts are not called into question. (A failure can happen if the backend datastore errors on the
+storage of one entry, but this then calls into question how successfully the other caches were saved.)
+
+## GET /cache
+
+Retrieves a single value from the cache. If the `id` isn't recognized, then it will return a 404.
+
+Assuming the above POST calls have been made, here are some sample GET responses.
+
+---
+
+**GET** */cache?uuid=279971e4-70f0-4b18-bd65-5c6e7aa75d40*
+
+```
+HTTP/1.1 200 OK
+Content-Type: application/xml
+
+Your XML content goes here.
+```
+
+---
+
+**GET** */cache?uuid=147c9934-894b-4c1f-9a32-e7bb9cd15376*
+
+```
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+[1, true, "JSON value of any type can go here."]
+```
+
+### Limitations
+
+- This application does *not* validate XML. If users `POST` malformed XML, they'll `GET` a bad response too.
+- The host company can set a max length on payload size limits in the application config. This limit will vary from host company to host company.
diff --git a/prebid-server/endpoints/status.md b/prebid-server/endpoints/status.md
deleted file mode 100644
index 2e31921290..0000000000
--- a/prebid-server/endpoints/status.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-layout: page_v2
-sidebarType: 5
-title: Prebid Server | Endpoints | Status
-
----
-
-# Get Status Endpoint
-
- `GET /status`
-
-This endpoint will return a 2xx response whenever Prebid Server is ready to serve requests.
-Its exact response can be [configured](https://github.com/prebid/prebid-server/blob/master/docs/developers/configuration.md) with the `status_response`
-config option. For eample, in `pbs.yaml`:
-
-```yaml
-status_response: "ok"
-```
diff --git a/prebid-server/endpoints/version.md b/prebid-server/endpoints/version.md
deleted file mode 100644
index 2d7e127590..0000000000
--- a/prebid-server/endpoints/version.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## `GET /version`
-
-This endpoint exposes the application version as defined at compilation time.
-Version can be set either:
-- manually using go build -ldflags "-X main.Rev=`git rev-parse --short HEAD`"
-- automatically via .travis.yml configuration
-See https://github.com/prebid/prebid-server/blob/master/pbs_light.go:
-
-```go
-// Holds binary revision string
-// Set manually at build time using:
-// go build -ldflags "-X main.Rev=`git rev-parse --short HEAD`"
-// Populated automatically at build / release time via .travis.yml
-// `gox -os="linux" -arch="386" -output="{{.Dir}}_{{.OS}}_{{.Arch}}" -ldflags "-X main.Rev=`git rev-parse --short HEAD`" -verbose ./...;`
-// See issue #559
-var Rev string
-```
-
-### Sample responses
-
-#### Version set
-```json
-{"revision": "d6cd1e2bd19e03a81132a23b2025920577f84e37"},
-```
-
-#### Version not set
-```json
-{"revision": "not-set"}`
-```
diff --git a/prebid-server/features/pbs-caching.md b/prebid-server/features/pbs-caching.md
new file mode 100644
index 0000000000..f52c897eb3
--- /dev/null
+++ b/prebid-server/features/pbs-caching.md
@@ -0,0 +1,90 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Features | Caching | Overview
+
+---
+
+# Prebid Server | Features | Caching
+
+There are several important scenarios where Prebid stores some or all of the bid in the 'cloud' for a time, either because it has to or because it's advantageous:
+
+1. Most video players require that they be given a URL that points to VAST XML for advertisements stored on the network.
+1. [AMP](/prebid-server/use-cases/pbs-amp.html) requires that only ad server targeting be returned, not the whole creative body. When chosen, the creative is obtained from network.
+1. [Mobile applications](/prebid-server/use-cases/pbs-sdk.html) could accept the full creative body, but it's better performance for users if ad creatives stay in the network unless they're going to be displayed.
+
+There are two flows in this diagram: the numbered circles follow the auction request and the lettered circles follow the retrieval of the creative:
+
+
+
+Populating Items in the Cache
+
+1. The device makes the auction request.
+2. Prebid Server processes the request.
+3. The bidders respond.
+4. Prebid Server stores the bid or the VAST XML in Prebid Cache. Note that in some cases, the answer may go back to the browser and be populated in the cache by a separate browser request.
+5. The Prebid Cache server stores the object in the No-SQL backend.
+
+Retrieving Items from the Cache
+
+A. The device makes the retrieval request.
+B. The request goes directly to Prebid Cache.
+C. Which retrieves the bid or VAST from the backend.
+
+## Technical Setup
+
+Each Prebid Server host company may set up Prebid Cache in a somewhat
+different way, but in general, the `/cache` endpoint gets routed directly
+to the Prebid Cache server.
+
+Also, each host company can choose to integrate different backend storage
+systems like Redis, Aerospike, etc.
+
+## Examples
+
+You can watch the caching take place with your browser developer tools.
+
+### Video
+
+From one of the [video instream examples](/examples/video/instream/jwplayer/pb-ve-jwplayer-platform.html):
+
+The VAST XML is stored into Prebid Cache from Prebid.js with this call:
+```
+POST https://prebid.adnxs.com/pbc/v1/cache
+
+```
+And the response from the /cache call is:
+```
+{"responses":[{"uuid":"9b05c38c-709c-4fb5-8592-8fcacb1289f7"}]}
+```
+
+And when the video player is ready to display the video ad, this
+call is seen go out:
+```
+GET https://prebid.adnxs.com/pbc/v1/cache?uuid=9b05c38c-709c-4fb5-8592-8fcacb1289f7
+```
+And the response is the VAST XML.
+
+### AMP
+
+Here's an example AMP response from Prebid Server:
+```
+{
+ "targeting": {
+ "hb_cache_id": "14b468d0-3c58-4a5d-ae5d-ab9a47b6152c",
+ "hb_pb": "0.40",
+ "hb_pb_rubicon": "0.40",
+ "hb_cache_path": "/cache",
+ "hb_size": "300x50",
+ "hb_bidder": "rubicon",
+ "hb_cache_host": "prebid-server.example.com",
+ "hb_bidid": "add62e49-9d5c-4e22-a450-fd4e922941aa"
+ }
+}
+```
+
+Then when the ad is chosen by the ad server, this fetch goes out from the browser:
+```
+https://prebid-server.example.com/cache?uuid=14b468d0-3c58-4a5d-ae5d-ab9a47b6152c
+```
+
diff --git a/prebid-server/features/pbs-currency.md b/prebid-server/features/pbs-currency.md
new file mode 100644
index 0000000000..8b6201fb5f
--- /dev/null
+++ b/prebid-server/features/pbs-currency.md
@@ -0,0 +1,106 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Feature | Currency Conversion
+
+---
+
+# Prebid Server | Feature | Currency Conversion
+
+Prebid server supports currency conversions when receiving bids.
+
+- The "desired request currency" is what the request would like all bids to be in
+- The "bid response currency" is what the bidder responded with
+
+Some bidders are able to bid in multiple currencies, but cannot, so Prebid Server can normalize the bids for the
+client.
+
+## Desired Request Currency
+
+There are several ways to define the request currency:
+
+- The OpenRTB request can define the `cur` parameter. This is an array in OpenRTB, but Prebid Server only looks at the first element of the array.
+- An AMP Stored Request can define the `cur` parameter.
+- An App 'top-level' Stored Request can define the `cur` parameter.
+- PBS-Java can configure the default installation currency (auction.ad-server-currency)
+- Otherwise, both PBS-Go and PBS-Java default to USD
+
+## Loading Currency Conversion Rates
+
+By default, the currency converter uses https://cdn.jsdelivr.net/gh/prebid/currency-file@1/latest.json for currency conversion. This data is updated every 24 hours on prebid.org side.
+By default, currency conversions are updated from the endpoint every 30 minutes in prebid server.
+
+Default configuration in PBS-Go:
+```
+v.SetDefault("currency_converter.fetch_url", "https://cdn.jsdelivr.net/gh/prebid/currency-file@1/latest.json")
+v.SetDefault("currency_converter.fetch_interval_seconds", 1800) // 30 minutes
+```
+
+Default configuration in PBS-Java:
+```
+currency-converter:
+ external-rates:
+ enabled: true
+ url: https://cdn.jsdelivr.net/gh/prebid/currency-file@1/latest.json
+ default-timeout-ms: 4000
+ refresh-period-ms: 900000 // 15 minutes
+```
+
+Notes:
+
+- The currency conversion mechanism can be disabled in PBS-Go by setting fetch_interval_seconds to 0.
+- Prebid updates the `latest.json` file daily from the European Central Bank. If there's a currency needed for your
+installation, you can host your own currency conversion file at a URL using the following JSON schema:
+ ```
+ {
+ "dataAsOf":"2018-09-12",
+ "conversions":{
+ "USD":{
+ "GBP":0.77208
+ },
+ "GBP":{
+ "USD":1.2952
+ }
+ }
+ }
+ ```
+
+## Examples
+
+Here are a couple examples showing the logic behind the currency converter:
+
+| Bidder bid price | Request Currency | Rate to USD | Rate converter is active | Converted bid price (USD) | Valid bid |
+| :--------------- | :------------ |:--------------| :------------------------| :-------------------------|:----------|
+| 1 | USD | 1 | YES | 1 | YES |
+| 1 | N/A | 1 | YES | 1 | YES |
+| 1 | USD | 1 | NO | 1 | YES |
+| 1 | EUR | 1.13 | YES | 1.13 | YES |
+| 1 | EUR | N/A | YES | N/A | NO |
+| 1 | EUR | 1.13 | NO | N/A | NO |
+
+## Request-Defined Conversion Rates
+
+Using PBS-Java, rates can be passed in on the request:
+
+```
+"ext": {
+ "prebid": {
+ "currency": {
+ "rates": {
+ "USD": { "UAH": 24.47, "ETB": 32.04, "EUR": 0.92, ... }
+ },
+ "usepbsrates": false // defaults to true
+ }
+ }
+}
+```
+
+Note that the `usepbsrates` flag allows you to define which rates to use when PBS has two rates to consider: the one it loaded from the external source and the one on the request:
+- If usepbsrates==true, then prefer the external source's rates
+- If usepbsrates==false, then prefer the rate from the request
+
+
+## Debug
+
+A dedicated endpoint on the Admin port will allow you to see what's happening within the currency converter.
+See [currency rates endpoint](/prebid-server/endpoints/pbs-endpoint-admin.html) for more details.
diff --git a/prebid-server/features/pbs-deals.md b/prebid-server/features/pbs-deals.md
new file mode 100644
index 0000000000..2c9fe1005f
--- /dev/null
+++ b/prebid-server/features/pbs-deals.md
@@ -0,0 +1,19 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Features | Deals
+---
+
+# Prebid Server | Features | Deals
+
+Prebid Server supports Private MarketPlace deals in this way:
+
+1. Prebid Server Bid Adapters can respond with a deal in `seatbid.bid.dealid`. All bids are returned to the client and the deal can pulled from `seatbid.bid.dealid`.
+2. Prebid-style ad server targeting is also applied:
+ 1. If the deal is the highest bid overall and the [`ext.prebid.targeting.includewinners`](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#targeting) option is on, then the `hb_deal` targeting value will contain the winning deal ID.
+ 2. If the deal is the highest bid for a particular bidder and the [`ext.prebid.targeting.includebidderkeys`](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#targeting) is on, then the `hb_deal_BIDDER` targeting value will contain that deal ID
+
+Ad server line items should be targeted to `hb_deal_BIDDER` (for sendAllBids)
+or `hb_deal` (for sendTopBid).
+
+Currently Prebid Server doesn't support the option of preferring deals over open market bids, though a [PreferDeals](https://github.com/prebid/prebid-server/issues/1355) flag is being considered.
diff --git a/prebid-server/developers/default-request.md b/prebid-server/features/pbs-default-request.md
similarity index 97%
rename from prebid-server/developers/default-request.md
rename to prebid-server/features/pbs-default-request.md
index 72be6ea88c..0c5c57c183 100644
--- a/prebid-server/developers/default-request.md
+++ b/prebid-server/features/pbs-default-request.md
@@ -5,7 +5,7 @@ title: Prebid Server | Developers | Default Request
---
-# Server Based Global Default Request
+# Server Based Global Default Request (PBS-Go only)
This allows a defaut stored request to be defined that allows the server to set up some defaults for all incoming requests. A request specified stored request will override these defaults, and of course any options specified directly in the stored request override both. The default stored request is only read on server startup, it is meant as an installation static default rather than a dynamic tuning option.
diff --git a/prebid-server/features/pbs-feature-idx.md b/prebid-server/features/pbs-feature-idx.md
new file mode 100644
index 0000000000..18683d93b4
--- /dev/null
+++ b/prebid-server/features/pbs-feature-idx.md
@@ -0,0 +1,64 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Features
+
+---
+
+# Prebid Server | Features
+
+{: .table .table-bordered .table-striped }
+| Feature Set | Feature | Description | PBS-Go | PBS-Java |
+|-------------+---------+-------------+--------+----------|
+| [Currency](/prebid-server/features/pbs-currency.html) | Core | Loads currency conversions from an outside source, allows non-supported currencies to come in on the OpenRTB2 request, converts bid currencies to the request's prefered currency. | 
| |
+| [Currency](/prebid-server/features/pbs-currency.html) | Request-Defined Rates | Allows the request to define its own currency rates. | | |
+| [Deals](/prebid-server/features/pbs-deals.html) | Core | Basic deal support, creating hb_deal targeting when appropriate. | | |
+| [AMP](/prebid-server/use-cases/pbs-amp.html) | Core | Reads and responds to the /openrtb2/amp endpoint | | |
+| Targeting | Core | Request can specify `includewinners` and `includebidderkeys`. These cause PBS to emit seatbid[].bid[].ext.prebid.targeting values. | | |
+| Targeting | Format | Request can specify `includeformat`, which causes PBS to emit hb_format along with other targeting values like hb_pb, etc. | | |
+| [Price Granularity](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#targeting) | Core | Request can define quantization rules. Bids are quantized before being added to ad server targeting. | | |
+| Price Granularity | Mediatype pricegranularity | Request can define different quantization rules for different mediatypes. Bids are quantized before being added to ad server targeting. | | |
+| [GDPR](/prebid-server/features/pbs-privacy.html) | TCF 1.1 core | Able to: read the TCF1.1 global vendor list, parse incoming TCF1.1 consent strings, and [take appropriate enforcement action](https://docs.google.com/document/d/1g0zAYc_EfqyilKD8N2qQ47uz0hdahY-t8vfb-vxZL5w/edit). | | |
+| GDPR | TCF 1.1 Account Config | Able to turn on and off TCF1 enforcement per account. | | |
+| GDPR | TCF 1.1 Geo-lookup | Can use a geographic lookup service to help determine whether the incoming request is in-scope for GDPR. | | |
+| GDPR | TCF 1.1 GVL Fallback | Allow the host company to optionally add a default TCF1 GVL file. | | |
+| GDPR | TCF 2 core | Able to: read the TCF2 global vendor list, parse incoming TCF2 consent strings, and [take appropriate enforcement action](https://docs.google.com/document/d/1fBRaodKifv1pYsWY3ia-9K96VHUjd8kKvxZlOsozm8E/edit). | | |
+| GDPR | TCF 2 Account Config | Able to turn on and off TCF2 enforcement per account. | | |
+| GDPR | TCF 2 Geo-lookup | Can use a geographic lookup service to help determine whether the incoming request is in-scope for GDPR. | | |
+| GDPR | TCF 2 Integration type exception | Can be configured to turn off GDPR checks for a specific account and a specific integration type. e.g. Account 123 has a different legal basis for AMP. | | |
+| [US Privacy](/prebid-server/features/pbs-privacy.html) | USP core | Able to: read the US Privacy consent string (CCPA) and [take appropriate enforcement action](https://github.com/prebid/prebid-server/issues/1129). | | |
+| US Privacy | USP AMP support | Able to: read the US Privacy consent string from AMP requests and [take appropriate enforcement action](https://github.com/prebid/prebid-server/issues/1176). | | |
+| COPPA | Core | Able to read the COPPA flag and [take appropriate enforcement action](https://github.com/prebid/prebid-server/issues/929). | | |
+| [Cache](/prebid-server/features/pbs-caching.html) | Bids core | Accepts the ext.prebid.cache.bids parameter, storing bid objects in PBC. | | |
+| Cache | VAST core | Accepts the ext.prebid.cache.vastxml parameter, storing VAST responses in PBC. | | |
+| Cache | Winning-only flag | Accepts a 'ext.prebid.cache.winningonly' parameter on the request. If true, instead of caching all bids and VAST, only the winning bid or VAST is stored. | | |
+| [Stored Requests](/prebid-server/features/pbs-storedreqs.html) | Core | Accepts a stored request ID in the OpenRTB, looks it up against a local data store, and merges with the OpenRTB request record. | | |
+| Stored Responses | Stored Responses | Accepts a stored response ID in the OpenRTB, looks it up against a local data store, and merges with the OpenRTB response record. | | |
+| First Party Data | Core | Accepts core first party data attributes and supports ext.prebid.data.bidders. | | |
+| First Party Data | Bidder-specific data | Accepts bidder-specific first party data attributes. | | |
+| First Party Data | AMP first party data | Accepts first party data attributes on an AMP request. | | |
+| [Supply Chain](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#supply-chain-support) | Bidder-specific schains | Accepts bidder-specific schain | | |
+| Publisher Accounts | Core | Ability to enforce that requests coming in have a valid account ID. | | |
+| Publisher Accounts | AMP account parameter | Accept the account parameter on the AMP request. | | |
+| Publisher Accounts | Account-specific TTLs | Allow each account ID to have a custom PBC time-to-live for banner and video. | | |
+| [Video](/formats/video.html) | Core | Support for basic instream and outstream video: passes video parameters to adapters, stores VAST responses when instructed. | | |
+| Video | Outstream renderers | Support for bidders specifying their own renderers for outstream video. | | |
+| Video | Long-form video | Support for the [long-form video endpoint](/prebid-server/endpoints/openrtb2/pbs-endpoint-video.html). | | |
+| Video | IAB advertiser category mapping | Able to map IAB advertiser categories to a supplied mapping table. | | |
+| Video | Echo video attributes | To support mobile video, copies stored request video attributes to the response. | | |
+| [Interstitials](/prebid-server/features/pbs-interstitials.html) | Core | Support device.ext.prebid.interstitial.minwidthperc and device.ext.prebid.interstitial.minheightperc parameters, [dynamically updating the impression format object](https://github.com/prebid/prebid-server/issues/755) from a configurable list of sizes filtered by these parameters. | | |
+| [Aliases](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#bidder-aliases) | Core | Can map bidders on an incoming request to a specific server-side bid adapter named in the request or defined in config. | | |
+| [User ID Sync](/prebid-server/developers/pbs-cookie-sync.html) | Core | Implements the /cookie_sync and /setuid endpoints. | | |
+| User ID Sync | Cooperative sync | Does a pixel sync with more than just the bidders on the page. | | |
+| [Events](https://docs.google.com/document/d/1ry0X4C2EV-R0pMrm1IQk9BstxaT395UCl3KKqTGa5c8/edit#heading=h.7w5yevygp2gz) | Events | Ability to process the /event endpoint, place /event URLs in the OpenRTB response, and place /event URLs in VAST XML. | | |
+| Events | Events vasttrack endpoint | Ability to process the /vasttrack endpoint initated by Prebid.js, placing /event URLs in VAST XML. | | |
+| Events | Events BidID Generation | Some bidders don't generate unique enough BidIDs to join with auction events. This feature allows the host company to inject a PBS-generated BidID alongside the bidder-generated ID. | | |
+| Analytics | Analytics module support | Allows developers to plug in a [custom analytics adapter](https://github.com/prebid/prebid-server/blob/master/docs/developers/add-new-analytics-module.md). | | |
+| [Bidder Info Endpoints](/prebid-server/endpoints/info/pbs-endpoint-info.html) | Core | Provides details on which bidders and parameters exist in this Prebid Server. | | |
+| [Troubleshooting](/troubleshooting/pbs-troubleshooting.html) | Test flag | Accepts the OpenRTB 'test' flag, emitting additional debug info on responses. | | |
+| Troubleshooting | Debug flag | Accepts the ext.prebid.debug flag, emitting additional debug info on responses. | | |
+| Operations | Core metrics | Emits detailed operational metrics to back-end systems: Graphite, Influx, and Prometheus | | |
+| Operations | Circuit breaker | Protects system performance during fault scenarios by detecting problems with external and internal endpoints, turning them off temporarily when a problem occurs. | | |
+| Operations | [Server default request](/prebid-server/features/pbs-default-request.html) | Support global defaults for incoming requests. | | |
+| Operations | IPv6 | Support taking IPv6 addresses and forwarding them to bidders. | | |
+| Operations | [Request Logging Admin Endpoints](/troubleshooting/pbs-troubleshooting.html#request-logging) | Log a limited number of requests to understand the raw data clients are sending. | | |
diff --git a/prebid-server/features/pbs-fpd.md b/prebid-server/features/pbs-fpd.md
new file mode 100644
index 0000000000..a488c46dac
--- /dev/null
+++ b/prebid-server/features/pbs-fpd.md
@@ -0,0 +1,130 @@
+---
+layout: page_v2
+sidebarType: 5
+title: First Party Data - Prebid Server
+---
+
+# First Party Data - Prebid Server
+{: .no_toc}
+
+* TOC
+{:toc}
+
+Prebid allows publishers to supply attributes related to their content
+and users, and to apply permissions so only certain bidders are allowed
+to access those attributes.
+
+{: .alert.alert-warning :}
+For now, this feature is only supported in PBS-Java and these conventions aren't implemented by all adapters. Please
+check with each of your bidders to make sure they're reading first
+party data from the standard Prebid locations.
+
+## How It Works
+
+Each of the three main sources of Prebid Server traffic will place
+First Party Data in the OpenRTB JSON in several places:
+
+{: .table .table-bordered .table-striped }
+| OpenRTB Attribute | Description | PBJS Source | SDK Source | AMP Source |
+| --- | --- | --- | --- | --- |
+| site.ATTR | Only standard OpenRTB attributes should be here: name, domain, cat, sectioncat, pagecat, page, ref, search, keywords. | config.fpd.context.ATTR | n/a | site.ATTR |
+| site.ext.data.ATTR | Any other site-related attributes should go here. | config.fpd.context.data | n/a | site.ext.data.ATTR |
+| app.ext.data.ATTR | Any app-related attributes should go here. | n/a | Targeting addContextData() | n/a |
+| user.ATTR | Only standard OpenRTB attributes should be here: yob, gender, keywords. | config.fpd.user.ATTR | n/a | user.ATTR |
+| user.ext.data.ATTR | Any other user-related attributes should go here. | config.fpd.user.data.ATTR | Targeting addUserData() | user.ext.data.ATTR |
+| imp[].ext.context.data.ATTR | AdUnit-specific attributes should go here. | AdUnit.fpd.context | AdUnit addContextData() | n/a |
+| ext.prebid.data.bidders[] | If specified, only these bidders are allowed to see fields in {site/app/user}.ext.data. | n/a | addBidderToAccessControlList() | bidders |
+| ext.prebid.bidderconfig | Bidder-specific config | [setBidderConfig()](/dev-docs/publisher-api-reference.html#module_pbjs.setBidderConfig) | n/a | n/a |
+
+This diagram summarizes how first party data flows into the OpenRTB JSON:
+
+{: .pb-lg-img :}
+
+{: .alert.alert-info :}
+Note that Prebid.js supports the [`setBidderConfig`](/dev-docs/publisher-api-reference.html#module_pbjs.setBidderConfig) method of defining
+bidder-specific first party data, while SDK and AMP only support the `ext.prebid.data.bidders[]` approach.
+
+## OpenRTB Examples
+
+In this example, only BidderA has access to the global first party data:
+```
+{
+ ext: {
+ prebid: {
+ data: { bidders: [ "bidderA" ] } // limit bidders that receive global data
+ }
+ },
+ site: {
+ keywords: "",
+ search: "",
+ ext: {
+ data: {
+ // only seen by bidderA as named in ext.prebid.data.bidders[]
+ GLOBAL CONTEXT DATA
+ }
+ }
+ },
+ user: {
+ keywords: "",
+ gender: "",
+ yob: 1999,
+ geo: {},
+ ext: {
+ data: {
+ // only seen by bidderA as named in ext.prebid.data.bidders[]
+ GLOBAL USER DATA
+ }
+ }
+ },
+ imp: [
+ ...
+ ext: {
+ context: {
+ keywords: "",
+ search: "",
+ data: {
+ // everyone sees this data
+ ADUNIT SPECIFIC CONTEXT DATA
+ }
+ }
+ }
+ ]
+}
+```
+
+This example shows an array of bidder-specific config:
+```
+{
+ ext: {
+ prebid: {
+ bidderconfig: [ {
+ bidders: [ 'bidderA', 'bidderB' ],
+ config: {
+ fpd: { site: { ... }, user: { ...} }
+ }
+ },{
+ bidders: [ 'bidderC' ],
+ config: {
+ fpd: { site: { ... }, user: { ...} }
+ }
+ }]
+ }
+ }
+}
+```
+
+## How Server-Side Bid Adapters Read First Party Data
+
+Bid adapters don't need to worry about whether the request came from
+Prebid.js, the SDK, or AMP -- everything is merged into the OpenRTB JSON. If a bid adapter receives first party data on any of the fields noted in
+the table above, they can simply pass that data to their endpoint in
+the expected way.
+
+In other words, just be aware of site.ext.data.ATTR, app.ext.data.ATTR, user.ext.data.ATTR,
+and imp[].ext.context.data.ATTR and either pass them straight through or map
+attributes to where your endpoints expect them.
+
+## Further Reading
+
+- [Prebid.js First Party Data](/features/firstPartyData.html)
+- [Prebid Server and AMP](/prebid-server/use-cases/pbs-amp.html)
diff --git a/prebid-server/features/pbs-interstitials.md b/prebid-server/features/pbs-interstitials.md
new file mode 100644
index 0000000000..1bd83d12fd
--- /dev/null
+++ b/prebid-server/features/pbs-interstitials.md
@@ -0,0 +1,57 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Features | Interstitials
+
+---
+
+# Prebid Server | Features | Interstitials
+
+Support for interstitial ads is enabled with the addition of two fields to the OpenRTB request: `device.ext.prebid.interstitial.minwidthperc`
+and `device.ext.interstial.minheightperc` The values will be numbers that indicate the minimum allowed
+size for the ad, as a percentage of the base side. For example, a width of 600 and "minwidthperc": 60
+would allow ads with widths from 360 to 600 pixels inclusive.
+
+Example:
+
+```
+{
+ "imp": [{
+ ...
+ "banner": {
+ "format": [
+ {"w":1, "h":1}
+ ],
+ ...
+ }
+ "instl": 1,
+ ...
+ }]
+ "device": {
+ ...
+ "h": 640,
+ "w": 320,
+ "ext": {
+ "prebid": {
+ "interstitial": {
+ "minwidthperc": 60,
+ "minheightperc": 60
+ }
+ }
+ }
+ }
+}
+```
+
+Upon receiving a request for an interstitial impression (`instl:1`) and these parameters set, PBS will rewrite the
+`format` object within the interstitial imp object.
+
+1. If the `format` array's first object is a size, PBS will take it as the max size for the interstitial.
+2. If the first entry in `format` is 1x1, it will use the device's size as the max size.
+3. Likewise, if `format` is not present, PBS will also use the device size as the max size.
+4. Each PBS host company configures a list of common interstitial ad sizes, generally organized by weighing the larger and more common sizes first.
+5. PBS generates a new format list for the interstitial imp by traversing this configured list and picking the first 10 sizes that fall within the imp's max size and minimum percentage size.
+6. There's no attempt to favor aspect ratios closer to the original size's aspect ratio.
+7. The limit of 10 is enforced to ensure we don't overload bidders with an overlong list.
+8. The `minwidthperc` and `minheightperc` parameters are passed to bidder adapters, so if desired, they may use their own size matching algorithms.
+
diff --git a/prebid-server/features/pbs-privacy.md b/prebid-server/features/pbs-privacy.md
new file mode 100644
index 0000000000..dd31507d47
--- /dev/null
+++ b/prebid-server/features/pbs-privacy.md
@@ -0,0 +1,104 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Features | Privacy
+---
+
+# Prebid Server | Features | Privacy
+{:.no_toc}
+
+* TOC
+{:toc}
+
+## Mobile 'Limit Ad Tracking' flag
+
+If PBS receives 'device.lmt' flag in the OpenRTB request, it does the following anonymization:
+
+- Mask take off the last byte of the IPv4 address and the last 2 bytes of IPv6 addresses
+- Removes user.id and user.buyeruid
+- Removes the request.device.ifa attribute
+- Rounds the request.device.geo. {lat,lon} to two decimal places
+
+## GDPR
+
+Prebid Server host companies and publishers have the ability to control the enforcement
+activities that take place.
+
+The enforcement strategy changed significantly between TCF 1.1 and TCF 2.0. [TCF2](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20Consent%20string%20and%20vendor%20list%20formats%20v2.md) is a
+more nuanced and stricter policy.
+
+{: .alert.alert-info :}
+If a Prebid Server host company wants to support GDPR, they must currently [register for the IAB Global Vendor List](https://register.consensu.org/).
+The user must provide legal basis for the host company to read/write cookies or `/cookie_sync` will return an empty response with no syncs and `/setuid` will fail.
+
+### TCF 1.1
+
+If Prebid Server determines that the user is in GDPR scope and doesn't consent
+to *all* of the vendor's 'purposes' as declared in the Global Vendor List, it 'anonymizes'
+the request to the adapters:
+
+- Mask take off the last byte of the IPv4 address and the last 2 bytes of IPv6 addresses
+- Removes user.id and user.buyeruid
+- Removes the request.device.ifa attribute
+- Rounds the request.device.geo. {lat,lon} to two decimal places
+
+Full details are available [here](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/developers/PrebidServerJava_GDPR_Requirements.pdf).
+
+### TCF 2.0
+
+If Prebid server determines the user is in GDPR scope, then consent is independently tested
+for each 'Purpose' with different consequences for each:
+
+{: .table .table-bordered .table-striped }
+| Activity | Legal Basis Required |
+| ----------- | ------------------------------------ |
+| Responding to /cookie-sync requests | Purpose 1 (Device Access) |
+| Setting a cookie on /setuid requests | Purpose 1 (Device Access) |
+| Conducting auctions | Purpose 2 (Basic Ads) |
+| Passing User IDs into an auction | Any Purpose 2-10. User IDs are important for more than personalizing ads - they can be used in frequency capping, building profiles, counting unique users, etc. So Prebid Server should pass User IDs through the auction if any of Purposes 2-10 pass the legal basis test. |
+| Invoke an analytics adapter | Purpose 7 |
+| Pass the user’s precise geographic information into auctions | Special Feature 1 |
+
+More details are available in the [Prebid Support for TCF2](https://docs.google.com/document/d/1fBRaodKifv1pYsWY3ia-9K96VHUjd8kKvxZlOsozm8E/edit#) reference and in the [Prebid Server GDPR Reference](https://docs.google.com/document/d/1g0zAYc_EfqyilKD8N2qQ47uz0hdahY-t8vfb-vxZL5w/edit#).
+
+### GDPR Configuration
+
+There are a number of configuration settings that PBS Host Companies need
+to consider:
+
+- Host company GVL ID. Currently PBS requires the host company to have a GVL-ID or the setting of the `uids` cookie in GDPR scope will fail.
+- The default expiration time of the uids cookie set in the host company domain should be defined to match what's in the TCF 2.1 `maxCookieAgeSeconds` GVL field.
+- GDPR enforcement flags for each Purpose and Vendor
+
+The specific details vary slightly between PBS-Go and PBS-Java, so check the
+version-specific documentation for more information.
+
+## COPPA
+
+The [Children's Online Privacy Protection Act (COPPA)](https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/childrens-online-privacy-protection-rule) is a law in the US which imposes certain requirements on operators of websites or online services directed to children under 13 years of age, and on operators of other websites or online services that have actual knowledge that they are collecting personal information online from a child under 13 years of age.
+If `regs.coppa` is set to '1' on the OpenRTB request, the following anonymization actions take place before going to the adapters:
+
+- Removes all ID fields: device.ifa, device.macsha1, device.macmd5, device.dpidsha1, device.dpidmd5, device.didsha1, device.didmd5
+- Truncate ip field - remove lowest 8 bits.
+- Truncate ipv6 field - remove lowest 32 bits.
+- Remove geo.lat, geo.lon. geo.metro, geo.city, and geo.zip
+- Remove user.id, user.buyeruid, user.yob, and user.gender
+
+## CCPA / US-Privacy
+
+The [California Consumer Privacy Act (CCPA)](https://oag.ca.gov/privacy/ccpa) is a law in the US. which covers consumer rights relating to the access to, deletion of, and sharing of personal information that is collected by businesses.
+The IAB has generalized
+this state-specific rule into a [US Privacy](https://iabtechlab.com/standards/ccpa/) compliance framework.
+If `regs.ext.us_privacy` is parsed to find that the user has opted-out of a "sale",
+the following anonymization steps are taken:
+
+- Mask the last byte of the IPv4 address and the last 2 bytes of IPv6 addresses
+- Removes user.id and user.buyeruid
+- Removes the request.device.ifa attribute
+- Rounds the request.device.geo. {lat,lon} to two decimal places
+
+## DNT
+
+Prebid Server does **not** recognize the Do-Not-Track header. The committee determined that it's obsolete in general and not supported on Safari specifically. We prefer not to implement, test, and document unsupported privacy flags. Prebid Server is not going to make a dent in the overall problems with DNT.
+
+We may reconsider this position if community members provide evidence that the flag is meaningful to their customers or lawyers.
diff --git a/prebid-server/developers/stored-requests.md b/prebid-server/features/pbs-storedreqs-go.md
similarity index 74%
rename from prebid-server/developers/stored-requests.md
rename to prebid-server/features/pbs-storedreqs-go.md
index 9c3d4aac4f..7a8492a6f8 100644
--- a/prebid-server/developers/stored-requests.md
+++ b/prebid-server/features/pbs-storedreqs-go.md
@@ -1,17 +1,13 @@
---
layout: page_v2
sidebarType: 5
-title: Prebid Server | Developers | Stored Requests
+title: Prebid Server | Features | Setting Up Stored Requests for Go
---
-# Stored Requests
+# Prebid Server | Features | Setting Up Stored Requests for Go
-This document gives a technical overview of the Stored Requests feature.
-
-Docs outlining the motivation and uses will be added sometime in the future.
-
-## Quickstart
+## PBS-Go Stored Request Quickstart
Configure your server to read stored requests from the filesystem:
@@ -41,7 +37,7 @@ Add the file `stored_requests/data/by_id/stored_imps/{id}.json` and populate it
},
"ext": {
"appnexus": {
- "placementId": 10433394
+ "placementId": 12883451
}
}
}
@@ -54,7 +50,7 @@ go build .
./prebid-server
```
-And then `POST` to [`/openrtb2/auction`](/prebid-server/endpoints/openrtb2/auction.html) with your chosen ID.
+And then `POST` to [`/openrtb2/auction`](../endpoints/openrtb2/auction.md) with your chosen ID.
```json
{
@@ -95,7 +91,7 @@ You can also store _part_ of the Imp on the server. For example:
},
"ext": {
"appnexus": {
- "placementId": 10433394
+ "placementId": 12883451
}
}
}
@@ -127,55 +123,6 @@ If the Stored Request and the HTTP request have conflicting properties,
they will be resolved with a [JSON Merge Patch](https://tools.ietf.org/html/rfc7386).
HTTP request properties will overwrite the Stored Request ones.
-## Interstitial Ads
-
-Prebid Server supports interstitial ad type requests. These requests are enabled through the addition of the interstitial key to `device.ext.prebid`. This key has two fields, `minwidthperc` and `minheightperc`. The values are integers that represent the minimum allowed size for the ad, as a percentage of the base size. For example, a `width` of 600 and `minwidthperc` of 60 would allow ad widths of 360 (600 * .60) to 600.
-
-```json
-
-{
- "mockBidRequest": {
- "id":"test-request-id",
- "imp": [
- {
- "id":"test-imp-id",
- "banner": {
- "format": [
-
- {
- "w":300,
- "h":250
- }
-,
-
- {
- "w":300,
- "h":600
- }
- ]
- },
- "instl":1,
- "device":
-{ ... }
-,
- "h":640,
- "w":320,
- "ext": {
- "prebid": {
- "interstitial":
- {
- "minwidthperc":60,
- "minheightperc":60
- }
- }
- }
- }
- ]
- }
-```
-
-
-
## Stored BidRequests
So far, our examples have only used Stored Imp data. However, Stored Requests
@@ -259,8 +206,8 @@ stored_requests:
```yaml
stored_requests:
http:
- endpoint: https://stored-requests.prebid.com
- amp_endpoint: https://stored-requests.prebid.com?amp=true
+ endpoint: http://stored-requests.prebid.com
+ amp_endpoint: http://stored-requests.prebid.com?amp=true
```
@@ -300,17 +247,15 @@ stored_requests:
dbname: database-name
query: SELECT id, requestData, 'request' as type FROM stored_requests WHERE id in %REQUEST_ID_LIST% UNION ALL SELECT id, impData, 'imp' as type FROM stored_imps WHERE id in %IMP_ID_LIST%;
http:
- endpoint: https://stored-requests.prebid.com
- amp_endpoint: https://stored-requests.prebid.com?amp=true
+ endpoint: http://stored-requests.prebid.com
+ amp_endpoint: http://stored-requests.prebid.com?amp=true
in_memory_cache:
ttl_seconds: 300 # 5 minutes
request_cache_size_bytes: 107374182 # 0.1GB
imp_cache_size_bytes: 107374182 # 0.1GB
http_events:
- endpoint: https://stored-requests.prebid.com
- amp_endpoint: https://stored-requests.prebid.com?amp=true
+ endpoint: http://stored-requests.prebid.com
+ amp_endpoint: http://stored-requests.prebid.com?amp=true
refresh_rate_seconds: 60
timeout_ms: 100
```
-
-Pull Requests for new Fetchers, Caches, or EventProducers are always welcome.
diff --git a/prebid-server/features/pbs-storedreqs.md b/prebid-server/features/pbs-storedreqs.md
new file mode 100644
index 0000000000..c6e6b59dfb
--- /dev/null
+++ b/prebid-server/features/pbs-storedreqs.md
@@ -0,0 +1,36 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Features | Stored Requests
+
+---
+
+# Prebid Server | Features | Stored Requests
+
+'Stored Requests' are blocks of OpenRTB stored on the server-side that are merged into
+OpenRTB requests in a couple of scenarios.
+
+The data source can be local files on Prebid Server, but more commonly it would be a relational
+database distributed across all the Prebid Servers in the host company's installation.
+
+## Mobile App
+
+Hardcoding bidders and parameters in a mobile app isn't ideal. Prebid Server allows Stored Request IDs to be
+used in two ways:
+
+1. Define cross-adunit parameters like currency and price granularity
+1. Define adunit-specific details: bidders and their parameters
+
+See the [Mobile SDK Use Case reference](/prebid-server/use-cases/pbs-sdk.html) for specific examples.
+
+## AMP
+
+The AMP protocol is converted to OpenRTB primarily using Stored Requests: the `tag_id` is used to look up
+the base OpenRTB from the data source. After getting the bulk of the OpenRTB, AMP query string parameters
+are used to inject and adjust parameters like size, url, etc. See the [AMP endpoint documentation](/prebid-server/endpoints/openrtb2/pbs-endpoint-amp.html) for more details.
+
+See the [AMP Use Case reference](/prebid-server/use-cases/pbs-amp.html) for specific examples.
+
+## Creating Stored Requests
+
+Details for setting up [PBS-Go Stored Requests](/prebid-server/features/pbs-storedreqs-go.html) are available.
diff --git a/prebid-server/hosted-servers.md b/prebid-server/hosted-servers.md
index eda6c448f6..a5eceaad6a 100644
--- a/prebid-server/hosted-servers.md
+++ b/prebid-server/hosted-servers.md
@@ -18,6 +18,10 @@ Several Prebid.org members host Prebid Server clusters for use by publishers.
Learn more about Rubicon Project's Hosted Prebid Server offering.
+
Contact OpenX or your account manager for information regarding OpenX's Hosted Prebid Server service
+
If you're a company hosting Prebid Server for others, [join Prebid.org](/overview/what-is-prebid-org.html) to get on this list.
diff --git a/prebid-server/hosting-options.md b/prebid-server/hosting-options.md
deleted file mode 100644
index eda6c448f6..0000000000
--- a/prebid-server/hosting-options.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-layout: page_v2
-title: Hosted Prebid Servers
-description: Hosted Prebid Servers
-pid: 0
-sidebarType: 5
----
-
-# Hosted Prebid Servers
-{:.no_toc}
-
-Several Prebid.org members host Prebid Server clusters for use by publishers.
-
-
-
-
-If you're a company hosting Prebid Server for others, [join Prebid.org](/overview/what-is-prebid-org.html) to get on this list.
diff --git a/prebid-server/hosting/hosted-servers.md b/prebid-server/hosting/hosted-servers.md
new file mode 100644
index 0000000000..f10b4e491b
--- /dev/null
+++ b/prebid-server/hosting/hosted-servers.md
@@ -0,0 +1,40 @@
+---
+layout: page_v2
+title: Prebid Server Managed Solutions
+description: Prebid Server Managed Solutions
+pid: 0
+sidebarType: 5
+---
+
+# Prebid Server Managed Solutions
+{:.no_toc}
+
+Several Prebid.org members host Prebid Server clusters for use by publishers.
+
+
+
+```
+
+{: .alert.alert-info :}
+**Note:** the `prebidrubicon` and `prebidappnexus` 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.
+
+- The other option is to construct a direct URL from component pieces: w, h, slot, targeting, gdpr_consent, account, page url (purl), etc.
+
+```
+
+
+
+
+## Features
+
+PBS-Go has all the core PBS features, but does have a backlog of newer [features](/prebid-server/features/pbs-feature-idx.html), so you'll want to look over the list to be familiar with the differences.
+
+## Code Repositories
+
+- [Prebid Server - Go](https://github.com/prebid/prebid-server)
+- [Prebid Cache Server - Go](https://github.com/prebid/prebid-cache)
+
+## Installation
+
+See [Hosting your own Prebid Server](/prebid-server/hosting/pbs-hosting.html) for
+important architectural considerations, then follow the instructions for [Installing PBS-Go](/prebid-server/developers/installing-go.html).
+
+## References
+
+- [Building an Analytics Adapter](/prebid-server/developers/pbs-build-an-analytics-adapter.html#adding-an-analytics-adapter-in-pbs-go)
+
+## See Also
+- [Prebid Server - Java](/prebid-server/versions/pbs-versions-java.html)
+- [Endpoint reference](/prebid-server/endpoints/pbs-endpoint-overview.html)
diff --git a/prebid-server/versions/pbs-versions-java.md b/prebid-server/versions/pbs-versions-java.md
new file mode 100644
index 0000000000..ae665e225d
--- /dev/null
+++ b/prebid-server/versions/pbs-versions-java.md
@@ -0,0 +1,52 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Versions | Java
+
+---
+
+# Prebid Server - Java
+
+**Example** @@ -61,10 +59,10 @@ Follow these instructions to set up a Native ad with HTML and CSS. For more deta ## MoPub -These instructions describe how to add a Native ad with the MoPub SDK. For more detailed information review the MoPub Native ad documentation for [iOS](https://developers.mopub.com/publishers/ios/native/) and [Android](https://developers.mopub.com/publishers/android/native/). +The instructions below describe how to add a Native ad with the MoPub SDK. For more detailed information review the MoPub Native ad documentation for [iOS](https://developers.mopub.com/publishers/ios/native/) and [Android](https://developers.mopub.com/publishers/android/native/). - 1. Create a `Medium rectangle` Ad Unit. - 2. Create a non-guaranteed line item targeting this ad unit and an `hb_pb price`. + 1. Create a `Medium rectangle` Ad Unit + 2. Create a non-guaranteed line item targeting this ad unit and a `hb_pb price` 3. Create a creative with 300x250 Medium Rectangle format, choose HTML and put in the following code: ```html @@ -86,7 +84,7 @@ These instructions describe how to add a Native ad with the MoPub SDK. For more ``` {% capture noteAlert %} -Do not to check Mraid ad.z. +Note not to check Mraid ad.z {% endcapture %} {% include alerts/alert_note.html content=noteAlert %} diff --git a/prebid-mobile/adops-price-granularity.md b/prebid-mobile/adops-price-granularity.md index 1358b82b25..4d883ba8ff 100644 --- a/prebid-mobile/adops-price-granularity.md +++ b/prebid-mobile/adops-price-granularity.md @@ -1,26 +1,24 @@ --- layout: page_v2 -title: Price Granularity -description: Price granularity -pid: 2 -top_nav_section: prebid-mobile -nav_section: prebid-mobile-adops +title: Mobile Price Granularity +description: Mobile Price granularity sidebarType: 3 --- -# Price Granularity +# Prebid Mobile Price Granularity -With Prebid Mobile, you’ll need to setup line items to tell your ad server how much money the “bidder” demand is worth to you. This process is done via key-values. +With Prebid Mobile, you’ll need to setup line items to tell your ad server how much money the “bidder” demand is worth to you. This process is done with an ad server key-value pair: `hb_pb`, which stands for "header bidding price bucket". Example: - * Prebid Mobile is going to call Prebid Server which calls your bidders for their price, then passes it into your ad server on the query-string. You want to target this bid price with a line item that earns you the same amount if it serves. * If you had 1-line item for every bid at a penny granularity of $0.01, $0.02, $0.03, ..., 1.23, ..., $4.56 you’d need 1,000 line items just to represent bids from $0-$10. We call this the “Exact” granularity option. * Creating 1,000 line items can be a hassle, so publishers typically use price buckets to represent price ranges that matter. For example, you could group bids into 10 cent increments, so bids of $1.06 or $1.02 would be rounded down into a single price bucket of $1.00. +The SDK itself doesn't deal with granularity. Instead, these details are set up in Prebid Server and your ad server. The specific details about how to set up the price granularity will differ for each Prebid Mobile managed service company -- check with your provider to get details for their system. + ## Accepted values for price granularity + `"low"`: $0.50 increments, capped at $5 CPM @@ -28,6 +26,12 @@ Example: + `"high"`: $0.01 increments, capped at $20 CPM + `"auto"`: Applies a sliding scale to determine granularity as shown in the [Auto Granularity](#autoGranularityBucket) table below. + `"dense"`: Like `"auto"`, but the bid price granularity uses smaller increments, especially at lower CPMs. For details, see the [Dense Granularity](#denseGranularityBucket) table below. ++ `"custom"`: If none of the above apply, your service provider should provide a way to establish arbitrary price buckets. + +Notes: +- Banner and outstream video generally share the same ad server line items. +- PBS-Java support the "mediatypepricegranularity" enhancement, which lets you define different +granularities for banner and video @@ -54,10 +58,8 @@ Example: | CPM > $20 | Caps the price bucket at $20 | $24.82 floored to $20.00 | -{: .alert.alert-success :} -**Action Item:** Once you have decided the price granularity, go to Prebid Server [account page](https://prebid.adnxs.com/account/) to set the price granularity setting for your account. - +Please contact your Prebid Mobile host company for details about how to implement granularity. -The below screenshot is taken from the Prebid Server account page where you can choose your price granularity setting from the options. +## Further Reading -{: .pb-md-img :} +- [Prebid.js MediaTypePriceGranularity](/dev-docs/publisher-api-reference.html#setConfig-MediaType-Price-Granularity) diff --git a/prebid-mobile/adops-setup-full-screen-video-mopub.md b/prebid-mobile/adops-setup-full-screen-video-mopub.md new file mode 100644 index 0000000000..429c0488d3 --- /dev/null +++ b/prebid-mobile/adops-setup-full-screen-video-mopub.md @@ -0,0 +1,57 @@ +--- +layout: page_v2 +title: Setup Rewarded Video for MoPub +description: Setup Full Screen Video for MoPub +pid: 1 +top_nav_section: prebid-mobile +nav_section: prebid-mobile-adops +sidebarType: 3 +--- + +# Step-by-Step Line Item Setup for Full-screen Video on MoPub + +* TOC +{:toc } + +This page provides step-by-step instructions to set up full-screen video line items on MoPub to be used with the Prebid Mobile SDK. + +## Step 1. Create full screen adUnit +
+
+## Step 2. Add a line item
+In the *Add a Line Item* section:
+1. For the *Type and Priority* settings, select *Non-Guaranteed* as the type and set the priority to *12*. This ensures the line item will compete with all other demand.
+2. Set the Rate to the price you want to target.
+
+3. In the *Advanced Targeting* section, set the target for *Keywords* to `hb_pb:0.50`
+
+
+For each level of pricing granularity required, one line item/creative pairing will need to be set up.
+
+Line items must be set up to target custom keywords that include bid price information. The bid price keywords will contain how much the buyer bid on the impression.
+
+Prebid Mobile, by default, will send the highest bid price to MoPub using the keyword `hb_pb` but will also submit the key `hb_pb_BIDDERCODE` for each bidder. You can decide to create one set of line items for all bidders or one set of line items for each bidder.
+
+## Step 3. Add creatives to your line item
+Full-screen video creatives must have a *VAST tag* with the *Format* set to *Fullscreen* that includes the code below:
+```
++
+
+The `hb_uuid` variable value is the cache id that will load the ad markup from the bid stored in Prebid Cache. Within each line item, for each ad unit size, there should be one creative with this content.
+
+The XML can be constructed by providing the VAST tag URL as:
+`https://%%KEYWORD:hb_cache_host%%%%KEYWORD:hb_cache_path%%?uuid=%%KEYWORD:hb_uuid%%`
+
+## Step 4. Duplicate line items
+Duplicate your line items according to your [price granularity](/prebid-mobile/adops-price-granularity.html) setting.
diff --git a/prebid-mobile/adops-setup-rewarded-video-mopub.md b/prebid-mobile/adops-setup-rewarded-video-mopub.md
new file mode 100644
index 0000000000..839a8593e7
--- /dev/null
+++ b/prebid-mobile/adops-setup-rewarded-video-mopub.md
@@ -0,0 +1,55 @@
+---
+layout: page_v2
+title: Setup Rewarded Video for MoPub
+description: Setup Rewarded Video for MoPub
+pid: 1
+top_nav_section: prebid-mobile
+nav_section: prebid-mobile-adops
+sidebarType: 3
+---
+
+# Step-by-Step Line Item Setup for Rewarded Video on MoPub
+
+* TOC
+{:toc }
+
+This page provides step-by-step instructions to set up rewarded-video line items on MoPub to be used with the Prebid Mobile SDK.
+
+## Step 1. Add a line item
+
+ In the *Add a Line Item* section:
+ 1. For the *Type and Priority* settings, select *Non-Guaranteed* as the type and set the priority to *12*. This ensures the line item will compete with all other demand.
+ 2. Set the Rate to the price you want to target.
+
+ 3. In the *Advanced Targeting* section, set the target for *Keywords* to `hb_pb:0.50`
+
+
+For each level of pricing granularity required, one line item/creative pairing will need to be set up.
+
+Line items must be set up to target custom keywords that include bid price information. The bid price keywords will contain how much the buyer bid on the impression.
+
+Prebid Mobile, by default, will send the highest bid price to MoPub using the keyword `hb_pb` but will also submit the key `hb_pb_BIDDERCODE` for each bidder. You can decide to create one set of line items for all bidders or one set of line items for each bidder.
+
+## Step 2. Add creatives to your line item
+Rewarded video creatives must have a *VAST tag* with the *Format* set to *Rewarded Video* that includes the code below:
+
+```
++
+The `hb_uuid` variable value is the cache id that will load the ad markup from the bid stored in Prebid Cache. Within each line item, for each ad unit size, there should be one creative with this content.
+
+The XML can be constructed by providing the VAST tag URL as:
+`https://%%KEYWORD:hb_cache_host%%%%KEYWORD:hb_cache_path%%?uuid=%%KEYWORD:hb_uuid%%`
+
+## Step 3. Duplicate line items
+Duplicate your line items according to your [price granularity](/prebid-mobile/adops-price-granularity.html) setting.
diff --git a/prebid-mobile/dr-prebid.md b/prebid-mobile/dr-prebid.md
index d672e5b846..799f8dab86 100644
--- a/prebid-mobile/dr-prebid.md
+++ b/prebid-mobile/dr-prebid.md
@@ -55,6 +55,8 @@ The type of ad you want to test. This will be the ad type that is associated wit
Select from:
- *Banner*
- *Interstitial*
+- *Native*
+- *Video*
**Ad Size**
@@ -94,6 +96,10 @@ Select your Prebid Server host:
- *AppNexus*
- *Rubicon*
+- *Custom*
+
+**Custom Server Host**
+Provide the url of the custom hosted prebid server
**Account ID**
diff --git a/prebid-mobile/pbm-api/android/pbm-adunit-android.md b/prebid-mobile/pbm-api/android/pbm-adunit-android.md
index 5a2acdc87d..5bdddecf88 100755
--- a/prebid-mobile/pbm-api/android/pbm-adunit-android.md
+++ b/prebid-mobile/pbm-api/android/pbm-adunit-android.md
@@ -47,12 +47,62 @@ PB Ad Slot is an identifier tied to the placement the ad will be delivered in. T
Trigger a call to Prebid Server to retrieve demand for this Prebid Mobile ad unit.
+#### Mopub or GAM
+
+By default, Prebid SDK uses inflection to determine the publisher ad server, one of Mopub or Google Ad Manager (GAM), to convert Prebid's targeting keys (PBS bid keys, host and cache key) to trigger targeted line items. To render ads in ad servers other than Mopub or GAM, follow the instructions in the 3rd party ad server below.
+
+
**Parameters**
- `adObj`: This is the ad server request object (for [Google Ad Manager](https://developers.google.com/android/reference/com/google/android/gms/ads/doubleclick/PublisherAdRequest) and for [Mopub](https://developers.mopub.com/publishers/reference/android/MoPubView/)). If you do not wish to add any additional /custom key values to the ad server after the Prebid auction, pass `adObj` to the fetchDemand function, where Prebid SDK will set all the Prebid targeting keys as well as any keys added prior to auction
- As of Prebid SDK 1.7, a publisher can optionally pass the Google Ad Manager `builder` object of the [Google Ad Manager Mobile Ads SDK](https://developers.google.com/android/reference/com/google/android/gms/ads/doubleclick/PublisherAdRequest.Builder) to pass custom keys to Google Ad Manager after the Prebid Auction
- `onCompleteListener`: listener object
+#### 3rd Party Ad Server
+
+The default ad servers for Prebid's Mobile SDK are MoPub and GAM. The SDK can be expanded to include support for 3rd party ad servers through the fetchDemand function. This function returns the Prebid Server bidder key/values (targeting keys), which can then be passed to the ad server of choice.
+
+In this mode, the publisher will be responsible for the following actions:
+* Call fetchDemand with extended targetingDict callback
+* Retrieve targeting keys from extended fetchDemand function
+* Convert targeting keys into the format for your ad server
+* Pass converted keys to your ad server
+* Render ad with Prebid Universal Creative or custom renderer
+
+
+**Function Callbacks**
+
+* `ResultCode`: enum [result codes](https://docs.prebid.org/prebid-mobile/pbm-api/android/pbm-api-result-codes-android.html)
+* `unmodifiableMap`: [Prebid Server Response targeting keys](https://docs.prebid.org/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#targeting)
+
+
+```
+func fetchDemand(completion: @escaping(_ result: ResultCode, _ kvResultDict: [String : String]?) -> Void)
+```
+
+{: .alert.alert-warning :}
+unmodifiableMap is an immutable object. Attempting to modify at runtime will throw an UnsupportedOperationException error. This is to prevent accidental changes to the Prebid targeting keys. If there is a desire to update, create or remove a key, making a copy of unmodifiableMap is recommended before passing to the ad server.
+
+
+Example:
+
+```java
+func loadMPRewardedVideo() {
+private void loadMPRewardedVideo() {
+
+ adUnit.fetchDemand(new OnCompleteListener2() {
+ @Override
+ public void onComplete(ResultCode resultCode, Map(gdprApplies = false)|The SDK will read and pass IDFA/AAID info to server. |The SDK will **not** read and pass IDFA/AAID info to server. | The SDK will read and pass IDFA/AAID info to server.| +|consentRequired=true
(gdprApplies = true)|The SDK will read and pass IDFA/AAID info to server. |The SDK will **not** read and pass IDFA/AAID info to server. | The SDK will **not** read and pass IDFA/AAID info to server.| +|consentRequired=undefined
(gdprApplies = undefined)|The SDK will read and pass IDFA/AAID info to server. |The SDK will **not** read and pass IDFA/AAID info to server. | The SDK will read and pass IDFA/AAID info to server.| + +{% capture codeNote %} + Publishers set the value of `gdprApplies` in `Targeting.shared.subjectToGDPR` and `purposeConsent` in `Targeting.shared.purposeConsents`. + + {% endcapture %} + +{% include /alerts/alert_important.html content=codeNote %} + +## Code Samples + +### iOS + +
+
+
+### Android
+
++ + /** * Set the consentRequired value in the SDK + * + * @param true if subject to GDPR regulations, false otherwise + */ + Targeting.shared.subjectToGDPR = false; + + /** + * Set the consent string in the SDK + * + * @param A valid Base64 encode consent string as per https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework + */ + Targeting.shared.gdprConsentString = "BOMyQRvOMyQRvABABBAAABAAAAAAEA"; + + /** + * Set the purpose consents in the SDK + * + * @param A valid Binary String: The '0' or '1' at position n – where n's indexing begins at 0 – indicates the consent status for purpose ID n+1; false and true respectively. eg. '1' at index 0 is consent true for purpose ID 1 + */ + Targeting.shared.purposeConsents = "100000000000000000000000"; + + + /** + * Get the device consent extracted from the purpose1 consent provided + * + */ + let deviceAccessConsent = Targeting.shared.getDeviceAccessConsent(); + ++
+
## California Consumer Privacy Act (CCPA)
@@ -81,5 +168,8 @@ The job of the Prebid SDK will:
- Not perform or make any attempt to validate or ensure correctness of the US Privacy string
- Not strip any user data or signaling of the request regardless of Notice and Opt out signal
-
It is worth noting Prebid Server will be a passthrough as well and will not validate format or correctness of US Privacy signal nor strip any user data from the request either, even if the presence of an opt out.
+
+
+
+
diff --git a/prebid-server/bidders/pbs-build-a-bid-adapter.md b/prebid-server/bidders/pbs-build-a-bid-adapter.md
new file mode 100644
index 0000000000..39e278d64c
--- /dev/null
+++ b/prebid-server/bidders/pbs-build-a-bid-adapter.md
@@ -0,0 +1,10 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Bidder | Build An Adapter
+
+---
+
+# Prebid Server | Bidder | Build An Adapter
+
+Check back for updated content.
diff --git a/prebid-server/developers/add-new-analytics-module.md b/prebid-server/developers/add-new-analytics-module.md
deleted file mode 100644
index 378b14e561..0000000000
--- a/prebid-server/developers/add-new-analytics-module.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-layout: page_v2
-sidebarType: 5
-title: Prebid Server | Developers | Adding a New Analytics Module
-
----
-# Adding a New Analytics Module
-
-This document describes how to add a new Analytics module to Prebid Server.
-
-### 1. Define config params
-
-Analytics modules are enabled through the [Configuration](https://github.com/prebid/prebid-server/blob/master/docs/developers/configuration.md).
-You'll need to define any properties in [config/config.go](https://github.com/prebid/prebid-server/blob/master/config/config.go)
-which are required for your module.
-
-### 2. Implement your module
-
-Your new module belongs in the `analytics/{moduleName}` package. It should implement the `PBSAnalyticsModule` interface from
-[analytics/core.go](https://github.com/prebid/prebid-server/blob/master/analytics/core.go)
-
-### 3. Connect your Config to the Implementation
-
-The `NewPBSAnalytics` function inside [analytics/config/config.go](https://github.com/prebid/prebid-server/blob/master/analytics/config/config.go) instantiates Analytics modules
-using the app config. You'll need to update this to recognize your new module.
-
-### Example
-
-The [filesystem](https://github.com/prebid/prebid-server/tree/master/analytics/filesystem) module is provided as an example. This module will log dummy messages to a file.
-
-It can be configured with:
-
-```yaml
-analytics:
- file:
- filename: "path/to/file.log
-```
-
-Prebid Server will then write sample log messages to the file you provided.
diff --git a/prebid-server/developers/add-new-bidder-go.md b/prebid-server/developers/add-new-bidder-go.md
new file mode 100644
index 0000000000..4f35c310c8
--- /dev/null
+++ b/prebid-server/developers/add-new-bidder-go.md
@@ -0,0 +1,266 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Developers | Adding a New Bidder
+
+---
+
+# Prebid Server - Adding a New Bidder in Go
+{: .no_toc}
+
+* TOC
+{:toc }
+
+This document describes how to add a new bid adapter to the Go version of Prebid Server. Our recommendation is to build new adapters in Go because we port them to Java within a couple of months. But if you'd like to build them yourself in both, there are [instructions for building an adapter in PBS-Java](/prebid-server/developers/add-new-bidder-java.html).
+
+**NOTE**: To make everyone's lives easier, Bidders are expected to make net-price bids (e.g. "If this ad wins, what will the publisher make?"), not gross-price bids.
+Publishers can correct for gross-price bids by setting [Bid Adjustments](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#bid-adjustments) to account for fees.
+
+## Choose a Bidder Name
+
+This name must be unique. Existing BidderNames can be found [here](https://github.com/prebid/prebid-server/blob/master/openrtb_ext/bidders.go).
+
+Throughout the rest of this document, substitute `{bidder}` with the name you've chosen.
+
+## Define Your Bidder Params
+
+Bidders may define their own APIs for Publishers to pass custom values subject to these guidelines:
+
+- Don't duplicate values already present in the [OpenRTB 2.5 spec](https://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf).
+- Don't add bidder-specific parameters that already have Prebid conventions: first party data, floors, schain, video params, referrer, COPPA.
+
+Publishers will send values for these parameters in `request.imp[i].ext.{bidder}` of
+[the Auction endpoint](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html). Prebid Server will preprocess these so that
+your bidder will access them at `request.imp[i].ext.bidder`--regardless of what your `{bidder}` name is.
+
+## Implement Your Bidder
+
+Bidder implementations are scattered throughout several files.
+
+- `adapters/{bidder}/{bidder}.go`: contains an implementation of [the Bidder interface](https://github.com/prebid/prebid-server/blob/master/adapters/bidder.go).
+- `openrtb_ext/imp_{bidder}.go`: contract classes for your Bidder's params.
+- `usersync/usersyncers/{bidder}.go`: A [Usersyncer](https://github.com/prebid/prebid-server/blob/master/usersync/usersync.go) which returns cookie sync info for your bidder.
+- `usersync/usersyncers/{bidder}_test.go`: Unit tests for your Usersyncer
+- `static/bidder-params/{bidder}.json`: A [draft-4 json-schema](https://spacetelescope.github.io/understanding-json-schema/) which [validates your Bidder's params](https://www.jsonschemavalidator.net/).
+- `static/bidder-info/{bidder}.yaml`: contains metadata (e.g. contact email, platform & media type support) about the adapter. Note that email cannot be a single individual – we need robust maintainer contact info read by multiple people like "support@example.com".
+
+Bidder implementations may assume that any params have already been validated against the defined json-schema.
+
+{: .alert.alert-warning :}
+Prebid Server bid adapters must follow all required conventions defined in the [Module Rules](/dev-docs/module-rules.html). Not doing so could lead to delays in approving your adapter for inclusion in Prebid Server. If you'd like to apply for an exception to one of the rules, make your request in a new [Prebid Server issue](https://github.com/prebid/prebid-server/issues).
+
+### Bid Request Standards
+
+Prebid clients ([Prebid.js](/use-cases/pbs-pbjs.html), [Prebid SDK](/use-cases/pbs-sdk.html), and [AMP](/use-cases/pbs-amp.html)) pass a number of parameters
+that bid adapters should take into account:
+
+- Currency: The publisher's desired bid currency is in the OpenRTB `cur` field. If your bid is in a different currency, you must set the bid currency in the response.
+- Bid Floor: `imp[].bidfloor` and `imp[].bidfloorcur` - please make use of this value before responding with a bid.
+- First Party Data: bidders should look in these locations for first party data: `imp[].ext.context.data.*`, `site.ext.data.*`, `app.ext.data.*`, and `user.ext.data.*`.
+- Supply Chain: `source.ext.schain`
+- GDPR: `regs.ext.gdpr` and `user.ext.consent`
+- CCPA: `regs.ext.us_privacy`
+- COPPA: `regs.coppa`
+- Test: Bidders should be aware that the OpenRTB `test` flag indicates non-production traffic.
+
+### Bid Response Metadata
+
+In addition to the standard OpenRTB2.5 response fields, Prebid encourages bidders to
+provide additional metadata in their bid response:
+
+{% highlight js %}
+{
+ "seatbid": [{
+ "bid": [{
+ ...
+ "ext": {
+ "prebid": {
+ "meta": {
+ "networkId": NETWORK_ID,
+ "networkName": NETWORK_NAME
+ "agencyId": AGENCY_ID,
+ "agencyName": AGENCY_NAME,
+ "advertiserId": ADVERTISER_ID,
+ "advertiserName": ADVERTISER_NAME,
+ "advertiserDomains": [ARRAY_OF_ADVERTISER_DOMAINS]
+ "brandId": BRAND_ID,
+ "brandName": BRAND_NAME,
+ "primaryCatId": IAB_CATEGORY,
+ "secondaryCatIds": [ARRAY_OF_IAB_CATEGORIES],
+ }
+ }
+ }
+ }]
+ }]
+}
+{% endhighlight %}
+
+Notes:
+
+- `advertiserDomains` is the same as the OpenRTB 2.5 `bid.adomain` field but replicated here for downstream convenience
+- See the [Prebid.js Bidder Adapter](/dev-docs/bidder-adaptor.html) page for details about the requested values for each field.
+
+{: .alert.alert-info :}
+Please provide as much information as possible in the meta object. Publishers use this data for tracking down bad creatives and ad blocking. The advertiserDomains field is particularly useful. Some of these fields may become required in a future release.
+
+### BidResponse Requirements
+
+**Note**: In order to be part of the auction, all bids must include:
+
+- An ID
+- An ImpID which matches one of the `Imp[i].ID`s from the incoming `BidRequest`
+- A positive `Bid.Price`
+- A `Bid.CrID` which uniquely identifies the Creative in the bid.
+
+Bids which don't satisfy these standards will be filtered out before Prebid Server responds.
+
+## Long-Form Video Support
+If long-form video will be supported ensure the bidder has the following:
+
+{: .table .table-bordered .table-striped }
+|Field |Type |Description
+|----------------|-------------------------------|-----------------------------|
+|bid.bidVideo.PrimaryCategory | string | The category for the bid. This should be able to be translated to Primary ad server format|
+|TypedBid.bid.Cat | []string | The category for the bid. Should be an array with length 1 containing the value in IAB format|
+|TypedBid.BidVideo.Duration | int | Ad duration in seconds|
+|TypedBid.bid.Price | float | Bid price|
+
+{% capture alertNote %}
+`bid.bidVideo.PrimaryCategory` or `TypedBid.bid.Cat` should be specified.
+{% endcapture %}
+
+{% include alerts/alert_note.html content=alertNote %}
+To learn more about IAB categories, refer site provided by adtagmacros.com: [IAB categories](https://adtagmacros.com/list-of-iab-categories-for-advertisement/)
+
+## Test Your Bidder
+
+### Automated Tests
+
+Bidder tests live in two files:
+
+- `adapters/{bidder}/{bidder}_test.go`: contains unit tests for your Bidder implementation.
+- `adapters/{bidder}/params_test.go`: contains unit tests for your Bidder's JSON Schema params.
+
+Since most Bidders communicate through HTTP using JSON bodies, you should
+use the [JSON-test utilities](https://github.com/prebid/prebid-server/blob/master/adapters/adapterstest/test_json.go).
+This comes with several benefits, which are described in the source code docs.
+
+If your HTTP requests don't use JSON, you'll need to write your tests in the code.
+We expect to see at least 90% code coverage on each Bidder.
+
+Bidders should also define an `adapters/{bidder}/{bidder}test/params/race/{mediaType}.json` file for any supported
+Media Types (banner, video, audio, or native). These files should contain a JSON object with all the bidder params
+(required & optional) which are expected in supporting that video type. This will be used in automated tests which
+check for race conditions across Bidders.
+
+### Manual Tests
+
+Build and start your server:
+
+```bash
+go build .
+./prebid-server
+```
+
+Then `POST` an OpenRTB Request to `https://localhost:8000/openrtb2/auction`.
+
+If at least one `request.imp[i].ext.{bidder}` is defined in your Request,
+then your bidder should be called.
+
+To test user syncs, [save a UID](/prebid-server/endpoints/pbs-endpoint-setuid.html) using the FamilyName of your Usersyncer.
+The next time you use `/openrtb2/auction`, the OpenRTB request sent to your Bidder should have
+`BidRequest.User.BuyerUID` with the value you saved.
+
+## Automated Tests
+
+This project uses [TravisCI](https://travis-ci.org/) to make sure that every PR passes automated tests.
+To reproduce these tests locally, use:
+
+```
+./validate --nofmt --cov
+```
+
+### Writing Tests
+
+Tests for `some-file.go` should be placed in the file `some-file_test.go` in the same package.
+For more info on how to write tests in Go, see [the Go docs](https://golang.org/pkg/testing/).
+
+### Adapter Tests
+
+If your adapter makes HTTP calls using standard JSON, you should use the
+[RunJSONBidderTest](https://github.com/prebid/prebid-server/blob/master/adapters/adapterstest/test_json.go#L50) function.
+
+This will be much more thorough, convenient, maintainable, and reusable than writing standard Go tests
+for your adapter.
+
+### Concurrency Tests
+
+Code which creates new goroutines should include tests which thoroughly exercise its concurrent behavior.
+The names of functions which test concurrency should start with `TestRace`. For example `TestRaceAuction` or `TestRaceCurrency`.
+
+The `./validate.sh` script will run these using the [Race Detector](https://golang.org/doc/articles/race_detector.html).
+
+## Add your Bidder to the Server
+
+- Add a new [BidderName constant](https://github.com/prebid/prebid-server/blob/master/openrtb_ext/bidders.go) for your `{bidder}`.
+- Update the [newAdapterMap function](https://github.com/prebid/prebid-server/blob/master/exchange/adapter_map.go) to make your Bidder available in auctions.
+- Update the [newSyncerMap function](https://github.com/prebid/prebid-server/blob/master/usersync/usersync.go) to make your Bidder available for user syncs.
+
+## Document Your Adapter
+
+There are two documents required before we'll accept your pull request:
+
+1. Repo metadata - create a new file https://github.com/prebid/prebid-server/blob/master/static/bidder-info/BIDDERCODE.yaml based on one of the other ones there. Note that you must provide an email that's not a single individual -- we need robust maintainer contact info read by multiple people like "support@example.com".
+1. User documentation - required to appear in the [Prebid Server adapters page](/dev-docs/pbs-bidders.html).
+ 1. If you already have a Prebid.js bid adapter, update your bidders existing file in https://github.com/prebid/prebid.github.io/tree/master/dev-docs/modules to add the `pbs: true` variable in the header section.
+ 1. If you don't have a Prebid.js bid adapter, create a new file in https://github.com/prebid/prebid.github.io/tree/master/dev-docs/modules based on the example below.
+
+```
+---
+layout: bidder
+title: example
+description: Prebid example Bidder Adapter
+biddercode: example
+gdpr_supported: true/false
+tcf2_supported: true/false
+gvl_id: 111
+usp_supported: true/false
+coppa_supported: true/false
+schain_supported: true/false
+userId: (list of supported vendors)
+media_types: banner, video, native
+safeframes_ok: true/false
+bidder_supports_deals: true/false
+pbjs: true/false
+pbs: true/false
+prebid_member: true/false
+---
+
+### Note:
+
+The Example Bidding adapter requires setup before beginning. Please contact us at setup@example.com
+
+### Bid Params
+
+{: .table .table-bordered .table-striped }
+| Name | Scope | Description | Example | Type |
+|---------------|----------|-----------------------|-----------|-----------|
+| `placement` | required | Placement id | `'11111'` | `string` |
+```
+Notes on the metadata fields:
+- Add `pbs: true`. If you also have a [Prebid.js bid adapter](/dev-docs/bidder-adaptor.html), add `pbjs: true`. Default is false for both.
+- If you support the GDPR consentManagement module and TCF1, add `gdpr_supported: true`. Default is false.
+- If you support the GDPR consentManagement module and TCF2, add `tcf2_supported: true`. Default is false.
+- If you're on the IAB's Global Vendor List, place your ID in `gvl_id`. No default.
+- If you support the US Privacy consentManagementUsp module, add `usp_supported: true`. Default is false.
+- If you support one or more userId modules, add `userId: (list of supported vendors)`. Default is none.
+- If you support video and/or native mediaTypes add `media_types: video, native`. Note that display is added by default. If you don't support display, add "no-display" as the first entry, e.g. `media_types: no-display, native`. No defaults.
+- If you support COPPA, add `coppa_supported: true`. Default is false.
+- If you support the [supply chain](/dev-docs/modules/schain.html) feature, add `schain_supported: true`. Default is false.
+- If your bidder doesn't work well with safeframed creatives, add `safeframes_ok: false`. This will alert publishers to not use safeframed creatives when creating the ad server entries for your bidder. No default.
+- If your bidder supports deals, set `bidder_supports_deals: true`. No default value.
+- If you're a member of Prebid.org, add `prebid_member: true`. Default is false.
+
+## Contribute
+
+Finally, [Contribute](https://github.com/prebid/prebid-server/blob/master/docs/developers/contributing.md) your Bidder to the project.
diff --git a/prebid-server/developers/add-new-bidder-java.md b/prebid-server/developers/add-new-bidder-java.md
new file mode 100644
index 0000000000..5a4d296f70
--- /dev/null
+++ b/prebid-server/developers/add-new-bidder-java.md
@@ -0,0 +1,217 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Developers | Adding a New Bidder
+
+---
+
+# Prebid Server - Adding a New Bidder - Java
+{: .no_toc}
+
+* TOC
+{:toc }
+
+This document describes how to add a new bid adapter to the Java version of Prebid Server. However, our recommendation is to [build new adapters in Go](/prebid-server/developers/add-new-bidder-go.html) because we port them to Java within a couple of months.
+
+**NOTE**: To make everyone's lives easier, Bidders are expected to make net-price bids (e.g. "If this ad wins, what will the publisher make?"), not gross-price bids.
+Publishers can correct for gross-price bids by setting [Bid Adjustments](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#bid-adjustments) to account for fees.
+
+## Choose a Bidder Name
+
+This name must be unique. Existing BidderNames can be found [here](https://github.com/rubicon-project/prebid-server-java/tree/master/src/main/java/org/prebid/server/bidder).
+
+Throughout the rest of this document, substitute `{bidder}` with the name you've chosen.
+
+## Define Your Bidder Params
+
+Bidders may define their own APIs for Publishers to pass custom values subject to these guidelines:
+
+- Don't duplicate values already present in the [OpenRTB 2.5 spec](https://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf).
+- Don't add bidder-specific parameters that already have Prebid conventions: first party data, floors, schain, video params, referrer, COPPA.
+
+Publishers will send values for these parameters in `request.imp[i].ext.{bidder}` of
+[the Auction endpoint](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html). Prebid Server will preprocess these so that
+your bidder will access them at `request.imp[i].ext.bidder`--regardless of what your `{bidder}` name is.
+
+## Implement Your Bidder
+
+Bidder implementations are scattered throughout several files:
+- `src/main/java/org/prebid/server/bidder/{bidder}/{bidder}Bidder.java`: contains an implementation of [the Bidder interface](../../src/main/java/org/prebid/server/bidder/Bidder.java).
+- `src/main/java/org/prebid/server/bidder/{bidder}/{bidder}Adapter.java`: contains an implementation of [the Adapter interface](../../src/main/java/org/prebid/server/bidder/Adapter.java).
+- `src/main/java/org/prebid/server/bidder/{bidder}/{bidder}Usersyncer.java`: contains an implementation of [the Usersyncer interface](../../src/main/java/org/prebid/server/bidder/Usersyncer.java).
+- `src/main/java/org/prebid/server/proto/openrtb/ext/{bidder}`: contract classes for your Bidder's params.
+- `src/main/resources/static/bidder-params/{bidder}.json`: A [draft-4 json-schema](https://spacetelescope.github.io/understanding-json-schema/) which [validates your Bidder's params](https://www.jsonschemavalidator.net/).
+
+Bidder implementations may assume that any params have already been validated against the defined json-schema.
+
+{: .alert.alert-warning :}
+Prebid Server bid adapters must follow all required conventions defined in the [Module Rules](/dev-docs/module-rules.html). Not doing so could lead to delays in approving your adapter for inclusion in Prebid Server. If you'd like to apply for an exception to one of the rules, make your request in a new [Prebid Server issue](https://github.com/prebid/prebid-server/issues).
+
+### Generic OpenRTB Bidder
+
+There's an option to implement a bidder by using a pre-existing template.
+OpenrtbBidder(https://github.com/rubicon-project/prebid-server-java/blob/master/src/main/java/org/prebid/server/bidder/OpenrtbBidder.java) is an abstract class that
+implements Bidder
+
+ /** * Set the consentRequired value in the SDK
+ *
+ * @param true if subject to GDPR regulations, false otherwise
+ */
+ TargetingParams.setSubjectToGDPR(context, true);
+
+
+ /**
+ * Set the consent string in the SDK
+ *
+ * @param A valid Base64 encode consent string as per
+ * https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework
+ */
+ TargetingParams.setGDPRConsentString("BOMyQRvOMyQRvABABBAAABAAAAAAEA");
+
+ /**
+ * Set the purpose consents in the SDK
+ *
+ * @param A valid Binary String: The '0' or '1' at position n – where n's indexing begins at 0 – indicates the consent status for purpose ID n+1; false and true respectively. eg. '1' at index 0 is consent true for purpose ID 1
+ */
+ TargetingParams.setPurposeConsents("101010001");
+
+
+ | |
+| [Currency](/prebid-server/features/pbs-currency.html) | Request-Defined Rates | Allows the request to define its own currency rates. | | |
+| [Deals](/prebid-server/features/pbs-deals.html) | Core | Basic deal support, creating hb_deal targeting when appropriate. | | |
+| [AMP](/prebid-server/use-cases/pbs-amp.html) | Core | Reads and responds to the /openrtb2/amp endpoint | | |
+| Targeting | Core | Request can specify `includewinners` and `includebidderkeys`. These cause PBS to emit seatbid[].bid[].ext.prebid.targeting values. | | |
+| Targeting | Format | Request can specify `includeformat`, which causes PBS to emit hb_format along with other targeting values like hb_pb, etc. | | |
+| [Price Granularity](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#targeting) | Core | Request can define quantization rules. Bids are quantized before being added to ad server targeting. | | |
+| Price Granularity | Mediatype pricegranularity | Request can define different quantization rules for different mediatypes. Bids are quantized before being added to ad server targeting. | | |
+| [GDPR](/prebid-server/features/pbs-privacy.html) | TCF 1.1 core | Able to: read the TCF1.1 global vendor list, parse incoming TCF1.1 consent strings, and [take appropriate enforcement action](https://docs.google.com/document/d/1g0zAYc_EfqyilKD8N2qQ47uz0hdahY-t8vfb-vxZL5w/edit). | | |
+| GDPR | TCF 1.1 Account Config | Able to turn on and off TCF1 enforcement per account. | | |
+| GDPR | TCF 1.1 Geo-lookup | Can use a geographic lookup service to help determine whether the incoming request is in-scope for GDPR. | | |
+| GDPR | TCF 1.1 GVL Fallback | Allow the host company to optionally add a default TCF1 GVL file. | | |
+| GDPR | TCF 2 core | Able to: read the TCF2 global vendor list, parse incoming TCF2 consent strings, and [take appropriate enforcement action](https://docs.google.com/document/d/1fBRaodKifv1pYsWY3ia-9K96VHUjd8kKvxZlOsozm8E/edit). | | |
+| GDPR | TCF 2 Account Config | Able to turn on and off TCF2 enforcement per account. | | |
+| GDPR | TCF 2 Geo-lookup | Can use a geographic lookup service to help determine whether the incoming request is in-scope for GDPR. | | |
+| GDPR | TCF 2 Integration type exception | Can be configured to turn off GDPR checks for a specific account and a specific integration type. e.g. Account 123 has a different legal basis for AMP. | | |
+| [US Privacy](/prebid-server/features/pbs-privacy.html) | USP core | Able to: read the US Privacy consent string (CCPA) and [take appropriate enforcement action](https://github.com/prebid/prebid-server/issues/1129). | | |
+| US Privacy | USP AMP support | Able to: read the US Privacy consent string from AMP requests and [take appropriate enforcement action](https://github.com/prebid/prebid-server/issues/1176). | | |
+| COPPA | Core | Able to read the COPPA flag and [take appropriate enforcement action](https://github.com/prebid/prebid-server/issues/929). | | |
+| [Cache](/prebid-server/features/pbs-caching.html) | Bids core | Accepts the ext.prebid.cache.bids parameter, storing bid objects in PBC. | | |
+| Cache | VAST core | Accepts the ext.prebid.cache.vastxml parameter, storing VAST responses in PBC. | | |
+| Cache | Winning-only flag | Accepts a 'ext.prebid.cache.winningonly' parameter on the request. If true, instead of caching all bids and VAST, only the winning bid or VAST is stored. | | |
+| [Stored Requests](/prebid-server/features/pbs-storedreqs.html) | Core | Accepts a stored request ID in the OpenRTB, looks it up against a local data store, and merges with the OpenRTB request record. | | |
+| Stored Responses | Stored Responses | Accepts a stored response ID in the OpenRTB, looks it up against a local data store, and merges with the OpenRTB response record. | | |
+| First Party Data | Core | Accepts core first party data attributes and supports ext.prebid.data.bidders. | | |
+| First Party Data | Bidder-specific data | Accepts bidder-specific first party data attributes. | | |
+| First Party Data | AMP first party data | Accepts first party data attributes on an AMP request. | | |
+| [Supply Chain](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#supply-chain-support) | Bidder-specific schains | Accepts bidder-specific schain | | |
+| Publisher Accounts | Core | Ability to enforce that requests coming in have a valid account ID. | | |
+| Publisher Accounts | AMP account parameter | Accept the account parameter on the AMP request. | | |
+| Publisher Accounts | Account-specific TTLs | Allow each account ID to have a custom PBC time-to-live for banner and video. | | |
+| [Video](/formats/video.html) | Core | Support for basic instream and outstream video: passes video parameters to adapters, stores VAST responses when instructed. | | |
+| Video | Outstream renderers | Support for bidders specifying their own renderers for outstream video. | | |
+| Video | Long-form video | Support for the [long-form video endpoint](/prebid-server/endpoints/openrtb2/pbs-endpoint-video.html). | | |
+| Video | IAB advertiser category mapping | Able to map IAB advertiser categories to a supplied mapping table. | | |
+| Video | Echo video attributes | To support mobile video, copies stored request video attributes to the response. | | |
+| [Interstitials](/prebid-server/features/pbs-interstitials.html) | Core | Support device.ext.prebid.interstitial.minwidthperc and device.ext.prebid.interstitial.minheightperc parameters, [dynamically updating the impression format object](https://github.com/prebid/prebid-server/issues/755) from a configurable list of sizes filtered by these parameters. | | |
+| [Aliases](/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#bidder-aliases) | Core | Can map bidders on an incoming request to a specific server-side bid adapter named in the request or defined in config. | | |
+| [User ID Sync](/prebid-server/developers/pbs-cookie-sync.html) | Core | Implements the /cookie_sync and /setuid endpoints. | | |
+| User ID Sync | Cooperative sync | Does a pixel sync with more than just the bidders on the page. | | |
+| [Events](https://docs.google.com/document/d/1ry0X4C2EV-R0pMrm1IQk9BstxaT395UCl3KKqTGa5c8/edit#heading=h.7w5yevygp2gz) | Events | Ability to process the /event endpoint, place /event URLs in the OpenRTB response, and place /event URLs in VAST XML. | | |
+| Events | Events vasttrack endpoint | Ability to process the /vasttrack endpoint initated by Prebid.js, placing /event URLs in VAST XML. | | |
+| Events | Events BidID Generation | Some bidders don't generate unique enough BidIDs to join with auction events. This feature allows the host company to inject a PBS-generated BidID alongside the bidder-generated ID. | | |
+| Analytics | Analytics module support | Allows developers to plug in a [custom analytics adapter](https://github.com/prebid/prebid-server/blob/master/docs/developers/add-new-analytics-module.md). | | |
+| [Bidder Info Endpoints](/prebid-server/endpoints/info/pbs-endpoint-info.html) | Core | Provides details on which bidders and parameters exist in this Prebid Server. | | |
+| [Troubleshooting](/troubleshooting/pbs-troubleshooting.html) | Test flag | Accepts the OpenRTB 'test' flag, emitting additional debug info on responses. | | |
+| Troubleshooting | Debug flag | Accepts the ext.prebid.debug flag, emitting additional debug info on responses. | | |
+| Operations | Core metrics | Emits detailed operational metrics to back-end systems: Graphite, Influx, and Prometheus | | |
+| Operations | Circuit breaker | Protects system performance during fault scenarios by detecting problems with external and internal endpoints, turning them off temporarily when a problem occurs. | | |
+| Operations | [Server default request](/prebid-server/features/pbs-default-request.html) | Support global defaults for incoming requests. | | |
+| Operations | IPv6 | Support taking IPv6 addresses and forwarding them to bidders. | | |
+| Operations | [Request Logging Admin Endpoints](/troubleshooting/pbs-troubleshooting.html#request-logging) | Log a limited number of requests to understand the raw data clients are sending. | | |
diff --git a/prebid-server/features/pbs-fpd.md b/prebid-server/features/pbs-fpd.md
new file mode 100644
index 0000000000..a488c46dac
--- /dev/null
+++ b/prebid-server/features/pbs-fpd.md
@@ -0,0 +1,130 @@
+---
+layout: page_v2
+sidebarType: 5
+title: First Party Data - Prebid Server
+---
+
+# First Party Data - Prebid Server
+{: .no_toc}
+
+* TOC
+{:toc}
+
+Prebid allows publishers to supply attributes related to their content
+and users, and to apply permissions so only certain bidders are allowed
+to access those attributes.
+
+{: .alert.alert-warning :}
+For now, this feature is only supported in PBS-Java and these conventions aren't implemented by all adapters. Please
+check with each of your bidders to make sure they're reading first
+party data from the standard Prebid locations.
+
+## How It Works
+
+Each of the three main sources of Prebid Server traffic will place
+First Party Data in the OpenRTB JSON in several places:
+
+{: .table .table-bordered .table-striped }
+| OpenRTB Attribute | Description | PBJS Source | SDK Source | AMP Source |
+| --- | --- | --- | --- | --- |
+| site.ATTR | Only standard OpenRTB attributes should be here: name, domain, cat, sectioncat, pagecat, page, ref, search, keywords. | config.fpd.context.ATTR | n/a | site.ATTR |
+| site.ext.data.ATTR | Any other site-related attributes should go here. | config.fpd.context.data | n/a | site.ext.data.ATTR |
+| app.ext.data.ATTR | Any app-related attributes should go here. | n/a | Targeting addContextData() | n/a |
+| user.ATTR | Only standard OpenRTB attributes should be here: yob, gender, keywords. | config.fpd.user.ATTR | n/a | user.ATTR |
+| user.ext.data.ATTR | Any other user-related attributes should go here. | config.fpd.user.data.ATTR | Targeting addUserData() | user.ext.data.ATTR |
+| imp[].ext.context.data.ATTR | AdUnit-specific attributes should go here. | AdUnit.fpd.context | AdUnit addContextData() | n/a |
+| ext.prebid.data.bidders[] | If specified, only these bidders are allowed to see fields in {site/app/user}.ext.data. | n/a | addBidderToAccessControlList() | bidders |
+| ext.prebid.bidderconfig | Bidder-specific config | [setBidderConfig()](/dev-docs/publisher-api-reference.html#module_pbjs.setBidderConfig) | n/a | n/a |
+
+This diagram summarizes how first party data flows into the OpenRTB JSON:
+
+{: .pb-lg-img :}
+
+{: .alert.alert-info :}
+Note that Prebid.js supports the [`setBidderConfig`](/dev-docs/publisher-api-reference.html#module_pbjs.setBidderConfig) method of defining
+bidder-specific first party data, while SDK and AMP only support the `ext.prebid.data.bidders[]` approach.
+
+## OpenRTB Examples
+
+In this example, only BidderA has access to the global first party data:
+```
+{
+ ext: {
+ prebid: {
+ data: { bidders: [ "bidderA" ] } // limit bidders that receive global data
+ }
+ },
+ site: {
+ keywords: "",
+ search: "",
+ ext: {
+ data: {
+ // only seen by bidderA as named in ext.prebid.data.bidders[]
+ GLOBAL CONTEXT DATA
+ }
+ }
+ },
+ user: {
+ keywords: "",
+ gender: "",
+ yob: 1999,
+ geo: {},
+ ext: {
+ data: {
+ // only seen by bidderA as named in ext.prebid.data.bidders[]
+ GLOBAL USER DATA
+ }
+ }
+ },
+ imp: [
+ ...
+ ext: {
+ context: {
+ keywords: "",
+ search: "",
+ data: {
+ // everyone sees this data
+ ADUNIT SPECIFIC CONTEXT DATA
+ }
+ }
+ }
+ ]
+}
+```
+
+This example shows an array of bidder-specific config:
+```
+{
+ ext: {
+ prebid: {
+ bidderconfig: [ {
+ bidders: [ 'bidderA', 'bidderB' ],
+ config: {
+ fpd: { site: { ... }, user: { ...} }
+ }
+ },{
+ bidders: [ 'bidderC' ],
+ config: {
+ fpd: { site: { ... }, user: { ...} }
+ }
+ }]
+ }
+ }
+}
+```
+
+## How Server-Side Bid Adapters Read First Party Data
+
+Bid adapters don't need to worry about whether the request came from
+Prebid.js, the SDK, or AMP -- everything is merged into the OpenRTB JSON. If a bid adapter receives first party data on any of the fields noted in
+the table above, they can simply pass that data to their endpoint in
+the expected way.
+
+In other words, just be aware of site.ext.data.ATTR, app.ext.data.ATTR, user.ext.data.ATTR,
+and imp[].ext.context.data.ATTR and either pass them straight through or map
+attributes to where your endpoints expect them.
+
+## Further Reading
+
+- [Prebid.js First Party Data](/features/firstPartyData.html)
+- [Prebid Server and AMP](/prebid-server/use-cases/pbs-amp.html)
diff --git a/prebid-server/features/pbs-interstitials.md b/prebid-server/features/pbs-interstitials.md
new file mode 100644
index 0000000000..1bd83d12fd
--- /dev/null
+++ b/prebid-server/features/pbs-interstitials.md
@@ -0,0 +1,57 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Features | Interstitials
+
+---
+
+# Prebid Server | Features | Interstitials
+
+Support for interstitial ads is enabled with the addition of two fields to the OpenRTB request: `device.ext.prebid.interstitial.minwidthperc`
+and `device.ext.interstial.minheightperc` The values will be numbers that indicate the minimum allowed
+size for the ad, as a percentage of the base side. For example, a width of 600 and "minwidthperc": 60
+would allow ads with widths from 360 to 600 pixels inclusive.
+
+Example:
+
+```
+{
+ "imp": [{
+ ...
+ "banner": {
+ "format": [
+ {"w":1, "h":1}
+ ],
+ ...
+ }
+ "instl": 1,
+ ...
+ }]
+ "device": {
+ ...
+ "h": 640,
+ "w": 320,
+ "ext": {
+ "prebid": {
+ "interstitial": {
+ "minwidthperc": 60,
+ "minheightperc": 60
+ }
+ }
+ }
+ }
+}
+```
+
+Upon receiving a request for an interstitial impression (`instl:1`) and these parameters set, PBS will rewrite the
+`format` object within the interstitial imp object.
+
+1. If the `format` array's first object is a size, PBS will take it as the max size for the interstitial.
+2. If the first entry in `format` is 1x1, it will use the device's size as the max size.
+3. Likewise, if `format` is not present, PBS will also use the device size as the max size.
+4. Each PBS host company configures a list of common interstitial ad sizes, generally organized by weighing the larger and more common sizes first.
+5. PBS generates a new format list for the interstitial imp by traversing this configured list and picking the first 10 sizes that fall within the imp's max size and minimum percentage size.
+6. There's no attempt to favor aspect ratios closer to the original size's aspect ratio.
+7. The limit of 10 is enforced to ensure we don't overload bidders with an overlong list.
+8. The `minwidthperc` and `minheightperc` parameters are passed to bidder adapters, so if desired, they may use their own size matching algorithms.
+
diff --git a/prebid-server/features/pbs-privacy.md b/prebid-server/features/pbs-privacy.md
new file mode 100644
index 0000000000..dd31507d47
--- /dev/null
+++ b/prebid-server/features/pbs-privacy.md
@@ -0,0 +1,104 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Features | Privacy
+---
+
+# Prebid Server | Features | Privacy
+{:.no_toc}
+
+* TOC
+{:toc}
+
+## Mobile 'Limit Ad Tracking' flag
+
+If PBS receives 'device.lmt' flag in the OpenRTB request, it does the following anonymization:
+
+- Mask take off the last byte of the IPv4 address and the last 2 bytes of IPv6 addresses
+- Removes user.id and user.buyeruid
+- Removes the request.device.ifa attribute
+- Rounds the request.device.geo. {lat,lon} to two decimal places
+
+## GDPR
+
+Prebid Server host companies and publishers have the ability to control the enforcement
+activities that take place.
+
+The enforcement strategy changed significantly between TCF 1.1 and TCF 2.0. [TCF2](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20Consent%20string%20and%20vendor%20list%20formats%20v2.md) is a
+more nuanced and stricter policy.
+
+{: .alert.alert-info :}
+If a Prebid Server host company wants to support GDPR, they must currently [register for the IAB Global Vendor List](https://register.consensu.org/).
+The user must provide legal basis for the host company to read/write cookies or `/cookie_sync` will return an empty response with no syncs and `/setuid` will fail.
+
+### TCF 1.1
+
+If Prebid Server determines that the user is in GDPR scope and doesn't consent
+to *all* of the vendor's 'purposes' as declared in the Global Vendor List, it 'anonymizes'
+the request to the adapters:
+
+- Mask take off the last byte of the IPv4 address and the last 2 bytes of IPv6 addresses
+- Removes user.id and user.buyeruid
+- Removes the request.device.ifa attribute
+- Rounds the request.device.geo. {lat,lon} to two decimal places
+
+Full details are available [here](https://github.com/rubicon-project/prebid-server-java/blob/master/docs/developers/PrebidServerJava_GDPR_Requirements.pdf).
+
+### TCF 2.0
+
+If Prebid server determines the user is in GDPR scope, then consent is independently tested
+for each 'Purpose' with different consequences for each:
+
+{: .table .table-bordered .table-striped }
+| Activity | Legal Basis Required |
+| ----------- | ------------------------------------ |
+| Responding to /cookie-sync requests | Purpose 1 (Device Access) |
+| Setting a cookie on /setuid requests | Purpose 1 (Device Access) |
+| Conducting auctions | Purpose 2 (Basic Ads) |
+| Passing User IDs into an auction | Any Purpose 2-10. User IDs are important for more than personalizing ads - they can be used in frequency capping, building profiles, counting unique users, etc. So Prebid Server should pass User IDs through the auction if any of Purposes 2-10 pass the legal basis test. |
+| Invoke an analytics adapter | Purpose 7 |
+| Pass the user’s precise geographic information into auctions | Special Feature 1 |
+
+More details are available in the [Prebid Support for TCF2](https://docs.google.com/document/d/1fBRaodKifv1pYsWY3ia-9K96VHUjd8kKvxZlOsozm8E/edit#) reference and in the [Prebid Server GDPR Reference](https://docs.google.com/document/d/1g0zAYc_EfqyilKD8N2qQ47uz0hdahY-t8vfb-vxZL5w/edit#).
+
+### GDPR Configuration
+
+There are a number of configuration settings that PBS Host Companies need
+to consider:
+
+- Host company GVL ID. Currently PBS requires the host company to have a GVL-ID or the setting of the `uids` cookie in GDPR scope will fail.
+- The default expiration time of the uids cookie set in the host company domain should be defined to match what's in the TCF 2.1 `maxCookieAgeSeconds` GVL field.
+- GDPR enforcement flags for each Purpose and Vendor
+
+The specific details vary slightly between PBS-Go and PBS-Java, so check the
+version-specific documentation for more information.
+
+## COPPA
+
+The [Children's Online Privacy Protection Act (COPPA)](https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/childrens-online-privacy-protection-rule) is a law in the US which imposes certain requirements on operators of websites or online services directed to children under 13 years of age, and on operators of other websites or online services that have actual knowledge that they are collecting personal information online from a child under 13 years of age.
+If `regs.coppa` is set to '1' on the OpenRTB request, the following anonymization actions take place before going to the adapters:
+
+- Removes all ID fields: device.ifa, device.macsha1, device.macmd5, device.dpidsha1, device.dpidmd5, device.didsha1, device.didmd5
+- Truncate ip field - remove lowest 8 bits.
+- Truncate ipv6 field - remove lowest 32 bits.
+- Remove geo.lat, geo.lon. geo.metro, geo.city, and geo.zip
+- Remove user.id, user.buyeruid, user.yob, and user.gender
+
+## CCPA / US-Privacy
+
+The [California Consumer Privacy Act (CCPA)](https://oag.ca.gov/privacy/ccpa) is a law in the US. which covers consumer rights relating to the access to, deletion of, and sharing of personal information that is collected by businesses.
+The IAB has generalized
+this state-specific rule into a [US Privacy](https://iabtechlab.com/standards/ccpa/) compliance framework.
+If `regs.ext.us_privacy` is parsed to find that the user has opted-out of a "sale",
+the following anonymization steps are taken:
+
+- Mask the last byte of the IPv4 address and the last 2 bytes of IPv6 addresses
+- Removes user.id and user.buyeruid
+- Removes the request.device.ifa attribute
+- Rounds the request.device.geo. {lat,lon} to two decimal places
+
+## DNT
+
+Prebid Server does **not** recognize the Do-Not-Track header. The committee determined that it's obsolete in general and not supported on Safari specifically. We prefer not to implement, test, and document unsupported privacy flags. Prebid Server is not going to make a dent in the overall problems with DNT.
+
+We may reconsider this position if community members provide evidence that the flag is meaningful to their customers or lawyers.
diff --git a/prebid-server/developers/stored-requests.md b/prebid-server/features/pbs-storedreqs-go.md
similarity index 74%
rename from prebid-server/developers/stored-requests.md
rename to prebid-server/features/pbs-storedreqs-go.md
index 9c3d4aac4f..7a8492a6f8 100644
--- a/prebid-server/developers/stored-requests.md
+++ b/prebid-server/features/pbs-storedreqs-go.md
@@ -1,17 +1,13 @@
---
layout: page_v2
sidebarType: 5
-title: Prebid Server | Developers | Stored Requests
+title: Prebid Server | Features | Setting Up Stored Requests for Go
---
-# Stored Requests
+# Prebid Server | Features | Setting Up Stored Requests for Go
-This document gives a technical overview of the Stored Requests feature.
-
-Docs outlining the motivation and uses will be added sometime in the future.
-
-## Quickstart
+## PBS-Go Stored Request Quickstart
Configure your server to read stored requests from the filesystem:
@@ -41,7 +37,7 @@ Add the file `stored_requests/data/by_id/stored_imps/{id}.json` and populate it
},
"ext": {
"appnexus": {
- "placementId": 10433394
+ "placementId": 12883451
}
}
}
@@ -54,7 +50,7 @@ go build .
./prebid-server
```
-And then `POST` to [`/openrtb2/auction`](/prebid-server/endpoints/openrtb2/auction.html) with your chosen ID.
+And then `POST` to [`/openrtb2/auction`](../endpoints/openrtb2/auction.md) with your chosen ID.
```json
{
@@ -95,7 +91,7 @@ You can also store _part_ of the Imp on the server. For example:
},
"ext": {
"appnexus": {
- "placementId": 10433394
+ "placementId": 12883451
}
}
}
@@ -127,55 +123,6 @@ If the Stored Request and the HTTP request have conflicting properties,
they will be resolved with a [JSON Merge Patch](https://tools.ietf.org/html/rfc7386).
HTTP request properties will overwrite the Stored Request ones.
-## Interstitial Ads
-
-Prebid Server supports interstitial ad type requests. These requests are enabled through the addition of the interstitial key to `device.ext.prebid`. This key has two fields, `minwidthperc` and `minheightperc`. The values are integers that represent the minimum allowed size for the ad, as a percentage of the base size. For example, a `width` of 600 and `minwidthperc` of 60 would allow ad widths of 360 (600 * .60) to 600.
-
-```json
-
-{
- "mockBidRequest": {
- "id":"test-request-id",
- "imp": [
- {
- "id":"test-imp-id",
- "banner": {
- "format": [
-
- {
- "w":300,
- "h":250
- }
-,
-
- {
- "w":300,
- "h":600
- }
- ]
- },
- "instl":1,
- "device":
-{ ... }
-,
- "h":640,
- "w":320,
- "ext": {
- "prebid": {
- "interstitial":
- {
- "minwidthperc":60,
- "minheightperc":60
- }
- }
- }
- }
- ]
- }
-```
-
-
-
## Stored BidRequests
So far, our examples have only used Stored Imp data. However, Stored Requests
@@ -259,8 +206,8 @@ stored_requests:
```yaml
stored_requests:
http:
- endpoint: https://stored-requests.prebid.com
- amp_endpoint: https://stored-requests.prebid.com?amp=true
+ endpoint: http://stored-requests.prebid.com
+ amp_endpoint: http://stored-requests.prebid.com?amp=true
```
@@ -300,17 +247,15 @@ stored_requests:
dbname: database-name
query: SELECT id, requestData, 'request' as type FROM stored_requests WHERE id in %REQUEST_ID_LIST% UNION ALL SELECT id, impData, 'imp' as type FROM stored_imps WHERE id in %IMP_ID_LIST%;
http:
- endpoint: https://stored-requests.prebid.com
- amp_endpoint: https://stored-requests.prebid.com?amp=true
+ endpoint: http://stored-requests.prebid.com
+ amp_endpoint: http://stored-requests.prebid.com?amp=true
in_memory_cache:
ttl_seconds: 300 # 5 minutes
request_cache_size_bytes: 107374182 # 0.1GB
imp_cache_size_bytes: 107374182 # 0.1GB
http_events:
- endpoint: https://stored-requests.prebid.com
- amp_endpoint: https://stored-requests.prebid.com?amp=true
+ endpoint: http://stored-requests.prebid.com
+ amp_endpoint: http://stored-requests.prebid.com?amp=true
refresh_rate_seconds: 60
timeout_ms: 100
```
-
-Pull Requests for new Fetchers, Caches, or EventProducers are always welcome.
diff --git a/prebid-server/features/pbs-storedreqs.md b/prebid-server/features/pbs-storedreqs.md
new file mode 100644
index 0000000000..c6e6b59dfb
--- /dev/null
+++ b/prebid-server/features/pbs-storedreqs.md
@@ -0,0 +1,36 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Features | Stored Requests
+
+---
+
+# Prebid Server | Features | Stored Requests
+
+'Stored Requests' are blocks of OpenRTB stored on the server-side that are merged into
+OpenRTB requests in a couple of scenarios.
+
+The data source can be local files on Prebid Server, but more commonly it would be a relational
+database distributed across all the Prebid Servers in the host company's installation.
+
+## Mobile App
+
+Hardcoding bidders and parameters in a mobile app isn't ideal. Prebid Server allows Stored Request IDs to be
+used in two ways:
+
+1. Define cross-adunit parameters like currency and price granularity
+1. Define adunit-specific details: bidders and their parameters
+
+See the [Mobile SDK Use Case reference](/prebid-server/use-cases/pbs-sdk.html) for specific examples.
+
+## AMP
+
+The AMP protocol is converted to OpenRTB primarily using Stored Requests: the `tag_id` is used to look up
+the base OpenRTB from the data source. After getting the bulk of the OpenRTB, AMP query string parameters
+are used to inject and adjust parameters like size, url, etc. See the [AMP endpoint documentation](/prebid-server/endpoints/openrtb2/pbs-endpoint-amp.html) for more details.
+
+See the [AMP Use Case reference](/prebid-server/use-cases/pbs-amp.html) for specific examples.
+
+## Creating Stored Requests
+
+Details for setting up [PBS-Go Stored Requests](/prebid-server/features/pbs-storedreqs-go.html) are available.
diff --git a/prebid-server/hosted-servers.md b/prebid-server/hosted-servers.md
index eda6c448f6..a5eceaad6a 100644
--- a/prebid-server/hosted-servers.md
+++ b/prebid-server/hosted-servers.md
@@ -18,6 +18,10 @@ Several Prebid.org members host Prebid Server clusters for use by publishers.
 |
-Fill out the AppNexus Prebid Server sign-up page. If approved, you will receive an email with your assigned accountId. | -
|
-Learn more about Rubicon Project's Hosted Prebid Server offering. | -
+
diff --git a/prebid-server/hosting/pbs-database.md b/prebid-server/hosting/pbs-database.md
new file mode 100644
index 0000000000..4dfde3d158
--- /dev/null
+++ b/prebid-server/hosting/pbs-database.md
@@ -0,0 +1,140 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Developer | Database
+
+---
+
+# Prebid Server Database
+
+Companies looking to spin up Prebid Server will need to connect a database. Our design
+strategy was to avoid a fixed schema, instead allowing each host company the flexibility
+to define their schema any way they'd like.
+
+So instead of Prebid defining your schema, we just define the fields that need to come
+from the query. You can then design the SQL query and put it in PBS configuration.
+
+## Database Queries
+
+Prebid Server queries the database in the following scenarios:
+
+{: .table .table-bordered .table-striped }
+| Data | SQL Config | Description |
+|------+---------------+-------------|
+| Stored Requests | settings.database.stored-requests-query | Retrieve stored request JSON for incoming OpenRTB |
+| AMP Stored Requests | settings.database.amp-stored-requests-query | Retrieve stored request JSON for incoming AMP |
+| Stored Responses (PBS-Java only) | settings.database.stored-responses-query | (PBS-Java only) Retrieve stored response data |
+| Account Data | (none) | Retrieve host company-specific account information |
+
+## Expected Response Fields
+
+### Stored Requests
+
+The Stored Request query needs to return fields in this order:
+
+{: .table .table-bordered .table-striped }
+| Field Num | Name | Type | Meaning | Default |
+|-----------+------+------+---------+---------|
+| 1 | request ID | string | The Stored Request ID | n/a |
+| 2 | request body | JSON | The body of the Stored Request | n/a |
+| 3 | label | string | This is always just the static value 'request' | n/a |
+
+There are two parameters that can be passed into the query:
+
+- %REQUEST_ID_LIST% : a comma-separated list of "top-level" stored request IDs
+- %IMP_ID_LIST% : a comma-separated list of "impression-level" stored request IDs
+
+This query is defined in settings.database.stored-requests-query. Example:
+```
+settings:
+ database:
+ type: mysql
+ stored-requests-query: SELECT uuid, config, 'request' as dataType FROM stored_requests WHERE uuid IN (%REQUEST_ID_LIST%) UNION ALL SELECT uuid, config, 'imp' as dataType FROM stored_requests WHERE uuid IN (%IMP_ID_LIST%)
+```
+
+Again, you can name the fields however you'd like in your database, and the query can be arbitrarily complicated as long as it returns the fields in the order and types shown here.
+
+### AMP Stored Requests
+
+AMP Stored Requests are the same as the section above it won't ever have the %IMP_ID_LIST% parameter, so
+the query can be simplified.
+
+This query is defined in settings.database.amp-stored-requests-query. Example:
+```
+settings:
+ database:
+ type: mysql
+ stored-requests-query: SELECT uuid, config, 'request' as dataType FROM stored_requests WHERE uuid IN (%REQUEST_ID_LIST%)
+```
+
+### Stored Responses
+
+(PBS-Java only) The Stored Response query needs to return fields in this order:
+
+{: .table .table-bordered .table-striped }
+| Field Num | Name | Type | Meaning | Default |
+|-----------+------+------+---------+---------|
+| 1 | response ID | string | The Stored Response ID | n/a |
+| 2 | response body | JSON | The body of the Stored Response | n/a |
+
+One parameter can be passed into the query:
+
+- %RESPONSE_ID_LIST% : a comma-separated list of stored response IDs
+
+This query is defined in settings.database.stored-requests-query. Example:
+```
+settings:
+ database:
+ type: mysql
+ stored-responses-query: SELECT resid, responseData FROM stored_responses WHERE resid IN (%RESPONSE_ID_LIST%)
+```
+
+### Account Data
+
+{: .alert.alert-info :}
+Despite what we said about Prebid not defining your schema, it's not true for account data.
+Currently the account query is hard-coded in both versions of Prebid-Server. You could
+create a view as desired. We'll fix this someday.
+
+Account data is queried on every request to pull in important data. There is an LRU cache in the server
+so the database isn't actually hit on every request.
+
+In PBS-Java, many account-configuration options come from the database, while in PBS-Go, those options are available in YAML configuration.
+
+In both versions the server can optionally validate the account against this database and reject accounts from
+unknown sources.
+
+The algorithm the server uses for determining the account ID of the incoming request is:
+
+1. look in site.publisher.id
+2. look in app.publisher.id
+3. if AMP, look for the 'account' parameter on the query string (PBS-Java only)
+
+Here are the fields the server can recognize in the database response:
+
+{: .table .table-bordered .table-striped }
+| Field Num | Name | Type | Meaning | Default |
+|-----------+------+-----+---------+---------|
+| 1 | uuid | string | Host-company specific account ID | n/a |
+| 2 | price_granularity | enum | Deprecated. Granularity should be part of stored requests or the incoming OpenRTB. | n/a |
+| 3 | banner_cache_ttl | integer | (PBS-Java only) How long (seconds) banner bids should be cached for this account. | Config |
+| 4 | video_cache_ttl | integer | (PBS-Java only) How long (seconds) VAST should be cached for this account. | Config |
+| 5 | events_enabled | 0 or 1 | (PBS-Java only) Whether to emit event URLs for this account. | 0 |
+| 6 | enforce_ccpa | 0 or 1 | (PBS-Java only) Whether to enforce US-Privacy rules for this account. | Config |
+| 7 | enforce_gdpr | 0 or 1 | (PBS-Java only) Whether to enforce TCF1 GDPR rules for this account. Deprecated. Use tcf_config for TCF2. | Config |
+| 8 | tcf_config | JSON | (PBS-Java only) TCF2 override settings for this account. | Config |
+| 9 | analytics_sampling_factor | tiny int | (PBS-Java only) Turns on analytics sampling for this account. Sampling mechanism is 1-in-N. e.g. if this value is a 2, it's a 1-in-2 (50%) sample. If 5, then 1-in-5 (20%). Max value is 100 (1%) | 1 |
+| 10 | truncate_target_attr | tiny int | (PBS-Java only) Number of bytes allowed for targeting attributes for this account. 0=unlimited. | Config |
+
+Currently this query is hard-coded in both versions of Prebid-Server:
+
+PBS-Go:
+```
+SELECT uuid, price_granularity FROM accounts_account where uuid = ? LIMIT 1
+```
+
+PBS-Java
+```
+SELECT uuid, price_granularity, banner_cache_ttl, video_cache_ttl, events_enabled, enforce_ccpa, tcf_config, analytics_sampling_factor, truncate_target_attr FROM accounts_account where uuid = ? LIMIT 1
+```
+
diff --git a/prebid-server/hosting/pbs-hosting.md b/prebid-server/hosting/pbs-hosting.md
new file mode 100644
index 0000000000..89beba33db
--- /dev/null
+++ b/prebid-server/hosting/pbs-hosting.md
@@ -0,0 +1,80 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Hosting
+
+---
+
+# Hosting a Prebid Server Cluster
+
+Spinning up a self-hosted cluster of Prebid Servers requires some up-front-planning.
+The components that will be needed are highlighted in this hardware
+layout diagram:
+
+{:class="pb-xlg-img"}
+
+## Global Load Balancer
+
+Assuming you need to serve more than one geographic region, you'll need to utilize a Global Load Balaning service so your users will hit the
+servers in the region closest to them.
+
+## Regional Load Balancers
+
+Once the users have come into their nearest server cluster, a load balancer will direct them in one of two ways:
+
+1. If the URI of the request contains `/cache`, they should be directed to one of the Prebid Cache servers.
+2. Otherwise, all other endpoints should be forwarded to one of the Prebid Servers.
+
+## Prebid Servers
+
+These servers will have a mix of network and CPU work. They benefit
+from a fair amount of memory so they can cache stored requests
+and many versions of the GDPR vendors list.
+
+Other services you may want to run alongside Prebid Server are:
+
+- Geographic lookup (for GDPR scope determination)
+- Device lookup service (future: for Programmatic Guaranteed targeting)
+
+## Prebid Cache Servers
+
+The PBC servers consume very little CPU or memory - they just translate
+between Prebid protocols and the chosen No-SQL system that implements the storage cluster.
+
+## Storage Clusters
+
+You can setup Redis, Aerospike, or Cassandra. How many you need will
+depend on the expected traffic, your traffic mix, and the average length of time that objects are cached.
+
+## Replicated Database
+
+Account information and StoredRequests are stored in a [database](/prebid-server/hosting/pbs-database.html)
+queried by Prebid Server at runtime.
+PBS has an internal LRU cache for this database, so it only queries when there's an account or stored request it hasn't seen recently.
+
+Getting data to each of the regions likely involves setting up a
+source database that replicates to each region.
+
+Note that there aren't any open source tools for populating this
+database. Each PBS host company establishes their own methods of
+populating data from their internal systems.
+
+## Metrics System
+
+You'll want to hook both Prebid Server and Prebid Cache up to an
+operational monitoring system.
+
+- PBS-Go currently supports Influx and Promotheus
+- PBS-Java currently supports Influx and Graphite
+
+## Installing the Software
+
+The process for actually installing and configuring the software will differ for
+the Go and Java versions of the software. See the relevant section
+as a next step.
+
+## Further Reading
+
+- [Prebid Server Database](/prebid-server/hosting/pbs-database.html)
+- [PBS-Go](/prebid-server/versions/pbs-versions-go.html)
+- [PBS-Java](/prebid-server/versions/pbs-versions-java.html)
diff --git a/prebid-server/overview/pbs-pbjs-migration-guide.md b/prebid-server/overview/pbs-pbjs-migration-guide.md
new file mode 100644
index 0000000000..877def404f
--- /dev/null
+++ b/prebid-server/overview/pbs-pbjs-migration-guide.md
@@ -0,0 +1,10 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Overview | Prebid.js Migration Guide
+
+---
+
+# Prebid Server | Overview | Prebid.js Migration Guide
+
+Check back for updated content.
diff --git a/prebid-server/overview/prebid-server-overview.md b/prebid-server/overview/prebid-server-overview.md
new file mode 100644
index 0000000000..89f1fe8603
--- /dev/null
+++ b/prebid-server/overview/prebid-server-overview.md
@@ -0,0 +1,63 @@
+---
+layout: page_v2
+title: Prebid Server Overview
+description: Prebid Server Overview
+sidebarType: 5
+---
+
+# Prebid Server Overview
+{:.no_toc}
+
+Prebid Server is an open-source solution for server-to-server header bidding. It supports a number of key use cases: [mobile app](/prebid-server/use-cases/pbs-sdk.html), [AMP](/prebid-server/use-cases/pbs-amp.html), [server-side web with Prebid.js](/prebid-server/use-cases/pbs-pbjs.html), and [long-form video](/prebid-server/use-cases/pbs-lfv.html).
+
+{:class="pb-xlg-img"}
+
+Prebid Server is a header bidding server with a growing list of features. At a high level, it works like this:
+
+1. Prebid Server completes and validates incoming requests
+ - Resolves dynamic stored requests
+ - Enforces privacy regulations
+2. Next, it calls server-side bid adapters
+ - There are currently 75+ server-side bid adapters available
+3. After everyone's responded (or the timeout period has expired), it formulates an appropriate response
+ - Handles currency conversion
+ - Quantizes bids
+ - Caches VAST XML or creatives as needed
+
+It also has optional analytics support.
+
+The Prebid Cache is an adjunct to Prebid Server that stores VAST and bids as needed, supporting video and AMP use cases.
+
+Explore [Prebid Server features](/prebid-server/features/pbs-feature-idx.html) in more detail.
+
+## Where to Run Prebid Server
+
+Unlike Prebid.js, Prebid Server is a server. It needs somewhere to run, and that somewhere ought to be scaleable, distributed, and fast.
+
+### Hosted
+
+The simplest route to working with Prebid Server is to sign up for a hosted solution. Several [Prebid.org members](/prebid-server/hosting/hosted-servers.html) host up-to-date server software with a global footprint, and provide tools to manage stored requests.
+
+### DIY
+
+But of course this is open source, so you're welcome to do this on your own. If you decide to implement your own Prebid Server solution, first check out the general [Prebid Server host company overview](/prebid-server/hosting/pbs-hosting.html).
+
+Then you need to decide which of the two implementations to utilize:
+
+- [Prebid Server (Go)](/prebid-server/versions/pbs-versions-go.html) - the original Prebid Server is written in the Go language.
+- [Prebid Server (Java)](/prebid-server/versions/pbs-versions-java.html) - Prebid Server with a Java language port.
+
+To choose between them, see the [Prebid Server version overview](/prebid-server/versions/pbs-versions-overview.html) and the [FAQ](http://prebid.org/faq/prebid-server-faq.html#why-are-there-two-versions-of-prebid-server-are-they-kept-in-sync).
+
+## Which Server-Side Bidders to Utilize
+
+We've provided a [full list of Prebid Server bidders](/dev-docs/pbs-bidders.html), including various details about those bidders, such as media types supported and contact info.
+
+If you're a demand source, we also have information about [creating your own server-side adapter](/prebid-server/bidders/pbs-build-a-bid-adapter.html).
+
+## Where to Find Help
+
+If you need help with Prebid Server, the best ways to communicate with us are:
+
+- [Post an issue](https://github.com/prebid/prebid-server/issues) in the prebid-server GitHub repo.
+- [Join prebid.org](https://prebid.org/membership/) and get access to our Slack workspace.
diff --git a/prebid-server/prebid-server-overview.md b/prebid-server/prebid-server-overview.md
deleted file mode 100644
index 46817ad133..0000000000
--- a/prebid-server/prebid-server-overview.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-layout: page_v2
-title: Prebid Server Overview
-description: Prebid Server Overview
-pid: 0
-top_nav_section: prebid-server
-nav_section: prebid-server
-sidebarType: 5
----
-
-# Prebid Server Overview
-{:.no_toc}
-
-Prebid Server is an open-source solution for server-to-server header bidding with Prebid.js and Prebid Mobile. By running your header bidding auction server-side you can improve your page’s load time, thereby improving performance.
-
-* TOC
-{:toc}
-
-## Hosted Solution
-
-Your simplest route to working with Prebid Server is to sign up for a hosted solution. Several [Prebid.org members host](/prebid-server/hosted-servers.html) up-to-date server software with a global footprint, and provide tools to manage stored requests.
-
-## On Your Own
-
-If you decide to implement your own Prebid Server solution, you can [download the source code from GitHub](https://github.com/prebid/prebid-server). The GitHub site has [full instructions](https://github.com/prebid/prebid-server/tree/master/docs/developers) for configuring, deploying, and testing your implementation.
-
-## Bidders
-
-Prebid.org provides a full list of [Prebid Server bidders]({{site.baseurl}}/dev-docs/prebid-server-bidders.html), including various details about parameters and open issues.
-
-You can also find [additional information]({{site.baseurl}}/prebid-server/developers/pbs-bidder-info.html) for some of the Prebid Server bidders that will help you with your implementation.
-
-## Endpoints
-
-Full documentation is available for all Prebid Server endpoints:
-
-- [Bidder List](/prebid-server/endpoints/info/bidders.html)
-- [Bidder Info - BidderName]({{site.baseurl}}/prebid-server/endpoints/info/bidders/bidderName.html)
-- [Bidder Params]({{site.baseurl}}/prebid-server/endpoints/bidders/params.html)
-- [Starting Cookie Sync]({{site.baseurl}}/prebid-server/endpoints/cookieSync.html)
-- [Prebid Server AMP]({{site.baseurl}}/prebid-server/endpoints/openrtb2/amp.html)
-- [Prebid Server Auction]({{site.baseurl}}/prebid-server/endpoints/openrtb2/auction.html)
-- [Saving User Syncs]({{site.baseurl}}/prebid-server/endpoints/setuid.html)
-- [Get Status]({{site.baseurl}}/prebid-server/endpoints/status.html)
-
-## Additional Developer Information
-
-- [Add a New Analytics Module]({{site.baseurl}}/prebid-server/developers/add-new-analytics-module.html)
- Description, including and example, of how to add an analytics module to Prebid Server.
-
-- [Add a New Bidder]({{site.baseurl}}/prebid-server/developers/add-new-bidder.html)
- Learn how to define and test a new bidder, then add the bidder to theExchange.
-
-- [Cookie Syncs]({{site.baseurl}}/prebid-server/developers/cookie-syncs.html)
- Describes the mechanics of a Prebid Server cookie sync.
-
-- [GDPR]({{site.baseurl}}/prebid-server/developers/gdpr.html)
- Explore the way in which Prebid Server supports GDPR regulations.
-
-- [Stored Request]({{site.baseurl}}/prebid-server/developers/stored-requests.html)
- Learn about the Prebid Server Stored Requests feature.
diff --git a/prebid-server/use-cases/pbs-amp.md b/prebid-server/use-cases/pbs-amp.md
new file mode 100644
index 0000000000..cfa2db3d5d
--- /dev/null
+++ b/prebid-server/use-cases/pbs-amp.md
@@ -0,0 +1,219 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Use Cases | AMP
+
+---
+
+# Use Case: Prebid Server | AMP
+{: .no_toc}
+
+* TOC
+{:toc}
+
+[Accelerated Mobile Pages (AMP)](https://ampproject.org/) is an alternate web technology that can speed page performance, but
+as part of the tradeoff, header bidding wrappers like Prebid.js don't work well. Instead, AMP supports a method of header bidding called Real Time Configuration(RTC), which is implemented by Prebid Server.
+
+## Workflow
+
+Here's a workflow diagramming how this works.
+
+{:class="pb-xlg-img"}
+
+1. A browser processing an Accelerated Mobile Page (AMP) calls Prebid Server using the Real Time Protocol (RTC) and passing in a number of parameters, including a stored request ID. Each ad on the page is a separate request.
+1. Prebid Server looks up the stored request to find which bidders and parameters to use.
+1. The auction takes place and bid responses are placed in a cache.
+1. Prebid Server responds to the AMP page with results and ad server targeting variables.
+1. The ad server targeting variables are sent along to the ad server with the ad request.
+1. When header bidding wins in the ad server, the ad server responds with a call to the [Prebid Universal Creative](overview/prebid-universal-creative.html).
+1. The Prebid Universal Creative pulls the winning bid from the cache.
+1. The Prebid Universal Creative displays the winning bid creative from the cache.
+
+## Details
+
+The following sections give additional details of the steps provided in the workflows.
+
+### AMP RTC Tags are Placed in the Page
+
+As described in the [Prebid AMP Implementation Guide](/dev-docs/show-prebid-ads-on-amp-pages.html), `amp-ad` tags are placed in the AMP content.
+
+There are two basic ways of invoking AMP RTC:
+
+- One option is to use one of the pre-defined [vendors listed in the AMP repo](https://github.com/ampproject/amphtml/blob/master/extensions/amp-a4a/0.1/callout-vendors.js).
+
+```
+
+
+
+
+
+
+ 
+
+ Magnite’s Prebid-as-a-service solution makes it easy for large publishers to deploy and control custom header bidding implementations without writing code. The combination of an intuitive UI and on-demand support from our Prebid and yield management experts enables publishers to make faster decisions and potentially capture more revenue. This solution supports display and video ads across desktop and mobile app environments via Prebid.js, Prebid Mobile and Prebid Server. Contact sales@magnite.com for more information.
+
+ 
+
+ OpenWrap provides a transparent enterprise wrapper solution for Prebid.js and Prebid Server. Manage demand partners and push updates via a cloud-based UI without development resources or code changes. Access powerful reporting and analytics tools for data driven business decisions and dedicated account optimization and technical support teams.
+
+ 
+
+ Contact OpenX or your account manager for information regarding OpenX's Hosted Prebid Server service.
+
+ 
+
+ Xandr offers a full managed Prebid solution including implementation and maintenance, as well as consulting support for publishers with their own tech resources. Xandr works with users to enable client and/or server-side header bidding across web, AMP, and mobile app channels, and support display, video, and native ad formats. Contact Xandr for more information, and to get a quote!
+
+
+The Go version of Prebid Server is for those who:
+
+-
+
- Need long-form video +
- Need the most recent bidder adapters +
- Prefer the Go language +
+
+
+
+
+
+
+
+
+
+
+## Features
+
+PBS-Java look over the [feature list](/prebid-server/features/pbs-feature-idx.html) to be familiar with the differences.
+
+## Code Repositories
+
+The repositories are currently in the Rubicon-Project GitHub organization, but
+will soon move to the Prebid org.
+
+- [Prebid Server - Go](https://github.com/rubicon-project/prebid-server-java)
+- [Prebid Cache Server - Go](https://github.com/prebid/prebid-cache-java)
+
+## Installation
+
+See [Hosting your own Prebid Server](/prebid-server/hosting/pbs-hosting.html) for
+important architectural considerations, then follow the instructions for [Installing PBS-Java](/prebid-server/developers/installing-java.html).
+
+## References
+
+- [Building an Analytics Adapter](/prebid-server/developers/pbs-build-an-analytics-adapter.html#adding-an-analytics-adapter-in-pbs-java)
+
+## See Also
+
+- [Prebid Server - Go](/prebid-server/versions/pbs-versions-go.html)
+- [Endpoint reference](/prebid-server/endpoints/pbs-endpoint-overview.html)
diff --git a/prebid-server/versions/pbs-versions-overview.md b/prebid-server/versions/pbs-versions-overview.md
new file mode 100644
index 0000000000..921e1779d8
--- /dev/null
+++ b/prebid-server/versions/pbs-versions-overview.md
@@ -0,0 +1,23 @@
+---
+layout: page_v2
+sidebarType: 5
+title: Prebid Server | Versions | Overview
+
+---
+
+# Prebid Server Code Bases
+
+Prebid Server has two code bases: Go and Java. The original version of Prebid Server was the Go-Lang version. Rubicon Project ported it to Java because they had more engineers who knew Java than Go.
+
+- [Prebid Server - Go](/prebid-server/versions/pbs-versions-go.html)
+- [Prebid Server - Java](/prebid-server/versions/pbs-versions-java.html)
+
+Both versions are live in production, and they are kept identical in external APIs and reasonably close in functionality.
+
+For demand partners, we recommend building new bid adapters in Go - the team will port it to Java for you within a couple of months.
+
+For those looking to host a Prebid Server, here's some guidance on selecting which version to use:
+
+- If you plan to use long-form video, we recommend the Go version of the server.
+- Look over the [features in each version](/prebid-server/features/pbs-feature-idx.html) and see if there are any available in only one version that are important to you.
+- Otherwise, just choose the language your engineering team is most comfortable with inspecting and enhancing.
diff --git a/prebid-video/video-getting-started.md b/prebid-video/video-getting-started.md
index ec5e60eb93..e9a76e3d99 100644
--- a/prebid-video/video-getting-started.md
+++ b/prebid-video/video-getting-started.md
@@ -47,7 +47,7 @@ Follow the instructions for your ad server to create line items for instream vid
If you already have a Prebid integration for banner, you don’t need to do anything differently for outstream video. Outstream units use the same creative and line item targeting setup as banner creatives. See the [Step by Step Guide to Google Ad Manager Setup]({{site.github.url}}/adops/step-by-step.html) for instructions. (If you’re not using Google Ad Manager as your ad server, follow your ad server’s guidelines for setting up your line items.)
{: .alert.alert-info :}
-**Prebid Server** If you’ve decided to conduct your header bidding auctions server-side rather than on the client, you need to have a Prebid Server account. See [Get Started with Prebid Server]({{site.github.url}}/dev-docs/get-started-with-prebid-server.html) to begin your integration. After you’ve created an account, you’ll need to pass along the account ID to your developers.
+**Prebid Server** If you’ve decided to conduct your header bidding auctions server-side rather than on the client, you need to have a Prebid Server account or set up your own. See the [Prebid Server Overview](/prebid-server/overview/prebid-server-overview.html) to begin your integration.
@@ -180,7 +180,9 @@ This section contains working examples of instream and outstream video ads for v
+ [Ooyala]({{site.baseurl}}/examples/video/server/ooyala/pbs-ve-ooyala.html)
+ [VideoJS]({{site.baseurl}}/examples/video/server/videojs/pbs-ve-videojs.html)
+
## Further Reading
- [Prebid.js for Video Overview]({{site.github.url}}/prebid-video/video-overview.html)
- [What is Prebid?]({{site.github.url}}/overview/intro.html)
+
diff --git a/prebid-video/video-long-form.md b/prebid-video/video-long-form.md
index a67ce223f8..4eb1a61b2d 100644
--- a/prebid-video/video-long-form.md
+++ b/prebid-video/video-long-form.md
@@ -133,7 +133,7 @@ A string indicating the type of content being displayed in the video player. The
mimes: ['video/mp4'],
-
+
+The Java version of Prebid Server is for those who:
+
+-
+
- Want to host Programmatic Guaranteed +
- Prefer the Java language +
+
+
+
+
+
+
+For more on Prebid Server ad unit requirements, see Getting Started with Prebid Server – Video.
+For more on Prebid Server ad unit requirements, see Getting Started with Prebid Server – Video.
Leader, Tech, and Publisher Prebid Members
- - |
-AppNexus, a Xandr company, offers a full managed Prebid solution including implementation and maintenance, as well as consulting support for publishers with their own tech resources. AppNexus works with users to enable client and/or server-side header bidding across web, AMP, and mobile app channels, and support display, video, and native ad formats. Contact AppNexus for more information, and to get a quote! | -
 | OpenWrap provides a transparent enterprise wrapper solution for Prebid.js and Prebid Server. Manage demand partners and push updates via a cloud-based UI without development resources or code changes. Access powerful reporting and analytics tools for data driven business decisions and dedicated account optimization and technical support teams. https://pubmatic.com/products/header-bidding/ - |
 | PubWise is the only Prebid.js management service offering Smart Path Optimization Technology (SPOT™) which uses AI to deliver an optimized ad configuration matched to user segments, with tailored demand inclusion that increases net revenue while improving latency. PubWise provides a turnkey platform to deploy, manage, monitor and optimize Prebid.js. PubWise is committed to protecting publisher value and data with clear auction dynamics, no arbitrage and transparent fees. Contact us for a live demonstration or try PubWise Analytics at no cost. - |
|
-Rubicon Project's Prebid-as-a-service solution makes it easy for large publishers to deploy and control custom header bidding implementations without writing code. The combination of an intuitive UI and on-demand support from our Prebid and yield management experts enables publishers to make faster decisions and potentially capture more revenue. This solution supports display and video ads across desktop and mobile app environments via Prebid.js, Prebid SDK and Prebid Server. Contact sales@rubiconproject.com for more information. |
Community Prebid Members
- - |
-Browsi, a tech provider solely focused on creating premium ad inventory for publishers, offers a fully managed Prebid solution service focused on personalization and speed, along with other AI-based solutions for inventory such as user viewability predictions, predictive lazy loading and more. Browsi makes it easy to integrate and to make any changes, and offers an intuitive unified analytics and monitoring solution. For more information contact us at contact@gobrowsi.com. - |
 |
-Media.net Managed Prebid solution gives flexibility to the publishers to manage complex header bidding integrations without compromising on revenue. Media.net's easy to use Configuration management system makes real-time changes to the publisher's page configurations without the need of any code changes. Our robust reporting and dashboard tools help publishers gain insights into their demand stack and make further optimizations. Additionally Media.net Marketplace brings together all formats of demand, including unique access to billions in search budgets, along with robust contextual data to induce more competition, overcome challenges with cookie-deficient environments and maximize revenues. This solution supports display and native ads across desktop and mobile web environments via Prebid.js and Media.net Server to Server. Contact pubsales@media.net for more information. - |
+## Common Bid Response Parameters + +The following parameters in the `bidResponse` object are common across all bidders. + +{: .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"` | +| `adId` | String | Unique identifier of a bid creative. Used by the line item's creative as in [this example]({{site.baseurl}}/adops/send-all-bids-adops.html#step-3-add-a-creative) | `"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"` | +| `pbHg` | String | High granularity price bucket: 0.01 increment, capped at $20, floored to 2 decimal places (0.01, 0.02, ..., 19.99, 20.00) | `"1.61"` | +| `size` | String | Size of the bid creative; concatenation of width and height by 'x' | `"300x250"` | +| `width` | Integer | Width of the bid creative in pixels | `300` | +| `height` | Integer | Height of the bid creative in pixels | `250` | +| `adTag` | String | Creative's payload in HTML | `"
"` |
+
+
## Related Topics
{:.no_toc}
diff --git a/wrapper_code_of_conduct.md b/wrapper_code_of_conduct.md
index 81c4bf654a..608521d72b 100644
--- a/wrapper_code_of_conduct.md
+++ b/wrapper_code_of_conduct.md
@@ -57,3 +57,4 @@ This Wrapper Code of Conduct establishes the principles by which we believe head
+ [Project Principles]({{site.baseurl}}/principles.html)
+ [Getting Started]({{site.baseurl}}/overview/getting-started.html)
++ [Prebid.org Community Code of Conduct](https://prebid.org/code-of-conduct/)