IAB Tech Lab today released the final version of v2.3 of its Podcast Technical Measurement Guidelines, the framework that sets out how podcast downloads, audiences and ad deliveries are tallied from server logs, according to a post by Brad Pipkin, the organisation's Director of Product for Advanced TV. The text now sits on GitHub after a comment period in which no comments required changes, and a version 3.0 aimed at measurement beyond downloads is planned for public comment in the middle of 2027.

In Short

IAB Tech Lab today published the final edition of the rulebook that tells the podcast industry how to count downloads and ad deliveries, and the rulebook now applies to video episodes as well as audio ones. The counts feed what advertisers are told they bought and what publishers report, so a shared definition touches both sides of every podcast ad sale. The method stays tied to server logs for now, and a next edition, due for public comment in mid-2027, is meant to look at what happens after a file has been downloaded.

What the final release contains

According to IAB Tech Lab, the release follows a public comment period in which "no comments required changes to the document," and the text has moved to GitHub to make it easier to find and to manage. PPC Land covered the draft, which IAB Tech Lab opened for comment on July 21, 2026, with a window running to August 19, 2026.

The file now lives in the IABTechLab/Podcast-Technical-Measurement repository as PTM-Guidelines_v2.3.md. The GitHub page lists 636 lines and 62.7 KB, with the latest commit, labelled ee49280, made from an account carrying Pipkin's name. The guidelines themselves supply the edition history: a first version in September 2016, version 2.0 in December 2017 and version 2.1 in 2021, the last adding a section on user agent structure, IPv6 recommendations, filtering for Apple watchOS user agents and further player recommendations. Neither IAB Tech Lab document dates version 2.2, although Triton Digital's Podcast Metrics service, for one, carries certification against it.

Section 1.3 of the guidelines lists six changes for this edition. The text now states that it covers video distributed through open RSS feeds or podcast applications that rely on server-side file delivery. The word "listener" gives way to "podcast consumer", a label meant to cover the listeners of audio and the viewers of video. New passages describe the URL prefix redirect method, explain how changes to an enclosure URL affect measurement, catalogue common types of fraudulent activity alongside existing standards for judging anomalies that may prove legitimate, and define three measurement window types with worked examples.

Where the document disagrees with itself

The text is not fully consistent with its own change list. Section 1.3 places the enclosure URL material in section 5.2, whereas the body and the table of contents number it 5.3. Step 1.3 of the filtering process refers to a one-minute rule "defined in 1.2 above," although the threshold appears in step 1.1 and again in step 2, and step 1.2 deals with bots. The swap of terms is also partial: the audience metric in section 6 is still labelled "Podcast Consumer/Listener". None of this alters a calculation, but each is a point where a reader following the text by cross-reference can end up in the wrong place.

A fourth point concerns numbers rather than numbering. The executive summary says podcast ad revenues were expected to reach over $4 billion in 2025, more than double the 2022 total, citing an IAB study conducted by PwC US and posted in May 2023. PPC Land reported that US podcast advertising reached $2.9 billion in 2025, a rise of 17.6 percent, in the IAB and PwC annual report of April 16, 2026 - more than $1.1 billion below the earlier projection. The two figures come from different IAB and PwC publications, and neither attached document reconciles them.

Scope: what a download can show and where the framework stops

Podcast measurement rests on an unusual foundation. Delivery typically runs through server-side file delivery rather than an open connection between device and server, so client-side playback data is, according to IAB Tech Lab, "usually limited, inconsistent, or unavailable". Files described as streamed are, according to the guidelines, progressively downloaded over standard HTTP and appear in server logs exactly as a downloaded file does. Aggregator apps such as Apple Podcasts and Spotify typically send no playback data to publishers. Host-branded players can, but the guidelines note that most consumers prefer the aggregators.

What a log line offers is modest. The guidelines list seven data points: the IP address, a time stamp, an HTTP status code, bytes served (available only in native server logs), the referrer, the user agent and the byte range. A low byte range can signal a pre-download, which is excluded from valid counts.

Video episodes delivered as MP4 files, or through segmented streaming formats such as HTTP Live Streaming (HLS), fall under the same measurement principles, filtering requirements and metric definitions, unless the text says otherwise. The guidelines class HLS delivery as a form of progressive download. Apple unveiled HLS video podcasts with dynamic ad insertion on February 16, 2026, which gives the clarification a commercial setting.

The boundary of the framework is drawn just as explicitly. True streaming, where a beacon from the client device reports delivery in real time, sits outside it. Such implementations generally do not support impression-level viewability metrics, according to the guidelines, though they allow validated counting of consumption sessions, and the text points to the Media Rating Council Audio Measurement Guidelines of January 2018 for true streaming audio. IAB Tech Lab expects to address these delivery methods more directly in later versions. The same boundary leaves out video played inside platforms that do not use an open feed: PPC Land noted that episodes distributed inside Netflix travel neither through an open RSS feed nor through a host's own server, which places them outside version 2.3.

