WHY OPEN SOURCE WILL WIN HEADER BIDDINGPrebid.js is The Right Choice for Publishers and the Industry

WHY OPEN SOURCE WILL WIN HEADER BIDDING - Prebid.js is The Right Choice for Publishers and the Industry 2

TABLE OF CONTENTSExecutive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Header Bidding Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Why We Care - A Quick Note on Transparency . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Intelligent Inventory Allocation: A Wrapper Choice . . . . . . . . . . . . . . . . . . . . . . . . 7

The Wrapper Is Integral to Revenue Optimization. . . . . . . . . . . . . . . . . . . . . . . 8

Proprietary Wrappers: A Monetization Dilemma. . . . . . . . . . . . . . . . . . . . . . . . . . 9

Considerations for Wrapper Monetization . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Inherent Bias and The Resulting Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Locking in the Publisher, Long Term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Opacity, Lack of Accountability, and the Industry Ecosystem . . . . . . . . . . . . . 12

Open Source: Wisdom, Checks, and Balances of the Crowd . . . . . . . . . . . . . . . . 13

The Open Source Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

How The Prebid.js Wrapper Succeeds Without Compromise. . . . . . . . . . . . . . 15

Looking Forward: Server-Side and Further Wrapper Considerations . . . . . . . . . . 16

Server Side Will Continue to Rely on Client-Side Integrations . . . . . . . . . . . . . 17

Rubicon Project’s Commitment to Support Prebid . . . . . . . . . . . . . . . . . . . . . . . . 18

Why Open Source Will Win Header Bidding - Prebid.js is The Right Choice for Publishers and the Industry 3

EXECUTIVE SUMMARYHeader bidding was developed to replace the legacy “waterfall” monetization environment with a solution intended to allocate inventory more e�ciently and at higher CPMs. It accomplishes this by enabling the maximum number of buyers to compete for every impression alongside private marketplace and prioritized deals. Buyer access to inventory is fundamental to the technology’s success. As header bidding wrappers entered the marketplace, enabling publishers to engage multiple header bidding exchanges simultaneously, many have shown to undermine the essential header bidding principles of accessibility, competition, and e�cient inventory allocation, ultimately preventing publishers from obtaining valuable revenue.

The Limitations of Proprietary WrappersAs the industry continues to evolve, proprietary wrappers will continue to undermine the growth and monetization opportunities of the ad tech ecosystem as a whole. These concerns are primarily due to four potential limitations which spawn directly from the private nature of these wrappers and their co-management of exchange demand.

The Benefits of Open Source WrappersThese limitations prove especially significant as publishers begin to integrate with server-side header bidding solutions, which will require transparent, objective, client-side mechanisms --on the page-- in order to succeed. The open source header bidding wrapper Prebid.js solves for these problems thanks to:

OpenRTB, the industry-driven standard that redefined the digital advertising marketplace over the past decade, has demonstrated the mutually beneficial powers of transparency and interoperability for both publisher bottom line and the industry at large. Prebid.js is the first step towards bringing this philosophy directly into the codebase that powers our technology, starting with the world of header bidding. The open source wrapper is the path forward for header bidding -- and we are investing to further develop Prebid.js into a scalable and manageable solution for all publishers.

Functional OpacityLacks crowd-sourced checks and balances

Slow to DevelopLack of frequent updates and

slow to provide solutions to new problems and setup ine�ciencies

Inherent BiasUnintelligent inventory allocation and decreased demand access to inventory, meaning less CPM lift

Publisher Lock-InPublishers commit to a proprietary

vision of header bidding, inhibits migrations to new solutions and

developments

Functional Transparencycommunity oversight ensures equitable bidding processes

through community oversight

Constantly Updatedcommunity contributes

updates and code improvements as needed

Inherent NeutralityImpartiality results in e�ective

and e�cient bidding processes, increased CPM lift opportunities

Publisher Flexibilitybuilt to evolve rapidly

alongside advances in monetization opportunities

Why Open Source Will Win Header Bidding - Prebid.js is The Right Choice for Publishers and the Industry 4

