when considering server side header bidding · pdf file5 questions, march 2017 introduction...

5 Questions To Ask When Considering Server Side Header Bidding

ServerSideHeaderBidding?

5 Questions, March 2017

Introduction

Server side (s2s) integrations have existed in

programmatic advertising for nearly a decade, having

been the preferred method of integration between DSPs

and exchanges during that span. Yet this integration type

is only now being considered for header bidding, and

quite tentatively at that. The obstacle that has

challenged the industry in its shift from client side to

server side header bidding has not been technology, but

trust. With s2s being a more opaque integration,

exchanges were previously hesitant to cooperate within

an environment that lacked the transparency inherent in

client side header integrations. A recent shift towards

s2s by larger tech giants has to an extent normalized this

integration, and incidentally paved the way for

independent exchanges to partner together to embrace

s2s, and create a new choice for publishers hoping to

enhance user experience and monetization without

sacrificing transparency and fairness.

1


Advantages:

Inherently transparent

Direct user sync

Advantages:

Reliability of connections

Low Latency

Capacity for many partners

Client Side

Server Side

Disadvantages:

Higher latency

Limited capacity for partners

Disadvantages:

Can be opaque

Indirect user sync

2

Figure 1

Before we dig into the specifics of s2s, here’s a quick refresher of header bidding and header bidding wrappers.

Header bidding is a process facilitated by a snippet of JavaScript in the header of a webpage that allows publishers to auction ad impressions in a flat parallel auction that can include multiple participants. This was a hugely impactful advancement to inefficient sequential auctions conducted in the waterfall era of programmatic.

A wrapper (also known as a container or container tag), was the natural progression of working with multiple header bidding partners. Rather than each partner’s client side header bidding integration sitting on page, individually managed by a publisher, one technology acts as a wrapper and can call (or “wrap”) multiple header bidders. This single point of integration allowed publishers to easily monitor and manage multiple header bidding partners for the first time.

A wrapper can either perform its functions of calling bidders on page so that every call runs through the browser, known as client side, or more recently, it can also operate server side conducting those calls outside of the client browser (also known as server to server, or s2s). There are discrete advantages to both solutions and some sizeable trade-offs involved. So, how does a media company decide how to operate their wrapper? We’ve put together a few questions to help you through the process.


How Will This Impact User Experience?

There are two core factors that impact latency in a wrapper

integration: connection based latency - how long it takes to

initiate a request, and locational latency - comprising the

round trip of the distance that must be traversed between

the user, wrapper, exchanges, and DSPs. Let’s take a closer

look at each.

Connection-BasedLatency

In a traditional client side integration, the wrapper makes a call to each exchange via the user’s browser. These ad calls are processed alongside a massive amount of other requests like images, fonts, videos, audio, and everything else that makes a website worth visiting. There are a finite number of items the browser can process at once, and the browser decides the priority. This means that calls related to header bidding can become heavily delayed.

1

3


User/Browser User/BrowserData center co-location

IntegratedExchanges

DSPs

0ms

0ms

Exchange/Wrapper

40ms

15ms

5ms

Integrated Exchanges DSPs

Co-location allows for lightning fast communication via direct connection, enabling more time for the auction

Figure 2a Figure 2b

s2s integrations are not a cure all – new latency can be introduced without advanced infrastructure

Exchange/Wrapper


Comparatively, in a server side integration, rather than call every single exchange individually (even multiple times) via the browser, the wrapper makes a single client side call to its server, which then calls the exchanges server side. This creates an environment in which multiple exchanges can be called reliably and simultaneously, without being at the mercy of the browser. Unlike the browser on a user’s mobile phone or computer, the servers used for this are specialized machines built to handle massive quantities of concurrent requests without negatively impacting latency or user experience.

Locational Latency

