> 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/understand-dynamic-ad-delivery-in-rss-audio.md). # Understand dynamic ad delivery in RSS audio Understand how Podigee keeps one RSS feed while it selects, inserts, delivers, measures, and reports audio ads for each eligible episode request. The Podigee Audio Video Ad Server can deliver a different audio presentation for each eligible request from a podcast app. The listener still subscribes to the normal Podigee RSS feed. Podigee changes the eligible episode enclosure only after the show has passed its delivery checks and an authorized operator has activated the new route. ## What stays stable Dynamic audio delivery does not create another show or feed. These items stay stable: * The public Podigee RSS feed address. * The episode GUID used by podcast apps. * The podcast and episode records in Podigee. * The clean episode master. * The published episode history. The enclosure URL becomes the stable entry point for the active delivery setup. Podigee resolves that URL to one exact audio presentation for the request. ## Follow one audio request The following sequence starts when a listener opens or downloads an eligible episode: 1. The podcast app reads the episode enclosure from the Podigee RSS feed. 2. The app requests the audio. It can request the full file or one byte range. 3. Podigee verifies the active show, episode, media, delivery setup, and request context. 4. The ad decision checks the available Campaigns, Creatives, schedule, targeting, pacing, frequency, rights, and publisher rules. 5. Podigee freezes one exact playback plan for the request. 6. Podigee combines the clean episode audio with each selected ad. 7. The delivery network returns the requested bytes. 8. Podigee records delivery observations. It qualifies commercial evidence only when the required delivery conditions are complete. The result can contain a paid ad, a house promotion, or no ad. The result depends on the eligible Campaigns and the fallback rule for the break. ## How progressive playback works Most podcast apps do not need the complete MP3 file before playback starts. They request an initial part of the file and request more parts as the listener continues. This is progressive playback. Podigee supports a complete request and a single byte-range request. It returns the exact content length and range information that the podcast app needs. A repeated or overlapping range does not create a second commercial result for the same qualified delivery evidence. The audio presentation stays fixed for its valid period. A later range from the same presentation cannot silently receive a different ad or a different episode version. ## How caching controls cost A content delivery network (CDN) stores reusable audio close to listeners. The stable enclosure URL is checked against the current delivery setup. After Podigee resolves the request, immutable source audio, Creative audio, and reusable presentation ranges can use shared caching. Podigee keeps listener context and private request data out of the shared cache. The cache can reuse the same verified bytes for common episode and ad combinations without making one listener's request visible to another listener. This separation gives Podigee two useful properties: * A show can keep one durable RSS enclosure route while its approved setup changes. * Common audio combinations can produce cache hits instead of a new origin transfer for each request. ## How chapters stay accurate Ad breaks are placed on the clean episode timeline. The **Break Canvas** shows the source audio, waveform, episode chapters, and exact break boundaries. ![The current One Podigee Break Canvas shows the selected episode and audio version, the audio player, the waveform, and the editorial chapter timeline.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-d87592de8f25200300b7a5485976461c8a430deb%2Fdoc-monetization-056-break-timeline.png?alt=media) *Set break positions against the exact clean episode version.* An inserted ad changes the duration that the listener hears. Podigee therefore derives a chapter map for the exact delivered presentation. It moves later chapter times by the inserted duration while it keeps each chapter tied to the correct point in the clean episode. If the episode audio or chapter data changes, Podigee requires current break and media authority before it publishes another exact presentation. ## How Podigee chooses an ad Each ad opportunity produces a recorded result and a customer-readable reason. Open **Monetization**, then open **Evidence & Money** and **Live ad delivery**. Select **Recent ad decisions** to filter by result, delivery method, privacy mode, name, episode, or reference. ![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) *Filter by Podcast audio to review decisions for RSS episode delivery.* ![The current One Podigee Recent ad decisions page is filtered to Podcast audio and shows selected RSS results with the Campaign, Creative, podcast, episode, reason, and delivery method.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-3a74a33197178ea144ec9389483fce00e46890dd%2Fdoc-monetization-151-rss-decisions-current.png?alt=media) *Use the Podcast audio filter when you investigate a dynamic RSS result.* A decision can report one of these common outcomes: | Result | Meaning | | ----------------------- | ----------------------------------------------------------------------------------- | | Ad selected | An eligible paid ad was selected for the slot. | | House ad selected | An eligible publisher promotion was selected. | | No ad selected | No eligible ad was available, or a delivery rule kept the slot empty. | | Original content played | Podigee used an approved clean fallback. | | Partially filled | A multi-slot break used some slots and followed the break rule for the other slots. | Open a decision to see the reason, Campaign, Creative, podcast, episode, break, privacy mode, and short reference values. The page also shows the qualified value when delivery evidence has met the commercial rule. ![The current One Podigee Ad decision details page shows a selected Podcast audio ad, its Campaign and Creative, the episode and break context, the qualified value, and shortened references.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-d9d28c2fbcd3d9e117208ed654ce670344de4240%2Fdoc-monetization-056-qualified-decision.png?alt=media) *Use the decision detail to connect one listener request to its content and revenue records.* ## How clean fallback works Podigee does not replace verified episode audio with an incomplete or mixed presentation. If no ad is eligible, it follows the break fallback rule. This rule can play the episode without an ad, use a house promotion, use the available ads, or reject a partially filled break. If a delivery setup cannot prove the required media, authority, or analytics binding, Podigee blocks activation or keeps the verified existing Podigee route in use. An active show can return to the verified existing route through the controlled recovery action. ## How analytics and qualified evidence differ An audio request is not automatically a paid impression. Podcast apps can retry, stop early, or request overlapping byte ranges. Podigee records the delivered ranges and joins them into one delivery history for the exact presentation. The audience analytics pipeline receives the listener observation for RSS audio. The commercial measurement rule then checks whether the required part of the Creative was delivered. Podigee creates qualified ad evidence only after that rule passes. Repeated observations do not create a second qualified event for the same evidence. This separation keeps audience reporting, Campaign delivery, and money evidence connected without treating every technical request as revenue. ## What to check as an operator Use these checks when you investigate RSS audio delivery: 1. Confirm that the show is live in **Monetization > Integrations > Podcast delivery**. 2. Confirm the current episode and break positions in **Inventory > Break Canvas**. 3. Filter **Recent ad decisions** by **Podcast audio**. 4. Open the exact decision and read the result and reason. 5. Confirm the Campaign, Creative, episode, break, and privacy mode. 6. Confirm the qualified value when you investigate billed delivery. 7. Use the recovery action if the active show must return to existing Podigee delivery. ## Expected result The listener keeps the same podcast subscription and episode identity. Podigee selects an eligible audio result, serves one consistent presentation through progressive MP3 delivery, preserves the chapter timeline, uses safe caching, and connects qualified delivery evidence to analytics and revenue records. --- # 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/understand-dynamic-ad-delivery-in-rss-audio.md?ask=&goal= ``` `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.