Is header bidding an addiction? It seems once you get your first demand source implemented you just get hungry for more and more (as long as latency isn’t an issue). Fortunately, there’s a simple tech fixit to enable your desire for greater numbers of header bidding partners: the wrapper. One bundle to rule (or at least manage) them all!
But beware – not all wrappers are alike. To suss out the differences between the most popular options, we reached out to Index Exchange’s VP of Partner Success Steve Sullivan and VP of Strategy Jourdain-Alexander Casale. In the interview below, we discuss the nuances of mediation platforms and open-source frameworks, what kind of control a wrapper should offer and what’s next for the fast-evolving world of header bidding.
Gavin Dunaway: How do you differentiate your wrapper solution from others?
Jourdain-Alexander Casale: First of all it’s a consultancy more than a technology, and what that means is we have a large dedicated resource pool that just focuses on integration. When a media holding company shows up with 90 properties, we work on it for months. It’s a way of life for us: integrating with the ad server, mass-loading line items, getting A/B analysis. The Javascript component is the smallest piece of what we do.
Media companies don’t always have the depth and the availability of specialized resources for these kinds of integrations, because it’s a one-time thing or maybe it happens a few times over the course of years of doing business. For a company like Index Exchange, it’s our every waking thought—it never goes away, it only accelerates and we keep stacking up more and more integrations. So for us, having that core competency, allowing publishers to share in that common resource pool is I think a unique part of our offering.
GD: There are also wrappers that are mediation platforms—could I get you to explain what that means?
Steve Sullivan: I would describe a mediation layer as a wrapper that essentially gathers up the resulting auction data and makes the determination of who the winning bidder was. So imagine you have three bidders in the header of a publisher and all three are deployed via the same wrapper, and that wrapper is also a mediation layer. Those bidders run their auctions and the results come back, and instead of those results all going back to the ad server, the mediation layer says, “Oh, of all three of these, including my own, this one is the highest bid, so this is the one I’m going to send to the ad server.”
JC: The technologies that provide mediation layers in the market are very specifically focused on the needs of an indirect-sales-heavy publisher, where price is largely what governs the outcome of the header auction. That’s actually the minority of transactional volume that we see with our publishers—of course, we work with pureplay indirect, but our real focus is large media companies that have large direct lines of business that are transacting programmatically.
GD: So the benefit is less work for the ad server to do?
SS: Maybe. Essentially less information is being sent via the same client-side redirect for the ad server to do its decisioning. The mediation layer could also exert more control over timing, for instance—anyone who doesn’t complete the auction by X amount of milliseconds is going to be out of the opportunity. That can also happen with a wrapper, but with a lot less granularity of control. If you’re a mediation layer, you can pick and choose who’s going to make it to the ad server with their bid, whereas with a wrapper you might be able to control the timing simply by cutting things off and saying, “Okay, it’s over. Time to send the bids in.” It’s a little bit more of a blunt force approach.
GD: I thought one of the main advantages of header bidding was everybody got to put in their bids to the ad server. So it’s a little strange for mediation platform to decide the “best bid.”
JC: There’s a lot of sensitivity to mediation. We’re trying to play nice with everybody in the ecosystem and not upset the apple cart, to allow this innovation to take full hold. So our wrapping philosophy is to drop the tags as the manufacturer of the tag defined in their specification document and not alter it in any way. Obviously we’re setting up so the publisher can control latency, but we’re not trying to diverge from practices that have been done with much success for the last five years by retargeters, for instance, who have robust products that are super-low-latency, friendly and over-engineered.
Some bidders have sensitivities to revealing the value of their audience. They advocate all exchanges do encrypted pricing, which goes against the whole concept of mediation. The only system that has any concept of price is the ad server, which is the system that should govern the outcome of the auction and priority.
GD: Why would multiple integrations be a better option than a wrapper?
SS: The only reason I think is if you were a publisher who is very technologically savvy, you then might want to have 100% control over each of those integrations separately. And not only that, you might not feel comfortable trusting anyone else to be a wrapper. What’s interesting is this scenario that I just described is perfect for an open-source wrapper. In that case, none of the actual partners own that technology, so it becomes the publisher’s technology.
The further advantage of an open-source wrapper is that you can do whatever you want with it. You can change it, you can improve on it, you can evolve it with the evolution of your site. If you are a very technologically sophisticated publisher, then you can do whatever you want with that open-source wrapper.
The disadvantage of course is that there’s nobody there to support it. You are out there on your own. There’s no one for you to lean on. There’s no one for you to look to with expectations of technological improvements and advances beyond what you have yourself. And that’s actually the thing we tell people when they say, “Well, we’re not sure what to do, we’re thinking about using an open-source wrapper.” We say, “That’s great—if you want to do that we can provide you with our code that you would integrate into that, but you have to remember, you will not have anyone to call.
GD: What are some of the biggest challenges with wrapper integration?
JC: Although the libraries themselves in the ad servers are the same, how they’re implemented varies quite drastically. The complexity is a function of how does this publisher versus the last one decide to implement their ad stack? Do they use an ad utility library that they’ve built that wraps all the calls? Have they organized the code in such a way that they centralize things like declaring slots on the page or are they scattered across the DOM? Do they use a consolidated CMS enterprise-wide across 90 properties, or are each one of the properties each one the result of consolidation or acquisition over a number of years and lack a common CMS backbone?
If we’re coming into an environment and they’re not familiar with the technology, there’s typically a several month dialogue just trying to get those stakeholders to see what it is we’re trying to do and what the impact is for the page. They have to preserve the integrity of the user experience.
As a consultancy, we provide an integration proposal, which details everything they have to change in their stack to accommodate the needs of our solution. We try to take on much of the work as opposed to sending a 40-page integration document that’s standard to all pubs. Once they get through some of that uncertainty, fear of the unknown kind of thing, which is perfectly normal, the engineering side becomes the best advocate for our solution.
GD: Do you think there’s a need for standards around header bidding?
SS: We think there should be standards. At some point soon, those publishers who work with or have worked with a variety of different partners will start to realize that some do it better than others. (I’m raising my hand right now; you can’t see.) And they’re going to start to want to say, I want to work with people who do it that way. And that’s when some sort of a guideline will be developed against which companies might get certified.
GD: Are wrappers the end game, or is this part of something bigger that we’re building to, and if it’s the latter, what exactly is that thing?
SS: As someone who’s been close to digital advertising technology for a long time, I came to understand right away that technology is advancing at an exponential rate, and advertising is tied directly to that technology. I think plateaus are achieved. Put it this way: Let’s think back to 10 years ago, just before people commonly understood what an exchange was. People thought, “Well, it’s all so fringe; it’s just another way for publishers to unload their remnant media, so it’s not going to have any real impact on the industry.” And somehow that changed, and programmatic became a platform that everyone understood and everyone recognized had a long history ahead of it.
Now header bidding I believe is a similar kind of plateau in the sense that it’s a technological advancement where the benefits are so obvious that there has been almost no barrier to entry. It’s unlocked so many opportunities, both for us, for companies like ours, and for publishers as well. In particular, the opportunity to begin allowing direct advertising to compete with programmatic on a price level.
I think what it represents is a plateau or an enhancement to the programmatic platform that will allow programmatic to spend the next five years, let’s say, really becoming something different than what it has been in the previous five.