> For the complete documentation index, see [llms.txt](https://docs.podigee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.podigee.com/documentation/grow-and-monetize/monetization/concepts-and-reference/understand-podcast-advertising-and-delivery-modes.md).

# Understand podcast advertising and delivery modes

Learn how embedded ads, host reads, dynamic insertion, RSS audio, HLS, and platform-controlled delivery differ before you plan a Campaign.

Podcast advertising can use the same Creative in different delivery systems. The important question is not only what the ad says. You also need to know when the ad is added, who controls the media, how the listener receives it, and what evidence can prove delivery.

The **Podigee Audio Video Ad Server** supports several modes. Each mode has a different authority, media, measurement, and fallback boundary.

## The simple model

| Question                                 | Embedded ad                           | Dynamic ad                                                          |
| ---------------------------------------- | ------------------------------------- | ------------------------------------------------------------------- |
| When is the ad added?                    | During production before publication. | At request or playback time.                                        |
| Can the ad change later?                 | Only by replacing the episode media.  | Yes, while the Campaign and rights remain eligible.                 |
| Does every listener receive the same ad? | Usually yes.                          | It can vary by time, market, policy, and eligible supply.           |
| What happens when demand is unavailable? | The embedded ad remains.              | The declared clean, house, or source fallback runs.                 |
| What evidence is available?              | Episode delivery and player evidence. | Decision, delivery, media, analytics, and qualified money evidence. |

Both modes are useful. Use the mode that matches the buyer promise, the show, the destination, and the evidence that the business needs.

## Embedded ads

An embedded ad is part of the episode media before the episode is published. It can be a host read, a produced sponsorship, a show promotion, or another editorially placed message.

Use an embedded ad when:

* the message should remain in the episode for every listener;
* the host or producer must record the message;
* the Campaign does not need request-time rotation;
* the destination cannot support dynamic insertion;
* the buyer accepts one fixed episode version.

An embedded ad is not a request-time decision. A Campaign can document the placement and the commercial terms, but it cannot change an already published audio file without a new media version.

## Host reads and sponsorships

A host read is spoken by the host or another approved voice. A sponsorship can include a host read, a produced audio or video asset, a fixed placement, a category restriction, or a presentation rule.

Host reads need:

* an approved script or recording;
* rights for the voice and message;
* a Creative version or episode media version;
* a placement or break binding;
* disclosure and brand-safety rules;
* the correct reporting and finance treatment.

Spotify sponsorships and other platform-controlled sponsorships can have a different execution authority. Podigee can prepare the approved intent and evidence, while the platform controls final playback or insertion.

## Dynamic ad insertion

Dynamic ad insertion selects an ad when a listener or viewer requests a presentation. The decision checks the Campaign, Flight, break, Creative, market, content, media, policy, rights, budget, frequency, demand, and fallback rules.

![The current One Podigee Recent ad decisions page shows selected ads for Podcast audio, with the Campaign, Creative, podcast, episode, reason, privacy mode, and decision time.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-d7e8fd4ca100c36e85d1231caf853395912d9401%2Fdoc-monetization-056-podcast-audio-decisions.png?alt=media)

*A recorded Podcast audio decision shows what the request received and why.*

Dynamic insertion is useful when:

* a buyer wants a date-bound or market-bound Campaign;
* several Creatives must rotate;
* the same episode needs different ads for different eligible requests;
* delivery and money evidence must stay linked to the selected ad;
* the publisher needs a safe fallback when paid demand is not available.

Dynamic insertion does not mean that every request receives a paid ad. No-fill, clean fallback, frequency caps, rights, privacy, and supply limits can all produce a correct non-paid result.

## Podcast RSS audio

Really Simple Syndication (RSS) audio uses the feed that podcast apps and directories read. The episode has a stable public URL and a media representation that a normal podcast player can fetch.

RSS audio is a strong choice when:

* the audience downloads or streams normal podcast audio;
* the show must keep its existing feed and episode identity;
* the player does not support HLS interstitials;
* the ad uses an approved audio rendition;
* the business accepts the measurement limits of download and progressive playback evidence.

RSS audio can use a request-time decision while preserving the feed contract. The serving path must keep source playback safe when a decision, provider, cache, or analytics component fails.

## HTTP Live Streaming audio and video

HTTP Live Streaming (HLS) uses a manifest and media segments. It can deliver audio, video, captions, I-frame variants, and timed interstitials.

![The current One Podigee Recent ad decisions page shows selected ads for Video ad stitching, with the Campaign, Creative, podcast, episode, reason, and decision time.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-cea052c594c382ab94110b59563d6406d953fce0%2Fdoc-monetization-057-hls-decisions.png?alt=media)

*A Video ad stitching decision is separate from an RSS audio decision.*

Use HLS when:

* the player supports HLS;
* the show offers video or segmented audio;
* the presentation needs timed interstitials or server-side ad stitching;
* the destination requires captions, multiple variants, or delayed companion video;
* the business needs a richer playback and delivery evidence path.

HLS needs a valid media and manifest contract. A valid decision is not enough if the playlist, segments, interstitial, captions, MIME type, CORS headers, or cache behavior is wrong.

## Programmatic demand

Programmatic demand lets an approved external source compete for an eligible opportunity. The source can use VAST, OpenRTB, CATS, or another certified protocol.

The decision engine remains responsible for:

* whether the opportunity is eligible;
* which demand source gets the opportunity;
* price floors, currency, and cost limits;
* privacy and consent boundaries;
* media and duration validation;
* timeouts, retries, and circuit breakers;
* no-fill and clean fallback;
* delivery, analytics, and money evidence.

A bid or provider response is not automatically a selected ad. The response must pass the current protocol, media, privacy, policy, and delivery checks.

## Podigee-controlled delivery

In a Podigee-controlled surface, Podigee prepares or serves the media, selects the decision, and owns the delivery evidence. This usually includes RSS audio and Podigee HLS audio or video.

Podigee can link these records:

1. The source episode and exact media version.
2. The approved break and timeline binding.
3. The Campaign and Flight version.
4. The selected Creative and rendition.
5. The decision reason and fallback.
6. The cache and media response.
7. The analytics and qualified money evidence.

This does not mean that Podigee can control every downstream player. The player still controls local buffering, skip, mute, and completion behavior.

## Platform-controlled delivery

In a platform-controlled surface, Podigee prepares an approved intent and submits it through the platform contract. The platform controls some or all of hosting, playback, insertion, auctioning, measurement, or revenue execution.

| Surface        | Podigee prepares                                                             | Platform controls                                            |
| -------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------ |
| Apple Podcasts | HLS media, interstitial assets, association input, and host evidence         | Apple playback and platform acceptance.                      |
| Spotify        | Show, episode, Campaign, Creative, targeting, sponsorship, or cuepoint input | Hosted media, insertion, auction, and destination execution. |
| Other provider | Contract mapping, eligibility, privacy, and fallback                         | The provider response and any provider-owned measurement.    |

Platform-controlled delivery can be commercially valuable even when Podigee cannot observe every playback event. The UI must show the authority boundary and the evidence that is actually available.

## Choose a mode for a simple Campaign

Use this example:

1. A buyer wants a 30-second German audio ad in Germany for four weeks.
2. The publisher has approved mid-roll breaks in two episodes each week.
3. The buyer wants the ad to rotate when the Creative changes.
4. The publisher wants clean content when no paid ad is eligible.

Choose dynamic RSS audio when the audience uses normal podcast players and the feed must remain the same. Choose HLS when the audience uses a compatible HLS player and the Campaign needs a richer audio or video presentation. Choose an embedded host read when the publisher wants one fixed message that remains in the episode. Use Spotify or Apple only when the platform path and grant are active.

## Compare the evidence

| Mode                       | Strong evidence                                                                     | Evidence that may be limited                                      |
| -------------------------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| Embedded ad                | Episode version, media delivery, published feed, player evidence                    | Request-time decision and per-listener selection.                 |
| RSS dynamic audio          | Decision, representation, qualified download or playback threshold, events          | Audible completion and person-level reach.                        |
| HLS dynamic audio or video | Decision, manifest, segment or interstitial, player events, qualified value         | Playback behavior when the player does not send events.           |
| Apple                      | HLS, binding, asset list, platform association, and available platform evidence     | Full Apple device execution when the platform does not return it. |
| Spotify                    | Submission, processing receipt, Campaign or sponsorship state, and platform reports | Podigee control of final insertion and playback.                  |
| Programmatic demand        | Request, provider response, selection, delivery, and qualified value                | Provider-owned auction or external player events.                 |

Do not promise a metric that the selected surface cannot prove. Use the metric and evidence definitions when you write an order or report.

## Safe fallback

Every dynamic mode needs a declared fallback. The fallback can be clean content, a house ad, the original source segment, or another approved representation.

When the decision or media path fails:

* source playback continues within the declared boundary;
* the paid result is not marked qualified unless its evidence passes;
* the fallback reason is recorded;
* the cache does not mix private and shared responses;
* the operator can trace the outcome in Evidence & Money.

## Expected result

You can explain the difference between an embedded ad, a host read, a dynamic decision, RSS audio, HLS audio or video, programmatic demand, and a platform-controlled destination. You can choose a mode that matches the buyer promise and the evidence the business needs, with a safe fallback when paid delivery is not available.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.podigee.com/documentation/grow-and-monetize/monetization/concepts-and-reference/understand-podcast-advertising-and-delivery-modes.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.