From c8bcad9ef5969da9a131a40337f5ab355652d961 Mon Sep 17 00:00:00 2001 From: bretg Date: Tue, 18 May 2021 14:34:25 -0400 Subject: [PATCH] removing blog (#2962) --- _data/message.yml | 4 - _includes/main_nav.html | 125 -------------- _layouts/blog.html | 15 -- _layouts/post.html | 31 ---- .../2015-07-20-how-to-simplify-line-items.md | 112 ------------ ...how-to-reduce-latency-of-header-bidding.md | 57 ------ _posts/2015-08-07-bidder-analysis.md | 40 ----- ...-12-how-many-bidders-for-header-bidding.md | 108 ------------ _posts/2015-08-29-what-is-post-bid.md | 72 -------- ...11-header-bidding-analytics-coming-soon.md | 86 ---------- _posts/2016-01-11-adjust-bid-price.md | 30 ---- ...aol-pulsepoint-indexexchange-for-prebid.md | 73 -------- ...adform-brealtime-springserve-for-prebid.md | 62 ------- _posts/2016-03-14-prebid-https.md | 36 ---- ...4-triplelift-nginad-adaptors-for-prebid.md | 45 ----- ...customize-prebid-with-selected-adaptors.md | 38 ---- ...4-20-sonobi-brightcom-adequant-adaptors.md | 72 -------- _posts/2016-06-21-enable-deals.md | 31 ---- _posts/2016-08-31-one-year-of-prebid-js.md | 49 ------ ...5-show-responsive-ads-with-size-mapping.md | 17 -- ...on-for-video-now-available-on-prebid-js.md | 58 ------- ...7-06-08-prebid-releases-outstream-video.md | 91 ---------- ...s-support-for-mobile-app-header-bidding.md | 63 ------- _posts/2017-09-11-announcing-prebid-org.md | 125 -------------- _posts/2017-12-11-prebid-1-is-released.md | 25 --- _posts/2019-01-08-updated-website.md | 37 ---- _posts/2019-01-31-prebidjs-2.md | 21 --- _posts/2019-02-12-barcelona.md | 32 ---- _posts/2019-03-05-marfeel-event.md | 70 -------- _posts/2019-05-22-nycevent.md | 32 ---- _posts/2019-06-19-londonevent.md | 32 ---- _posts/2019-09-17-sfevent.md | 30 ---- _posts/2019-10-07-prebid-3.0.md | 162 ------------------ _posts/2019-12-04-ccpa.md | 20 --- _posts/2020-03-12-tcf2.md | 55 ------ _posts/2020-07-22-ix-joins-prebid.md | 12 -- _posts/2020-07-24-PB4-release.md | 82 --------- blog.md | 28 --- dev-docs/analytics-ga.md | 2 +- dev-docs/faq.md | 2 +- dev-docs/modules/consentManagement.md | 2 +- guide.md | 22 --- .../how-many-bidders-for-header-bidding.md | 6 +- overview/how-to-simplify-line-item-setup.md | 4 +- prebid/prebidjsReleases.md | 2 +- 45 files changed, 9 insertions(+), 2109 deletions(-) delete mode 100644 _data/message.yml delete mode 100644 _includes/main_nav.html delete mode 100644 _layouts/blog.html delete mode 100644 _layouts/post.html delete mode 100644 _posts/2015-07-20-how-to-simplify-line-items.md delete mode 100644 _posts/2015-07-25-how-to-reduce-latency-of-header-bidding.md delete mode 100644 _posts/2015-08-07-bidder-analysis.md delete mode 100644 _posts/2015-08-12-how-many-bidders-for-header-bidding.md delete mode 100644 _posts/2015-08-29-what-is-post-bid.md delete mode 100644 _posts/2015-10-11-header-bidding-analytics-coming-soon.md delete mode 100644 _posts/2016-01-11-adjust-bid-price.md delete mode 100644 _posts/2016-01-11-aol-pulsepoint-indexexchange-for-prebid.md delete mode 100644 _posts/2016-02-11-adform-brealtime-springserve-for-prebid.md delete mode 100644 _posts/2016-03-14-prebid-https.md delete mode 100644 _posts/2016-03-14-triplelift-nginad-adaptors-for-prebid.md delete mode 100644 _posts/2016-03-18-ui-customize-prebid-with-selected-adaptors.md delete mode 100644 _posts/2016-04-20-sonobi-brightcom-adequant-adaptors.md delete mode 100644 _posts/2016-06-21-enable-deals.md delete mode 100644 _posts/2016-08-31-one-year-of-prebid-js.md delete mode 100644 _posts/2016-10-05-show-responsive-ads-with-size-mapping.md delete mode 100644 _posts/2016-12-15-first-open-header-bidding-solution-for-video-now-available-on-prebid-js.md delete mode 100644 _posts/2017-06-08-prebid-releases-outstream-video.md delete mode 100644 _posts/2017-08-21-prebid-adds-support-for-mobile-app-header-bidding.md delete mode 100644 _posts/2017-09-11-announcing-prebid-org.md delete mode 100644 _posts/2017-12-11-prebid-1-is-released.md delete mode 100644 _posts/2019-01-08-updated-website.md delete mode 100644 _posts/2019-01-31-prebidjs-2.md delete mode 100644 _posts/2019-02-12-barcelona.md delete mode 100644 _posts/2019-03-05-marfeel-event.md delete mode 100644 _posts/2019-05-22-nycevent.md delete mode 100644 _posts/2019-06-19-londonevent.md delete mode 100644 _posts/2019-09-17-sfevent.md delete mode 100644 _posts/2019-10-07-prebid-3.0.md delete mode 100644 _posts/2019-12-04-ccpa.md delete mode 100644 _posts/2020-03-12-tcf2.md delete mode 100644 _posts/2020-07-22-ix-joins-prebid.md delete mode 100644 _posts/2020-07-24-PB4-release.md delete mode 100644 blog.md diff --git a/_data/message.yml b/_data/message.yml deleted file mode 100644 index 987d4697f4..0000000000 --- a/_data/message.yml +++ /dev/null @@ -1,4 +0,0 @@ -#-------------Message---------------- -- messageId: 1 - messageText: Register for our webinar on Aug 27, 2020: How to Make Prebid the Supply Path Buyers Choose - messageCreateDt: 08_04_2020 diff --git a/_includes/main_nav.html b/_includes/main_nav.html deleted file mode 100644 index 848b4b43be..0000000000 --- a/_includes/main_nav.html +++ /dev/null @@ -1,125 +0,0 @@ - diff --git a/_layouts/blog.html b/_layouts/blog.html deleted file mode 100644 index 21dc4beb6a..0000000000 --- a/_layouts/blog.html +++ /dev/null @@ -1,15 +0,0 @@ -{% include head.html %} - -{% include nav.html %} - -
- - {% if page.is_full_screen %} - {{content}} - {% else %} - {{content}} - {% endif %} - -
- -{% include footer.html %} diff --git a/_layouts/post.html b/_layouts/post.html deleted file mode 100644 index a60d357421..0000000000 --- a/_layouts/post.html +++ /dev/null @@ -1,31 +0,0 @@ -{% include head.html %} - -{% include nav.html %} - -
-
-
-
-
-

{{ page.date | date: '%B %d, %Y' }}

-
-

{{page.title}}

- {{content}} - -
-
-

Other blog posts:

-
    - {% for p in site.posts %} - {% if p.id == page.id %} - {% continue %} - {% endif %} -
  • {{ p.title }}
    • - {% endfor %} -
-
-
-
-
-
-{% include footer.html %} diff --git a/_posts/2015-07-20-how-to-simplify-line-items.md b/_posts/2015-07-20-how-to-simplify-line-items.md deleted file mode 100644 index a8f7edacc4..0000000000 --- a/_posts/2015-07-20-how-to-simplify-line-items.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -layout: post -title: How to simplify line item setup -head_title: How to simplify line item setup for header bidding with prebid.js - -description: A walkthrough of why header bidding implementations cause latency. An overview of how to use prebid.js to reduce it. - -permalink: /blog/how-to-simplify-line-item-setup - ---- - -## Let's do the math: - -* Per bidder per size: $0.01 increment, capped at $10 => 1000 line items -* 10 creative sizes -* 5 bidders - -1000 x 10 x 5 = 50,000 line items and creatives for header bidding! - -
- -## How to reduce the number of line items for header bidding? - -> Prebid.js helps you use 1 set of line items for all bidders and all creatives. - -By removing the size and bidder dimension, the number of line items now becomes: - -1000 x 1 x 1 = 1000 line items! 50 times less! - -
- -### Simplification 1: Remove the size dimension - -In this section, we'll learn how to remove the creative size dimension for header bidding. Before, a publisher would have to create different set of line items for different creative sizes. With Prebid.js, a publisher only need to create 1 set of line items for all creative sizes. - -Let's first clarify what "different set of line items for different creative sizes" means. In this scenario, a line item's creative is only of one size. In Google Ad Manager, this looks like: - -![Header Bidding Normal Line Item Creative]({{ site.github.url }}/assets/images/blog/line-item-creative.png){: .pb-md-img :} - - -Because a site would have many creative sizes, with this setup you need X number of line item sets for X number of creative sizes. - -There's a reason bidders recommend different set of line items for different creative sizes. If we simply attach all creative sizes to a line item, the line item wouldn't know which size of creative to choose. Consider this case: - -* Your line item has all creatives of different sizes attached. -* Your ad unit can accept both 300x250 and 300x600. A bidder bid $6.00 for the 300x600 size and has the highest price. -* The $6.00 line item got picked by the line item. -* The best your ad server can do is to RANDOMLY choose a creative. If the 300x250 one is chosen, the ad will be cut in half. - -#### How Prebid.js solves this problem: - -Prebid.js can dynamically resize the returned creative to the right size. Here's the setup: - -* Submit a few creatives of size 1x1 and make them override the line items' sizes. -* Your ad unit can accept both 300x250 and 300x600. A bidder bid $6.00 for the 300x600 size and has the highest price. Prebid.js passed the bid in, as well as a generated bid ID. -* The $6.00 line item got picked by the line item. -* Your ad server randomly choose a 1x1 creative. However, because all creatives have the same content, it does not make a difference. -* The creative content has the bid ID. Prebid.js reads this bid ID, which is mapped to size 300x600. -* Prebid.js resize the returned creative to size 300x600 and injects the bid's cretive payload. - -There you go! - - -### Simplification 2: Remove the bidder dimension - -In this section, we'll learn how to remove the bidder dimension for header bidding. Before, a publisher would have to create different set of line items for different bidders. For example, 3 different set of line items for AppNexus, Pubmatic, and Rubicon. With Prebid.js, a publisher only need to create 1 set of line items for all bidders. - -There're a few reasons why previously you'd need different set of line items for bidders. - -1. Bidders did not design their implementation guide with other bidders in mind. -2. Bidders all have different targeting parameters. -3. You need to run reports to learn fill rates and CPM from different bidders. - -Assume we have 1 set of line items for ALL bidders. Consider the below key-value pairs came in: (AppNexus bid $1.60, Rubicon bid $1.20. Ad IDs are used for rendering the right creative): - -* `appnexus_cpm`: 1.60 -* `appnexus_adId`: 65432 -* `rubicon_cpm`: 1.20 -* `rubicon_adId`: 23456 - -The line item for $1.60 is chosen because it has the highest price. However, the creative attached to this line item will be given both `appnexus_ad_id`: 65432 and `rubicon_ad_id`: 23456. There's not an easy way for the right creative (in this case the AppNexus creative) to render. - - - -#### How Prebid.js solves the problem: - -Prebid.js only picks the highest price bid and sends its key-value pairs to the ad server. Given the above example, Prebid.js will send: - -* `hb_pb`: 1.60 -* `hb_adId`: 65432 -* `hb_bidder`: appnexus - -This simplifies the setup and the right creative (with adId 65432) will get displayed. - -#### How about reporting? - -It's important to understand the fill rates and CPM from different bidders. Prebid.js therefore passes in `hb_bidder`: bidderCode. This enables Google Ad Manager to report on query strings. You can therefore run queries like: - -* For bidder X, at what CPM does it fill? -* For bidder X, what's the fill rate out of all the winning header bidding bids? - -Note that because Prebid.js only sends in the highest price bid, DFP does not see the rest of the lost bids. However, from working with publishers, we conclude that the rest of the bids do NOT matter that much. Let's say one bidder always fills at 1 penny and bids 100% of the time. Is that information helpful? Not really, only the winning bids count. We belive the above 2 queries well serve the reporting and analytics needs. - -### Conclusion - -Enjoy the much more simplified line items, creatives, and targeting setup! - - - - - - diff --git a/_posts/2015-07-25-how-to-reduce-latency-of-header-bidding.md b/_posts/2015-07-25-how-to-reduce-latency-of-header-bidding.md deleted file mode 100644 index 36d908ddf0..0000000000 --- a/_posts/2015-07-25-how-to-reduce-latency-of-header-bidding.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -layout: post -title: How to reduce latency of header bidding -head_title: How to reduce latency of header bidding with prebid.js - -description: A walkthrough of why header bidding implementations cause latency. An overview of how to use prebid.js to reduce it. - -permalink: /blog/how-to-reduce-latency-of-header-bidding - ---- - - - -> Why do header bidding cause latency? How to reduce it? - -Having seen almost all bidders' header bidding API calls, we've observed the few problems listed below: - -* Many bidders can NOT load their Javascript library asynchronously. -* Publishers make more money if all bidders are treated fairly. However, bidders that offer asynchronous integrations today (better for the publisher) are given LESS time to respond. -* Blocking ad calls is bad for user experience. Users leave the site if content takes too long to load. - -Here're a few screenshots of websites' network calls after implemented header bidding. In a later section, there's a screenshot showing how header bidding is accelerated by prebid.js. - -####Blocking Call Screenshot 1 - -![Blocking Ad Calls 1]({{ site.github.url }}/assets/images/icons/latency-blocking-1.png){: .pb-lg-img } - -* All header bidding requests combined took 4 seconds to load! -* Users have to wait for 4 seconds of blank space in their web browser before any content can load. - -
- -####Blocking Call Screenshot 2 - -![Blocking Ad Calls 1]({{ site.github.url }}/assets/images/icons/latency-blocking-2.png){: .pb-lg-img } - -* All header bidding requests in total took 1 second to load. -* However, if all calls are made asynchrnously, latency can be dramatically reduced. - -
- -### After prebid.js's acceleration: - -![Blocking Ad Calls 1]({{ site.github.url }}/assets/images/icons/latency-concurrent.png){: .pb-lg-img } - -* #####All Pre-bid Calls are made concurrently within 100ms. - - Note that AppNexus, Pubmatic, OpenX, Rubicon header bidding calls were all made within the first 100ms. - -* ##### Timeout at 400ms is respected. - - We set the timeout to 400ms. As you can see from the graph, the GPT tag (gpt.js) is loaded at around 500ms. The reason that GPT didn't get loaded exactly at 400ms is Javascript's timer is underterministic. Some partners take longer than the others. The ones that took longer than the timeout setting did not get a chance to bid due to latency concerns. - -* ##### Rotate order of bidders - - To help publishers maximize yield, all header bidders should be given the same amount of time to respond. However, Javascript doesn't make calls exactly at the same time, so we help you rotate the order that the bidders get called. - diff --git a/_posts/2015-08-07-bidder-analysis.md b/_posts/2015-08-07-bidder-analysis.md deleted file mode 100644 index f4962ad94f..0000000000 --- a/_posts/2015-08-07-bidder-analysis.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -layout: post -title: Bidder Analysis on price and latency -head_title: Header Bidding Bidder Analysis on Price and Latency - -description: An analysis of header bidding bidders' price granularity and latency report. - -permalink: /blog/header-bidding-bidder-analysis - ---- - -{: .alert.alert-warning :} -The content on this page is from 2015 and is now obsolete. - -While implementing Prebid.js' adaptors for different bidders, we've noticed not all bidders return exact price to the publisher's page. Different bidders also have vastly different response latency. We hope the analysis here can help you make smart decisions when implementing header bidding. - -{: .table .table-bordered .table-striped } -| Bidder | Price | *Latency (rough estimate) | -| :---- |:--------| :-------| -| AOL | Unknown | Unknown | -| AppNexus | Exact | 200ms, however async calls have to be made for multiple slots | -| Casale | Exact | Unknown | -| Criteo | Estimated | 200ms | -| OpenX | Exact | 500ms | -| Pubmatic | Exact | 400ms | -| Rubicon | Exact | 400ms | -| Sonobi | Exact | Unknown | -| YieldBot | Estimated at $1.00 increment | Unknown | - -*Note that the above latency estimate was done in New York, US with fast Internet connection. To provide more accurate report, publishers can implement latency trackers through the prebid.js API. - -### Live Test - -{% include live_demo.html %} - -#### The above ad is auctioned with Prebid.js. - -* **Hover over** the timeline bars to discover how long each bidder takes. -* Ad server is set to only wait for **up to 400ms**. If all bidders respond faster than that, Prebid.js will load the ad server early. If not, Prebid.js will ignore bidders that took too long. -* You may notice Javascript cannot initiate all bidder calls at once. To prevent bidders that get installed last to always have less time to respond, Prebid.js helps you keep the auction fair and rotate the order that bidders get called. diff --git a/_posts/2015-08-12-how-many-bidders-for-header-bidding.md b/_posts/2015-08-12-how-many-bidders-for-header-bidding.md deleted file mode 100644 index a39d367ddf..0000000000 --- a/_posts/2015-08-12-how-many-bidders-for-header-bidding.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -layout: post -title: How many bidders should I work with? -head_title: How many bidders for header bidding - -description: An analysis of the optimal number of bidders to work with for header bidding, to optimize yield and user experience. - -permalink: /blog/how-many-bidders-for-header-bidding - ---- - -While helping publishers run header bidding, we hear the same questions asked many times: - -* How many bidders should I work with? -* How can I maximize revenue while maintaining a good user experience? - -We've all heard anecdotally a webpage should not have more than 10 bidders' bids, or the page should not wait for longer than 1 second before it sends the bids to the ad server. Are they true? - -Luckily, the publishers using Prebid.js are curious about these questions too. We thus ran A/B tests and collected real data from pages running header bidding. We measured overall revenue & latency versus the number of bidders and how long the ad server waits for. - -
- -### Q1: How is revenue affected by different factors? - -![Prebid Diagram Image]({{ site.github.url }}/assets/images/blog/experiments/revenue.png){: .pb-lg-img :} -(_the above data is normalized to CPM = 1 for anonymity_) - -Revenue is mainly determined by: - -* How many bidders the page works with (as the blue and orange line show). -* How long does the page wait so the most number of bids can get back in time (X-axis). - -Conclusions: - -##### 1. You make more money when you include more bidders! - -* Perhaps not surprising - more competition, better yield. But the below 2 points are even more interesting: - -##### 2. When you include more bidders, the page should wait longer too! - -* Working with 10 bids (orange) makes incrementally more money as the ad server waits longer. But the 5 bids revenue plateaued. -* As the graph's 0 - 300ms (X-axis) shows, either working with 5 bids or 10 bids makes no difference; In fact, working with 10 bids has a slight dip at 200ms, possibly due to the latency caused by sending out more bid requests. - - -##### 3. Revenue actually drops if the page waits for too long - -* This could be caused by users leaving the page, when the ads took too long to load. - -
- -### Q2: How is page content load time affected? - -![Prebid Diagram Image]({{ site.github.url }}/assets/images/blog/experiments/page-load-time.png){: .pb-lg-img :} -_(The above page has on average 130 HTTP requests, 1.5MB data transferred per refresh)_ - - -Page content load time is critical to measure user experience. Your page's content taking 200 millisecond to load delivers a MUCH BETTER experience than if it takes 2 seconds. - -In this test, we measured the front section's load time. We define the front section as what's visible to the user when they open the webpage. For example, when the above graph's Y-axis is at 100ms, it means that the front section took 100ms to load before a user can see it. - -Conclusions: - -##### Page content load time is NOT really affected by the number of bidders or by how long the page waits. - -* The front section continues to load between 60 to 120ms, unaffected by the given factors. -* **This is expected**, as Prebid.js sends out bids asynchronously and they **do NOT block** the page content from loading. Modern browsers also prioritize the page content load over asynchronous Javascript scripts. - - -
- -### Q3: How about ad load time? - -![Prebid Diagram Image]({{ site.github.url }}/assets/images/blog/experiments/ad-load-time.png){: .pb-lg-img :} -_(The above page has on average 130 HTTP requests, 1.5MB data transferred per refresh)_ - -Ad load time measures how long a user has to wait before he/she can see the ad. This is less important than the page's content load time. However, the initial blank space in the ad unit, or the page elements shifting around due to a late ad load, can both demage the user experience. - -Conclusions: - -##### 1. It's linear. Longer the adserver waits, longer it takes the ads to load. - -* This makes perfect sense. It's important to note that the ads load at around 1200ms even when the adserver waits for 2 seconds, because most of the bids come back within 1200ms and Prebid.js stops the adserver from waiting. - -##### 2. When your ad server waits for < a threshold (500ms in this case), working with more bids take longer for the ads to load. - -* This makes sense, because sending out more bid requests takes longer. - -##### 3. When your ad server waits for > a threshold (500ms in this case), ads load in the same amount of time regardless of the number of bids. - -* Our guess is, when the ad server waits for long enough, there's enough time for 10 bid requests. Thus it didn't further delay the ads from loading. - - - -### Recommendations: - -Every webpage is different. Every site's users are different. Different publishers will put different weights on revenue vs. user experience. Our main recommendation is: **Create the above 3 graphs.** They will help you understand how many bids you should work with and how long your page should wait for. - -Prebid.js is a good place to start for free : ) - -
- -Note that the above data is collected by pages that run true header bidding auctions, which is defined by Prebid.js as: - -* All bid requests are sent out concurrently, not blocking each other or blocking the page content to load. -* All participating bidders are treated equally, given the same amount of time to respond. -* Ad server only waits for a limited amount of time, ignoring all bids that come after. - -If your page does not run a true header bidding auction, the above analysis may not apply. diff --git a/_posts/2015-08-29-what-is-post-bid.md b/_posts/2015-08-29-what-is-post-bid.md deleted file mode 100644 index 3863258d01..0000000000 --- a/_posts/2015-08-29-what-is-post-bid.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -layout: post -title: What is post-bid? -head_title: What is post-bid and when to use it vs. header bidding. - -description: What is post-bid and when to use it vs. header bidding. - -permalink: /blog/what-is-post-bid - ---- - - - -### What is post-bid? - -> Post-bid allows a publisher’s mediated demand sources all compete in one auction based on price, after the ad server has picked the post-bid line item. - -In post-bid, the competition among your mediated demand sources compete AFTER your ad server has chosen the winning line item (vs. in header bidding, demand sources compete BEFORE your ad server has seen the impression). In post-bid, your mediated demand sources no longer run daisy chain; they all compete in one single line item based on price. - -![Add Creative to Line Item]({{ site.github.url }}/assets/images/blog/postbid-diagram.png){: .pb-lg-img :} - -Steps: - -1. The webpage sends an impression to the ad server. -2. The ad server chooses a winning line item among class 1, exchanges, and the post-bid line items. In this case, the post-bid line item wins because the eCPM on the line item is high (based on historical price) and the higher priority class 1 line items have all exhausted their spend. -3. The post-bid line item’s creative is served to the page. The creative runs an auction for the bidders using prebid.js, which then displays the highest price creative in that creative’s ad slot. - - -### Why post-bid? - -The main reasons we have seen publishers opt for post-bid (instead of header bidding) are: - -##### 1. The post-bid setup does not need engineering resources. - -The Post-bid creative is just a 3rd party tag. Once it’s served to the page, prebid.js runs an auction across all demand sources. The only technical work is to insert the tag Ids into the 3rd party tag’s JSON config for your demand sources. It’s trivial work. - -##### 2. The post-bid setup adds no latency to class 1 ad delivery. - -Because post-bid is just a 3rd party tag, your ad server receives the impressions as soon as the page loads. The post-bid setup does not affect the class 1 or exchange spend. Post-bid actually reduces latency compared to a daisy chain mediation setup, because in post-bid all demand sources are requested concurrently, instead of in a waterfall. - -Additionally, post-bid does not need additional line items. The initial setup is easier than header bidding. - -### How to choose between header bidding and post-bid? - -We’ve listed the advantages of post-bid over header bidding in the previous section. The disadvantages are listed below: - -##### 1. No dynamic allocation across all demand sources. - -The bid price on the post-bid line item is static (based on historical price). It thus has the typical problems of a 3rd party tag line item. Due to this downside, the Post-bid setup cannot make your demand partners compete with class 1 or exchanges. - -##### 2. Reporting is harder. - -In your ad server's post-bid line item report, you’d only get an aggregated report of all demand sources. You may need to rely on a 3rd party reporting service to record which demand partner wins how much inventory. - -{: .table .table-bordered .table-striped } -| | Mediation | Post-bid | Pre-bid (header bidding) | -| :--- | :---- | :---------- | :------ | -| Engineering Resources | Not required | Not required | Required | -| Ad Latency | No additional class 1 latency. Waterfall adds latency when networks do not fill. | No additional class 1 latency. Parallel auction for demand sources thus minimum latency. | Additional class 1 latency from the page's timeout setting. | -| Compete among demand sources | No | Yes | Yes | -| Compete with Class 1 & AdX dynamic allocation | No | No | Yes | -| Monetization Capability | Low | Medium | High | -| Block page content from loading? | No | No | No (with prebid.js) | - -### FAQ: - -##### 1. If none of the post-bid demand sources fill, can I still passback to another tag, say from Adsense? - -Yes. Check out the example. - -##### 2. How can I get started? -If you need help, email support@prebid.org. diff --git a/_posts/2015-10-11-header-bidding-analytics-coming-soon.md b/_posts/2015-10-11-header-bidding-analytics-coming-soon.md deleted file mode 100644 index cc6feb4c02..0000000000 --- a/_posts/2015-10-11-header-bidding-analytics-coming-soon.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -layout: post -title: Analytics for Prebid.js Coming Soon! -head_title: Analytics for Prebid.js Coming Soon! - -description: Analytics for Prebid.js Coming Soon! - -permalink: /blog/header-bidding-analytics-coming-soon - ---- - - -> Are my header bidding demand partners generating more revenue for me? If not, is it because of latency or is it due to low bid CPM? How about discrepancy? - -##### Prebid.js is launching its Analytics Platform to help you better manage your header bidding partners. Analytics Platform includes: - -- Bidder bid/win price analysis by geo, domain, with price range distribution. -- Bid latency by bidder, geo, and domain. -- Seamless integration with your Google Analytics account and scheduled reports delivered to your mailbox. - -
- -#### Example reports by Prebid.js Analytics: - -The day starts from making sure the bidders are not generating less revenue: - -![Blocking Ad Calls 1]({{ site.github.url }}/assets/images/blog/analytics/revenue-by-date.png){: .pb-lg-img } - -Something is not right here - total revenue from yesterday dropped quite a bit. This could be caused by certain bidders were down or experienced technical issues. Let's take a look at the bidder timeout rate: - -![Blocking Ad Calls 1]({{ site.github.url }}/assets/images/blog/analytics/timeout-by-date.png){: .pb-lg-img } - -Bidder timeout seems okay. The problem might then be caused by bidders' lower bid rate: - -![Blocking Ad Calls 1]({{ site.github.url }}/assets/images/blog/analytics/bidrate-by-date.png){: .pb-lg-img } - -Here we go. Bidder 1 and 4 bid much less than usual. You may want to drill down even further - Prebid.js Analytics also provides: - -- More metrics such as: bid load time, avg bid CPM, bid rate, avg win CPM, win rate. -- Filter the above metrics further by geo, domain, and OS - -> **Try out the product and explore the demo dashboard here!** This will be the base of your dashboard! - -
- -#### Histogram analysis of latency and CPM distribution: - -To understand exactly how much time per bidder spent, the Analytics Platform allows you to make the below query: - -- For country X, what are bidders' bid load time, for mobile traffic on Android only? - -
- -![Blocking Ad Calls 1]({{ site.github.url }}/assets/images/blog/analytics/loadtime-histogram.png){: .pb-lg-img } - -You might derive: - -- Bidder 1 is really fast, because 1/3 of its bids are in red, which is in the 200 - 300ms response time range. -- Bidder 5 is really slow, as 1/3 of its bids are in 800 - 1000ms. - -
- -Similar query for bidders' bid CPM: - -
- -![Blocking Ad Calls 1]({{ site.github.url }}/assets/images/blog/analytics/cpm-histogram.png){: .pb-lg-img } - -> **Try out the product and explore the demo dashboard here!** This will be the base of your dashboard! - -
- -### How does it work? - -Prebid.js has a seamless integration with Google Analytics (other analytics software support coming) and Google Spreadsheet. - -1. Prebid.js has a built-in plugin for Google Analytics, i.e. zero development work if your site uses Prebid.js. -2. All data are sent as Events to Google Analytics. You can build reports and dashboards there just as you do today with web traffic data. -3. We've also built dashboards and data visulization in Spreadsheet (where all the above diagrams come from). You can copy our demo dashboard and link it to your Google Analytics account in a few minutes! -4. The Spreadsheet dashboard can be scheduled to run every morning (or in other intervals). You can get 7 day revenue lookback, latency/CPM distribution analysis and more every morning! - -> **Try out the product and explore the demo dashboard here!** This will be the base of your dashboard! - -#### Leave your comments below for questions or early access to Prebid.js Analytics! - - diff --git a/_posts/2016-01-11-adjust-bid-price.md b/_posts/2016-01-11-adjust-bid-price.md deleted file mode 100644 index 502ff0424f..0000000000 --- a/_posts/2016-01-11-adjust-bid-price.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: Adjust Bid Price for Gross/Net Now Supported - -description: Adjust Bid Price for Gross/Net Is Now Supported for Prebid.js - -permalink: /blog/adjust-bid-price - ---- - -### Background - -Bidders may have different pricing deals with publishers, and the returned bid prices may or may not reflect what the publisher will truly receive in the end. - -For example, some bidders returned the bid prices in gross (before any fee is taken). This artificially sets that bidder's bid (say $1.2) at an unfair advantage, because the bidding price, when bid wins, is in fact not what the publisher will receive. The publisher in fact got paid $1. However, if there was a competing price $1.1 in net (after the fee is taken), the publisher would have earned more if taking that $1.1 bid. - -
- -### What is the feature - -This feature allows the publisher to adjust the bidding price before the bids targeting are set on the ad server tag. This is especially relevant for publishers who choose to let prebid.js send only the top winning bid to the ad server, because the price adjustment is done before the top winning bid is chosen. - -![Prebid.js Adjust Bid Price]({{ site.github.url }}/assets/images/blog/prebid-adjust-price.png){: .pb-md-img :} - -
- -### How to use the feature - -See the [Publisher API Reference](/dev-docs/publisher-api-reference.html#module_pbjs.bidderSettings) for more details. - diff --git a/_posts/2016-01-11-aol-pulsepoint-indexexchange-for-prebid.md b/_posts/2016-01-11-aol-pulsepoint-indexexchange-for-prebid.md deleted file mode 100644 index 46d9f5a686..0000000000 --- a/_posts/2016-01-11-aol-pulsepoint-indexexchange-for-prebid.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -layout: post -title: New Adaptors AOL, Pulsepoint, IndexExchange - -description: New Adaptors AOL, Pulsepoint, IndexExchange are now available for Prebid.js - -permalink: /blog/aol-pulsepoint-indexexchange-for-prebid - ---- - - -### How to add bidder AOL: - -{% highlight js %} - -var adUnits = [{ - code: '/9968336/header-bid-tag-0', - sizes: [[300, 250], [300, 600]], - bids: [{ - bidder: 'aol', - params: { - placement: 'TO ADD', //String placement - network: 'TO ADD' //String network, - //optional params - sizeId : 123, //Number - alias : 'TO ADD, //String - size : [300,250] //Array[Number] - } - }] -}]; - -{% endhighlight %} - - -### How to add bidder Pulsepoint: - -{% highlight js %} - -var adUnits = [{ - code: '/9968336/header-bid-tag-0', - sizes: [[300, 250], [300, 600]], - bids: [{ - bidder: 'pulsepoint', - params: { - cf: '300X250', //String adSize identifier - cp: 123345, //Number Publisher Id - ct: 123456 //Number Ad Tag Id - } - }] -}]; - -{% endhighlight %} - -### How to add bidder IndexExchange: - -{% highlight js %} - -var adUnits = [{ - code: '/9968336/header-bid-tag-0', - sizes: [[300, 250], [300, 600]], - bids: [{ - bidder: 'indexExchange', - params: { - id: 'TO ADD', //String - id of placement required - siteID: TO ADD, //Number - site id required - timeout: 1000, //Number Optional - tier2SiteID: 'TO ADD', //String Optional - tier3SiteID: 'TO ADD' //String Optional - } - }] -}]; - -{% endhighlight %} \ No newline at end of file diff --git a/_posts/2016-02-11-adform-brealtime-springserve-for-prebid.md b/_posts/2016-02-11-adform-brealtime-springserve-for-prebid.md deleted file mode 100644 index 4a49730ff3..0000000000 --- a/_posts/2016-02-11-adform-brealtime-springserve-for-prebid.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -layout: post -title: New Adaptors Adform, bRealTime, Springserve - -description: New Adaptors Adform, bRealTime, Springserve are now available for Prebid.js - -permalink: /blog/adform-brealtime-springserve-for-prebid - ---- - -### How to add bidder Adform: - -{% highlight js %} - -var adUnits = [{ - code: '/9968336/header-bid-tag-0', - sizes: [[300, 250], [300, 600]], - bids: [{ - bidder: 'adform', - params: { - adxDomain: 'adx.adform.net', //optional - mid: 74042 - } - }] -}]; - -{% endhighlight %} - - -### How to add bidder BRealTime: - -{% highlight js %} -var adUnits = [{ - code: '/9968336/header-bid-tag-0', - sizes: [[300, 250], [300, 600]], - bids: [{ - bidder: 'brealtime', - params: { - placementId: '2251610' - } - }] -}]; - -{% endhighlight %} - -### How to add bidder Springserve: - -{% highlight js %} - -var adUnits = [{ - code: '/9968336/header-bid-tag-0', - sizes: [[300, 250], [300, 600]], - bids: [{ - bidder: 'springserve', - params: { - impId: 1234, //Required - number - supplyPartnerId: 1, //Required - number - } - }] -}]; - -{% endhighlight %} \ No newline at end of file diff --git a/_posts/2016-03-14-prebid-https.md b/_posts/2016-03-14-prebid-https.md deleted file mode 100644 index d388262008..0000000000 --- a/_posts/2016-03-14-prebid-https.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -layout: post -title: HTTPS proof comes to Prebid and all its adaptors - -description: Prebid.js and all its adaptors now fully support HTTPS. - -permalink: /blog/prebid-https - ---- - -### Background - -Many publishers require their users load some of, or all of their pages securely via HTTPS. The main motivation for HTTPS is authentication of the visited website and protection of the privacy and integrity of the exchanged data. [source](https://en.wikipedia.org/wiki/HTTPS). - -
- -### What does it mean that HTTPS has come to Prebid and all its adaptors? - -**1. Prebid.js library can be loaded securely via HTTPS.** - -When the prebid.js library is loaded securely via HTTPS, it will auto ensure the adaptors are also loaded securely via HTTPS. The adaptors should also return the bid responses and ads securely via HTTPS. - -**2. All adaptors that Prebid.js supports can be loaded securely.** - -Some adaptors may load external Javascript. During the prebid.js adaptor certification process, we ensure these external Javascript are also loaded securely via HTTPS. - -**3. All bid responses and ads returned by the adaptors are via HTTPS.** - -When a page is loaded securely via HTTPS, all the data exchange and communication have to be in HTTPS. This includes the data coming back from the servers as well. - -
- -### How to turn on HTTPS for prebid? - -Load prebid.js library via HTTPS. [All examples](/dev-docs/examples/basic-example.html) documented on Prebid.org provide examples for how to load prebid.js via HTTPS. - diff --git a/_posts/2016-03-14-triplelift-nginad-adaptors-for-prebid.md b/_posts/2016-03-14-triplelift-nginad-adaptors-for-prebid.md deleted file mode 100644 index 00a5583a7c..0000000000 --- a/_posts/2016-03-14-triplelift-nginad-adaptors-for-prebid.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -layout: post -title: New Adaptors TripleLift, NginAd - -description: New Adaptors TripleLift, NginAd are now available for Prebid.js - -permalink: /blog/triplelift-nginad-adaptors-for-prebid - ---- - -### New adapter for NginAd - how to add - -{% highlight js %} - -var adUnits = [{ - code: '/9968336/header-bid-tag-0', - sizes: [[300, 250], [300, 600]], - bids: [{ - bidder: 'nginad', - params: { - pzoneid: '7', // PublisherAdZoneID - nginadDomain: "server.nginad.com" // the domain where you installed NginAd - } - }] -}]; - -{% endhighlight %} - - -### New adapter for TripleLift - how to add: - -{% highlight js %} - -var adUnits = [{ - code: '/9968336/header-bid-tag-0', - sizes: [[300, 250], [300, 600]], - bids: [{ - bidder: 'triplelift', - params: { - inventoryCode: 'headerbidding_placement' } - } - }] -}]; - -{% endhighlight %} diff --git a/_posts/2016-03-18-ui-customize-prebid-with-selected-adaptors.md b/_posts/2016-03-18-ui-customize-prebid-with-selected-adaptors.md deleted file mode 100644 index f077e912f9..0000000000 --- a/_posts/2016-03-18-ui-customize-prebid-with-selected-adaptors.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: post -title: New UI to Customize Prebid.js with Selected Adaptors - -description: New UI to Customize Prebid.js with Selected Adaptors - -permalink: /blog/ui-customize-prebid-with-selected-adaptors ---- - -### Background - -Since we introduced Prebid.js 8 months ago with only 4 adaptors, more than 15 SSPs have started contributing and maintaining their adaptors through GitHub. The number of demand adaptors Prebid.js supports has now grown to 17! (more are coming) - -The average number of adaptors publishers use are between 3 to 8. It makes more sense now for publishers to choose and pick the adaptors they would like prebid.js to include. - -
- -### Benefits - -- **Load prebid.js and header bidding ads faster**, with a smaller file size of Prebid.js. For example, prebid.js with one bidder is of file size 30KB. Prebid.js with 17 adaptors is of size 80KB. Browsers can download a smaller file size faster. - -- **Higher level of control**: While prebid.js with all 17 adaptors gives convenience to the publisher when adding new partners, being able to choose which adaptors to include gives more control back to the publisher. - -
- -### What is it: - -A [new UI](/download.html) to customize Prebid.js with the adaptor you choose: - -
- -![Prebid.js Customize Download UI]({{ site.github.url }}/assets/images/blog/prebid-download-ui.png){: .pb-lg-img } - -
- -### How to use it: - -The service is now available at [Prebid Download](/download.html). diff --git a/_posts/2016-04-20-sonobi-brightcom-adequant-adaptors.md b/_posts/2016-04-20-sonobi-brightcom-adequant-adaptors.md deleted file mode 100644 index 5e486150a6..0000000000 --- a/_posts/2016-04-20-sonobi-brightcom-adequant-adaptors.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -layout: post -title: New Adaptors Sonobi, Brightcom, Adequant - -description: New Adaptors Sonobi, Brightcom, Adequant are now available for Prebid.js - -permalink: /blog/sonobi-brightcom-adequant-adaptors-for-prebid - ---- - -### New adapter for Sonobi - how to add: - -{% highlight js %} - -var adUnits = [{ - code: '/9968336/header-bid-tag-0', - sizes: [[300, 250], [300, 600]], - bids: [{ - bidder: 'sonobi', // New format - params: { - ad_unit: 'PER SLOT' // ad unit code - } - }, - { - bidder: 'sonobi', // Old account format - params: { - placement_id: 'PER SLOT' // placement Id - } - }] -}]; - -{% endhighlight %} - -### New adapter for Brightcom - how to add - -{% highlight js %} - -var adUnits = [ - { - code: '/9968336/header-bid-tag-0', - sizes: [[300, 250], [300, 600]], - bids: [ - { - bidder: 'brightcom', - params: { - tagId: 12345 // Tag ID supplied by Brightcom - brightcom.com - } - } - ] - } -]; - -{% endhighlight %} - -### New adapter for Adequant - how to add: - -{% highlight js %} - -var adUnits = [{ - code: '/9968336/header-bid-tag-0', - sizes: [[300, 250], [300, 600]], - bids: [{ - bidder: 'adequant', - params: { - publisher_id: '1234567', // REQUIRED int or str publisher ID. To get one, register at https://control.adequant.com - bidfloor: 0.01 // OPTIONAL float bid floor in $ CPM - } - } - ]} -}]; - -{% endhighlight %} \ No newline at end of file diff --git a/_posts/2016-06-21-enable-deals.md b/_posts/2016-06-21-enable-deals.md deleted file mode 100644 index 665496f4d9..0000000000 --- a/_posts/2016-06-21-enable-deals.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -layout: post -title: Enable Deals in Prebid - -description: Enable Deals in Prebid for header bidding. - -permalink: /blog/enable-deals - ---- - -Prebid is making it easier for publishers to run deals in header bidding! - -
- -#### Benefits: - -- No development change is required to enable deals! If your pages are using the standard key-values, simply upgrade to the latest prebid.js to enable deals. - -- Easy ad ops setup with a complete [step by step guide](/adops/deals.html). Setup deal line items in a few minutes. - -
- -#### How to implement it? - -In order to enable deals for prebid, the ad ops setup are slightly different from the standard header bidding setup. Specifically: - -+ From the ad ops side, you'll create separate orders and line items that target the deal ID key-values. These line items will be at different priorities than your standard header bidding line items. Follow the step by step [Deals Ad Ops Guide](/adops/deals.html) to implement. - -+ From the dev side, if your page is using the standard prebid.js key-values, no change is required. - -Note that the initial list of bidders that support deals are: Pubmatic, TripleLift, AppNexus, bRealTime. More bidder adaptors are implementing deals currently. If you'd like to check progress on a bidder, create a [GitHub issue](https://github.com/prebid/Prebid.js/issues). diff --git a/_posts/2016-08-31-one-year-of-prebid-js.md b/_posts/2016-08-31-one-year-of-prebid-js.md deleted file mode 100644 index aee8161ae7..0000000000 --- a/_posts/2016-08-31-one-year-of-prebid-js.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -layout: post -title: Happy Birthday, Prebid.js! -head_title: Happy Birthday, Prebid.js! -description: Looking back on the first year of Prebid.js development -permalink: /blog/happy-birthday-prebid-js ---- - -## The Beginning - -About a year ago, the publisher engineering team at AppNexus began noticing a common problem with some of our forward-looking publishers: many of their websites were taking a long time to load. - -Since all the pages were written in JavaScript and HTML, our team was able to dig deep and see why all those pages were taking their sweet page-load time. What we soon found was that these forward-looking publishers had started experimenting with header bidding, but the integrations weren't designed in the best interest of publishers. - -To be specific, these integrations were blocking the page content from loading, and they interfered with other header bidding integrations. Some publishers reported 10 - 20% impression loss, because once a site stacks up a few header bidding partners, the page blocking effect goes up significantly. - -After speaking one-on-one with our clients, we came to a pretty straightforward conclusion: the header bidding integrations were opaque. Publishers weren't given enough information about how they worked. In addition to the blocking behavior that causes latency and impression loss, each header bidding implementation was taking several weeks for publishers: in other words, way too long. Somewhere in the intensive process of writing a few hundred lines of code, of setting keywords and loading the right creatives, header bidding was devolving into a real-time traffic jam. - -We quickly realized there is something we can do to significantly improve sites' user experience and monetization. After a very intensive two weeks, we managed to build the first [Prebid.js](https://github.com/prebid/Prebid.js) container prototype, and presented it to the rest of the company and our publisher friends. - -We knew how important this solution would be. Just like our forward-thinking publishers were willing to adopt this industry change with header bidding, we owed it to our publishers to pioneer this technology. The [Prebid.js](https://github.com/prebid/Prebid.js) container solution was one of the first container solutions available to publishers. While others in the industry were still trying to figure out header bidding, we were already thinking ahead on how we can make this technology better for publishers and easier to implement. - -Only one question remained... how would we distribute it? The ad tech market has always been so competitive on revenue and profit, and there were other companies selling their proprietary solutions at a premium price. However, at AppNexus, our ultimate goal has always been to make the Internet a better place. We believe header bidding is on the right track, and the best way to help publishers is to teach them everything we learned, including the code we wrote, the challenges that early adopters have faced, and the efficient ad ops setting we were experimenting with. We also do not believe our solution can fit all, or is the best yet - publishers are smart and they know their pages the most. - -Therefore, we open sourced the [Prebid.js](https://github.com/prebid/Prebid.js) code on GitHub and documented everything we learned on [Prebid.org](https://prebid.org). We wanted to help publishers unlock ideas and innovate faster, and to accelerate the growth and adoption of header bidding. - -And - gulp! - we sent our baby out into the world. - -## The Response - -The first week after the launch of [Prebid.js](https://github.com/prebid/Prebid.js) we started receiving GitHub responses from publishers. The responses were positive - several key metrics were telling us publishers were deeply engaged with this product, even from day 1 with the minimum viable product. For example, users on average spent over 5 minutes on the site, and over 35% of the users came back to the [Prebid.org](https://prebid.org) site almost every day during the week - a sign suggesting they were reading and implementing [Prebid.js](https://github.com/prebid/Prebid.js). - -And the power of open source started kicking in. On GitHub, publishers started posting comments, fixing bugs, and contributing code, big chunks of code! For example, our first version of [Prebid.js](https://github.com/prebid/Prebid.js) didn't have a popular header bidding partner implemented. Within a week, we received 3 versions of it, submitted by 3 different publishers! - -To date, [our GitHub repo](https://github.com/prebid/Prebid.js) has received over 485 tickets (we closed 452 of them), 1600 comments, 237 pull requests, 173 forks, and 59 contributors. Over 25 companies have submitted their header bidding adaptors, making [Prebid.js](https://github.com/prebid/Prebid.js) one of the most collaborative ad tech projects. Over 2100 people have given us their emails to stay up to date with the latest news on [Prebid.js](https://github.com/prebid/Prebid.js). In June 2016 alone, we've had over 350 downloads of the custom built version of [Prebid.js](https://github.com/prebid/Prebid.js)! - -We are also happy to see the fast growing adoption of [Prebid.js](https://github.com/prebid/Prebid.js) on publisher pages. According to the third party analytics provider [Builtwith](http://trends.builtwith.com/ads/Prebid), [Prebid.js](https://github.com/prebid/Prebid.js) saw exponential growth in the past year, and has been installed on over 12,000 sites! - -## The Product Evolution - -The [Prebid.js](https://github.com/prebid/Prebid.js) Engineering team has spent time and effort making sure the industry comes together to provide guidelines and consistency around header bidding. We began publishing more content around the problem of latency, strategies on how to reduce latency, and tips on how to simplify ad ops set ups for header bidding. - -We also started building products to benchmark header bidding integrations. For example, we designed [Headerbid Expert](https://chrome.google.com/webstore/detail/headerbid-expert/cgfkddgbnfplidghapbbnngaogeldmop?hl=en), a browser plug-in, because we noticed publishers struggling to find out accurate latency information on their header bidding partners. To date, 3,000 users have downloaded [Headerbid Expert](https://chrome.google.com/webstore/detail/headerbid-expert/cgfkddgbnfplidghapbbnngaogeldmop?hl=en) - all the more interesting because the development of Headerbid Expert was a weekend project, plain and simple. During the course of one 48-hour mini-hackathon, we managed to build a tool that publishers and tech vendors alike seem to find cool and useful. - -So, what's in store for the future of [Prebid.js](https://github.com/prebid/Prebid.js)? Well, header bidding is still in its early stages, and there is plenty of room for improvement and innovation. We want to keep [Prebid.js](https://github.com/prebid/Prebid.js) super light, simple, and fast, and that's our grand mission. Today's adaptor integrations still require much more data transfer than they need, and we know we can score a 10x speed improvement in the very near future, especially with the amount of support and adoption from the community. - -We also want to make [Prebid.js](https://github.com/prebid/Prebid.js) excel on mobile pages, and we have a good plan for that. For the remainder of the year, we're going to invest heavily in those efforts so that publishers can enjoy faster page load, higher viewability rate, and much more efficient header bidding integrations. - -Ultimately, as we see the continued success of header bidding, we'll continue our commitment to the evolution of header bidding - and our community will see the fruits of this labor in the near future. Happy Birthday to [Prebid.org](https://prebid.org)! Be sure to stay tuned for more exciting developments in this space. diff --git a/_posts/2016-10-05-show-responsive-ads-with-size-mapping.md b/_posts/2016-10-05-show-responsive-ads-with-size-mapping.md deleted file mode 100644 index 6182292c0c..0000000000 --- a/_posts/2016-10-05-show-responsive-ads-with-size-mapping.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -layout: post -title: Show Responsive Ads with Size Mapping -head_title: Show Responsive Ads with Size Mapping -description: Show Responsive Ads with Size Mapping -permalink: /blog/show-responsive-ads ---- - -Prebid is making it easier for you to adjust ad sizes based on the device's screen width. Using the new size mapping feature, you can: - -- Change ad sizes depending on the user's screen size - -- Use declarative syntax during ad unit setup - -- Avoid adding tricky custom logic to your code - -For more information, [see the example code here]({{site_url}}/dev-docs/examples/size-mapping.html). diff --git a/_posts/2016-12-15-first-open-header-bidding-solution-for-video-now-available-on-prebid-js.md b/_posts/2016-12-15-first-open-header-bidding-solution-for-video-now-available-on-prebid-js.md deleted file mode 100644 index 0ac2eeef02..0000000000 --- a/_posts/2016-12-15-first-open-header-bidding-solution-for-video-now-available-on-prebid-js.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -layout: post -title: First Open Header Bidding Solution for Video Now Available on Prebid.js -head_title: First Open Header Bidding Solution for Video Now Available on Prebid.js -description: A walkthrough of why header bidding implementations cause latency. An overview of how to use prebid.js to reduce it. -permalink: /blog/first-open-header-bidding-solution-for-video-now-available-on-prebid-js ---- - -(*This post first appeared on the [AppNexus Product Blog](http://productblog.appnexus.com/first-open-header-bidding-solution-for-video-now-available-on-prebid-js/).*) - -At its core, Prebid.js has always worked towards achieving a few simple goals: providing publishers with fair and transparent access to demand; improving monetization by unlocking the true value of publisher inventory; and, asserting control over the (often narrow and unfavorable) auction dynamics kept locked by closed publisher adservers. - -The release of PreBid Video marks an important step forward for the open-source project, as market participants can begin to realize these same benefits across inventory formats beyond those of traditional display. - -In a supply-constrained video ecosystem in which the majority of inventory is monetized via direct sales, PreBid Video offers a programmatic avenue through which publishers can achieve incremental value while still maintaining these guaranteed and/or direct buys. - -![PreBid Video Evian]({{ site.github.url }}/assets/images/blog/PreBid-Evian.png){: .pb-md-img :} - -The true value of an open-sourced project is realized through the ability to incorporate new functionalities, feature development, and bug fixes from a wide contributor network which encompasses diverse expertise and an array of market positions. We encourage and welcome these contributions as we look ahead towards iterative improvement on PreBid Video. With help from the community, we expect to be able to build portfolios of video-capable adapters to match the nearly 40 demand partners integrated today with PreBid display; of video player and adserver integrations with Prebid.js; and, of video-specific formats. - -This paradigm has already netted tangible positive results among the several publishers with whom AppNexus has been working closely to enable PreBid Video on live traffic. - -One alpha partner who had already been monetizing display traffic through Prebid.js was able to expand upon the open-source code to integrate PreBid Video directly with hundreds of publishers using their proprietary video player and adserver stack. While Prebid.js currently offers built-in support for Google's DoubleClick for Publishers' Video Adserver, this partner was able to seamlessly incorporate PreBid Video demand into their existing Prebid.js implementation and their own adserver with only a few extra lines of code. Shortly after implementation, PreBid Video was providing real-time demand from some of the largest advertisers in the U.S. at CPMs ranging from $15 to $30, helping to realize strong incremental revenue lifts without adding page latency or compromising user experience. - -```javascript -var videoAdUnit = { - code: 'video', - sizes: [640,480], - mediaType: 'video', - bids: [ - { - bidder: 'appnexusAst', - params: { - placementId: '123456' // <-- Replace this! - video: { - skippable: true - } - } - } - ] -}; -``` - -PreBid Video is and will continue to be adserver, video player, and demand partner agnostic, and is designed to work seamlessly with existing Prebid.js implementations. The Prebid.js source code is now [available in beta on GitHub](https://github.com/prebid/Prebid.js). - -Supporting documentation is available through [Prebid.org](http://prebid.org), including: - -+ [Setting up PreBid Video in Google's DoubleClick for Publishers' Video Adserver]({{ site.github.url }}/adops/setting-up-prebid-video-in-dfp.html) - -+ [How to add a (Video) Bidder]({{ site.github.url }}/dev-docs/bidder-adaptor.html) - -+ End-to-end examples integrating Prebid.js demand with popular video player technologies, including: - - + [video.js](http://video-demo.appnexus.com/pbjs/mjacobson/video_testing/prebid_video_videojs_new.html) - + [JW Player](http://video-demo.appnexus.com/pbjs/JWPlayerDemo/jwPlayerPrebid.html) - + [Brightcove](http://video-demo.appnexus.com/pbjs/brightcove-prebid/bc-demo.html) - + [Kaltura](http://video-demo.appnexus.com/pbjs/kaltura-prebid/klt-demo.html) - + [Ooyala](http://video-demo.appnexus.com/pbjs/ooyala-prebid/ooyala-demo.html) diff --git a/_posts/2017-06-08-prebid-releases-outstream-video.md b/_posts/2017-06-08-prebid-releases-outstream-video.md deleted file mode 100644 index ab466eb97a..0000000000 --- a/_posts/2017-06-08-prebid-releases-outstream-video.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -layout: post -title: Prebid.js Releases Outstream Video Support -head_title: Prebid.js Releases Outstream Video Support -description: Late last year, Prebid.js took an important first step beyond traditional display advertising formats with a release of formal support for instream video. Today, Prebid.js is doubling down on its focus on formats with the release of outstream video support. -permalink: /blog/first-open-header-bidding-solution-for-video-now-available-on-prebid-js ---- - -(*This post first appeared on the [AppNexus Product Blog](http://productblog.appnexus.com/prebid-js-releases-outstream-video-support/).*) - -Late last year, Prebid.js took an important first step beyond traditional display advertising formats with a release of formal [support for instream video](http://productblog.appnexus.com/first-open-header-bidding-solution-for-video-now-available-on-prebid-js/). Today, Prebid.js is doubling down on its focus on formats with the release of outstream video support. - -![Outstream Prebid]({{ site.github.url }}/assets/images/blog/outstream-prebid.png){: .pb-md-img :} - -Given the high cost of creating true instream video inventory and the inherent constraints that this places on supply, outstream video formats are proving extremely valuable for publishers looking for video monetization alternatives, and for marketers looking for more available video supply. - -### How Does Prebid Outstream Work? - -For those already familiar with the workflows for "traditional" Prebid display, getting started with outstream video through Prebid.js is very simple! - -#### In the Ad Server - -Within the ad server, you will need one or more display adUnits mapped to the intended size(s) of your outstream placement(s), or you can assign these adUnits a custom outstream size like ```1x1```. From there, you just need to configure Prebid line items in the same way that you would for display. The key / value targeting and creative setup will be identical! - -#### On the Page - -Making sure to update Prebid.js to its latest release version, the on-page setup requires only a few steps: - -1. Add one or more adUnits to your page with the new ```video-outstream``` media type -2. Include at least one bidder on these adUnits capable of ingesting outstream video bid requests -3. Invoke your ad server for the outstream adUnit from the body of the page in the same way that you would for a display adUnit - - -```javascript -var outstreamVideoAdUnit = [ - { - code: 'video-1', - sizes: [ 640, 480 ], - mediaType: 'video-outstream', - bids: [ - { - bidder: 'appnexusAst', - params: { - placementId: '5768085', - video: { - skippable: true, - playback_method: [ 'auto_play_sound_off' ] - } - } - } - ] - } -]; -``` - -#### Renderers - -With its brand new support for "renderers", Prebid.js is able to traffic outstream video through display placements. In general, a renderer is the client-side code (usually a combination of JavaScript, HTML and CSS) responsible for displaying a creative on a page. Fundamentally, a renderer for outstream ads must provide a player environment capable of playing a video creative (most commonly, a VAST XML document). However, in practice, most outstream renderers provide additional functionality / logic, including, but not limited to: - -* Volume, pause, and play controls for the user -* Ability to expand the player to fullscreen -* Skippability controls -* Vendor-specific text, color schemes or logos -* Expanding the video player when the user scrolls into view -* Contracting the player on video completion, or when the user scrolls out of view - -Renderers, though, are not specific to outstream video ads. In fact, all creatives must have a renderer. The properties and required functionality of these renderers differ depending on the type of content being displayed. For example, native content (which is usually defined as a JSON structure containing a collection of assets) requires a renderer capable of assembling the included assets into the ad displayed on the page. - -Today, for outstream video impressions, Prebid requires that each participating demand partner [return its own renderer on the bid response](https://github.com/prebid/Prebid.js/pull/1082). In general, however, it should not really matter where the renderer comes from, as long as at least one is specified. In the following section, we will discuss upcoming plans to expand the possible set of renderer sources and Prebid.js renderer selection logic. - -### What's Next for Prebid Outstream? - -In upcoming Prebid.js releases, we will be continuing to iterate on top of this initial outstream support to ensure that it satisfies the needs of the broadest possible set of publishers and demand partners. As such, we are focusing on a few key topics. - -#### Running Outstream Without an Ad Server - -Prebid.js has always been ad server agnostic, and so we do not believe that publishers looking to create and monetize outstream inventory should be tied to third-party publisher ad servers if they choose not to be. Publishers will be able to choose to give Prebid.js the ultimate responsibility for rendering outstream placements, thus removing the reliance on an ad server to monetize outstream video inventory. - -#### Renderer Selection Logic - -To ensure that publishers can take advantage of outstream video with every demand partner, we are expanding the logic by which Prebid.js will select the appropriate renderer to invoke for a given outstream video adUnit. As a result, demand partners will be able to participate on Prebid outstream video impressions even if they do not have their own outstream renderer. In order of priority, Prebid.js will choose a renderer on a given adUnit in the following way: - -1. If the publisher specifies a renderer, Prebid.js will invoke it across all demand partners -2. If a demand partner specifies a renderer, Prebid.js will invoke it if and only if that demand partner serves -3. If neither the publisher nor the demand partner specify a renderer, Prebid.js will invoke its own open-source default renderer - -#### Combining the Power of Both Instream and Outstream - -We will consolidate instream and outstream video impressions under a common video adUnit definition, and add support for format-specific targeting parameters that demand partners will be able to ingest. As a result, instream and outstream video supply will have access to the same set of video-capable demand partners by default. - -Supporting documentation specific to Prebid outstream video is available through prebid.org, including [How to Show Outstream Video Ads]({{ site.github.url }}/dev-docs/show-outstream-video-ads.html) and an [outstream end-to-end working example page](http://acdn.adnxs.com/prebid/alpha/unrulydemo.html). diff --git a/_posts/2017-08-21-prebid-adds-support-for-mobile-app-header-bidding.md b/_posts/2017-08-21-prebid-adds-support-for-mobile-app-header-bidding.md deleted file mode 100644 index e446cf98ea..0000000000 --- a/_posts/2017-08-21-prebid-adds-support-for-mobile-app-header-bidding.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -layout: post -title: Prebid Adds Support for Mobile App Header Bidding -head_title: Prebid Adds Support for Mobile App Header Bidding -description: The addition of Prebid Mobile libraries for iOS and Android marks another milestone for Prebid, representing its first formal steps towards providing an end-to-end open-source header bidding solution for mobile app publishers. -permalink: /blog/prebid-adds-support-for-mobile-app-header-bidding ---- - -Last week, the [prebid-mobile-android](https://github.com/prebid/prebid-mobile-android) and [prebid-mobile-ios](https://github.com/prebid/prebid-mobile-ios) repositories were open-sourced under the Prebid GitHub project. The addition of these libraries marks another milestone for Prebid, representing its first formal steps towards providing an end-to-end open-source header bidding solution for mobile app publishers. - -![Prebid Mobile - Banner and Interstitial Ads running on iOS]({{site.baseurl}}/assets/images/blog/prebid-mobile-ios-banner-and-interstitial.png){: .pb-md-img :} - -## Why Should I Be Interested in Prebid Mobile? - -This year, mobile programmatic spend in the US is expected to exceed $21 billion, representing 78% of all mobile display spend1. Prebid Mobile helps app publishers unlock a greater portion of this mobile app growth by solving for many of the problems endemic to today's mobile programmatic ecosystem, and by applying the advantages of "traditional" web header bidding to mobile app environments. - -Major benefits include: - -- **Increased Transparency**: Prebid Mobile brings transparency and fair, real-time competition to the mobile app monetization black box. Today, most mobile publishers route impressions to mediation partners without knowing how much each impression is actually worth. By enabling real-time impression-level competition among all configured demand partners, Prebid Mobile allows publishers to more efficiently monetize their most valuable impressions. - -- **Better User Experience**: Prebid Mobile offers significant improvements to the end-user experience by reducing latency and resource contention on the user's mobile device. By establishing a single server-side point of integration for programmatic demand partners, Prebid Mobile eliminates the need to set up sequential mediation waterfalls. And, by continuously pre-caching creatives in the background, Prebid Mobile can deliver ads with near-zero delay without interrupting the app's workflow. - -- **Streamlined Integration for App Developers**: Prebid Mobile is designed to be as streamlined as possible for mobile app developers. Once integrated, Prebid Mobile ad unit configurations are maintained and managed server-side. This means that publishers can subsequently add or remove demand partners, change demand partner parameters, or alter global settings without making any updates to native app code. - -## How Prebid Mobile Works - -![How Prebid Mobile Works]({{site.baseurl}}/assets/images/blog/prebid-mobile-how-it-works.png){: .pb-lg-img :} - -### Initial Setup - -Mobile developers register each ad unit with the Prebid Mobile framework (ideally early in the application lifecycle). In doing so, each Prebid Mobile ad unit is associated with the ad object in your primary ad server SDK, and with a unique configuration ID pointing to a set of Prebid demand partners maintained server-side. - -In parallel, the publisher ad ops team will configure Prebid Mobile line items and creatives in the primary ad server targeted to Prebid key/values. This ad ops setup is nearly identical to Prebid.js for web and should be familiar for publishers that have integrated. - -![Prebid Server Config Page]({{site.baseurl}}/assets/images/blog/prebid-server-config-page.png){: .pb-lg-img :} - -### In the App - -As the Prebid Mobile module runs, it sends bid requests to Prebid Server via a single integration point. Prebid Server looks up the settings associated with the ad unit's configuration ID, and makes server-side OpenRTB requests to each appropriate demand partner. Prebid Server caches the creative content associated with each demand partner bid response, and sends lightweight bid-level metadata (including bid price) back to the client device as key/value pairs. - -The client-side Prebid Mobile module communicates this key/value targeting to the primary ad server SDK. If the primary ad server selects a Prebid Mobile line item based on this targeting, the Prebid Mobile JavaScript creative is served into the ad server's ad view. Once delivered, this placeholder JavaScript fetches the actual cached creative content from Prebid Server, and the winning demand partner counts the transacted impression. - -## Getting Started - -Once you've reviewed the [Prebid Mobile Documentation]({{site.baseurl}}/prebid-mobile) on Prebid.org, the most important first step is to register for a Prebid Server account through the [Prebid Server Homepage](https://prebid.adnxs.com/). Upon registration, you will be assigned a Prebid Server account ID, and can begin setting up demand partner configurations that will be associated with Prebid Mobile ad units. - -From there, you can download the Prebid Mobile [Android](https://github.com/prebid/prebid-mobile-android) and/or [iOS](https://github.com/prebid/prebid-mobile-android) SDKs from GitHub, and can begin working with your ad ops team to configure Prebid Mobile line items and creatives in your primary adserver. - -## What's Next for Prebid Mobile - -Moving forward, we will focus on adding additional support in two key areas: - -- **Ad types**: The initial Prebid Mobile rollout includes support for banner and interstitial ads running through the Google Ad Manager and MoPub ad server SDKs. We are working to add support for additional ad types in each of these ad server SDKs, including interstitial video, rewarded video and native ads. - -- **Demand partners**: In parallel, we are working to increase the available set of Prebid Mobile demand partners, focusing initially on mobile-first SSPs as well as the set of demand partners already integrated with Prebid Server for display. - -## How to Contribute - -Prebid is an open-source project, and we very much encourage community participation in driving its design and development. The [prebid-mobile-android](https://github.com/prebid/prebid-mobile-android) and [prebid-mobile-ios](https://github.com/prebid/prebid-mobile-ios) repositories are now available on GitHub, along with the source code for [Prebid Server](https://github.com/prebid/prebid-server). - -We love pull requests, and will be looking to collaborate with the community as we look to broaden Prebid Mobile support across ad servers, mobile ad types, and demand partners. - -by [Matt Jacobson](https://www.linkedin.com/in/matthew-jacobson-5a947940/), Product Manager at AppNexus diff --git a/_posts/2017-09-11-announcing-prebid-org.md b/_posts/2017-09-11-announcing-prebid-org.md deleted file mode 100644 index 81f3ff72f6..0000000000 --- a/_posts/2017-09-11-announcing-prebid-org.md +++ /dev/null @@ -1,125 +0,0 @@ ---- -layout: post -title: Announcing the formation of an independent Prebid.org -head_title: Announcing the formation of an independent Prebid.org -description: This week, we're pleased to announce the formation of Prebid.org, an independent organization dedicated to open source tools that drive publisher monetization. -permalink: /blog/announcing-prebid-org ---- - -This week, we're pleased to announce the formation of -[Prebid.org](/overview/what-is-prebid-org.html): an -independent organization dedicated to open source tools that drive -publisher monetization. - -We sat down with -[Michael Richardson](https://www.linkedin.com/in/mtrichardson/) to -answer a few questions about why -[Prebid.org](/overview/what-is-prebid-org.html) is -being launched as an independent entity and what it means for -publishers and vendors. Michael is a Product Line Manager at -[AppNexus](https://www.appnexus.com) and Chairman of -[Prebid.org](/overview/what-is-prebid-org.html). - -* TOC -{:toc} - -## What's the background on Prebid.org? - -[Prebid.js]({{site.baseurl}}/overview/getting-started.html) has been a -transformative piece of technology for our industry. It makes it a lot -easier for publishers to do header bidding, choose which demand -partners they want to work with, and quickly add new ones at will. - -Given how much header bidding has benefited the digital ecosystem – -including advertisers and consumers – we want to bring it to as many -different publishers and vendors as possible. It's so important to us -that, rather than backing a proprietary solution, we want it to be a -group effort. We want to work together with the rest of the industry -to keep driving header bidding adoption and effectiveness. - -That's why we're launching -[Prebid.org](/overview/what-is-prebid-org.html): a -coalition to champion open-source header bidding and its ongoing -development. [Prebid.org](/overview/what-is-prebid-org.html) -will act as an independent voice on how publishers should interact -with programmatic, help ensure that header bidding remains fair and -transparent across all parties affiliated with Prebid, and continue to -develop and work on features like we do today. - -## Why are openness and transparency so important with header bidding? - -We've governed Prebid in an open-source manner since the beginning of -the project, so thematically, this is nothing new. The Prebid.org -coalition allows us to make this a more concerted group effort. We can -bring together talent from different ad tech providers and solve -problems together, rather than work on them independently or focus -only on our own companies' offerings. - -But let me also answer your bigger question about why openness is so -crucial to the Prebid project in general. One of the core benefits of -Prebid – and header bidding in general – is that it allows every -advertiser an equal chance at every impression. Open-sourcing Prebid -makes it easy for everyone to see that there aren't any tricks or -biases happening in the wrapper, proving to users that the benefit is -really there. - -Beyond that, open-sourcing Prebid makes it easier for the industry to -adapt as it changes, since the users of Prebid are the ones driving -new features and functionality. It's also made it easy for new -companies to work with Prebid. There are over 80 demand partners with -adapters available for Prebid, and -[multiple analytics companies]({{site.baseurl}}/overview/analytics.html) -who have built extensions for Prebid. Only an open-source project can -reach such broad adoption. - -I think you see these values – fairness, adaptability, openness to new -partners – reflected most in Prebid.org's -[Wrapper Code of Conduct]({{site.baseurl}}/wrapper_code_of_conduct.html). The -code is a set of rules and principles that govern how we think all -wrappers should operate. We want to build a consensus around what -wrappers should and should not be doing so that publishers and demand -partners can trust that their wrappers are treating them fairly. - -## Who is part of Prebid.org? - -We're launching with [Rubicon Project](https://rubiconproject.com) to -start. They've contributed a ton -to Prebid already – some great additions to the project have come from -the AppNexus and Rubicon Project teams working together. - -Moving forward, we envision many other partners joining -Prebid.org. [SSPs]({{site.baseurl}}/dev-docs/bidders.html), -[analytics providers]({{site.baseurl}}/overview/analytics.html) – -pretty much any ad tech vendor who works with publishers and supports -header bidding will likely come into contact with Prebid at some -point. We'd welcome any of them to join Prebid.org and collaborate -with us. - -## Should current Prebid users expect any changes? - -There will be no changes to functionality in the short term. In the -long term, we hope that users will see Prebid continue to get better -and better. Getting more people involved is the best way to foster the -creation of more tools to support more use cases and generally ensure -Prebid is easy to use. - -## Any parting tips for publishers using header bidding? - -Header bidding has unlocked huge revenue gains for publishers, but -they need to stay on top of the latest trends to keep getting the most -out of it. I have two key tips for publishers to set themselves up for -long-term success with header bidding. - -First, don't just use header bidding for display only. Channels like -[video]({{site.baseurl}}/dev-docs/docs-by-format.html) and -[mobile app]({{site.baseurl}}/prebid-mobile) are really heating up -right now, and header bidding can make them even more lucrative for -publishers. - -My second piece of advice would be to put a lot of thought into the -demand partners you work with. As the existence of our -[Wrapper Code of Conduct]({{site.baseurl}}/wrapper_code_of_conduct.html) -suggests, we as an industry have nailed down the basic criteria for -what a wrapper ought to do. The next problem every publisher needs to -solve is building a roster of partners who bring them unique demand -without compromising user experience. diff --git a/_posts/2017-12-11-prebid-1-is-released.md b/_posts/2017-12-11-prebid-1-is-released.md deleted file mode 100644 index ed4f3c73b1..0000000000 --- a/_posts/2017-12-11-prebid-1-is-released.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: post -title: Prebid.js 1.0 is Released! -head_title: Announcing the release of Prebid.js 1.0 -description: This week, we're pleased to announce the release of Prebid.js 1.0 -permalink: /blog/prebid-1-is-released ---- - -We're pleased to announce the release of [Prebid.js 1.0!](https://github.com/prebid/Prebid.js/releases/tag/1.0.0) [Download it]({{site.baseurl}}/download.html) or [build it from master](https://github.com/prebid/Prebid.js/blob/master/README.md#Build)! - -As a publisher, you can look forward to the following improvements when adopting Prebid.js 1.0: - -- Universal ad unit type support for [native](/dev-docs/show-native-ads.html), [video](/dev-docs/show-video-with-a-dfp-video-tag.html), and banner -- Faster performance due to using fewer JS libraries and simplifying adapter code -- Module integrations that support things like: - - [*Multiple currencies*]({{site.baseurl}}/dev-docs/modules/currency.html) - - [*User syncing*]({{site.baseurl}}/dev-docs/publisher-api-reference.html#setConfig-Configure-User-Syncing) - - [*Simplified config APIs*]({{site.baseurl}}/dev-docs/publisher-api-reference.html#module_pbjs.setConfig) -- Better support for single page applications/sites (concurrency) -- Better [size mapping and responsive site support](/dev-docs/publisher-api-reference.html#setConfig-Configure-Responsive-Ads) - -For more information, see: - -- [Prebid 1.0 Publisher API Changes]({{site.baseurl}}/dev-docs//prebid-1.0-API.html): A complete list of all 1.0 API changes -- [Publisher API Reference]({{site.baseurl}}/dev-docs/publisher-api-reference.html): Updated to mark all deprecated methods that are no longer available in version 1.0 diff --git a/_posts/2019-01-08-updated-website.md b/_posts/2019-01-08-updated-website.md deleted file mode 100644 index 16eb9b21ce..0000000000 --- a/_posts/2019-01-08-updated-website.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -layout: post -title: Prebid.org Website Updated -description: We've given the prebid.org website a new look. -permalink: /blog/updated-website ---- - - -
- -### Highlights: - -- **Prebid.org is more than Prebid.js**: Prebid.js is likely to remain our most important product, but the new website has placed Prebid SDK and Prebid Server on equal footing with it -- all products are in their own areas now. - -- **Updated Navigation**: The top and left navigation elements have been completely revised. The goal was to have *everything* in the left nav, and the most commonly used pages in the top nav. - -- **Adaptive**: the site should look better than ever on small screens. - -- **Cookie Permission**: you may have noticed already that we have a 'cookie banner' on the bottom asking for permission to set cookies. If you don't grant permission, some content like code examples and videos won't be available. There's also a new [privacy policy](/privacy.html). - -- **New Content**: - - [Prebid Server docs](/prebid-server/prebid-server-overview.html) - - [Product Management Committees](/overview/prebid-management-committees.html) - - [Community Code of Conduct](https://prebid.org/code-of-conduct/#community) - - [Prebid Members and Partners](/partners/partners.html) - - [Prebid Members providing Managed Services](https://prebid.org/product-suite/managed-services/) - - [Format index page](/formats/formats.html) - -### Coming Up: - -We'd like to have your feedback about the changes and any other things you'd like to see. Email us at website@prebid.org. Here's what's on our list so far: - -- Search -- Left nav for blog pages -- Differentiate expanded arrow on left nav -- Clean up extra space at the bottom of the home page - diff --git a/_posts/2019-01-31-prebidjs-2.md b/_posts/2019-01-31-prebidjs-2.md deleted file mode 100644 index 28c81800a2..0000000000 --- a/_posts/2019-01-31-prebidjs-2.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -layout: post -title: Prebid.js 2.0 Released -description: A minor major version number release -permalink: /blog/pbjs-2 ---- - - -
- -### Prebid.js 2.0 is a minor major release - -Compared to Prebid.js 1.0, the 2.0 release will be a non-event for most sites. - -The Prebid.js team has adopted a policy of incrementing the major version number whenever there's a 'breaking change' -- a change in behavior we want everyone to be aware of. The idea is that everyone will wonder "what's with the new version", and come looking for blog entries like this. For 2.0, the change is: - -{: .alert.alert-warning :} -The "[limited bid caching](/dev-docs/faq.html#does-prebidjs-cache-bids)" feature is now **off** by default. - -Any publisher that was utilizing this limited form of bid caching may turn it back on. Do this by calling `setConfig()` with the [useBidCache](/dev-docs/publisher-api-reference.html#setConfig-Use-Bid-Cache) option. - diff --git a/_posts/2019-02-12-barcelona.md b/_posts/2019-02-12-barcelona.md deleted file mode 100644 index 88725c280e..0000000000 --- a/_posts/2019-02-12-barcelona.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: Prebid Leadership Summit in Barcelona on Feb 25th 2019 -description: -permalink: /blog/barcelona-2019 ---- - - -
- -### Prebid Leadership Summit in Barcelona on Feb 25th 2019 - -Prebid.org invites you to the first Prebid Leadership Summit of the year, taking place in Barcelona during Mobile World Congress on 25 February. The event will take place at [Marfeel’s office](https://goo.gl/maps/4pxcDAaZVk82), from 3:00PM – 6:00PM CET, followed by cocktails until 8:30PM. - -[REGISTER NOW](https://www.eventbrite.com/e/prebid-leadership-summit-mwc-tickets-55547775893) - -**What to expect:** - -The Prebid Leadership Summit is an educational event including overviews, deep dives and conversations about Prebid and its evolution. It’s a chance to explore the latest Prebid solutions and how they work for different kinds of publishers. In particular: - -* Insights from member organizations and premium publishers into current best practices and future plans for Prebid -* Panel discussions on the expansion of header bidding into emerging formats, such as video and native -* Networking opportunities for publishers and Prebid members -* And more! - -**Who should attend?** - -The audience is meant to be Product, Engineering, and AdOps from the Publisher side, so people close to the technology. Space is limited, so be sure to register by 18 February. Feel free to forward to your colleagues. - -Please email event-committee@prebid.org if you have any questions. - -We look forward to seeing you on 25 February! diff --git a/_posts/2019-03-05-marfeel-event.md b/_posts/2019-03-05-marfeel-event.md deleted file mode 100644 index de40176866..0000000000 --- a/_posts/2019-03-05-marfeel-event.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -layout: post -title: 4 Ideas from the Barcelona Prebid Summit -description: -permalink: /blog/marfeel-event-2019 ---- - - -
- -(Originally [posted on Marfeel's site](https://www.marfeel.com/blog/prebid-leadership-summit-2019/), slightly edited for clarity.) - -![Barcelona Summit](/assets/images/blog/2019-03-05-marfeel-event-1.jpg){: .pb-lg-img :} - -As Mobile World Congress has brought the digital publishing world to us this week, we welcomed our industry partner Prebid.org to the Marfeel’s offices to host their third ever Prebid Leadership Summit. Led by the Chair of Prebid, Alexandra Smith, the mission of the day was to understand the changes leading the header bidding industry, and the role of the Prebid organization in driving these changes. - -We were also joined by Remi Boudard from AppNexus, Enrique Blanc from Grupo Zeta, and Lucas Isern and Xavi Beumala from Marfeel, discussing the rise and challenges of adopting server-side header bidding. - -To recap the key points for those that weren’t able to attend, we’ve collated everything publishers need to know. - -Here are the key takeaways: - -## 1. Header Bidding is still in the early-adopter phase, especially for Server Side - -In Europe in 2017, 10-15% of display impressions were generated using header bidding. By the end of 2018, it was closer to 50%. Client-side is still the dominant method of implementation. - -Client-side header bidding was always supposed to be a temporary phenomenon before a rapid migration to server-side. This was due to the impact of page-load on the user experience and the efficiency gains provided by server-side. - -But, there are still limitations that prevent server-side from being rolled out across advertisers. One of the main challenges for adoption is user identification. When you add an additional step for cookie matching, match rates can go down and in turn, impact monetization. Buyers only bid high when they know who the user is, so losing match rates can severely impact monetization for many. Until universal ID solutions come to fruition, the industry is hindered. - -Whats more, web publishers already have working systems for display. There is not currently enough incentive to apply wholesale changes to their approach. They don’t want to spend time and money shifting to a system that will be more advanced and more rigorously industry-tested in a year or so. - -Publishers are waiting for companies and organizations such as Marfeel and Prebid to solve these issues before fully committing to server-side. - -To bridge this gap, Marfeel has a dedicated team that has built our own header bidding solution, now incorporated into the Prebid open-source platform. Working alongside our publishers and the Prebid organization has allowed us to create one of the industry’s first server-side header bidding solutions, that is live across our publishers now. - -## 2. Mobile will be the driving force for mass-adoption - -Most major publishers operate with a hybrid solution, across their formats, such as web, mobile, app, and video. But, running different ad logic for every format is costly and difficult, as is running many SDKs. - -However, mass-adoption of server-side header bidding will require a catalyst that proves its value and utility. For publishers, this revolution will start with mobile, since the Prebid Mobile SDK works hand in hand with Prebid Server. Since Prebid Mobile relies on Prebid Server, publishers will begin to adopt it and consider its use-case for web traffic as well. As more and more publishers adopt, the community will dedicate more time and energy to its development. - -Once mobile proves the market for server-side header bidding, publishers will start to migrate towards it, making Prebid Server become a unified header bidding solution across all formats and devices. - -## 3. Hybrid Models will dominate 2019 but after that… - -No-one at the event was expecting server-side header bidding to be universally adopted by all publishers, across all formats this year. However, the increasing value of this technology and the rise of header bidding in mobile will lead to some major changes. - -It’s expected that, with the adoption of EB (Google’s Exchange Bidding) and Prebid Server that SSPs will eventually become commoditized. This may force them to shift into more technology and service-focused companies, helping publishers navigate the complexities of the ecosystem and providing them with the latest developments. - -Until this mass-migration to Server, publishers are able to incorporate different Prebid implementations to maximize their revenue, which is where the beauty of the platform lies. However, client-side will gradually evolve to be replaced by server-side header bidding and is likely to spread across all formats after a successful initial implementation across mobile. - -## 4. Header Bidding and Machine Learning = Intelligent Ads - -Finally, the results of mass-adoption—though the proving ground of mobile—will enable the development of more advanced systems of header bidding. - -The combination of a unified platform like Prebid Server, alongside machine learning, will allow advertisers to break down impressions and revenue by demand partner, ad format, inventory, and region. Publishers and advertisers will be able to track deal performance across multiple exchanges with a single report to see who is winning, where, and be able to infer why. - -Machine-learning powered algorithms will segment data by size, ad format, and Google Ad Manager ad unit. Automated systems will see through the entire monetization funnel to spot bottlenecks and eliminate inefficiencies in real-time. Effective server-side header bidding will help facilitate the development of these intelligent ads. - -Prebid open-source tech: Deeper development through collaboration -The current challenges of Prebid Server go beyond just cookie matching. They stretch to scaling server infrastructure and building creative caching. However, the accelerated development of the Prebid open source tech will create advancements beyond reduced latency, including intelligent ads and ad delivery that comes directly from Prebid server. - -The collaborative Prebid organization creates independent standards that benefit everyone. There is no bias because the technology is not created or operated by a single content provider and anyone can build on it and improve it. This collaboration is helping define a transparent industry standard that will ease the path for the implementation of header bidding into publisher’s platforms. - -Marfeel’s product manager in our monetization department, Lucas Isern summarized what this ethos will help deliver: - -{% highlight bash %} -‘Prebid Server is not just Prebid.js without its latencies. It’s an opening door to many more improvements and making crucial steps towards getting out of the browser.’ -{% endhighlight %} diff --git a/_posts/2019-05-22-nycevent.md b/_posts/2019-05-22-nycevent.md deleted file mode 100644 index 15f50b7a04..0000000000 --- a/_posts/2019-05-22-nycevent.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: Prebid Leadership Summit in New York on June 11th 2019 -description: -permalink: /blog/newyork-event-2019 ---- - - -
- -### Prebid Leadership Summit in New York on June 11th 2019 - -Prebid.org invites you to attend the Prebid Leadership Summit: NYC on June 11th, 2019, at Xandr's Razzle Dazzle space in NYC, from 1– 4.30pm, followed by networking until 6.30pm. - -[REGISTER NOW](https://www.eventbrite.com/e/june-2019-prebid-leadership-summit-nyc-tickets-61926422597) - -**What to expect:** - -The Prebid Leadership Summit is an educational event including overviews, deep dives and conversations about Prebid and its evolution. It’s a chance to explore the latest Prebid solutions and how they work for different kinds of publishers. In particular: - -* Insights from member organizations and premium publishers into current best practices and future plans for Prebid -* Panel discussions on the expansion of header bidding into emerging formats, such as video and native -* Networking opportunities for publishers and Prebid members -* And more! - -**Who should attend?** - -The audience is meant to be Product, Engineering, and AdOps from the Publisher side, so people close to the technology. Space is limited, so be sure to register. Feel free to forward to your colleagues. - -Please email event-committee@prebid.org if you have any questions. - -We look forward to seeing you at the event! diff --git a/_posts/2019-06-19-londonevent.md b/_posts/2019-06-19-londonevent.md deleted file mode 100644 index 45fa106583..0000000000 --- a/_posts/2019-06-19-londonevent.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: Prebid Leadership Summit in London on July 11th 2019 -description: -permalink: /blog/london-event-2019 ---- - - -
- -### Prebid Leadership Summit in London on July 11th 2019 - -Prebid.org invites you to attend the Prebid Leadership Summit in London on July 11th, 2019. It will be held at the IAB UK venue from 1:30–4:30pm, followed by networking until 6:30pm. - -[REGISTER NOW](https://www.eventbrite.com/e/july-2019-prebid-leadership-summit-london-tickets-63441520295) - -**What to expect:** - -The Prebid Leadership Summit is an educational event including overviews, deep dives and conversations about Prebid and its evolution. It’s a chance to explore the latest Prebid solutions and how they work for different kinds of publishers. In particular: - -* Insights from member organizations and premium publishers into current best practices and future plans for Prebid -* Panel discussions on the expansion of header bidding into emerging formats, such as video and native -* Networking opportunities for publishers and Prebid members -* And more! - -**Who should attend?** - -The audience is meant to be Product, Engineering, and AdOps from the Publisher side, so people close to the technology. Space is limited, so be sure to register. Feel free to forward to your colleagues. - -Please email event-committee@prebid.org if you have any questions. - -We look forward to seeing you at the event! diff --git a/_posts/2019-09-17-sfevent.md b/_posts/2019-09-17-sfevent.md deleted file mode 100644 index f22a02399d..0000000000 --- a/_posts/2019-09-17-sfevent.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: Prebid Meetup and Leadership Summit in San Francisco on Oct 24th 2019 -permalink: /blog/2019-sf-event ---- - -
- -### Prebid Meetup and Leadership Summit in San Francisco on Oct 24th 2019 - -Prebid.org invites you to attend a Prebid Meetup and Leadership Summit in -San Francisco on October 24, 2019. Our event will be at the historic -Merchant’s Exchange Club. There will be presentations from 1.30–4.30pm, -followed by networking and socializing over appetizers and drinks until -6.30pm. Space is limited, so [register now](https://www.eventbrite.com/e/prebid-meetup-and-leadership-summit-san-francisco-october-24-2019-registration-72716612345) to reserve your spot! - -**What To Expect** - -The Prebid Meetup and Leadership Summit is an educational event including -overviews, deep dives and conversations about Prebid, its evolution, roadmap -and vision. It’s a chance to get key insights on the latest Prebid solutions -and how they work for different kinds of publishers. Here are a few things you -can expect from this event: - -- Insights from member organizations and premium publishers into current best practices and future plans for Prebid -- Panel discussions on the expansion of header bidding into emerging formats, such as video and native -- Networking opportunities for publishers and Prebid members -- And more! - -We look forward to seeing you at the event! diff --git a/_posts/2019-10-07-prebid-3.0.md b/_posts/2019-10-07-prebid-3.0.md deleted file mode 100644 index 146e01c44e..0000000000 --- a/_posts/2019-10-07-prebid-3.0.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -layout: post -title: Prebid.js 3.0 Major Release Announcement -description: -permalink: /blog/pbjs-3 ---- - - -
- -The Prebid core team is excited to announce a major release: Prebid.js 3.0! Here are the main items that will be included in this release: - -* Upgrade all bidder adapters to HTTPS all the time. -* Removal of miscellaneous legacy APIs and functions (should be a minor publisher impact). ([Issue 4118](https://github.com/prebid/Prebid.js/issues/4118)) -* Unbundle PubCommon ID and Unified ID from the User ID module build. -* Fix for `getHighestCpmBids` to not return rendered bids. ([Issue 2959](https://github.com/prebid/Prebid.js/issues/2959)) -* Remove the legacy PBS adapter endpoint support. ([Issue 4172](https://github.com/prebid/Prebid.js/issues/4172)) -* Improve caching behavior if enabled. ([Issue 4148](https://github.com/prebid/Prebid.js/issues/4148)) -* Remove the 'min' attribute from custom pricegranularities. - -[See the full list](https://github.com/prebid/Prebid.js/labels/3.0%20API%20Change) of items that are associated with the 3.0 release. - -### Publisher-facing API Changes - -Review these changes to make sure you're ready to upgrade to 3.0. - -#### 1. AdUnit.sizes can no longer be used - -To upgrade to Prebid.js 3.0, you'll need to make sure that ad sizes are in mediaTypes.banner.sizes. - -For example, instead of including sizes like this: -``` - var adUnits = [ - { - code: 'test-div', - sizes: [[300,250],[300,600]], -``` -You will need to define adUnits sizes like this: -``` - var adUnits = [ - { - code: 'test-div', - mediaTypes: { - banner: { - sizes: [[300,250],[300,600]] - } - }, -``` - -AdUnit.sizes should not have been used for video player size, but be aware that video requires mediaTypes.video.playerSize. e.g. - -``` - var adUnits = [ - { - code: 'test-div', - mediaTypes: { - video: { - playerSize: [640, 480], - ... - } - }, -``` - -#### 2. The userSync API no longer supports iframeEnabled, pixelEnabled, or enabledBidders - -There has been a much more flexible syntax for userSync available for a long time, and it's what you need to be using now. See the [Publisher API docs](http://prebid.org/dev-docs/publisher-api-reference.html#setConfig-Configure-User-Syncing) for more details, but here's an example of the improved syntax: - -``` -pbjs.setConfig({ - userSync: { - filterSettings: { - iframe: { - bidders: ['def'], // only this bidder is excluded from syncing iframe pixels, all other bidders are allowed - filter: 'exclude' - }, - image: { - bidders: ['abc', 'def', 'xyz'], // only these 3 bidders are allowed to sync image pixels - filter: 'include' - } - }, - syncsPerBidder: 3, // and no more than 3 syncs at a time - syncDelay: 6000, // 6 seconds after the auction - } -}); -``` - -#### 3. Remove legacy protocol support for Prebid Server - -You will need to check the s2sConfig.endpoint defined for Prebid Server. If it's `/auction`, you'll need to change to `/openrtb2/auction`. No other changes are necessary, but you should test the change with your Prebid Server provider. - -#### 4. pbjs.loadScript() is gone - -If you happen to be using this ancient function, you'll need to find an alternative. - -#### 5. Be aware that the getHighestCpmBids() function will no longer return already-rendered bids - -This is a bug that some of you may have implemented workarounds for. More details [here](https://github.com/prebid/Prebid.js/issues/2959). - -#### 6. The 'min' attribute is no longer used on [pricegranularity](http://prebid.org/dev-docs/publisher-api-reference.html#setConfig-Price-Granularity) - -The existence of the 'min' attribute should not harm existing price granularities, but if anyone has defined price granularities with gaps between the buckets, they won't work anymore. (**EDIT**: see box below) - -For example, this is no longer possible. (It's unclear to us why anyone would need this.) - -``` -const customConfigObject = { - "buckets" : [{ - "min" : 0, - "max" : 5, - "increment" : 0.01 - }, - { - "min" : 5.25, // ignore bids between $5 and $5.25 - "max" : 10, - "increment" : 0.05 - }] -}; -``` - -{: .alert.alert-warning :} -**EDIT**: since launching Prebid.js 3.0, we've discovered that some publishers had explictly defined non-overlapping min/max ranges like 0-0.99, 1-4.99, 5-19.99, etc. Unfortunately, this arrangement doesn't work as expected in 3.x. Instead of producing values 1.00, 1.05, 1.10, etc. it produces 0.99, 1.04, 1.09, etc. We apologize for missing this breaking change. - -#### 7. Specifically pull PubCommon ID and Unified ID into your build - -In previous versions, PubCommon ID and Unified ID were automatically -included as part of your Prebid.js build when you included the [userId module](/dev-docs/modules/userId.html) - -This is no longer the case; in order for a Prebid.js package to include PubCommon ID and Unified ID, the `gulp build` command will need to specifically include them. - -#### More details - -Implementation details for all Publisher-facing changes are [here]( -https://github.com/prebid/Prebid.js/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22Pub+API+Change%22+label%3A%223.0+API+Change%22+) - -### Adapter Maintainers Action Required - -If you're responsible for any adapters, be sure you've taken the actions outlined here. - -#### 1. Ensure your bidder doesn't use deprecated functions - -**Referrer detection and related code** - -Bidder adapters should review their implementation to see if they are relying on getting referrer information from updated APIs in `utils.js`. If they are, they should instead use the new [referrer methods](http://prebid.org/dev-docs/bidder-adaptor.html#referrers) on the bid request (`bidderRequest.refererInfo`). - -**Important** -If you are using a deprecated function, your bidder adapter will be removed from the 3.0 branch. You will need to re-submit compliant code. Please target re-submission by *November 1, 2019*. This will give enough time for the core team to review and target the release of mid November. - - -#### 2. Verify bidder supports HTTPS - -We ask all bidder adapters to ensure they are compliant with secure requests to their endpoints (HTTPS). It is already a requirement for bidders to support it on secure pages, so hopefully this will not be a big issue. For the 3.0 release the Prebid core team will automatically update all the endpoints to secure if they are not already updated. - -#### 3. Verify adapter reads sizes from mediaTypes.banner.sizes - -We are telling pubs that they need to confirm that their adUnits define sizes in `mediaTypes.banner.sizes` instead of just `sizes`. - -Adapter code and examples must be updated to reflect this change. - - -### Target release date - -**Mid-November, 2019** diff --git a/_posts/2019-12-04-ccpa.md b/_posts/2019-12-04-ccpa.md deleted file mode 100644 index bcb32466d6..0000000000 --- a/_posts/2019-12-04-ccpa.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -layout: post -title: Prebid.js 2.43.0 supports CCPA/US Privacy -description: -permalink: /blog/ccpa ---- - - -
- -Prebid.js 2.43.0 includes a new [consent management module](/dev-docs/modules/consentManagementUsp.html) for supporting the California Consumer Privacy Act (CCPA). The [IAB has generalized CCPA support](https://www.iab.com/guidelines/ccpa-framework/) to cover future regulations, referring to the feature as "US Privacy." - -The module works with supported Consent Management Platforms (CMPs) to fetch an encoded string representing the user’s consent choices, making it available for adapters to consume and process. -Bidder adapters can consider making use of this additional consent data in the header bidding auction. - -{: .alert.alert-warning :} -Prebid functionality created to address regulatory requirements does not replace each party’s responsibility to determine its own legal obligations and comply with all applicable laws. -**We recommend consulting with your legal counsel before determining how to utilize these features in support of your overall privacy approach.** - -See the [US Privacy Consent Management Module](/dev-docs/modules/consentManagementUsp.html) page for details and which adapters are supporting the US-Privacy parameter. diff --git a/_posts/2020-03-12-tcf2.md b/_posts/2020-03-12-tcf2.md deleted file mode 100644 index 1605781a0a..0000000000 --- a/_posts/2020-03-12-tcf2.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -layout: post -title: Prebid.org Support for TCF v2.0 -description: -permalink: /blog/tcf2 ---- - - -
- -The IAB's Transparency and Consent Framework (TCF) version 2.0 for enhanced support of GDPR is scheduled to take effect April 1, 2020. This is a major update from TCF version 1.1. - -The key changes are: -- More defined 'purposes'. -- More flexibility for the legal bases used by vendors. -- Different in-page JavaScript API. - -References -- [IAB Europe's TCF v2.0 Homepage](https://iabeurope.eu/tcf-2-0/) -- [TCF Policies](https://iabeurope.eu/tcfdocuments/documents/legal/tcfpolicyFINALv2.pdf) -- [TCF v2.0 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) -- [Prebid Support for Enforcing TCF v2.0](/dev-docs/requirements/tcf2/PrebidSupportforEnforcingTCF2.html) - -{: .alert.alert-warning :} -**Consult with your legal counsel before determining how to utilize Prebid features in support of your overall privacy approach.** - -The following is a summary of how various Prebid components will support TCF v2.0 and the estimated availability dates: - -## Prebid.js - -Support for TCF2 is broken into several phases: - -{: .table .table-bordered .table-striped } -| Phase | Description | Est. Availability | -| ----- | ----------- | ----------------- | -| 1 | DONE - Support a ['deviceAccess' flag](/dev-docs/publisher-api-reference.html#setConfig-deviceAccess). Publishers can parse the TCF string on their own and configure Prebid.js appropriately. | Released with v3.12 | -| 2 | DONE - Update the [GDPR ConsentManagement module(/dev-docs/modules/consentManagement.html) to [read TCF v2.0 strings](https://github.com/prebid/Prebid.js/issues/4801) and forward to bid adapters. | Released with v3.12 | -| 3 | DONE - Support a ['default GDPR scope'](/dev-docs/modules/consentManagement.html) flag to allow control over scenarios where the CMP doesn't respond in time. | Released with v3.13 | -| 4 | DONE - Add a new ['GDPR Enforcement Module'](/dev-docs/modules/gdprEnforcement.html) to support parsing TCF v2.0 strings and enforcing Device Access. | Released with v3.14 | -| 5 | DONE - Update the GDPR ConsentManagement module to support parsing TCF v2.0 strings and enforcing Purposes 2 | Prebid.js 4.0 | - -## Prebid Server - -{: .table .table-bordered .table-striped } -| Phase | Description | Est. Availability | -| ----- | ----------- | ----------------- | -| 1 | DONE - Support parsing the TCF v2.0 string and enforcing Device Access. | PBS-Go v0.105.0, PBS-Java v1.32 | -| 2 | DONE - Support parsing TCF v2.0 strings and enforcing Purposes 2, 4, 7 and Special Feature 1 | PBS-Go v0.109.0, PBS-Java v1.35.2 | - -## Prebid SDK - -{: .table .table-bordered .table-striped } -| Phase | Description | Est. Availability | -| ----- | ----------- | ----------------- | -| 1 | DONE - Support the 'deviceAccessConsent' flag and passing TCF v2.0 strings to Prebid Server. | SDK v1.5 | diff --git a/_posts/2020-07-22-ix-joins-prebid.md b/_posts/2020-07-22-ix-joins-prebid.md deleted file mode 100644 index 043c0b8504..0000000000 --- a/_posts/2020-07-22-ix-joins-prebid.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -layout: post -title: Index Exchange Joins Prebid.org -description: -permalink: /blog/ix-joins-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/announcement-index-exchange-joins-prebid-org/). - diff --git a/_posts/2020-07-24-PB4-release.md b/_posts/2020-07-24-PB4-release.md deleted file mode 100644 index 0c97117696..0000000000 --- a/_posts/2020-07-24-PB4-release.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -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.advertiserDomains` | Optional | array | Array of Advertiser Domains for the landing page(s). This is an array to align with the OpenRTB ‘adomain’ field.| -| `meta.brandId` | Optional | int | Bidder-specific Brand ID (some advertisers may have many brands)| -| `meta.brandName` | Optional | string | Brand Name | -| `meta.primaryCatId` | Optional | string | Primary IAB category ID | -| `meta.secondaryCatIds` | Optional | array | Array of secondary IAB category IDs ["IAB-222","IAB-333"] | -| `meta.mediaType` | Optional | string | “banner”, “native”, or “video” - this should be set in scenarios where a bidder responds to a “banner” mediaType with a creative that’s actually a video (e.g. outstream) or native. | - - -While various fields may currently be passed in via bidResponse today, we think it’s important to the future functionality of Prebid to have a standardized taxonomy for this data. You’ll notice a number of important fields, for example **meta.advertiserName** and **meta.advertiserId**, that provide publishers with the ability to report against which advertisers are running on their website. This is all with an eye towards eventually being able to implement logic in the page relating to advertiser, DSP, category, etc. - -In version 4.0 these fields are not required and this is not a breaking change. However, we expect some or all of these fields to become a requirement in the future. Bidders should begin implementing these fields properly as soon as possible. While not yet a global taxonomy, the bidders actively using the field in the near term will shape the community discussion around the final execution of the standardization. - -## Staying on top of Privacy - -Prebid has developed flexible software solutions to help Publishers conform to [TCF 2.0](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/blog.md b/blog.md deleted file mode 100644 index 079ec6b9a2..0000000000 --- a/blog.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: blog -title: Blog -head_title: Prebid.org - Blog for Header Bidding -description: All about Prebid and header bidding - -sidebarType: 7 ---- - -{% for post in site.posts %} - -
-
-
- {{ post.date | date: '%B %d, %Y' }} -
-
-
-
-

- {{ post.title }} -

- {{ post.content }} -
-
-
- -{% endfor %} diff --git a/dev-docs/analytics-ga.md b/dev-docs/analytics-ga.md index 70e7071b2d..6e9ebaa939 100644 --- a/dev-docs/analytics-ga.md +++ b/dev-docs/analytics-ga.md @@ -48,7 +48,7 @@ pbjs.que.push(function() { ##### Distribution Data -Note: we recommend disabling `enableDistribution` if you are using more than 4 bidders. This is because GA throttles the number of events that can be logged (20 initial + 2/second). Distribution data provides you with a histogram of CPM distribution and bid load time (latency) for each bidder. See distribution data [demo here](/blog/header-bidding-analytics-coming-soon/#histogram-analysis-of-latency-and-cpm-distribution). +Note: we recommend disabling `enableDistribution` if you are using more than 4 bidders. This is because GA throttles the number of events that can be logged (20 initial + 2/second). Distribution data provides you with a histogram of CPM distribution and bid load time (latency) for each bidder. See distribution data [demo here](https://prebid.org/blog/header-bidding-analytics-coming-soon/#histogram-analysis-of-latency-and-cpm-distribution). See [this link](https://developers.google.com/analytics/devguides/collection/protocol/v1/limits-quotas) for details on GA's throttling. diff --git a/dev-docs/faq.md b/dev-docs/faq.md index 931e99b616..6fb525a246 100644 --- a/dev-docs/faq.md +++ b/dev-docs/faq.md @@ -50,7 +50,7 @@ In both scenarios, your goal should be to see your inventory fill at the highest There is an analysis from the Prebid team here which may be useful: -[How many bidders should I work with?]({{site.baseurl}}/blog/how-many-bidders-for-header-bidding) +[How many bidders should I work with?](https://prebid.org/blog/how-many-bidders-for-header-bidding) ## Does Prebid.js cache bids? diff --git a/dev-docs/modules/consentManagement.md b/dev-docs/modules/consentManagement.md index 021d2a09c9..a1dc9b9794 100644 --- a/dev-docs/modules/consentManagement.md +++ b/dev-docs/modules/consentManagement.md @@ -22,7 +22,7 @@ sidebarType : 1 {% include /alerts/alert_important.html content=legalNotice %} {: .alert.alert-warning :} -Prebid.org is working on updates that will enable support for reading and parsing TCF 2.0 consent strings. See the [blog post](/blog/tcf2) for timelines. +Prebid.org is working on updates that will enable support for reading and parsing TCF 2.0 consent strings. See the [blog post](https://prebid.org/blog/tcf2) for timelines. ## Overview diff --git a/guide.md b/guide.md index 1a5c0998de..f397c5a8d5 100644 --- a/guide.md +++ b/guide.md @@ -73,10 +73,6 @@ The layout directory contains HTML files that, in conjunction with CSS and JS fi 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. - **_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. @@ -224,24 +220,6 @@ Each menu item is represented in the YML map as a collection of key value pairs **Code Use** This data file is read in the page_v2.html file using Liquid. -blog entry for more info. - messageCreateDt: 01_08_2019 -``` - -| Key | Type | Example | Use | -| ----- | ------ | ------ | ------ | -| messageId | int | 0 | A unique identifier for each message | -| messageText | string | A message | The displayed text. (Use HTML formatting for links.) | -| messageCreateDt | string | 01_08_2019 | Date the message was created, for historical purposes. | - **Code Use** This data file is read in the home.html file using Liquid. diff --git a/overview/how-many-bidders-for-header-bidding.md b/overview/how-many-bidders-for-header-bidding.md index 9de7e733bf..a006ab240f 100644 --- a/overview/how-many-bidders-for-header-bidding.md +++ b/overview/how-many-bidders-for-header-bidding.md @@ -31,7 +31,7 @@ Luckily, the publishers using Prebid.js are curious about these questions too. W ### Q1: How is revenue affected by different factors? -![Prebid Diagram Image]({{ site.github.url }}/assets/images/blog/experiments/revenue.png){: .pb-lg-img :} +![Prebid Diagram Image](/assets/images/blog/experiments/revenue.png){: .pb-lg-img :} (_the above data is normalized to CPM = 1 for anonymity_) Revenue is mainly determined by: @@ -59,7 +59,7 @@ Conclusions: ### Q2: How is page content load time affected? -![Prebid Diagram Image]({{ site.github.url }}/assets/images/blog/experiments/page-load-time.png){: .pb-lg-img :} +![Prebid Diagram Image](/assets/images/blog/experiments/page-load-time.png){: .pb-lg-img :} _(The above page has on average 130 HTTP requests, 1.5MB data transferred per refresh)_ @@ -79,7 +79,7 @@ Conclusions: ### Q3: How about ad load time? -![Prebid Diagram Image]({{ site.github.url }}/assets/images/blog/experiments/ad-load-time.png){: .pb-lg-img :} +![Prebid Diagram Image](/assets/images/blog/experiments/ad-load-time.png){: .pb-lg-img :} _(The above page has on average 130 HTTP requests, 1.5MB data transferred per refresh)_ Ad load time measures how long a user has to wait before he/she can see the ad. This is less important than the page's content load time. However, the initial blank space in the ad unit, or the page elements shifting around due to a late ad load, can both demage the user experience. diff --git a/overview/how-to-simplify-line-item-setup.md b/overview/how-to-simplify-line-item-setup.md index a3c18c9784..3e1a05061d 100644 --- a/overview/how-to-simplify-line-item-setup.md +++ b/overview/how-to-simplify-line-item-setup.md @@ -43,7 +43,7 @@ In this section, we'll learn how to remove the creative size dimension for heade Let's first clarify what "different set of line items for different creative sizes" means. In this scenario, a line item's creative is only of one size. In Google Ad Manager, this looks like: -![Header Bidding Normal Line Item Creative]({{ site.github.url }}/assets/images/blog/line-item-creative.png){: .pb-md-img :} +![Header Bidding Normal Line Item Creative](/assets/images/blog/line-item-creative.png){: .pb-md-img :} Because a site would have many creative sizes, with this setup you need X number of line item sets for X number of creative sizes. @@ -59,7 +59,7 @@ There's a reason bidders recommend different set of line items for different cre Prebid.js can dynamically resize the returned creative to the right size. Here's the setup: -* Submit a few creatives of size 1x1 and make them override the line items' sizes when you [attach creatives to the line item]({{ site.github.url }}/adops/step-by-step.html#step-3-attach-the-creative-to-the-line-item). +* Submit a few creatives of size 1x1 and make them override the line items' sizes when you [attach creatives to the line item](/adops/step-by-step.html#step-3-attach-the-creative-to-the-line-item). * Your ad unit can accept both 300x250 and 300x600. A bidder bid $6.00 for the 300x600 size and has the highest price. Prebid.js passed the bid in, as well as a generated bid ID. * The $6.00 line item got picked by the line item. * Your ad server randomly choose a 1x1 creative. However, because all creatives have the same content, it does not make a difference. diff --git a/prebid/prebidjsReleases.md b/prebid/prebidjsReleases.md index 1a2720af47..23b022efc7 100644 --- a/prebid/prebidjsReleases.md +++ b/prebid/prebidjsReleases.md @@ -62,7 +62,7 @@ The table below is a summary of feature changes and important bug fixes in core | 3.3 | [Prebid Ad Slot](/features/pbAdSlot.html) support | | 3.2 | [Bidder-specific Supply Chain](/dev-docs/modules/schain.html#bidder-specific-supply-chains) support, added [static API option](/dev-docs/modules/consentManagementUsp.html) to the CCPA/USP module | | 3.1 | pbsBidAdapter: fix for handling response currency | -| 3.0 | [Prebid.js 3.0](/blog/pbjs-3) | +| 3.0 | [Prebid.js 3.0](https://prebid.org/blog/pbjs-3) | | 2.44 | Stopped duplicate alias user syncs | | 2.43 | [US Privacy/CCPA Consent Module](/dev-docs/modules/consentManagementUsp.html) | | 2.39 | Made originalCpm and originalCurrency fields in bid object always available |