The term “header bidding” has recently grown in scope to include a “server-side” subset, which is unintuitive considering the header’s location on the client-side browser. As such, this paper references “header bidding” and “header bidder” as distinct terms.

Header Bidding: The conceptual practice of requesting and receiving bids from multiple demand sources simultaneously via header bidders, built to supercede the legacy “waterfall” system. Originally built to call all exchanges directly from a web page’s “header,” the term header bidding has recently grown to include new o�-page mechanisms.

Header Bidder: A digital advertising exchange, connected directly to a publisher’s inventory, that forwards bid requests to demand partners, receives bid responses, and returns them to the page. When multiple header bidders are used, they can be simultaneously managed by the use of a wrapper. There are two general types of header bidders:

• Client-Side Header Bidder: The original header bidder. An advertising exchange that is called directly from the web page.

• Server-Side Header Bidder: An o�-page ad exchange that receives header bidding requests from a SSHB host or publisher ad server.

Wrapper: An on-page JavaScript container that enables the distribution of bid requests to multiple header bidders simultaneously, receives their bid responses, and passes one or multiple responses to the ad server.

Native Exchange: A header bidder advertising exchange that is operated by the same entity that operates the wrapper.

Publisher: A seller of advertising inventory that includes desktop and mobile web content providers as well as mobile app developers.

Intelligent Allocation: The e�cient distribution of inventory across multiple transaction types (such as prioritized deals and the open market) that explicitly considers impression scarcity in addition to price when determining an auction winner. Previously impossible to achieve as the ad server’s discrete, waterfall line items could not be evaluated simultaneously, this model was brought to bear by header bidding. Intelligently allocating inventory typically increases publisher revenue over the long term when compared to competition based on price alone.

HEADER BIDDING TERMINOLOGY:

WHY WE CARE:A QUICK NOTE ON TRANSPARENCY

WHY OPEN SOURCE WILL WIN HEADER BIDDING - PREBID.JS IS THE RIGHT CHOICE FOR PUBLISHERS AND THE INDUSTRY 6

Rubicon Project has a deep-rooted history in understanding the needs of our publishers. We support the Prebid.js project because we believe operating an open marketplace that enables all participants to trade and transact with transparency is fundamental to the health of both our publishers and the greater advertising industry. As Rubicon Project moves to contribute new extensions into the Prebid.js codebase, we hope to demonstrate that the open source wrapper is capable of surpassing publisher expectations in both performance and ease of implementation. We are committing ourselves to building out additional features and service layers in Prebid.js that will further cement its position as the trustworthy and opportunistic header bidding foundation it has become.

INTELLIGENT INVENTORY ALLOCATION:A WRAPPER CHOICE

Publishers seeking maximum revenue should carefully analyze their wrapper selection. Not only do proprietary wrapper

solutions compromise a publisher’s ability to allocate inventory e�ectively, but they can also prevent

publishers from taking advantage of industry advancements over time.

Why Open Source Will Win Header Bidding - Prebid.js is The Right Choice for Publishers and the Industry 8

Few will contest the “impression” that header bidding has left on the advertising industry thus far. The rapid-growth technology has a�ected nearly all aspects of the programmatic landscape in just a few short years. Having heavily influenced the way industry players buy and sell digital advertising, header bidding no longer remains a mere snippet of client-side code. The technology is progressing frantically but with purpose, inching closer each day toward fulfilling its conceptual promises: To become an integrated solution with which publishers can intelligently allocate all of their inventory, DSPs can enjoy uninhibited access to that inventory, and through which buyers can choose audiences with precision. To fully realize this synergistic goal, however, there are important technological choices that must be made by both publishers and the industry as a whole.

Sellers want to earn top dollar for their inventory, and header bidding has provided a healthy taste of what a well-distributed inventory supply can yield to the optimization-minded publisher.1 Numerous integrated mechanisms exist along the header bid and response chain that enable publishers to maximize its potential. The most important mechanism -- considering header bidding’s current state of maturity -- is the JavaScript container responsible for distributing ad calls from the publisher’s page to numerous header bidding partners. This header bidder management tool is commonly called the “wrapper,” and its e�cient, unbiased functionality is vital if the advertising industry’s crusade for high-performance, competitive RTB is to succeed.