With s2s, there should be an increased focus on Location Based Latency wherein we consider each leg of the journey as well as the speed (or latency) of the round trip for the wrapper to make its initial call to all of the integrated exchanges and return the clear price to the ad server. When we move the core functions of the wrapper from the user’s browser to the server, we are creating a distance between the user and the wrapper that must be traversed. This distance, along with the distance between the wrapper server and the servers of the 3rd party exchanges, as well as those 3rd party exchanges to their DSPs/buyers are important to consider, since a weak link in this chain can bring new latency into the equation. Speed and infrastructure go hand in hand, so co-location and data center distribution must be seen as a key consideration of vendor selection.

Index Exchange adapted its technology early-on to be browser

friendly and lightweight to browser connections, requiring only a

single call (single request architecture), regardless of the number of

ad slots on any given page. This significantly reduces the impact of

connection-based latency.

5


How will this impact my overall RTB revenue?

This is both the most important question for publishers and

the hardest to predict. There are two key factors to consider

when examining the projected change in revenue.

Incremental Demand

The key draw for many publishers considering s2s is the ability to add additional demand partners without negatively impacting latency. This particular selling point is often overstated and heavily nuanced. While you can run many exchanges s2s, it’s important to understand how much additional value you will actually be adding with each partner. A more impactful goal for s2s is the amount of premium incremental demand that can be added without negatively impacting latency. For each additional exchange to add incremental value, there has to be a substantial amount of unique demand, priced to compete with direct sales, and technologically able to respond to the demands of an ever decreasing timeout. Today there are currently a handful of exchanges that match this description, and running partners outside of this criteria may bring unnecessary exposure to poor quality ads, over exposure of requests to DSPs, and ultimately the potential for gaming.

2

6


Server side connections provide speed and reliability, but lack direct access to users

Wrapper Client

1 2 3

1 2Server Side Wrapper

Users 1, 2

Exchange AResult: Low Latency Connection

Exchange BResult: Low Latency Connection 2 31 3

Server Side Call

Client Side Call

KEY

Figure 2

7

1 2

Exchange CResult: Low Latency Connection


Identifying Users

User sync (aka cookie sync, cookie matching, or user matching) is the ability to recognize a user, allowing platforms (i.e. DSPs) to ascribe value to that impression. This is specific exclusively to desktop and mobile web environments, not app where user syncing is replaced with device identifiers.

In a client side integration, cookie matching is a straightforward process with a direct line of communication between each exchange and the user’s browser.

In an s2s integration, only the wrapper has a touchpoint with the user’s browser. As such, a 3rd party exchange participating in the wrapper relies on the wrapper having conducted a match of its user data, since it must first perform a match with the wrapper before it can perform a DSP match. Without user data, impressions have diminished value to buyers, therefore any decrease in user sync rate can have a significant negative impact on revenue.

8


Figure 3

Client side connections have better user matching, but are slower and less reliable

1 2 3

Wrapper Client

1 2 3

1 2 3

Exchange A Result: Full User Match

Exchange B Result: Full User Match

Exchange C Results: Unknown

Server Side Call

Client Side Call

KEY

9

The number of exchange partners integrated client side must be limited due to latency impact


How will this impact transparency and fairness?

As publishers know all too well, transparency is key for

creating a fair auction that ensures impressions go to the

highest bidder and surprise fees aren’t shifting dollars from

the publishers’ pockets to middle men buried in the supply

chain. Bringing the wrapper server side innately introduces

new risks to transparency, which must be closely monitored.

When the wrapper resides in the browser, every part of the

process is available for inspection. This is not the case for the

server side integration.

The Index wrapper re-introduced transparency by providing robust

reporting and log level data to both publisher and 3rd party

exchanges. Fairness is further cemented by creating an A/B testing

framework between client side connections (fully transparent) and

server side (less transparent) connections, putting control and choice

squarely into the hands of the publisher.

3

10


Figure 5

The IX wrapper gives publishers a choice of how to set up their wrapper to ensure the best balance of user experience and revenue, and the tools to make a data driven decisions