Two families of ad are distinguished. Baked-in ads, read by a host or included as a jingle, ship inside the episode file and reach everyone who downloads it, with limited targeting. Dynamically inserted ads are chosen by an ad server when the episode is requested, and in a progressively downloaded file they may be placed at designated breaks. Sponsorships can take either form.

From server log to countable download

The guidelines prescribe five steps: filter the logs, apply a file threshold, identify and aggregate uniques, generate metrics, and audit the process. Most of the technical detail sits in the first three.

Filtering

Filtering begins with pre-loads, which register downloads that no person requested. The text offers three remedies: a policy against pre-loading in players and on websites (preload=none in HTML5 is the example), a download threshold based on one minute of content, and a search of log data for evidence of pre-loading, followed by contact with the business responsible.

A second pass removes bots and bogus requests. Metrics providers must filter seven categories: IP addresses responsible for an unrealistic volume of downloads; addresses tied to known bots, data centres or VPN traffic; erroneous referrer data; malformed user agents; self-identifying bots; two-byte range requests (Range: 0-1) that apps use to test whether byte-range requests work; and duplicates from paired Apple Watch devices. The malformed-agent example is precise: a legitimate Firefox version is 55.0.2, while a bogus agent could read 55.02, missing a single separator. Known safe addresses, such as dormitories and corporate networks, go on an inclusion list that must be re-validated at least every 90 days.

Status codes then decide what survives. HEAD requests are excluded because no data moves. A 200 response outside an HLS context counts. A 206 partial response, or a 200 inside an HLS context, counts only when the download covers the one-minute rule, after de-duplication on IP address and user agent to handle consumers who skip ahead; this may require reassembling requests. A 304 is excluded, and Akamai's use of code 000 for prematurely ended 206 requests is flagged as a platform quirk.

Thresholds and uniques

A valid download needs header information plus enough content to play for one minute, a threshold the text calls conservative against other media. Because ID3 tag size varies, the guidelines recommend that each publisher measure it per show and recalculate when artwork changes. Episodes shorter than a minute, or cases where sizes cannot be computed regularly, fall back to complete file downloads.

Uniques are identified by IP address plus user agent. In the document's example, one episode downloaded 10 times by six user agents behind one address within 24 hours yields six podcast consumers and six downloads. Additional metadata, such as a user ID, cookie or playback session ID, may refine the result if disclosed. IPv6 addresses, which cycle rapidly on a single device, are truncated to their first 64 bits, and either address form may be hashed for privacy. A play-pause-play sequence split across several file requests counts as one download.

How sturdy is an identifier built on an IP address? The guidelines concede the weakness, describing mobile consumers whose addresses change as "IP-hopping" and noting that recycled addresses can undercount. A Stanford study covered by PPC Land found that 5 percent of IP addresses send 55 percent of web requests and that client operating systems rotate IPv6 addresses at most every 24 hours by default.

Audit and tolerance

Metrics providers must self-audit the whole process and report it in a corporate document of methodology at least twice a year, investigating uncharacteristic spikes or drops. Even certified vendors are expected to differ slightly. Gaps within plus or minus 5 percent, assuming alignment on date range, geography and show selection, are generally acceptable, and larger gaps may warrant investigation.

Three windows, and what the worked example adds up to

Version 2.2 referred to a rolling 24-hour window as compared with a calendar day, but, according to the guidelines, the difference was never stated clearly and there were two readings of "rolling". Version 2.3 names three. A calendar daywindow resets at a fixed time, such as 12:00am UTC, and requests on the same day are not counted again. A first touchwindow starts at a qualifying request, identified by IP address and user agent, and typically runs 24 hours. A last touchwindow extends and resets whenever a further request lands inside the period.

The document works one consumer through four requests, and the table below reproduces its counts.

RequestCalendar dayFirst touchLast touch
1) 10:00 PM Monday111
2) 3:00 AM Tuesday100
3) 10:15 PM Tuesday010
4) 11:15 PM Wednesday111
Total counted332

The totals row is not in the source. Summed from the document's own figures, the calendar and first touch columns each reach three and the last touch column reaches two: two distinct totals, three different patterns of which requests count. The source table labels its last two columns "Rolling" and "Extending", while the text calls them first touch and last touch. Implementers must apply whichever logic they choose consistently, according to the guidelines, which describe the choice as useful for systems that do not align with fixed calendar boundaries.

Fraud, anomalies and the platform question