Considering how quickly the ad tech space evolves, wrappers are relatively old news. Nearly two years into their existence, however, the faults of many early-stage, proprietary wrappers have begun to reveal themselves to the industry. Some have been shown to bind their publishers into non-standard implementations, leaving them unable to take full advantage of the collective learnings of a constantly-changing industry landscape. Worse, some wrappers do not treat all demand sources equally, and publisher CPMs have su�ered as a result. After all, publishers do not implement multi-partner header bidding with the expectation of receiving a mere one or two bids on each impression. It is critical that publishers receive maximum demand for every impression with their header bidding implementations.

The flaws and challenges of these wrappers are often unavoidable due to the provider’s inherent conflict of interest. The good news, however, is that for every categorical weakness born from a wrapper’s proprietary, biased nature, the open source alternative brings a discernable strength.

The developers who brought the open source Prebid.js wrapper into the marketplace a mere 18 months ago did so precisely to resolve these issues.2 Since its inception, the Prebid.js community has grown significantly, and has developed a strong case for publishers to consider in their search for a wrapper. However before diving too deep into Prebid.js specifically, it is important to understand the potential consequences of a proprietary solution, both now and looking forward into the evolving world of header bidding.

1 eMarketer Chart: “Benefits Derived from Header Bidding Technology Adoption According to US Publishers, August 2016” 2 AppNexus Prebid Blog

Benefits Derived from Header Bidding TechnologyAdoption According to US Publishers, Aug 2016% of respondents

48%

31%

23%

23%

11%

Higher CPMs

Increased yield

Fewer passbacks

Less latency

Other

The Wrapper Is Integral to Revenue Optimization

PROPRIETARY WRAPPERS:A MONETIZATION DILEMMA

“A fully functional container solution can only be achieved when publishers ensure transparency and flexibility for themselves and the demand

partners they work with. Publishers cannot a�ord to relinquish yield optimization opportunities to a third party, especially

those with demand behind them, because they will never fully optimize to the highest potential.”

- Stephanie LayserDirector of Advertising Technology

News Corp

WHY OPEN SOURCE WILL WIN HEADER BIDDING - PREBID.JS IS THE RIGHT CHOICE FOR PUBLISHERS AND THE INDUSTRY 10

The core of the wrapper’s significance lies in its ability to e�ectively distribute requests to a publisher’s header bidding exchange partners, retrieve their bid responses, and return either all or a single winner to the publisher’s ad server. The wrapper, when performing these functions, is not a viable revenue source in and of itself. This is precisely because its job is to enable those exchange partners to perform a variety of bid-collecting actions. These bidding actions, or transactions with DSPs, are themselves the predominant billable point of monetization.3

Proprietary wrapper providers may, in fact, have developed these wrappers with the right intentions; built to perform their rightful duties of distribution, collection, and sometimes decisioning. Their capacity to monetize however -- as a technology that inherently does not present a self-sustaining revenue model -- has in turn become reliant on two primary revenue sources:

• The additional support and service-layer required by publishers who lack the development resources to integrate with a wrapper. This layer often includes an informed sales team to consult on strategy, on-site solutions engineers to assist with implementation, and white-glove account-based services to optimize and maintain the solution.

• The revenue accrued by a provider whose wrapper is inherently biased in favor of its own native exchange.4

An exchange that bids into its own wrapper creates an inherent conflict of interest. This conflict has frequently shown, through publicly available header bidding data, to produce sub-optimal demand competition, ultimately leaving the publisher to bear the financial consequences. While there are several enticing, extra services that a proprietary wrapper can provide to its publishers, these add-ons do not always outweigh the downsides of a wrapper’s inherent bias. While publishers might not experience these challenges in the same ways, they can result in a number of compromises that a�ect both a publisher’s bottom line and the health of the industry ecosystem at large.

3 See Figure 14 See Figure 2 for an example

DSP

Exchange 1Page

ProprietaryWrapper

Exchange 2

NativeExchange

DSP

DSP

DSP

DSP

DSP

wrapper must remain neutral

here and not favor any exchange

point of monetization for exchange via fees

Considerations for Wrapper Monetization

