IAB Tech Lab released version 2.3 of its Podcast Technical Measurement Guidelines for public comment on July 21, 2026, extending the framework that governs how downloads and ad delivery are counted to cover video podcast episodes distributed through open RSS feeds. Comments close on August 19, 2026.

The 32-page draft resolves an ambiguity that has sat inside podcast trading for several years. Audio episodes have long been measured through server log analysis, filtered against published rules. Video episodes travelling through the same distribution pipes occupied an undefined space.

For the avoidance of doubt, the document states, the guidelines apply to both audio and video podcast episodes when distributed via open RSS feeds or podcast applications that rely on server-side file delivery. Video podcasts delivered as MP4 files or through segmented streaming formats such as HTTP Live Streaming are subject to the same measurement principles, filtering requirements, and metric definitions.

An MP4 episode pulled through an RSS enclosure now has to clear the same one-minute content threshold, survive the same invalid traffic filters, and be de-duplicated by the same IP-plus-user-agent logic that has applied to MP3 files since the framework's first release in September 2016.

What changed in version 2.3

The draft lists six substantive updates against version 2.2. The first is the video scope clarification. The second replaces the word listener with podcast consumer throughout, covering both audio listeners and video viewers under one metric name.

According to IAB Tech Lab, that terminology shift is not cosmetic. The change of terminology lays a foundation that will be built on in 2027 with the v3.0 guideline focusing on the growth area of streaming video podcasts, the organisation stated. Version 3.0 is currently in development by the Podcast Technical Working Group.

Four further additions address measurement mechanics. Section 5.2 now describes the prefix URL redirect method and its role in producing discrepancies, and documents how enclosure URLs in RSS feed servers affect measurement. Section 5.4 sets out common fraudulent activity types alongside existing standards for assessing anomalies that may turn out to be legitimate. Section 5.5.1 defines three distinct measurement window types and works through a numeric example showing how each produces a different count from identical server log data.

Anthony Katsur, chief executive of IAB Tech Lab, framed the release around counting consistency. "Measurement only works if everyone is counting the same way," Katsur said. "These updates give the industry clearer guidance for today's podcast ecosystem and help reduce the inconsistencies that slow deals down and create unnecessary questions. That is good for buyers, publishers, and everyone responsible for reporting the numbers."

Three measurement windows, three different answers

The most technically consequential addition may be section 5.5.1. Version 2.2 referenced a rolling 24-hour window compared against a calendar day window, but the draft acknowledges that the difference was never stated clearly, and that two separate interpretations of the word rolling existed in the market.

Version 2.3 names all three. A calendar day (fixed) measurement window resets at a fixed time, for example midnight UTC. Requests falling on the same calendar day are not counted as new downloads, while a request on the following calendar day counts as unique.

A first touch rolling measurement window begins at the timestamp of a qualifying download request, identified by IP address and user agent, and typically runs 24 hours. Subsequent requests from that source are evaluated against that fixed start point.

A last touch rolling measurement window extends and resets each time a subsequent request arrives inside the period. A request landing within the window does not count and pushes the window forward; one arriving after it counts as unique and starts a new window.

The document illustrates the divergence with four requests from one IP and user agent. A download at 10:00 PM Monday counts once under all three methods. A second at 3:00 AM Tuesday counts under the calendar method, because the date changed, but under neither rolling method. A third at 10:15 PM Tuesday counts only under first touch, because more than 24 hours have elapsed since the Monday timestamp. A fourth at 11:15 PM Wednesday counts under all three.

Same log file, same consumer, three published totals. The draft states that choice of windowing algorithm provides flexibility for systems that do not align with fixed calendar boundaries, and that implementers must apply the rolling logic consistently to produce comparable results. For buyers reconciling numbers across platforms, a publisher reporting a higher figure than a third-party vendor may simply be using a different window definition, not a different filtering standard.

The prefix redirect problem

Section 5.2 documents a structural limitation in prefix-based measurement, the method used by third-party vendors that append a tracking domain to the front of an episode URL. The draft maps the request path across six steps: the device requests the prefixed URL, the redirect platform logs it without storing the media file, the device is redirected to the host server, the host records what it sends, and the file is delivered.

The failure mode sits at step three. After the redirect, depending on device and player behaviour, subsequent partial requests may bypass the prefix and request the remainder of the file directly from the hosting platform. The redirect measurement platform then never sees those requests or the bytes requested, which the document identifies as a challenge in consistently confirming that the first minute of content has been requested.

That first minute is the qualifying threshold for a valid download. A vendor unable to observe it has to estimate. The draft notes that a prefix measurement vendor may not be able to discern how much of the file was downloaded because it cannot directly gather byte data, and that results will vary from measurement using filtered server log data including bytes served.

Enclosure URL changes trigger phantom downloads

