How Does Dynamic Ad Insertion Work?

Let’s take a quick dive into how dynamic ad insertion works for podcasting, how it is different from display ads on the web, and prognosticate over what the future might be.

(Caveat: this is all based on my own research, please get in touch with corrections!)

A very brief and simplified history of display advertising

Back in the days of print, advertisers would buy ads in magazines whose reader demographics fitted those customers they wanted to reach. If Ford wanted its ads to be seen by a young, affluent, married person, they would buy ads in, say, the New York Times Magazine. Ford had no way to know who exactly saw the ad but publishers would tell them how many magazines they sold which advertisers would use to estimate how many people their ad campaign reached.

Then the web came along and now it was possible to make reasonable guesses about who the individual reader was. Instead of Ford having to buy ads that targeted a broad demographic, they could buy ads against specific readers with particular traits. Perhaps they wanted to find people who had searched for particular terms or people who had visited certain websites. The reader demographics of individual publications became largely irrelevant. Ford could now say “find me young, affluent, married people wherever they are reading on the web” and would pay per ad shown. This is where ad networks came along. They would act as a broker between lots of advertisers and lots of publishers.

As long as a publisher could install a small piece of ad-serving code and had space on their site for a banner ad, they could sell ads. Each time a user viewed a page, the publisher would execute this code (remember this, as this is important later) that would ask the ad network for the best ad for that slot based on the user and how much an advertiser was willing to pay. Publishers now didn’t need to have a direct relationship with Ford’s marketing department, all they had to do was to tell an ad network that yes, I will show whatever ads you want to a reader. For advertisers they can now ask the ad network to target individuals regardless of what website they were on; just find me people with these traits and show my ad to them.

How User Tracking Works on the Web

Now let’s take a look at how the technology works behind being able to identify and show ads to users with specific traits.

Cookies The mainstay of web display advertising. These are small blobs of data that websites can store on its reader’s browser and then access at a later time. Maybe they want to store how many times you visited or what you searched for or any other interesting data that they want. The cookies are specific to the ad tracking software so as long as publishers used the same ad trackers they could track users across websites.

The ad industry is now trying to move on from just using cookies since they can’t track users across multiple devices and are also able to be cleared or turned off by the user.

Device Fingerprinting This tech tries to identify the individual device not just the browser that is being used. It can try and do this by combining an IP address, browser version, operating system, location and time zone settings, installed apps, in fact as many data points as they can. These data points are collected to create an identifier; the more data points, the more likely that the device can be identified as unique. It is essentially a game of Guess Who? at massive scale. If you only guessing against blue eyes then its pretty useless. But if you’re guessing against blue eyes, brown hair, receding hairline, mustache, glasses, oval head then you can make a pretty good guess. Of course the problem here is that we’re using multiple devices. How do you know if that ad for a vacation in Florida led to that person booking a vacation on their iPhone?

User Identification One level above device finger printing is to identify the individual user across whichever device they are using - even if they have switched from using their phone to their laptop. There are two main approaches. Deterministic and Probabilistic.

The difference between web and podcast downloads.

On the web as we have seen, there are many ways to track a user and be able to sell ads against them. Why is it different with podcasts? Remember when I said that publishers can execute code every time a page is viewed? That is the key to this whole ad tracking empire that has been built. If the publisher can’t execute whatever code it wants when a page is viewed then you’re left with a pretty dumb system. (Try turning off JavaScript in your browser and see what happens) Which is what happens with podcasts. Podcast players don’t execute publishers code when a listener requests an episode. Publishing a podcast episode is like mailing a letter. You’re pretty sure it’ll be delivered but you can be certain and you don’t know if the recipient even read it.

What can podcast players do?

Podcast players will send a “user-agent” when downloading a file. A user-agent is just a string of text that identifies what piece of software has made the request to download something. Podnews has a nice list of podcast player user agents, so a podcast publisher will know what podcast player has requested an episode. The podcast server will know the IP address that made the request to download too, and that can reasonably accurately identify the geographic location of the request (you can use a service like Maxmind that maintain a database of geographic locations for all known IP addresses). and of course they know the time that a podcast episode was requested. And that is pretty much all you can do with podcasts. You can target based on the location (certainly country-level, maybe city-level) of the request, the time of the request, and which podcast player is being used.

