When Considering Server Side Header Bidding · PDF file5 Questions, March 2017 Introduction...
Transcript of 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
5 Questions, March 2017
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.
5 Questions, March 2017
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
5 Questions, March 20174
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
5 Questions, March 2017
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
5 Questions, March 2017
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
5 Questions, March 2017
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
5 Questions, March 2017
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
5 Questions, March 2017
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
5 Questions, March 2017
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
5 Questions, March 2017
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
5 Questions, March 2017
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
5 Questions, March 2017
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
5 Questions, March 2017
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
5 Questions, March 2017
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