server side header bidding - index exchange€¦ · server side (s2s) integrations have existed in...

5 QUESTIONS TO ASK WHEN CONSIDERINGSERVER SIDEHEADER BIDDING

25 Questions To Ask When Considering Server Side Header Bidding | MARCH 2017

IntroductionServer 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.


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.

Advantages:

Inherently transparent

Direct user sync

Advantages:

Reliability of connections

Low Latency

Capacity for many partners

Client Side

Server Side

Disadvantages:

Potential to be unreliable

Higher latency

Limited capacity for partners

Disadvantages:

Can be opaque

Indirect user sync

Figure 1


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-Based LatencyIn 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


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

Figure 2a Figure 2b


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.

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.


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.

2

Incremental DemandThe 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.


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

1 2

Exchange CResult: Low Latency Connection

Figure 3

Identifying UsersUser 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

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

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

Figure 4

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


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.

3

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.


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 TransparencyMake 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.

Figure 5


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.

Auction Dynamic TransparencyThe 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.

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.


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


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

What should I look for in a s2s provider?

5


ConclusionWhile 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.

server side header bidding - index exchange€¦ · server side (s2s) integrations have existed in...

Documents