In the last of the series on programmatic premium (sorry, guaranteed!) we speak to Paulo Cunha, Co-Founder & CEO shiftforward who breaks down, in some detail, how the ad exchange can be used to deliver programmatic premium buys - and compares this methodology against the direct sales model and programmatic premium trades executed via the RTB protocol. Cunha also goes into detail about the importance of forecasting in this type of premium trade.

How would you execute a programmatic premium (guaranteed) buy through a typical ad exchange?

It may seem obvious, but it's important to reiterate the keys to enabling premium guaranteed trading:

A) Ways to automate and ease the buying process
B) Premium inventory access
C) Methods to guarantee delivery of campaign bookings, including availability forecasting and inventory pre-allocation

When ad exchanges first appeared, they allowed, for the first time, for supply and demand sides to trade directly with multiple partners, harvesting the benefits of scale in both directions.

Automation was achieved by allowing buyers, which previously had to contact and deal with multiple publishers and networks separately, to book one single campaign with common targeting and reporting across multiple inventory suppliers.

By adding some technology goodies onto the platform, such as contextual and behavioural targeting, fancy reporting, optimisation technologies, quality control automation, etc., ad exchanges enticed publishers to bring over more of their premium inventory and even to use the ad exchange in self-booking mode, allowing publishers to effectively use them as their own ad server.

Now back to the question at hand, because the ad exchange, in essence, operates as one large ad server and, crucially, makes the final decision of which campaign to deliver for a given ad impression, it has the opportunity to produce inventory availability forecasts, allocate campaign volumes to future inventory and run campaign priority optimisation during run time. All the things you can do on your own publisher ad server. This enables guaranteed inventory pockets which can be traded over the exchange.

Exchange technology became almost a swiss-knife of ad tech, where everyone was using them in their own way. Agencies could use them as their own trading platform; ad networks as their ad tech stack; publishers as their own ad server, as their reaching extension tool (retargeting their users on other web properties) or as their automated ad shop front. Obviously, this technology wasn't originally designed to do all these things at once, and eventually companies appeared to specialise on each different model, giving rise to the SSP, DSP, DMP, Trading Desk, etc., with RTB technology eventually appearing as the glue to bind them together. Those believing in the benefits of a do-it-all platform didn't disappear; on the contrary, it's having a revival rebranded as the "full stack", and some of the companies that started out with a specialised model are now coming back towards it.

Can this provide publishers with a way to ask the ad exchange platforms, in real time, if they have a campaign for that ad space. How would this work?

Yes.

Some ad exchanges have a method to "query" the exchange in real time, before any ad request is made, and find out if there is a campaign available for that user on that page at this time. The result of this query is sent over to the publisher's ad server and the decision to deliver that particular ad exchange campaign is left to the publisher's ad server, allowing them some degree of inventory management and optimisation.

This allows for publishers to safely offer more, and higher, quality inventory on the exchange without the drawbacks found with a standard integration such as default redirections back to publisher's ad servers, which double ad serving costs. This also allowed buyers to have the opportunity to "talk" to the publisher's ad server before the ad decision was made.

This "query" has been implemented in different ways and with different names by different vendors. I first came across the concept in 2009 while working at Wunderloop (now AudienceScience) where we developed what is now called Adprobe on the AudienceScience private exchange. AppNexus describes something similar in their Preemptive tags, and Semasio calls it PreCall on their User Intelligence Platform (UIP). This method is not particular to ad exchanges, in fact SSPs, DSPs and other different third-party advertising platforms can benefit from this solution.

The "query" method came into existence because one of the key issues ad exchanges had was in their integration model (pre-RTB). It forced publishers to send ad impressions to the exchange, where it would be evaluated, and if no appropriate campaign was found the exchange would re-direct (or default) back to an ad placement on the publisher's ad server. This has consequences: 1) for every ad not delivered through the exchange there is an additional ad request to the publisher's ad server, increasing ad serving costs 2) made it impossible to manage exchange campaigns on the publisher's ad server: there was no way to prioritise a specific exchange campaign over other running campaigns 3) messed up ad server forecasting because the ad server was now seeing two impressions (the original and the redirect) when there was really only one. This lead publishers to reduce the amount and level of quality of impressions they send over to the exchange, but which impressions to send to the exchange and which not to? Which to send to which exchange or network, to yield the best eCPM?

