23 January 2013 in ExchangeWire EMEA 9 Comments

Programmatic Premium Explained: Part 2, The Case For Using RTB As The Mechanism For Programmatic Premium

img_0650We have already looked at how you would execute premium programmatic from a direct sales platform in the first of this series of posts. But what about the other options, namely RTB and the ad exchange. Today we will examine RTB as a means of executing programmatic premium buys.

Let’s be clear, when we speak about RTB here, we are not necessarily talking about impression-level buying – more the method of delivery. In the context of programmatic premium, it is merely a buying mechanism for automating a premium buy. Using Deal ID, this buying methodology can identify a premium deal previously done or an agreed trading agreement as a trigger for executing a buy. So RTB is only the automation of the ad delivery rather than the trading itself. To get the low down on how this might all work in practice we asked Neal Richter, Chief Scientist at the Rubicon Project, to give us his insight.

How does this process actually work? How is this different from agreed floor pricing?

Yes. RTB is a protocol for comunicating the opportunity for a transaction, the auction is the mechanism for executing the transaction. The DealID extensions in RTB change the semantics of the auction mechanism fundamentally. Without the DealID the assumption is that the auction awards the win to the highest approved bid. With the DealID present the auction changes, it now must consider delivery objectives and priority preferences of the underlying orders. RTB as a protocol evolves to serve a real-time matchmaking signal that a given impression has been matched to an order.

There are two separate processes at work here. The first is the automation of the order process, the second is the automation of the execution of the order. Ideally the buyer and seller are having a conversation via a GUI or platform. The buyer is bringing forward their campaign objectives and parameters and the seller is bringing forward their inventory packages. Once there is a match then an IO object is created that captures the agreement and objectives in terms of dates, targeting, placement, volume, price and priority. This completes the first process and it then transitions to execution. This part might look like extended RTB or a direct insertion of ‘tags’ into an ad-server. The key is that it is automated to a greater extent that it is today.

Is this a CPM buy rather than impression level buying, and if so should it be called RTB? Is it merely a private exchange model with hard floor pricing? Is it even an auction anymore?

RTB is just a protocol, and it’s important to note what that means. RTB as a protocol is about individual impressions and giving the buyer an option to bid on them. It’s far more low-level than an order. RTB platforms in DSPs and SSPs automate the mechanics of doing this process at scale. And we’ve largely agreed on standards via OpenRTB, yet what is not standardized is the process of automating the order workflow and how that transitions into RTB.

Is programatic premium still an auction? I suppose that depends on what you define as an auction. An auction is a way of taking buyer interest and deciding a winner. While that tends to mean ‘highest bid wins’, what is being bid on? If we’re taking the view of an auction at the impression level then the highest bid should win as the objective is to maximize the sales price. However take the view of an auction of a million impressions.. Should you sell each of those to the highest bidder? Not necessarily if we take the view that the orders for blocks of impressions are the bids. There the job of the auction is to execute the orders for each impression.

Will Deal ID bring in more additional high-end spend for publishers?

DealID shifts the focus to the order rather than the microscopic view of individual impressions. RTB and the technology partners powering it have done a wonderful job of enabling the buyer to use data for more precise audience targeting than ever before.. yet the direct-response budgets were the early adopters. We’re all betting that further automation will bring higher brand budgets to programmatic.

Is RTB the best delivery mechanism for programmatic premium compared to the other two options, namely, 1) a direct sales platform (shinyads, isocket); and 2) through an exchange?

We see two logical mechanisms for programmatic premium, RTB and ad server API automators.

What ShinyAds, iSocket, Maxifier, YieldEx and others are working on is automating directly with the primary ad servers to insert orders and prioritize them correctly.

Both are viable options as ‘execution protocols’. Which one is used seems to depend primarily on how the inventory is sold as a package and what private data the buyer wants to use to determine which impressions to buy.

Rubicon is currently proposing a dealID extension standard within the OpenRTB community. We’re thrilled with the feedback and iteration so far. The next step should be an order and inventory packaging API that encompasses RTB and direct integration protocols. We believe these efforts will help the industry move forward in automating premium guaranteed.

Display, Premium, Programmatic Premium, Publisher, RTB

