What is dynamic ad insertion? A plain-English guide

Dynamic ad insertion (DAI) is a way of putting ads into a podcast without recording them into the episode. The ad lives outside the audio file, and your host stitches it in when a podcast app requests the episode — which may be the moment someone presses play, or earlier, when their app downloads it automatically. Either way the same episode can serve a different ad tomorrow, next month, or to the person listening right after you.

That one mechanical difference is the whole story. Everything else people say about dynamic ads — that you can monetize a two-year-old episode, that you can kill a campaign the day a sponsor goes bust, that you can sell the same slot twice — follows from the fact that the ad was never welded into the file in the first place.

The short version: the ad is not in the file

When you bake an ad in, you record it, drop it on the timeline in your editor, export one MP3, and upload it. From that point the ad and the content are the same waveform. There is no way to remove the ad short of re-editing, re-exporting and re-uploading the episode — and even then, listeners who already downloaded the old version keep the old ad forever.

Dynamic insertion breaks that bond. You upload your episode exactly as you recorded it, with no ads in it at all. Separately, you place ad markers: timestamps that say “an ad is allowed here.” When a listener’s app requests the episode, the platform builds the audio stream that listener will receive — content, plus whatever ad is currently scheduled for each marker — and sends that.

The listener gets one continuous MP3. They cannot tell it was assembled a quarter of a second ago. But it was, and the next request will be assembled again.

What actually happens when an app requests your episode

Walk it through in order, because the sequence is where the intuition comes from:

1. You upload a clean master. No ads. Just the show.
2. You place markers. Typically one pre-roll marker at 0:00, one or two mid-roll markers at points you choose, and a post-roll marker at the end. See pre-roll vs. mid-roll vs. post-roll for how to choose those points.
3. You schedule campaigns against the markers. A campaign is an ad file plus rules: which shows and episodes it applies to, which marker it fills, when it starts, when it stops.
4. A listener’s app requests the episode URL from the RSS feed, the same way it always has.
5. The ad server picks what fills each marker for that particular request, based on the campaigns that are live right now.
6. The platform assembles and streams the file — ad, content, ad, content, ad — as one response.
7. The listener hears a normal episode.

Step 5 and step 6 are the parts that did not exist before DAI. Everything else looks identical from the outside, which is why dynamic insertion needs no cooperation from Apple Podcasts, Spotify, Overcast or any other app. They are just fetching a URL.

Ad markers: where an ad is allowed to go

A marker is not an ad. It is permission and a position: a timestamp plus a slot type (pre-roll, mid-roll, post-roll). Markers are the part you control as a producer, and they are the part that most affects whether the finished episode sounds good.

Two things worth knowing:

• A marker can be empty. If no campaign is scheduled for a marker at the time of the request, nothing is inserted and the episode plays straight through. That is a feature — an unsold slot is silent, not awkward — but it also means an unsold show earns nothing from having markers.
• Markers are per-episode but campaigns are usually per-show. That asymmetry is the mechanism behind back-catalogue monetization: place mid-roll markers on 120 old episodes once, and a single new campaign fills all 120 at once.

The ad server: who decides what plays

The ad server is the decision layer. When the request arrives it answers one question per marker: given everything scheduled right now, what goes here?

At a small-show scale the answer is usually simple — you sold a mid-roll to one sponsor for eight weeks, so the mid-roll marker gets that ad until the end date, then goes quiet. At larger scale the same layer supports rotation across several advertisers, frequency and impression caps so a campaign stops once it has delivered what was bought, and — on the big programmatic ad servers used by ad networks — geographic and audience targeting, which is how a single episode can carry a regional advertiser for regional listeners only.

That last capability is worth understanding as an industry concept, because it explains why national brands buy podcast inventory at all. It is not something every host offers, and you should check exactly what any platform’s ad server does before you promise a buyer anything.

Why the same episode can be assembled differently from one request to the next

Here is the part that surprises people the first time they see it. A 42-minute episode with a 30-second pre-roll and a 60-second mid-roll is 43.5 minutes long for that listener. Swap the mid-roll for a 30-second spot next month and the same episode is 43 minutes. Sell nothing and it is 42.

That has real consequences:

• The duration your listener sees may differ from the duration you edited. Apps display the length of what they fetched.
• The length attribute in your RSS feed is a stated byte size, not a promise. Because the assembled file varies, that number is an approximation for dynamically inserted episodes. Well-behaved apps handle this; a few older ones show a slightly wrong scrubber.
• You cannot verify an ad by downloading the file once and calling it done. What you got is what the ad server chose for your request at that moment.
• Chapter markers and timestamps drift. If you say “at 22 minutes we talk about X” in the show notes, that is now approximate. Reference topics, not timestamps.

What it means for your download numbers

A common worry: does inserting ads at request time mess up analytics? Short answer, no — the counting rules are unchanged, because the insertion happens inside the same HTTP request that the download was always measured on.

Under the IAB Tech Lab’s Podcast Measurement Technical Guidelines, a download is counted when at least 60 seconds’ worth of the file has been delivered, deduplicated to one download per listener per episode per 24 hours, with a listener identified by the combination of IP address and user agent, and with known bots and data-centre traffic filtered out. Dynamic insertion does not change any of those conditions.

What it does change is what a download is worth. Because the assembled file is built per request, an old episode downloaded today carries today’s ad — so downloads on your back catalogue become sellable inventory instead of decoration. That is the single largest revenue difference between the two approaches, and it is covered in depth in how to monetize your podcast back catalogue.

How it compares to baked-in ads

Baked-in is not obsolete and it is not the amateur option. It wins on total creative control, on ads woven into the actual conversation, and on never depending on a piece of infrastructure at playback time. Dynamic wins on flexibility, expiry, and the ability to earn from episodes you published two years ago.

Most shows end up doing both — a baked-in read for the long-term partner who is genuinely part of the show, dynamic slots for everything else. The full head-to-head, including where each one loses money, is in baked-in vs. dynamic ads. If you are working out what any of this inventory is actually worth, start with podcast ad rates and CPMs. And before you commit, read the downsides — there are real ones.

What you need to run dynamic ads

Three things: a host that supports ad markers, somewhere to schedule campaigns against them, and an ad to insert. That is it. You do not need to change your feed, resubmit to directories, or ask listeners to do anything.

On TurboCast, dynamic ad insertion is part of the Hosting Pro plan at $29/mo billed annually, and it includes pre-, mid- and post-roll markers, campaigns with start and end dates, and the ability to swap or remove an ad across your whole back catalogue without re-uploading a single episode. If you are still deciding whether the mechanic is worth it for your show size, work the numbers first — that is what the rest of this cluster is for.