John Hodge

How I conceptualize the basics of adtech

How I conceptualize the basics of adtech

Published by on

I believe that our understanding of complicated concepts is influenced by our understanding of the basics. The way I conceptualize the structure of adtech is influenced by my background in media buying and my position as a Solutions Engineer at one of the major ad servers in the industry.

That said, my understanding of adtech isn’t “the right”, or even “the best”, understanding. It’s what works for me, and I hope seeing my perspective can help someone who’s struggling to conceptualize the landscape.

I’ll be writing more detailed articles in the coming weeks that will look at some of the concepts discussed here more closely.

Transactions at the center of all adtech integrations

The center of how I conceptualize adtech is within the transaction between the player and the ad system. This transaction consists of an ad request sent from the player to the ad system, and a response from the ad system back to the player.

In its simplest form it looks like this:

Diagram of a transaction

Between the data in this ad request and the configuration of the ad system (including integrations with other systems), an ad response can be generated and sent back to the player.

This transaction influences a few concepts in advertising, such as:

  • Targeting
  • Delivery
  • Reporting
  • Forecasting

Notice: I’m going to focus on digital endpoints like connected TVs, mobile and desktop devices, and most of these requests will be handled as an HTTP GET request.

How transactions influence targeting

Targeting represents the act of assigning some criteria on a piece of demand, like a campaign. This could be a specific DMA or audience segment. If the information in the request matches the targeting on the campaign, then the campaign will be considered for delivery.

So, the targeting criteria is passed in the request. Great, but where and how is it passed? This answer can get a bit complicated, but some common examples are:

  • The IP might be passed in the HTTP request header
  • The device ID could be passed as a parameter in the request

Either of those examples could be used for audience targeting and IP is commonly used for geographic targeting.

Soon, we may see more contextual targeting2, like showing a Pepsi ad after a TV show featured a Pepsi can on a table. This information will be based on artificial intelligence that identifies the Pepsi can in the content and inserts information (possibly in the form of key value pairs) in the request to the ad system.

All this information passed in the request allows targeting to function as expected.

How transactions influence delivery

Individual players may have different supported content types. To be sure that a delivered ad can be played by the player, it’s important for an ad system to know what these supported content types are.

This information will be shared in the request of the transaction and will enable it to filter ads with unsupported content types.

While this concept is straightforward, it’s increasingly important in an ad ecosystem that supports multiple sales channels and endpoint types.

For example, how does Comcast allow VOD creatives to be delivered to their set-top boxes through programmatic sales channels1? Keep in mind, the advertisers booking campaigns likely don’t have access to the Comcast headend, so they’re going to book a standard digital creative (like an MP4). The short answer is by having a firm creative qualifying and transcoding process between the information passed in the request and what’s delivered to the player in the ad response.

Sidenote: There’s a process of delivering the creative to the headend that’s interesting and a little too complicated for this article. Maybe we’ll look closer at that in the future.

How transactions influence reporting

In addition to creative content type support, the request may also tell the ad system what beacons are supported by the player.

A beacon is essentially just a URL that, when triggered, logs event data on a server. This event data might be passed as query parameters in the URL. For example, when the first frame of an ad creative plays, the player might trigger the beacon https://adsystem.com/events?eventName=impression&transactionId=123.

This beacon will then inform the ad system that a transaction with an ID of 123 contained an impression event.

Obviously, this is oversimplified a little. In a real transaction, the beacon may contain more information than what’s shown above.

There are many kinds of beacons to accommodate different reporting parameters, and these beacons are included in the ad response for the player to access and fire when needed. The ad request from the player will contain some information to tell the ad system which beacons to return and the ad system will return those beacon URLs in the response.

Referring to our transaction diagram from above, this might look like the following:

Transaction diagram with beaconing

We’ve added the concept of time to show beacons firing at appropriate intervals. As the 60 second ad creative plays, it's the player's responsibility to fire these beacons.

How transactions influence forecasting

An ad system will know that it should forecast based on slot opportunities or impressions by the information that’s passed in the request.

This information will specify first, what kind of response to be expected (this will then inform the beacons available), and second the forecasting strategy that should be used.

As an example, let’s suppose a publisher wants to forecast based on opportunities instead of impressions so they could get forecasting data whether an ad was served or not. Assuming the publisher returns multiple ads in an ad response, this would require them to access a slot where an ad would serve. As we saw in the sections above, information about the response type and beacons will be sent to the ad system in the ad request.

If they can tell the ad system to forecast based on the breakStart event passed in the VMAP response, then the system would be enabled to use slot parameter information to identify the opportunities that would have been in that slot even if an ad didn’t return. It could do this with simple slot information like: slot duration, maximum ads, minimum ad duration, etc.

This is possible because the breakStart event is passed whether an ad served or not. However, to have a concept of a breakStart event, the response type will need to be VMAP.

Conclusion

For me, tying everything back to the transaction between the player and the ad system helps conceptualize an integration that’s further downstream of this initial transaction. I’ll be publishing more articles about the different aspects of this transaction and how it influences integrations further downstream. If there’s something specific you want to discuss, don’t hesitate to reach out.

Resources

  1. Business Wire. “Comcast Technology Solutions and FreeWheel Partner to Bring Programmatic Advertising to the On-Demand Living Room.” Business Wire, June 9, 2020. https://www.businesswire.com/news/home/20200609005455/en/Comcast-Technology-Solutions-and-FreeWheel-Partner-to-Bring-Programmatic-Advertising-to-the-On-Demand-Living-Room.

  2. Dimitrov, Ned. “Why Contextual Advertising Makes More Sense Now than Ever.” AI-powered contextual ads key to privacy compliance. Ad Age, May 18, 2021. https://adage.com/article/StackAdapt/why-contextual-advertising-makes-more-sense-now-ever/2336431.