Header tags and bidding have worked wonders for publisher revenue when it comes to display, so no surprise that pubs were eager to put the so-called “hack” to work on the video side.
But news flash: video is a whole different world from display. While header integrations would be incredibly useful in accurately valuing video inventory for both direct and programmatic purposes, working with players and video ad servers has proven challenging.
Still, Index Exchange has managed to find a way in, which VP of Strategy Jourdain-Alexander Casale was willing to detail for us. In addition to giving us the low-down on the tech side, he opened up about challenges with residual player and ad technology, what has slowed TV dollars from moving to programmatic pipes, and the ultimate server-side solution.
GAVIN DUNAWAY: Can you explain to us in layperson terms how the magic works?
JOURDAIN-ALEXANDER CASALE: We realized players were exactly the main challenge. In header display, you just wire into the ad server. A player intermediates the request with the ad server, so it was a hop in between that we weren’t used to.
Fortunately, the players have evolved to be friendly, with a JavaScript interface. With older players, the ad server request was hard-coded into Flash, and we didn’t have a way in. The shift in technologies has opened up a lot of this for us in the last year and a half.
The modern player just accepts a long URL with our bid—which includes key value pairs, pricing information, industry information, and some way to look up the ad—and sends it to the ad server. When you’re simply dealing with display units on a web page, you don’t have to deal with this hop.
The other challenge was, even if you’ve worked with the player before, you find the pub is also using a whole video stack, with a video content management system in addition to an ad server. We’ve had to build relationships with each one of those providers.
The largely pre-programmatic technology stack that’s powering video is working today, but it’s not the future. We see a lot of insane passback situations—20 to 40. Video-incumbent platforms are deeply entrenched and have become somewhat more antiquated compared with their display counterparts.
Thus, we see a much larger opportunity here for our growth into the future as an exchange. From a header standpoint, we had to break through the fact that we weren’t wiring into a browser anymore, we were wiring into a player.
In display you have pure JavaScript, so you can be incredibly agile. But video is based on rigid, ancient XML-based stuff. We had to make sure that the ad server could look up the XML and call us, so we provided inputs to allow for the reconstruction of a VAST request, which can come in and feed the XML. We’re sensitive to that and we know ways that we can work around it.
So now we ask: Is this a supported ad-serving platform? Can we pass a key value into it? Is there some CMS in the middle that’s intermediating things in a non-standard way?
If this is known, we have a solution. If this is unknown, it’s an engineering task. The team that does our video integrations now is about 10 times bigger than the team we had for header a year ago. This is very resource-intensive.
GD: You mentioned there’s a hop from the page to the player – they’re really separate entities. So how do you facilitate communication?
JAC: Whether it’s one pre-roll or a long-form video with 15 slots, we have all the bid information in about 200ms. In the header, we’re held to an insanely strict latency standard, so before anything even happens, we understand the composition of this inventory and how many slots we have to monetize. Because of things like competitive separation, we’ll classify every single ad by brand and industry before the player loads.
GD: So the publisher has to share all that information with you in the header?
JAC: Ideally. Optimally we can do what we call pre-fetch. Pre-fetch started in the display side, because header bidding can be a disaster for latency if not set up correctly. When we installed a header tag, we quantitatively looked at page performance before and after.
We found if you can queue things up earlier, you’re affording yourself more flexibility with parallel think time. In some cases for video, we will ingest dynamic mapping into our system, find the commercial breaks, take all that to auction and then bring it back. We try to avoid having any kind of extra hops in the chain by utilizing a pre-fetch architecture but sometimes this method is required.
A lot of what I’m doing with video pubs is aligning road map—integration, product and pub-side resources. If everything’s perfect, we can integrate in a week. Since we are constantly running into new ad stack configurations, including ad servers and proprietary solutions, lead times can be sigifnicantly longer to deploy.
The signals we send from the header are possible since the same “custom criteria targeting” or “key-value targeting” previously existed for a lot of ad ops reasons, ad servers support the ingestion, because somebody’s using it for targeting a site channel, keyword or first-party audience segment.
Ad servers like DFP and FreeWheel are super-advanced, in terms of their ability to manage those ad rule sets. We typicaly have an ad server seat that we use for all of our QA, engineering and product. We can do automate everything with APIs, but it’s still a learning process that never stops.
GD: What kind of challenges have you run into so far with this channel?
JAC: Sell-through is largely dominated by direct. It’s a challenge to explain the advantage as direct dollars move to programmatic.
The trust isn’t fully there yet to get those dollars flowing in video, even if you have a great story and a great reputation. This has improved to a great degree with transparency in the market place but there is still a lot of work to do. Additionally when we think about bringing all these TV budgets in, and shifting all these direct dollars to programmatic the whole SSP exchange model we have doesn’t work. No holding company is going to pay 10% to an intermediary – the fax machine didn’t charge a rev share!
GD: We’ve been chatting a lot about how header tags have really opened up programmatic and turned it more into what was always supposed to be: a true way to evaluate all the inventory on the web. But where is the tech headed next?
JAC: What makes header sticky is the fact that it’s a great way to solve for large participants not agreeing on how to transact. The secondary benefit is that it’s the easiest way for us to read a market and express what we see in the purest form. As soon as you go through a system of mediation, you’re beholden to whatever that platform is doing which likely isn’t fully transparent to all market participants.
In the case where we already have the header relationship with the pub, we’re already coded on page. When you have a wrapper, we can bring in any new things the publisher wants. So with relative ease, we got to the point where we’ve overcome those hurdles.
Where this is all going ultimately is server-side ad stitching: the end user’s stream and a server-to-server connection handling advertising functions – nothing differentiating content from advertising. Eventually, we wouldn’t need to wire in from the header. The connected TV, app or browser is bringing those ad streams in directly in a universal interface where the content delivery network is powering ad delivery and proxying all the analytics.