Section 5.3 addresses a related issue with commercial consequences. The enclosure URL in an RSS feed points to the episode media file, and some podcast players interpret a changed URL as a new episode. The result is a re-download of content the consumer already has. The draft gives a concrete example: switching from //hostingplatform.com/123.mp3 to //prefixplatform.com/123.mp3 can trigger a fresh download. Those re-downloads register as duplicated events across both the prefix and hosting platforms, which the document says can skew campaign reporting. Each subsequent URL change, including reverting to a previous prefix, can trigger another round.

The stated best practice is to avoid changing episode GUIDs during hosting changes, and where possible to leave episode titles and publication dates alone, because different podcast applications use different heuristics for deciding whether an episode matches one already encountered.

Invalid traffic and the limits of disclosure

Section 5.4 splits invalid traffic into General Invalid Traffic and Sophisticated Invalid Traffic. GIVT covers crawlers, known data centres, pre-fetching, and routine practices filterable with common technology. SIVT is built to resemble human traffic, generated through hijacked devices, bots mimicking human behaviour, or data manipulation.

The draft is explicit about what it will not publish. The public version will not offer specific guidance on what to filter, because the organisations generating that traffic might use the guidance to adjust their strategies. Measurement organisations are instead directed to look for anomalies and address them.

On fabricated inventory the language is blunt. Operations set up to fabricate traffic sell inventory never exposed to humans, and the draft describes that as fraudulent regardless of implementation. It also identifies a diagnostic signal: such campaigns are almost completely ineffective, so effectiveness measured on reach alone might look promising while conversions or return on investment produce little to nothing.

Section 5.4.1 pushes the other way, warning that not all anomalies are fraudulent and that legitimate consumer behaviour or platform quirks can be mistaken for invalid traffic, producing undercounting and inconsistent audience metrics.

The mandatory filter list in step 1.2 runs to seven items, covering implausible download volumes from one IP address, traffic from known bots, data centres, and VPNs, erroneous referrer data, malformed user agents, self-identifying bots, two-byte range requests used to test byte-range support, and duplicates on paired Apple Watch devices. Known safe IP addresses, such as dormitories and corporate networks, sit on an inclusion list that must be re-validated at least every 90 days.

Section 5.4.2 assigns a share of the responsibility to player platforms, describing them as often best positioned to support anti-fraud practices because they control the environment where files are requested, downloaded, cached, and consumed. Publishers, hosting providers, measurement vendors, and buyers are pointed toward ads.txt and app-ads.txt for seller transparency and Open Measurement for client-side verification.

The counting rules that survive unchanged

Several core mechanics carry over. A valid download still requires header information plus enough content to play for one minute, a threshold the document describes as conservative relative to other media. Where an episode runs shorter than a minute, or where file and ID3 tag sizes cannot be computed regularly, complete file downloads at 100 percent are used instead.

HTTP handling remains specific. HEAD requests are excluded because no data transfers. A 200 response outside an HLS context counts. A 206 partial response or a 200 inside an HLS context counts only if the download covers the one-minute rule, with de-duplication on IP and user agent to handle consumers skipping ahead. A 304 response is excluded. The draft also flags Akamai's use of HTTP code 000 for 206 requests ending prematurely.

Unique identification still rests on IP address plus user agent. The document gives a worked case: an episode downloaded 10 times by six user agents behind one IP address within a 24-hour window counts as six podcast consumers and six downloads. IPv6 addresses are truncated to their first 64 bits before calculation, because they cycle rapidly on a single device and would otherwise inflate metrics and disrupt frequency capping.

Ad Delivered requires either all bytes of the ad file to have been sent, or the bytes representing the portion of the episode containing it. An ad inside the first 25 percent of an episode counts when at least 25 percent was downloaded. Dynamically inserted ads require 100 percent of the ad content. An ad inside a download that never reached one full minute cannot be counted as valid even when the ad itself downloaded completely.

Differences within plus or minus 5 percent between certified vendors, assuming alignment on date range, geography, and show selection, are generally considered acceptable. Larger gaps may warrant investigation.

The Apple Watch case study

Section 8 keeps a worked example of technology change breaking measurement. In 2020, Apple Watch altered the metadata conventions in its user agent, disrupting the ability of metrics providers to filter duplicate downloads. Compliant companies noticed the resulting spike and raised it with IAB Tech Lab, which issued an addendum requiring filtering of user agents beginning with atc/ and containing watchOS. The label changed again, prompting a second addendum covering user agents containing (null)/(null) watchOS.

Apple Watch subsequently became capable of downloading episodes independently of a paired device, which means some filtered downloads are unique rather than duplicated. The document acknowledges the tension: Apple Watch downloads still represent a significant amount of duplication, so guidance continues to require filtering them out, with a new addendum promised should the methodology change.

Who built it and who signed on

