The Server-to-Server Way: Going Beyond Header Bidding With Sonobi’s Tony Katsur

Header Bidding Is Strong, But Server-to-Server Is Stronger

Of course the mainstreaming of header bidding has rocked the broader digital landscape, for reasons that ought to be familiar to most AdMonsters readers. But for all its merits, there’s been this widespread suspicion that maybe the header isn’t the end game here: What if the header is just a way station on the road to a better way of transacting?

That said, there’s a lot of uncertainty about what the next step might be. We’re starting to hear some suggestions, some theoretical and a few already in play. One of those suggestions is that server-to-server connections, not the header, are a more appropriate place for publishers to manage demand. Sonobi is one of the companies that’s gung ho about making a go of server-to-server solutions right now, and they’ve just released a whitepaper, “Evolution of a Market—Impressions to People,” detailing how the process can work for publishers.

Of course, Sonobi will drill down into server-to-server solutions and other hot issues during their panel at OPS in New York on June 7. But in the interim, to illuminate the white paper and get a sense of how existing server-to-server connections compare to managing demand in the header, AdMonsters sat down with Sonobi President Tony Katsur for some answers. AdMonsters Senior Editor Gavin Dunaway asked the questions.

GAVIN DUNAWAY: Is server-to-server header bidding? What do we call this now?

TONY KATSUR: Header bidding is a hack. Publishers need to manage and merchandize their audiences much like, and in many cases better than, they’ve managed and merchandized their supply. There are two ways that has been approached recently. Number one way has been through the header, and frankly we look that as a hack.

WITH THE SUPPORT OF SONOBI
Sonobi Jetstream is a technology that is built to change the business of digital advertising, and create a holistic marketplace to deliver digital advertising experiences built to serve exact audiences.

We’re seeing about 30% buyer dropoff from trying to cram buyers into the header. Imagine selling something at Sotheby’s or Christie’s, and 30% of the potential buyers couldn’t get through the door. So let’s leverage server-to-server connections, which are hooked up to fat pipes, have low latency, are not putting a lot of pressure on the client side of the browser. The publisher can see all the opportunities of how partners want to buy; you’ve got a lot more flexibility in terms of data you can leverage. Ultimately, the increased weight multiple header partners put on the browser is a crappy experience for the audience that no brand wants to be associated with.

We realize the commercial utility publishers see in a header bidding solution. But there is a much more efficient way.

Frankly, header technology shouldn’t be used for opportunistic demand, full stop. That’s what RTB was built for! That’s what the RTB protocol was designed for! Why are we not using it?

GD: I think a lot of people in the industry would agree with you. But there aren’t a whole lot of server-to-server products on the market. What kind of technical engineering challenges do you have to overcome to bring this to life?

TK: It’s more of a business issue than a tech issue: Does the ecosystem and do the major players in the ecosystem want to play ball? Building scalable, real-time S2S infrastructure is damn hard, and only a few companies can support this standard. So the shift to S2S is going to whittle down the dozen or so header wrapper solutions to a handful of companies that can offer this. You’re leveraging the RTB protocol and infrastructure designed and built by all of the major players—ourselves, Criteo, Amazon, Rubicon, Index, and so on. More companies need to re-orient how they’re leveraging current programmatic technology to support server-to-server. And we’re not talking about months and months of engineering work. It’s a sprint, one dev cycle, probably a month to get through it.

GD: It would seem there would be a lot of trust issues here. But if you guys all have played with each other for a long time…

TK: We have, but I do think there are trust issues across the ecosystem.

Sonobi will counsel publishers as to what we believe is more efficient, and where the future of this market’s going. But we’re an agnostic technology platform. We don’t bring demand, per se. Through technology, we facilitate the transaction of the demand, with brands, agencies, DSP partners, other exchanges. If pubs say, “Other partners don’t want you to be involved,” fine, we’ll bow out. But what I am going to do is continue to work with agencies and brands to bring publishers those upper-funnel budgets through guaranteed audiences. The conversations we’ve had with some of the bigger players that are insisting they need to be tag on page—I think they feel like if they’re not tag-on-page, they don’t have a relationship with the publisher. That’s a business issue, though, a trust issue amongst partners.