Downloads generated by bots or other systems that no human will consume count as invalid traffic. The guidelines split it into two groups. General invalid traffic comes from crawlers, known data centres and pre-fetching, and can be filtered with common technology. Sophisticated invalid traffic is built to look human, using hijacked devices, imitation bots or manipulated data. The public version of the text declines to say what to filter for the second group, on the reasoning that the organisations producing that traffic might adjust their tactics, and instead directs measurement companies to look for anomalies. One diagnostic is offered: campaigns bought on fabricated traffic tend to look promising on reach alone and produce little on conversions or return on investment.

Section 5.4.1 pushes the other way, warning that legitimate behaviour and platform quirks can be mistaken for invalid traffic, producing undercounting. Section 5.4.2 turns to the players. Platforms that control the environment in which files are requested, downloaded, cached and consumed are, according to the guidelines, often best placed to support anti-fraud practices. Publishers, hosting providers, measurement vendors and buyers are pointed towards working with them on which verification signals are supported, with the caveat that support varies by app, device, playback model and business relationship. The document names ads.txt and app-ads.txt for authorised seller transparency and Open Measurement for supported client-side verification.

The guidelines keep a case study on how a platform change can distort logs. In 2020 Apple Watch altered the metadata in its user agent, defeating duplicate filtering and producing a spike that compliant companies noticed and reported. An addendum required filtering user agents beginning with atc/ and containing watchOS, and a later label change brought a second addendum for (null)/(null) watchOS. The watch can now download episodes independently of a paired phone, so some filtered downloads may be unique. Telling the two cases apart remains hard, so filtering continues, with a new addendum promised should the method change.

Metrics, and the signal the format lacks

The metric definitions are short. A download is a unique episode request that results in an episode being delivered to the podcast consumer's device, complete or partial under the filtering rules. The audience metric is a count of unique IP and user agent pairs, using the full IPv4 address or the 64-bit IPv6 prefix, within a stated time frame; shorter frames give better results, the text notes, and the frame must be disclosed to customers.

Ad Delivered rests on filtered logs for validated downloads showing that either all bytes of the ad file or the bytes covering the ad's position in the episode were sent. An ad in the first 25 percent of an episode counts when at least 25 percent was downloaded. A dynamically inserted ad needs all of its bytes. An ad inside a download that never reached one full minute cannot count even if the ad file arrived whole.

Client-Confirmed Ad Play is different in kind: it counts an ad that prompted a tracking beacon from the client device, ideally with markers at start, 25, 50, 75 and 100 percent. The guidelines call it the most accurate count for ad plays but observe that the platforms used to download, store and play podcasts often lack or prevent client-side metrics. IAB Tech Lab says it will keep working with player platforms to gain more access to those signals. Pipkin's post makes the same distinction plainly, stating that "A download is not the same thing as a confirmed play".

Where no consumer ID exists, metrics above episode level can be built in two ways: by summing across episodes, which suits a total of unique downloads but ignores audience overlap, or by tracking IP address and user agent, which gives a better view of the consumer base at the cost of the address problems described above.

Recommendations for player makers

Section 7 addresses companies that supply players, and its list is specific. The recommendations are to avoid auto-play except where consumer intent is implied; to avoid pre-loading unless the intent to play is clear; to use header information at the start of the file to prevent unnecessary full downloads; to request a full download as one whole file but a progressive download in slices larger than two bytes, so the two can be told apart; not to modify the enclosure URL or add parameters; not to cache episodes on the player's own servers; to use the GUID rather than URL, title or publication date to identify new episodes; to stop auto-downloading after a run of unplayed episodes; not to download entire back catalogues by default; and to send enough detail in the user agent header to tell devices apart.

The suggested user agent pattern is app name and version, device information, operating system name and version, and other information, with AppName/1.2.3 DeviceBrand DeviceModel OSName/1.2.3 LibName/1.2.3 as the example. The guidelines advise against injecting user or session IDs into the string, ask platforms to submit their headers to the IAB Tech Lab Spiders and Bots inclusion list, and say that indexing bots should carry the word "bot". The stakes are stated bluntly: where these practices are not followed, measurement companies may discount all traffic from an app or site because true downloads or plays cannot be discerned.

The document opens with a disclaimer. It is provided as a practical guide and general information, not legal advice, and IAB Tech Lab makes no representations about completeness or correctness. It adds that one or more of the measurement processes described may be subject to patents, that IAB Tech Lab has done no diligence on their validity, and that anyone implementing them is responsible for their own analysis and any licensing. IAB Tech Lab also states that it is not promulgating any standards or specifications under the guidelines.