There are a few hosting platforms out there that claim to be able to provide more granular audience targeting, such as being able to bucket them into 60,000 different audience profiles. While the ad industry certainly has a well-developed data profile of IP addresses and user-agents, I would suggest that you treat these claims with skepticism.

What happens when I download and play a new episode

The vast majority of ads are created ‘server-side’. That means that the server does the work of inserting an ad into the episode and whichever podcast player is used, they will hear ads (we will discuss client-side ad serving a little later).

Here is the basic order of operations:

  1. The podcast player sends a request to the podcast server.
  2. The podcast server will see an IP address and a user-agent string and the time the episode was requested.
  3. Using that info it will identify, out of all the ads it knows about, the most relevant one.
  4. If you are the first person to request that episode and ad combination, the server will stitch together the podcast episode with the ads into a new mp3 file and return it to the player. It will also save a copy for the next request whose profile matches that ads so it can serve it faster.
  5. The server sends the complete mp3 file back to the player that requested it.

How does the server know where to insert the ads? Most commonly, the ad server is integrated into the publishing platform so when a producer uploads a new episode they will just type in the timecodes where ads can go while they add the episode title and description and other metadata. The other way is a little more automatic. When making the episode the producer can insert an audio tone outside the range of the human ear that the ad server can check for and use that position to insert an ad. The ad server can also recognize the waveform of a certain jingle or other cue to identify where to insert an ad.

Server-side vs client-side ad insertion

So far we have just talked about server-side ad insertion. ‘Client-side’ ad insertion means that the podcast player itself inserts the ad rather than the server that sends the mp3 file. This is currently pretty rare since this means that only the audience using a certain player will hear an ad (unlike server-side insertion where the ads are in the mp3 file that are sent to all players). Hence you can only monetize against a subset of your audience. A recent example of this is RadioPublic’s Paid Listens. The listener will only hear a pre-roll ad if they are listening on the RadioPublic app.

What is the difference between Dynamic Ads and Host-read ads?

The conflation of these two things is a pet peeve of mine. The perception seems to be that dynamic ads must mean radio-style commercials but that is not the case. One is the tech that delivers an ad and the other is a type of ad. I like to think of dynamic ads actually as dynamic content. There is no reason it has to be used for ads. One use case is to automatically insert a content warning read by the host at the top of the episode if the episode contains explicit language.

Are there any problems with dynamic ads?

The main problem is that unless your ads are all exactly the same length, dynamic ads can break sharing episodes at certain timestamps. Say there is a great segment I want to share with my sister. I send her a link to listen to the episode at the exact start of the segment. The pre-roll ad I got for that episode was 30 seconds long. However, when she downloads the episode, the ad server gives her a different ad that is 75 seconds long. Now the start of the segment in her episode is 45 seconds later than the segment in my episode.

Another problem (which is just the nature of podcast downloads) is that ads are inserted at the time of download not at the time playback so you could download an episode and not actually play it until a month later.

What is the future

I think we will see a stratification of podcasts: the top tier shows with host read, highly produced ads and then the rest that will have radio-style ads (hell, lets not just pick on radio, Pandora or Spotify have those same style ads too).

We have seen this with YouTube, the top creators are putting in host-read ads with promo codes in their videos and everyone else just has YouTube’s standard pre-roll or mid-roll ads. What is interesting to think about is the consumer’s perception of these ads. I think the general perception to a viewer is that YouTube inserts the ads so you hear people complaining about ‘YouTube ads’. When of course it is actually the creator’s decision to allow ads in their content. With podcasts, there isn’t (yet) a ‘bad guy’ to blame and the perception to the listener is that it is the creator putting in these ads.

The two questions I keep thinking about: will creators actually want to have these radio-style ads in their content? And will they pay well enough to be worthwhile for creators?

Further reading:

Back