IAB podcast measurement guidelines v2.3
Open a source-aware analysis with this article as the primary source.
Add us to your Preferred Sources.
IAB podcast measurement guidelines v2.3 now state that the server-log framework covers video episodes distributed through open RSS feeds or podcast apps that use server-side file delivery. It does not turn every video view into an IAB-style podcast download. Hosts and networks need to separate eligible delivery paths from closed-platform playback before combining audio and video inventory in a sponsor report.
The update also explains why prefix reports can differ from host logs, how enclosure URL changes can create duplicate requests, and how different measurement windows affect counts. Those details deserve a reporting check before anyone compares a new video total with an older audio baseline.
What IAB podcast measurement guidelines v2.3 cover
The primary v2.3 guidelines define their scope as downloaded and progressively downloaded podcast episodes. The document now says those principles apply to audio and video delivered through open RSS or podcast applications that rely on server-side file delivery. It includes MP4 delivery and segmented formats such as HLS when they move through those podcast distribution mechanisms.
True streaming sits outside that scope. A video play inside a closed platform may use client-side signals and a different measurement standard. Classify the metric by its delivery method rather than by whether the episode has a picture.
A network cannot put an RSS-delivered video request and a closed-platform view in one column, label the sum "IAB downloads," and preserve a useful definition. Keep the platform view in its own row with the platform's metric name. Put that boundary in writing.
The immediate video reporting check
Ask your host or network to map each video path before the next sponsor report. Start with the delivery path.
| Delivery path | What to verify | Reporting treatment |
|---|---|---|
| Open RSS media file | Server logs, filtering, file threshold, deduplication | May fit the v2.3 framework |
| Podcast app using server-side file delivery | Which server records the request and response | May fit when the guideline process is applied |
| Closed video platform | Native view or playback definition | Report separately under the platform's definition |
| Embedded or owned player | Progressive download or true streaming | Classify from the actual delivery method |
Do not infer the answer from the word "video" in a dashboard. Ask where the media request went, which server recorded it, and whether the provider can apply the same filtering and threshold rules used for podcast delivery.
For the audio side of the report, how to measure podcast downloads covers the difference between a media request and a filtered download.
Prefixes and enclosure URLs can break the comparison
Version 2.3 describes the redirect path used by measurement prefixes. A prefix can record the initial request, then redirect the device to the host that serves the media. Later partial requests may go straight to the host, so the prefix provider and hosting platform can observe different parts of the same delivery.
The guidelines also warn that changing an episode's enclosure URL can prompt some podcast apps to download the episode again. Adding, removing, or replacing a prefix changes that URL. The resulting requests can inflate a before-and-after comparison even when the editorial file has not changed.
Record the date and exact URL whenever you change a video enclosure or redirect chain. Keep episode GUIDs stable, then annotate the reporting period. If counts jump on the change date, investigate requests and player behavior before crediting the video format.
A prefix is still useful, but it measures a particular point in the request chain. The podcast analytics guide explains how to keep host, prefix, and app-level evidence in separate lanes.
Count windows need a label
V2.3 spells out three ways to deduplicate qualifying requests: a fixed calendar-day window, a first-touch rolling window, and a last-touch rolling window. The methods can produce different totals from the same request sequence.
That does not make one dashboard wrong by default. It means a report needs the method next to the result. Ask the provider which window it applies, when the window resets, and whether the method is consistent across the audio and video rows you want to compare.
The same discipline applies to advertising. A served ad is a server-side delivery observation, not proof that a person watched or heard the whole placement. Ad impression measurement should remain distinct from client-confirmed playback or a conversion reported by the sponsor.
What to ask your provider now
Send these questions to the person who owns hosting or monetization reporting:
- Which video delivery paths are included in the podcast download and ad-delivery reports?
- Which paths are excluded because they use closed-platform or true-streaming measurement?
- Did any video launch change enclosure URLs, prefixes, redirects, episode GUIDs, titles, or publication dates?
- Which fixed or rolling window is used to deduplicate requests?
- Are audio and video filtered with the same invalid-traffic and file-threshold rules?
- Can the report preserve the original metric names instead of combining unlike counts?
Save the answers with the campaign report. A sponsor can then see which inventory followed the v2.3 server-log framework and which inventory came from a platform's own playback system.
Use Podder Analytics to monitor cross-app delivery trends, and keep closed-platform video metrics in their native reports. Compare them as separate evidence, not as one unlabeled total.
See who's actually listening.
Podder gives you audience demographics, per-episode analytics, and chart tracking. The Chartable alternative that goes deeper.
Start free