Compliance is handled separately. The guidelines inform the Podcast Compliance Program, but the two are kept apart so that the program can meet the expectations of third-party certification. Certified metrics providers must support the described process or follow one of similar or greater stringency, disclose which options they chose and where they diverge, and explain why. PPC Land reported when NPR and Rawvoice/Blubrry became the first companies to earn seals of compliance. Neither attached document says when certified companies are expected to move from version 2.2 to 2.3, or whether existing certifications carry over.

What version 3.0 is meant to answer

Pipkin calls v2.3 "the bridge to the next one". The Podcast Technical Working Group is planning version 3.0, with a planned release for public comment in the middle of 2027; the July 21 materials had said only that version 3.0 was in development for 2027. According to IAB Tech Lab, it will move beyond downloads to the next generation of podcast measurement, and the industry first has to decide which new signals from video-era consumption can be standardised. The post lists five areas:

  • how to define and measure consumption when playback signals are available;
  • what should count as client-confirmed playback, listen-through or ad completion;
  • how measurement should treat streaming, video podcasts, HLS delivery, skip behaviour, scrubbing and ad position;
  • what role podcast apps and platforms should play in supplying more consistent signals;
  • how open RSS can keep supporting broad distribution while allowing more transparency into modern consumption and monetisation.

The post says none of these is a small question and that all will need input from across the industry, and it invites readers to join the Podcast Technical Working Group. The contributor list in the guidelines shows who already sits at the table: hosting platforms such as Acast, ART19 and Libsyn; publishers and networks including NPR, ESPN, The New York Times Company and Warner Bros. Discovery; measurement firms including Nielsen, DoubleVerify, Podtrac and Veritonic; and buy-side and platform names such as Google LLC, The Trade Desk, Spotify, SiriusXM Media and Triton Digital.

Why this matters for the marketing community

Podcast advertising is large enough that definitions carry a price. PPC Land reported that US podcast advertising reached $2.9 billion in 2025, and the channel now trades on several currencies at once. The download, defined in the document above, remains the unit of record for open-feed audio and, with this release, open-feed video. Spotify redefined a podcast play on June 11, 2026 as at least 30 seconds of listening or watching. Acast, in second-quarter results reported on July 23, 2026, replaced its listens indicator with listens and views, a measure that adds HLS listens and views to IAB-validated listens. Podtrac moved its YouTube podcast rankings to engaged views on September 3, 2026, and PPC Land reported its finding that YouTube's new view count overstates podcast attention by 36 percent.

Each of those measures a different event: a file request, half a minute of consumption, a validated listen, a view. The differences fall in the space the version 3.0 questions touch, and they mean that a figure quoted in a media plan can carry a different meaning depending on who produced it.

The download layer is already visible in public tables. Triton Digital's August 2026 US rankings, released on September 17, put 96,286,970 average weekly downloads across the 20 networks in its table, a total PPC Land calculated from the published rows, under a certification the company lists against version 2.2. The passage from 2.2 to 2.3 will therefore reach numbers that are already in circulation, though neither IAB Tech Lab document sets a date for it.

The final text also leaves gaps that only later work can fill. It does not cover streaming inside closed platforms, it depends on an identifier that research on IP addresses treats with caution, and it defers client-confirmed playback to a version that will open for comment about nine months from now. For buyers and sellers reconciling reports across hosts, vendors and video platforms, the practical significance of v2.3 is that it fixes the vocabulary and the arithmetic of one layer of podcast measurement while the others continue to evolve.

Timeline

Summary

Who: IAB Tech Lab, through its Podcast Technical Working Group in partnership with the IAB Audio Committee, with Brad Pipkin, Director of Product for Advanced TV, as the named author of the post and Tech Lab lead for the document. The contributor list names dozens of member companies across hosting, publishing, measurement and the buy side.

What: The final edition of the Podcast Technical Measurement Guidelines v2.3, which sets out how downloads, audiences and ad deliveries are measured from server logs for audio and video podcasts distributed via open RSS feeds or server-side file delivery. It swaps "listener" for "podcast consumer", documents prefix redirects, enclosure URL effects and three measurement windows, and moves the text to GitHub. Version 3.0 is planned for public comment in mid-2027.

When: Today, September 29, 2026, following a public comment period that ran from July 21 to August 19, 2026.

Where: On IAB Tech Lab's website and in the public IABTechLab/Podcast-Technical-Measurement GitHub repository, applying to podcasts distributed through open RSS feeds and podcast applications that rely on server-side file delivery.

Why: Most podcast apps provide no client-side playback confirmation, so server-log analysis remains the basis for counting, and consistent definitions are needed for buyers, sellers, hosts and measurement vendors to compare figures. According to IAB Tech Lab, the release gives clearer guidance for today's practice while version 3.0 takes up measurement beyond downloads.