What is partial download podcast measurement?

What is partial download podcast measurement? A partial download happens when a podcast app receives only part of an episode file, not the complete file in one transfer. It can still become a reported download, but only after the requests meet the measurement provider's content threshold, traffic filters, uniqueness rules, and reporting window.

The word "partial" describes file delivery. Nothing more. It does not tell you whether somebody listened, where they stopped, or whether the transfer should count.

What is partial download podcast measurement under IAB v2.3?

The IAB Tech Lab Podcast Technical Measurement Guidelines v2.3 define a download as a unique episode request that delivers an episode to a device. That definition includes complete downloads and partial downloads that satisfy the filtering process in section 5.

For a partial HTTP request, the server commonly returns status code 206. It then delivers a requested byte range. An app may ask for several ranges as playback moves through the episode, with pausing, resuming, or skipping creating more than one request for the same episode.

IAB v2.3 says those requests can count only if they cover enough podcast content to play for one minute. Headers do not satisfy the content threshold. Providers may need to reassemble several requests to determine whether the delivered ranges reach it. A two-byte range check, often written as bytes 0-1, must be disregarded because it tests whether range requests work but does not deliver meaningful episode content.

The IAB measurement landing page identifies v2.3 as the September 2026 release and says podcast measurement is based on server logs. That context matters. A partial download is reconstructed from delivery records, not from a listener pressing a visible button.

How several requests become one download

A partial transfer can leave several rows in a server log. The measurement process first removes requests that fail the rules. It then applies the file threshold and aggregates qualifying activity into unique downloads.

Consider a listener who starts an episode in a web player, pauses, and resumes later. The server may receive separate range requests for the first and second parts. IAB v2.3 says a play-pause-play sequence divided across file requests counts as one unique download after aggregation, provided the requests qualify.

The same logic prevents a small probe from becoming an audience event. A row in a log is evidence that a request occurred. A reported download comes later, after processing. Our guide to what counts as a podcast download covers the complete filtering sequence, while the unique download glossary explains the deduplication step.

Why host and prefix reports can differ

A podcast host and a prefix measurement service may observe different parts of the delivery path. IAB v2.3 explains that a prefix records the initial request and redirects the device to the host that stores the media. Later partial requests can bypass that prefix. They go straight to the host.

The host can record bytes served and later range requests in its native server logs. The prefix service may see the initial request but not the response or the remainder of the transfer. IAB v2.3 therefore notes that a prefix provider may need first-party or partner server-log data, or a disclosed correction method, to remove partial requests that never reached the threshold.

Do not assume that a larger total is more accurate. Compare the same episodes, dates, geography, measurement window, and method. Document any prefix or enclosure URL change. Changed URLs can trigger fresh requests in some podcast apps.

What a partial download can and cannot show

A qualifying partial download shows that the server delivered enough episode content under the provider's rules. It does not confirm playback. It also does not reveal a listening stop point, completion rate, or ad exposure.

Use podcast downloads versus listens when a report mixes delivery with player-confirmed behavior. Keep completion and consumption metrics tied to the app that recorded playback. For a broader reporting structure, the podcast analytics guide separates cross-app delivery from platform engagement and campaign outcomes.

When you compare episodes, keep the provider and measurement window consistent. A change in partial-request handling can move the reported total even when audience demand has not changed. Record methodology changes beside the chart. Do not explain every movement as growth or decline.

Track a consistent episode-delivery series with Podder Analytics, then use listening-platform data for playback and completion questions.