Latest jobs on Exchangewire

  • Wayne Blodwell

    Thanks for the excellent post. I feel as though we should define the difference between Real Time Bidding and Real Time Guaranteed. Technically I can see the points made as to why it should remaind RTB, but from a managing upwards perspective to advertisers a more definitive split would resonate much better. We can rid ‘private exchange’, ‘private marketplace’ as they can all fall under the Real Time Guaranteed name? RTB & RTG?

  • http://twitter.com/btrenda Ben Trenda

    To be clear, the difference between the two is in execution of delivery. And they’re not mutually exclusive. Whether you use RTB or “ad server insertion” as an execution protocol, there needs to be automation around the first piece– what is bought and sold, by whom, creating a master catalog of packages and pricing, making a market for inventory, helping the buy side find what they need, automating the transaction on both sides, eliminating paperwork, etc.

  • http://twitter.com/btrenda Ben Trenda

    But to reiterate, if you use RTB as the execution protocol, you still have the problem of actually getting access to premium Class 1 inventory. Like I said, they’re not mutually exclusive in theory, but you’d still have to insert the RTB vendor’s ad tag into the publisher’s ad server. Why? Because otherwise it won’t be treated as a high priority direct sold ad in the publisher ad server– it will be treated as part of the RTB platform’s existing tag, which as previously described, is lower priority than true direct sold buys.

  • Andy Atherton

    Some great perspective and careful thinking in evidence here, but think it’s important we are just as careful with terminology. Can we please retire “premium”?

    http://andyatherton.com/2012/11/09/can-we-please-retire-premium/

  • http://twitter.com/tshields Tom Shields

    Thanks for the mention, Neal, and nice article. Seems like the main challenge with using RTB as the protocol is that most publishers have implemented RTB at a lower priority tier in their ad server. This means that (by definition) it can’t compete with their direct sold campaigns. Do you think this will change?

  • Petteri Vainikka, Enreach

    What is holding back RTB protocol use for anything remotely Class 1 inventory, are two things:

    (1) The service fees demanded by SSPs. When these come down to a justifiable level (what about 2-5 % of campaign net revenue?), then it starts to make sense for premium publishers to use RTB protocol for Class 1 inventory on a Deal-ID basis.

    (2) Audience inventory forecasting and reservation (prerequisite for guaranteed sales) and audience targeted campaign prioritization amongst each other, as segments are by definition nested. I.e., “female + 25-45″ is a subsection of “female.” Primary ad servers are not up to this task, nor are the SSPs. Most DMPs have also not even though of this issue, because in the non-guaranteed RTB ecosystem, this is not a concern at all – nor has this been considered to be part of a DMPs task list…

    Given these major challenges, adding automation to primary ad server IOs (and the rest of the sales workflow incl. self-service buying) has the upper hand here. The only remaining major element that the isocket & co. are missing – and that is very fundamental to creating new data-driven value, not just reducing transaction friction on the existing inventory (although this alone is plenty of value) – is the application of value-adding (publisher) audience data. Without this, we’re loosing the biggest innovation that RTB gave the online ad ecosystem: DATA.

  • cpokane

    Andy, I would tend to agree. Programmatic Reserve would seem to be a better definition. But we were only looking to get into the guts of the concept – and trying to make sense of the noise in the trade press around this (kind of like the idiotic commentary being written about native). The guaranteed delivery is at he heart of the series as opposed to some mythical inventory classification. I’ve always thought the term “premium” was a misnomer. And while we are at it, let’s retire the word “remnant” too.

  • Paulo Cunha

    I like that distinction between Guaranteed and Premium, but in the end they go hand in hand, do they not? One is referring to the transactional model (guaranteed vs non-guaranteed) and the other is referring to the [insert appropriate definition of "premium-ness" here] of the inventory being transacted. It just so happens that they both fit well together and are both sought after for planning and executing Branding campaigns, which is the next step in the journey of RTB use (the protocol, not the business model), as adequately presented during ATS London (I believe by Frank Addante from Rubicon Project)

  • SimonHalstead

    Great Series of articles. It provokes a number of thoughts for me, not least that 2014 is likely to be the year of Programmatic Reserve, and 2013 is the year we all work through options that suit our needs and goals. I also agree with Ben, that there may well be a combination of solutions, that aren’t mutually exclusive.

    I think as well as publisher readiness, we need to consider buy side activity closely as we develop these options. Who will be the buyer – will it be individual planner/buyers in agencies? Will it be ATD as a service layer ? Are they ready, or even ready to evolve to programmatic buying?
    And, for a buyer to shift to programmatic execution, can they fully execute plan goals. Without this, we are potential shifting friction rather than reducing.

    The challenge for publishers is around effective holistic yield management, and we need to look at the value of reservation. Is it audience, is it publisher context?

    We also need to look at the trend of buying, and goals of advertisers within solution design.