GD: How else can you improve latency versus a header bidding wrapper?

TK: With server-to-server connections, you’re talking about very fast pipes coming out of a data center— in many cases, a lot of partners have geolocated where their servers are for minimal latency between servers. These transactions are managed at the server which are purpose built for high volume, low latency. That beats any connection at home. All those calls effectively become an asynchronous transaction, versus JavaScript in the browser, which is typically synchronous and hyper-inefficient. The browser is a lightweight application not built for this much processing.

Right now we’re talking very much about desktop. What about mobile? It’s atrocious! Think about your data plan. It’s one thing for advertising to subsidize great content. Consumers now, because they’re eating into their data plan, are indirectly subsidizing ad tech! Let’s say you’re browsing on mobile web; it’s potentially making 12 calls out of the container. It’s not just a bad consumer experience with page load time, but you’re literally paying for that.

GD: Is there any reason I would want to have multiple server-to-server connections, as with header bidding?

TK: Sure. For opportunistic demand—performance buying is still a large part of that—you definitely want maximum bid density. But server-to-server gives you much greater scale of demand partners than doing something in the header. We’ve looked at the data on this: Pubs doing header are getting 30% drop-off in buyers that are trying to get the bid in. The browser is the fulcrum in this transaction. There’s already enough weight on the client, frankly. With a server-to-server connection, over low-latency fiber connections, you’re going from anywhere between 500 to 1000 milliseconds off the browser, to sub-hundred-millisecond server-to-server. So in theory, you have infinite scale of buyers, and you can then bring into opportunistic demand without increasing page latency.

GD: What about the data itself that’s sent through to your server? Are you receiving more stuff than a typical header bidder?

TK: It’s really about what the publisher wants to communicate to those demand partners, and what the demand partners need to make an informed buying decision. That can be much more easily configurable at a server level versus going in and modifying tags. It’s, “We’ve gotta crack open the code. When’s your next CMS build?,” versus, “We’ll just drop that token right in the server.”

GD: Seems like most header bidders send only a price back. Are you guys sending more than that?

TK: We can send a lot more than just pricing. When you make the fulcrum the server, which it’s intended to be, you have a lot more opportunity for richness of the transaction—more variables, opportunities to better weigh buying partners based on the demand they’re bringing. It gives the publisher greater control.

GD: We’re talking a lot about audience, but what about contextual data?

TK: Within our platform, the buyer can build and execute on a media plan on context, their data or third-party data. Do you want to buy new moms reading about Caribbean vacations? Go for it. We’ll tell you where they are, what sites they’re on and what your reach is against those audiences on those sites. And then we’ll give you a pricing curve, which we also give to the pub. If you want to lowball the pub, go ahead. You’re not going to get much scale. But if you want to pay fair market value, we will plot out the apex of that pricing curve for the buyer. If the publisher has the supply and the audience at a price point that’s amenable to the buyer, then have a conversation through our platform.

There are some pubs that don’t want us to show the pricing curve—they may not have the reach the buyer thinks they have. But fast forward two years—new moms, as the buyer defines them, are quantifiably scarce, and a buyer will pay top dollar to reach them in a high-quality environment. That’s not well measured in today’s ecosystem. So you’ll grow budgets based on value of audience and media quality. There just won’t be the tonnage of media like today.

And is that such a bad thing for the consumer? This is all about the consumer, and I think it’s great for them! Highly relevant messaging in the proper context via a healthy experience is valued. Is that necessarily bad for the pub? No! It’s good for premium publishers. That premium will be quantified through the data, proving out scarcity in audiences and quality environments. Now, the flip side of that is the bad news goes back to the brand, “I’m going to spend your entire budget out, but your CPM just tripled.”

Sonobi is focused on buyer-curated audience and media, and that’s why if there’s a trust issue with opportunistic demand, we don’t have to participate. But we have the tools for you to do that, and we happen to believe server-to-server is the future of that.


Comments are closed.