Figure 1

WHY OPEN SOURCE WILL WIN HEADER BIDDING - PREBID.JS IS THE RIGHT CHOICE FOR PUBLISHERS AND THE INDUSTRY 11

For the header bidding-entrenched industry to flourish and realize its full potential, the wrapper must remain a neutral and equitable component. Unfortunately for publishers and the industry at large, proprietary wrappers are not neutral, and their inherent bias is most apparent when the provider’s own exchange exists as an integrated partner.

The industry brought header bidding to bear with the intention to replace the waterfall entirely. In many current header bidding implementations, however, the biased nature of the wrapper has shown to drag some of the waterfall’s consequences back into the ecosystem, resulting in an ine�ective allocation of inventory. There are numerous situations in which a wrapper cannot escape its own bias. Consider the following potential circumstances and resulting conflicts of interest in which:

• Multiple exchange adapters --the technology that allows the wrapper to communicate to header bidder partners-- including that of the native exchange, fail or require updating. Whose adapter will the provider fix first? Does that provider have the necessary tools to fix partner exchange adapters as quickly as their own?

• The wrapper utilizes standard asynchronous call and response technology; however, due to lack of browser “swim lanes,” one exchange must wait for the first exchange to respond before receiving a request. Which exchange will the wrapper provider call first? Are additional exchanges unable to bid due to irregular call algorithms?

• The wrapper provider’s native exchange library is pre-built into their wrapper while other exchanges’ libraries are not, speeding up its own request. Even if the provider does build in other exchanges’ libraries, will this always remain the case?

Regardless of the specific issue or concern, building and maintaining a wrapper takes time and energy, and the associated costs will consistently present an inescapable bias as a proprietary wrapper vendor expects to recoup them elsewhere.

In the second situation listed above, in which one exchange is preferred over another, we find a cautionary scenario. Not only is inter-exchange competition inhibited, but the possibility of a scarce impression being allocated to a potentially high-value, audience-targeted bid may be lost entirely. This unintelligent allocation is a loss that publishers should not tolerate and likely cannot a�ord in the modern programmatic environment. As a publisher’s header bidding setup becomes more complex, these dilemmas occur more frequently and with increased resolutions times. Most importantly, all of these conflicts of interest impact the publisher’s ability to monetize e�ectively by degrading the naturally intelligent allocation of their inventory; the value of header bidding at its core.

Figure 2Representations of exchange calls as made by wrappers. Notice the ine�ciency and waterfall-esque nature of the first graphic.

Example: Ideal ExchangeCalls from WrapperNativeExchange

Exchange 2

Exchange 3

Adserver

TIME

Example: Ine�cient Exchange Callsfrom Wrapper

150ms

150ms

150ms

200ms

VS

NativeExchange 250ms

Exchange 3 3661ms

Exchange 2 2526ms

Adserver 436ms

TIME

Inherent Bias and The Resulting Challenges

WHY OPEN SOURCE WILL WIN HEADER BIDDING - PREBID.JS IS THE RIGHT CHOICE FOR PUBLISHERS AND THE INDUSTRY 12

The use of a proprietary wrapper also means that, for better or worse, the publisher is indefinitely locked into the vision of header bidding as determined by a particular technology provider. This proprietary vision includes, but is not limited to: new features, partner adapter availability, decisioning logic, and capacity for timely updates -- or lack thereof -- all of which are built and maintained by the provider. In an industry that moves as quickly as advertising technology, this can create di�cult and revenue-compromising situations. Publishers cannot a�ord to continuously play catch-up to the rest of the industry.

As a publisher’s header bidding formula becomes increasingly complex, it becomes even more di�cult to sever ties to a proprietary wrapper. Lock-in becomes a growing concern as publishers consider integrating server-side solutions, in which client-side wrappers will be required to initiate bid requests to a server-side exchange. Many of our publishers have experienced one or more of the following as a result of being locked into a proprietary wrapper system:

• Limited exchange partner adapters (or slow build time for new partners)

• Beholden to updates and support or lack thereof

• Call request / response orders not optimized for inventory allocation

• Service level agreement issues

• Risk of wrapper company getting acquired or exiting the Market