This is the problem SSPs tackled when they started their business: aggregating multiple exchanges and networks and performing this type of yield management job by selecting which inventory to send over to which exchange or network, in a effort to minimise defaults and increase eCPMs.

Would this be done on server-to-server basis, or on the browser-side? What benefit would this be to publishers?

It can work in various ways, all running on the browser-side. This is one of the key differences to RTB and the reason it works with the vast majority of publisher's ad servers without any additional functionality, making use of the key-value targeting or cookie retargeting already available.

In all cases, publishers place an additional tag (the "query" tag) on their pages before their ad tags. This retrieves from the third-party advertising platform the information about deliverable campaigns. Some implementations of this "query" tag return just a "yes/no" variable, a campaign or deal ID information, while others deploy retargeting pixels from the publisher ad server and some can also return campaign CPMs or CPM levels (e.g. Semasio's UIP PreCall).

This information is then sent to publisher's ad servers as a key-value (or as cookie targeting in case of delivering re-targeting pixels).

Publishers book the third-party platform's ad tags, not as a low-priority campaign on remnant inventory, but across all their properties channel's, targeted to the appropriate key-values, specifying, for example, maximum delivery volumes and minimum campaign price levels for each different section they manage.

Crucially, the "query" tag is executed for every ad impression, not just for ad impressions sent over to the third-party ad platform. This means it's possible to reach high quality audience pockets at larger scale, produce availability forecasts for buyers that bring over their own data and allow them to create higher valued RFPs across all of the publisher's inventory (or the inventory the publisher allows, of course) without the publisher ever having to send a single impression over (and having to serve exchanges campaigns or paying for a redirection back to their ad server). Publishers typically have the chance to review RFPs for volume and pricing before executing them, making sure they have enough volume allocated to the third-party advertising platform to guarantee it.

When RFPs are live, the publisher's ad server sends the necessary, and only the necessary, impressions over. In this context, "publisher" can be any type of supply side player.

Why would you use this method ahead of the direct sales interface and programmatic guaranteed buy executed via the RTB protocol? Any clear benefits?

Direct sale platforms only solve part of the problem, the selling and booking automation part, and consequently opening up of premium inventory access. However, not touching the real-time ad delivery workflow has its drawbacks, for example, in inventory availability forecasting with buyer's own targeting data, or realising global campaigns with cross-publisher frequency caps.

RTB technology has clear advantages over the browser-side "query", namely running reduced client calls (lower page loads) and allows for easier scaling the number of partner platforms. Though it still lacks the method to guarantee campaign delivery, including availability forecasting and inventory pre-allocation. This is because guaranteed delivery and bidding (the B in RTB) aren't completely compatible trading models: highest CPM can't win all the time. Deal-ID, as a method for identifying specific deals, together with bidding overriding works towards this goal, and is a great step forward but it doesn't cover all necessary basis: increase access to all that high-quality publisher inventory.

To understand the issue, we have to think how publishers can decide in their ad servers which inventory to send over to SSPs: this decision is normally done based on the publisher's own perception of context, quality and volume, but not based on SSPs' knowledge of the particular user behind the impression, nor on the current demand for that particular inventory. This means potentially high-value inventory (from the SSPs' point of view) may not be sent over, and lower-quality inventory being used at lower CPMs, making it even harder for publishers to justify sending over more inventory.

In a ideal world, all of this integration and communication would be done server-side, and not through a browser-side "query" method. For this to happen though, all publisher's ad servers would have to connect server-side to demand partners, in a sort of federated real-time ad trading architecture. This could be achieved, for example, by them having their own Real Time Bidding server integrated into their stack (including forecasting and pre-allocation of inventory usable by publisher's ad ops teams) - but hang on, isn't this RTB server process the current role of the SSPs? So, in this solution, the SSPs would have to adapt, possibly turning into a publisher's ad server or an even more complete platform including the DSP functionality ("the full stack"). Ironically, this is what the ad exchanges originally proposed to be and from which SSPs saw a specialisation opportunity and emerged from, but we digress. Until then, publishers will find it hard to make all their inventory visible to demand partners. This is where the "query" method first employed by ad exchanges wins: it works today with almost all publisher ad servers.

In terms of inventory forecasting, how critical will it be for all the options already discussed in this series, direct sales interface, RTB trading, and ad exchange?

Inventory forecasting is paramount to guaranteed delivery, regardless of how that is achieved. You can't guarantee delivery if you don't know what you have available to sell. You may use excel sheets, simply do them in you head, or use specialised technology for the job. The question becomes which tool solves your problem. As a publisher alone, as long as you book more or less standard campaigns, then the major publisher ad servers are more or less able to do this for you.

The more complex and targeted your campaigns and inventory becomes (frequency capping, audience segmentation, contextual, etc.) the less you can trust in your excel sheets or even standard ad server forecasting engines.

Direct sales platforms aren't doing their own forecasts, instead they rely on publishers to supply this information via their ad servers through APIs. For programmatic to really exist, you have to do these forecasts in real time, as you have to produce estimations to buyers in the direct sales platform in seconds, not days. If a guaranteed campaign is reserved, you have to immediately remove that inventory from all sell-able inventory, as you can't guarantee those impressions any more. If the publisher's ad server isn't doing a good job here, then manual intervention and re-booking is required, throwing away the programmatic premise.

On RTB and ad exchange models, some players can live through the "we have so much inventory we don't need to worry" mantra, and for those forecasting is not a big problem. Yet. However, once you start funneling down to get to the "right" inventory, with audience targeting, frequency capping and filtering for higher-quality inventory, then all that goes out the window because inventory will be in limited supply and you require a reliable forecasting engine if you are to build a business model offering guaranteed delivery.

With the growth of inventory access that RTB enables, forecasting has to run on a massive scale in both number of users and impressions but also in the amount of buyers, campaigns and third-party data thrown into the system. Now, think also there are two business models running concurrently: bidding and guaranteed. Forecasts may have to take bids and eCPMs into account to show real availability at given price levels. Yield Managers would also benefit tremendously with this programmatic forecasting information to optimise and prioritise campaigns in this new paradigm.

True for all three, but especially for RTB and ad exchanges, forecasts have to be technologically driven with scalable, efficient and reliable engines, and those are not easy to come by. In fact, it was this lack of offering we have been feeling for a while that lead us at ShiftForward to build the AdForecaster, a forecasting engine that addresses these difficult technical requirements and is able to integrate via APIs with any player in this space that needs one.

How would inventory forecasting work in each of the cases stated above?

In any of the cases above inventory forecasting starts by accessing total possible deliverable impressions. A forecasting engine should then be able to expose a way for the systems to query it (e.g. a GUI or API) and answer their campaign availability queries, such as "how many impressions, starting tomorrow, for 28 days, targeted to males on this list of publishers with a frequency cap of six per campaign, with this list of formats, at high-priority". The engine must reply back with the number of available impressions, within seconds, taking into account a) all total impressions, b) all other campaigns booked that overlap with this query and c) the ad decision logic of the server responsible for delivering the campaign

Access to total possible deliverable impressions can be achieved through the "query" tag mentioned earlier, through actual ad requests sent to the platform or through RTB connections with other providers. The later case creates an additional difficulty: you can forecast but you won't know if those impressions are truly going to be available in the future (e.g. you may be outbid, publishers may reduce volume to the platform, etc), unless using RTB providers that allow you to perform guaranteed delivery buys (full circle back to the guarantee delivery issue over RTB). One possible solution around this third-party inventory forecasting issue is if platforms expose forecasting APIs, allowing for example, a DSP to query an SSP on total avails for a new campaign that is being booked on the DSP user interface at that time.

In any case, the idea is whenever someone is looking to buy a guaranteed campaign on a programmatic/automated platform, it should reveal, in real time, the volume estimations it can guarantee, without human or manual intervention. Until then, it may be programmatic or guaranteed but not both at the same time.

- Programmatic Premium Explained: How An Automated Direct Sales Platform Works & Why It Could Help Publishers Unlock The Value Of Premium
- Programmatic Premium Explained: Part 2, The Case For Using RTB As The Mechanism For Programmatic Premium