Server Side Call

Client Side Call

Wrapper Client

1 2 3

Exchange A Result: Full User Match

Exchange B Result: Low Latency Connection

Exchange C Result: Low Latency Connection

Server SideWrapper

1 2 3

1 3 2 3

1 2

KEY

Pricing Transparency

Make sure you are aware of any charges for 3rd party exchanges for participation in their s2s offering. This can correspond to a reduction in participation and a decrease in working media.

11


Auction Dynamic Transparency

The move server side also introduces mediation for most wrapper offerings. A mediated wrapper runs an additional auction amongst wrapper participants and passes a single winning price to the ad server (or a second in the event of deal based bid handling), rather than passing a price for every single exchange. This is desirable to publishers for the increase in scalability gained by streamlining line items in their ad server. With auction dynamics being managed across all 3rd

party exchanges by the wrapper provider, it’s important to learn about those dynamics and ensure this aligns with the goals of both publisher and buyer. Be on the lookout for a lack of disclosure and built-in advantages for the operator of the wrapper that might deter buyers. If the wrapper provider also has a buy-side business, it’s a strong hint to look closer and get everything in writing.

Index Exchange has not charged fees for its client side wrapper,

and will not be charging fees for its server side wrapper. We believe

exchanges should only be compensated when they source and

provide the highest net bid for publishers, thereby increasing

publisher revenue.

The Index wrapper offers full transparency to both publishers and

partners alike on pricing and auction dynamics. There are no

advantages built into the Index bidder and we aim only for a flat, fair

auction driving the best price for publishers, regardless of the source.

The auction dynamics of the server side integration are the same as

the client side integration, continuing the level playing field for all

participants for which the Index is known.

12


Do I have to move all of my partners to s2s at once?

No. The quick rise in popularity of s2s header bidding has

thrown the industry into flux, and it may take time for every

exchange to catch up in the technology and trust required

for an effective s2s bidder integration. In the meantime,

publishers should have the option to begin testing with

exchanges as they do become ready. An either/or

approach will be unnecessarily limiting to publishers who

want to begin testing and learning now. Most importantly,

publishers should ensure that they can make data-driven

decisions about where each partner performs best in terms

of user experience and revenue before shifting everything

server side.

4

13


What should I look for in a s2s provider?

Choice: Support for server side and client side connections, by partner

Transparency: Clear auction dynamics and fee structures for publishers, partners, and buyers

Tested: A/B testing capabilities to show the impact to speed and revenue by partner based on integration type

Service: White glove service to take on the heavy lifting of implementation and upgrades

Technology: Reliable technology, robust infrastructure, and broad global data center distribution with strategic co-location

Fair: Free of fees and conflicting interests

5

14


Conclusion

While it can be easy to get caught up in the potential user

experience upsides of s2s, there are clearly many variables to

take into consideration as the market evolves. To respond to

this, Index has kept our focus on putting the choice into the

hands of publishers by offering both client side or server side

integrations, by partner, within the same wrapper.

Publishers will have direct control over critical aspects of their

server side wrapper auction, including the partners involved,

timeout thresholds, and deal handling to ensure they have the

tools to make the right decisions for their business.

About Index Exchange

Index Exchange is an advertising marketplace where premium digital media companies can sell their ad impressions transparently, in real time, to programmatic buyers. Built on the pillars of neutrality, openness, and the most reliable technology, we aspire to be the ad exchange that media companies can trust.

Because we are independent, with no other business interests, the top technology companies in

the industry choose to partner with us and together, we build better solutions with media

companies in mind. And we’re independent by choice, because that lets us make decisions for the

long-term benefit of our clients, not the immediate demands of investors, or for short term profits.

We believe greater competition leads to better yield for media companies and better inventory

access for marketers.

15

when considering server side header bidding · pdf file5 questions, march 2017 introduction...

Documents