• Di�erences in values when assessing the movement or direction of the industry

While more philosophical than scientific, this potential compromise speaks to the goals of the advertising ecosystem at large. Transparency and interoperability in the marketplace enables the percentage of advertising dollars moving from direct budgets into programmatic to increase more rapidly, which ultimately drives greater opportunities for all players. The wrapper is the central component of the header bidding chain that enables e�ective inventory distribution and industry growth. If this core component is not equitable and constantly optimized to the needs of the ad tech ecosystem, it restricts the expansion of the marketplace as a whole. The Prebid.js solution, by nature of being open source, solves for all of these issues.

Locking in the Publisher, Long TermOpacity, Lack of Accountability, and the IndustryEcosystem

OPEN SOURCE: WISDOM, CHECKS, AND BALANCES OF THE CROWD

“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. We

therefore open sourced the Prebid.js code on GitHub and documented everything we learned on prebid.org.

We wanted to help publishers unlock ideas and innovate faster, and to accelerate the

growth…”6

- Paul Yangfounding developer of

Prebid.js

Why Open Source Will Win Header Bidding - Prebid.js is The Right Choice for Publishers and the Industry 14

The numerous benefits of open source technology are widely written about and the drawbacks are minimal when discussed in the context of technology that connects a large, multi-vendor community with a common purpose. OpenRTB comes to mind as an example of the powerful growth that a fully-adopted, consortium-driven, open source solution can bring to our marketplace. Prebid.js represents the transcendence of that power from a guiding, standardized protocol into the the actual codebase that executes along its pipelines. In the world of header bidding, wrapper technology represents the ideal candidate for an open source solution as it requires impartiality, communal accountability and development, and a transparent foundation upon which many players can operate. The developers who first launched Prebid.js’s codebase were not building for the sake of their company’s interests alone, but with the interests of the industry as a whole.

“After speaking one-on-one with our clients, we came to a pretty straightforward conclusion: the header bidding integrations were opaque.” Paul Yang, who together with Matt Kendall initiated the development of Prebid.js, identified that the transparent and expansive requirements of header bidding wrappers and their publisher clients were best addressed by the advertising technology community at large. The constantly evolving nature of the industry, the high volume of work these evolutions require, and, most importantly, the implicit need for the wrapper to be inherently equitable and transparent, all made the case for an open source solution. There has remained, until now however, one potential drawback.

The overwhelming majority of publishers who use proprietary wrappers choose to do so for one reason: service. Not all publishers have the in-house development resources required to customize, implement, and manage a complex container wrapper. Proprietary wrapper providers pitched their product to publishers on the basis of mutual exclusivity between open source and white-glove service. However, as Prebid.js expands into a fully supported solution and grows its community ever larger, this perception of incompatibility will be proven incorrect.

6 Prebid.js Blog

The Open Source Solution

How The Prebid.js Wrapper Can Succeed WithoutCompromise

WHY OPEN SOURCE WILL WIN HEADER BIDDING - PREBID.JS IS THE RIGHT CHOICE FOR PUBLISHERS AND INDUSTRY AS A WHOLE 15

Prebid.js is a 100% free and open source JavaScript header bidding wrapper. It performs all of the duties a proprietary wrapper can, but due to its open source nature, it does them better. It is inherently neutral, adaptable, transparent, and mutually beneficial to all industry players. Its only perceivable imperfection as a product is that no one will ever “finish” it, for it can continuously evolve with the ever growing needs and complexities of the advertising marketplace. The open source nature of Prebid.js enables the community at large to constantly provide insight, improvements, and checks and balances. More than ever, fair play and open development is needed to enable industry growth and innovation from all sides. If fully adopted by the industry, Prebid.js publishers will always have the relevant updates, tools, and adapters required for header bidding success.

Many publishers have been quick to recognize the power of Prebid.js. As of Q1 2017, over 75% of Rubicon Project’s premium publishers utilizing a header bidding wrapper have chosen Prebid.js. This rapid and wide adoption is due to the numerous benefits presented by the Prebid.js wrapper:

• Inherent Neutrality - Impartiality results in e�ective and e�cient bidding processes, increased CPM lift opportunities