The Podcast Technical Working Group developed version 2.3 in partnership with the IAB Audio Committee. Brad Pipkin, Director of Product for Advanced TV, is listed as the Tech Lab lead.

The contributor roster spans roughly 80 member companies across most of the podcast supply chain. Hosting and distribution platforms include Acast, Libsyn, Omny Studio, Spreaker, and Triton Digital. Publishers and networks include NPR, ESPN, NBCUniversal, Paramount, Warner Bros. Discovery, The New York Times Company, and News UK. Measurement and verification firms include Nielsen, DoubleVerify, Podtrac, Podscribe, Magellan AI, and Veritonic. Demand-side participants include Google LLC, The Trade Desk, StackAdapt, TripleLift, Nexxen, Publicis Media, and GroupM US. Spotify, SiriusXM Media, iHeartMedia, and Audacy also appear.

Hugo Martel, senior vice president for podcast and content delivery at Triton Digital, addressed the video component. "Server-side log data remains the backbone of podcast measurement, and these updates reflect the continued evolution of the medium," Martel said. "Clearer guidance for video podcast measurement is a welcome addition, helping the industry adapt as podcast consumption expands across formats while giving publishers and advertisers greater confidence in the insights they rely on."

Robert Freeland, founder and chief technology officer of Podtrac, tied the update to trading practice. "Our industry depends on trusted measurement that everyone can understand and apply consistently," Freeland said. "These updates help bring that consistency."

Why this matters for media buyers

The commercial backdrop makes the timing legible. Podcast advertising spending grew 26% year-over-year in the third quarter of 2025, with 1,689 brands entering the channel for the first time, and Q4 2025 growth reached 32%. December 2025 set a single-month record of $408 million.

Confidence in the numbers has lagged the money. Bauer Media Audio research found that only 13% of advertisers confidently use audio attribution tools while 73% said stronger effectiveness evidence would raise their investment. A separate survey found downloads and listens tracked by 61.2% of podcast marketers, with direct sales or revenue attribution measured by just 20.4%.

The video question is where version 2.3 lands hardest. Apple announced HLS video podcast infrastructure with dynamic ad insertion in February 2026, entering a market where Spotify and YouTube already operate at scale. Audioboom disclosed audio revenue per thousand downloads of roughly $71 against video rates below half that figure.

Standardisation efforts have been arriving from several directions at once. Spotify redefined its podcast play metric on June 11, 2026, requiring at least 30 seconds of listening or watching, aligned with a definition published by the Alliance for Measurement in Podcasting. Version 2.3 addresses a different layer: not what counts as a play, but what counts as a delivered download and ad in server logs.

The comment structure matches the pattern IAB Tech Lab has used through 2026. The Content Monetization Protocol ran from March 10 to April 9. Bot and crawler management guidance ran from May 27 to June 25. The Programmatic Auction Definitions document ran from January 29 to February 27 before finalisation on June 26. Thirty days is the standard interval.

One inconsistency sits inside the source material. The announcement and the IAB Tech Lab standards page both state that the comment period runs 30 days until August 19, 2026. The cover page of the draft document itself asks for feedback by August 21, 2026. The two dates differ by two days, and the draft does not reconcile them.

Compliance details sit outside the guidelines themselves, in the Tech Lab Podcast Compliance Program. Because the working group defines the guidelines and many member companies go through certification, the document notes, the program must be defined separately to gain buyer trust. Certified providers must self-audit and report methodology in a corporate document at least twice a year.

Timeline

Summary

Who: IAB Tech Lab, through its Podcast Technical Working Group in partnership with the IAB Audio Committee, with Brad Pipkin as Tech Lab lead and roughly 80 contributing member companies including Spotify, Triton Digital, Nielsen, NPR, Google LLC, The Trade Desk, Podtrac, and Warner Bros. Discovery. Anthony Katsur, Hugo Martel, and Robert Freeland provided statements.

What: Version 2.3 of the Podcast Technical Measurement Guidelines, a 32-page draft that extends download, audience, and ad delivery measurement rules to video podcast episodes distributed via open RSS feeds, replaces the term listener with podcast consumer, defines three measurement window types, documents prefix URL redirect and RSS enclosure URL effects on counting, and expands invalid traffic guidance.

When: Released July 21, 2026. The announcement and the Tech Lab standards page state a 30-day comment period closing August 19, 2026, while the draft cover page states August 21, 2026. Version 3.0 is planned for 2027.

Where: Published by IAB Tech Lab, headquartered in New York, on its standards website, with comments directed to the organisation's support address.

Why: Most podcast applications still provide no client-side playback confirmation, leaving server log analysis as the basis for counting. Video podcast distribution through RSS grew without explicit measurement guidance, and inconsistent handling of prefix redirects, URL changes, and measurement windows produced discrepancies between publishers and third-party vendors that complicate trading.