Podcast Measurement Counts Downloads. VAST Counts Events. Version 2.3 Sharpens One and Leaves the Other Alone.

Two counting systems, one ad break

IAB Tech Lab released version 2.3 of the Podcast Technical Measurement Guidelines on 21 July 2026, with a 30 day public comment window that closes on 19 August. The guidelines are the reason podcast numbers from different measurement vendors can be compared at all, and the reason they exist in their current form is a constraint that has not moved in a decade: most podcast applications never tell the server whether anyone played the file. There is no client to ask. So the industry counts what the server can see, which is a request for bytes.

That approach is stated plainly in the release. Server side log analysis remains the backbone, because client side playback confirmation is not available across the open RSS ecosystem. Everything downstream follows from it. A download is inferred from a byte threshold rather than observed from a player, duplicates are collapsed inside a time window, and known invalid traffic is filtered by list rather than by behaviour.

Now look at the ad inside that episode. If it was trafficked programmatically, it arrived as a VAST document, because DAAST was deprecated and folded into VAST 4.1 in 2018 and audio has been a first class media type in VAST ever since. VAST counts differently. It counts an impression when a client fires a pixel, a start when playback begins, quartiles as the ad progresses, and a complete when it ends. Every one of those numbers comes from a player that decided to make an HTTP request.

So the same ad break is measured twice, by two systems, with two definitions of the event, and nothing in either specification reconciles them. None of that is new. Version 2.3 adds a clause that makes the gap visible to people who had never had to think about it.

What version 2.3 actually changes

• Listener is replaced with podcast consumer throughout, which is terminology cleanup with a real consequence: the metric was never a person, and calling it one invited comparisons to audience measurement that the method does not support.
• New guidance on measuring streaming video podcasts, the distribution path where a real player exists and the download model stops describing what happened.
• Updated guidance for URL prefix measurement and for changes to RSS enclosure URLs, the two places where a measurement vendor sits between the feed and the file.
• Expanded invalid traffic considerations, which in a log based system means better heuristics rather than better observation.
• Clearer application of the different measurement window approaches, so two vendors counting the same episode over different windows can at least say so.
• Improved handling of duplicate downloads and platform driven anomalies, the category that covers prefetching, retries and aggressive caching by large podcast apps.
• Version 3.0 is already in development and is aimed at streaming video podcasts, targeted for 2027.

The video podcast clause is the one that touches VAST

An audio podcast delivered over open RSS has no player to instrument, which is why the download model exists. A video podcast on a streaming platform, a CTV app or a video service has one. It has a player, a playback timeline, and in most cases an ad serving stack that already speaks VAST. The same show, the same episode, sometimes the same ad, is measured as a download on one path and as a VAST impression with quartiles on the other.

That divergence has a predictable outcome for anyone selling across both. The numbers will not match, and the mismatch will be attributed to measurement methodology, because measurement methodology is the visible difference. Some of it genuinely is methodology. A download counted at a byte threshold and an impression counted at a fired pixel are different events and will never produce the same number, no matter how clean the plumbing.

A meaningful share of the gap comes from somewhere else entirely: tags that do not fire. The download side cannot detect that, because the download was counted before the ad ever ran. The VAST side can, and can do it before the campaign starts rather than after the discrepancy report lands.

What that document gets wrong in practice

Audio ad tags accumulate a specific set of defects, and they persist longer than video defects do because nobody is watching a screen when they happen. A broken video ad produces a black frame somebody notices. A broken audio ad produces silence, or the previous segment continuing, and the listener assumes the episode simply had no ad.

The MediaFile element is the usual site. VAST requires a media type on it, and an audio creative served with a video mime type, or with no type at all, will be skipped by a player that filters on type before it downloads anything. Dynamic insertion platforms that transcode on the fly are particularly good at emitting the wrong one, because the transcode target and the declared type are set in different parts of the pipeline.

Duration is the second. It is a required element on a Linear creative, it has a fixed HH:MM:SS format, and an ad server that emits a bare number of seconds produces a document that fails to parse in strict players and silently rounds in permissive ones. In audio that error is invisible until a reconciliation two weeks later shows a completion rate that cannot be right.

Then the trackers themselves. Mixed content, HTTP tracking URLs on an HTTPS delivery path, unencoded macros, and wrapper chains that resolve to an endpoint returning an HTML error page with a 200 status. All of those are ordinary VAST failures. None of them are audio specific. All of them are more expensive in audio because the feedback loop that would surface them does not exist.

What a parser settles on an audio tag, before anything plays

• Whether the response is well formed XML at all, or an error page with a success status, which remains the single most common thing a working looking ad tag endpoint returns.
• Whether the declared VAST version on the root element matches the elements actually used, including DAAST era markup that survived a migration and now sits in a document claiming 4.x.
• Whether every Linear creative carries a Duration in HH:MM:SS form rather than a bare integer or an empty element.
• Whether MediaFile carries a type attribute, and whether that type is an audio type consistent with what the CDN actually serves.
• Whether the tracking event set is complete enough to support the reporting the buyer was sold, which is the check that matters when the download side of the ledger cannot corroborate anything.
• Whether every tracking and impression URL is HTTPS and macro correct, and whether wrapper chains terminate within a sane depth rather than looping.
• Whether an ad pod or VMAP structure declares breaks that a dynamic insertion platform can actually fill at the offsets it names.

The reconciliation you can actually do

You cannot make a download equal an impression. The two definitions are not convertible, and version 2.3 does not pretend otherwise: the guidance is that everyone counts the same way, not that the counts converge across methods. Anthony Katsur put the goal as measurement only working at scale if everyone is counting the same way, which is a statement about consistency inside a method rather than agreement across methods.

What you can do is remove the variable that is not methodology. If the VAST tag is valid, the discrepancy between the log count and the event count is explained by the difference in definitions, and that is a conversation both sides can have with numbers. If the VAST tag is broken, the discrepancy is explained by the tag, and no amount of methodology discussion will find it, because the log side has no visibility into whether the ad played and the event side is reporting the absence of events as if it were the absence of listeners.

So the case for validating audio tags has nothing to do with audio being complicated. It is the simplest surface VAST supports. It is also the only one where no other part of the stack will raise its hand.

Before 19 August

The comment window closes on 19 August 2026, and the constituency most likely to skip it is the one that traffics the ads rather than the one that counts the episodes. That is a shame, because the video podcast section is where a technical comment would land best. A guideline that describes how to measure a streaming video podcast is describing an environment with a player in it, and once there is a player there is a VAST document, and once there is a VAST document the question of whether it fired is answerable rather than inferred.

If you run audio inventory, the useful thing to do this month is smaller than a comment letter. Take the tags you are already serving, run them through a parser, and find out how many of them would have been caught by a check nobody was running.