• Publisher Flexibility - built to evolve rapidly alongside advances in monetization opportunities

• Functional Transparency - community oversight ensures equitable bidding processes through community oversight

• Constantly Updated - community contributes updates and code improvements as needed

LOOKING FORWARD: SERVER-SIDE ANDFURTHER WRAPPER CONSIDERATIONS

Server-side solutions will require open and transparent development if publishers expect to continue the rapid

growth derived from client-side header bidding.

Server Side Will Continue to Rely on Client-SideIntegrations

WHY OPEN SOURCE WILL WIN HEADER BIDDING - PREBID.JS IS THE RIGHT CHOICE FOR PUBLISHERS AND THE INDUSTRY 17

basis for interconnectivity and parallel development, as transparency and openness will reign as the vital foundations on which these solutions can be built. This is mainly due to fact that some elements inherent to the world of servers pose significant challenges to transparency.

Servers are, by nature, closed systems that do not provide the same, publicly-accessible insight that client-side solutions do on the browser. Cookie synchronization poses significant challenges in a server-server world. User cookie-sync capabilities will likely rely heavily on transparent interconnectivity and may require the capability to integrate with third-party data-escrow systems. These conditions make user identification a daunting task, which is especially concerning as the industry works to develop audience-focused PMP capabilities. Reporting, billing, and security tools too will require significant retooling and bolstering if desirable server-side integrations are to flourish.

Server-side solutions have the potential to repeat the same mistakes of both proprietary wrappers and waterfalls all over again. Closed inventory allocation systems that run their own demand will continue to compromise publisher revenue due to inherent bias. They have the same likelihood to limit interoperability, lock a publisher into an all-or-nothing solution, and due to their inherent lack of user cookie sync capabilities, will inhibit the development of audience based PMP solutions.

Low CPMs

Too many di�erent metrics (”conditionals” like viewability)

Lack of transparency with partners

Hard to optimize on a regular basis

Lack of connection to diret sales

Low revenues

Reporting discrepanies

di�culty managing quality

Low fill rates

Too much manual labor

Advertisers gaming the system

Header bidding causes site latency

44.9%

28.6%

Issues with Programmatic AdvertisingAccording to US Publishers, Oct 20168

% of respondents

Note: respondents choose their top 3

22.4%

22.4%

20.4%

20.4%

16.3%

14.3%

8.2%

6.1%

6.1%

2.0%

As the industry looks to server-side header bidding solutions to resolve some of the remaining frustrations from client-side header bidding -- most revolving around page latency and consumer experience -- it is more important than ever to support the open source wrapper. The ad tech industry will likely endure a fragmented transition to server-side. Many industry experts argue that client-side header bidding will not disappear for quite some time, if at all, suggesting that publishers will continue to utilize its functionality in tandem with server-side exchange partners. These “hybridized” wrappers that can call both client-side exchanges and a preferred server-side exchange partner simultaneously present rewarding potential opportunities.

Prebid.js is not currently making hybrid calls, but that doesn’t mean it will not in the future, and that is one of the key benefits of the open source solution. Anyone can inspect, customize, and enhance it for their own needs, ultimately passing those benefits onto the industry as a whole. While the exact path of server-side is unclear, a powerful open source solution provides the ideal

8 Operative. “Programmatic is Here to Stay” Jan 4, 2017

WHY OPEN SOURCE WILL WIN HEADER BIDDING - PREBID.JS IS THE RIGHT CHOICE FOR PUBLISHERS AND THE INDUSTRY 18

Adoption and further development of the Prebid.js solution provides an ideal foundation for the community at large to develop and refine these mechanisms of monetization. Prebid.js was not created by Rubicon Project, and this is precisely the reason why we must support it. It is a solution that, as its adoption and development continues to grow, will prove to benefit the entire advertising markeplace. As such, Rubicon Project is committing to becoming a devoted contributor of the Prebid.js project, and will work tirelessly to make sure publishers have the Prebid.js extensions and tools they need to e�ectively implement, maintain, and utilize this powerful monetization tool.

RUBICON PROJECT’S COMMITMENT TO SUPPORT PREBID.JS