What is range request podcast delivery?
Open a source-aware analysis with this article as the primary source.
Add us to your Preferred Sources.
What is range request podcast delivery? A range request asks a server for a specified portion of an episode media file instead of requesting the entire file at once. Podcast apps use partial delivery to start playback, seek, pause, or resume. Measurement systems inspect the requested ranges with other server-log fields to decide how much media was delivered and whether the activity belongs in a download count.
What is range request podcast delivery used for?
An episode can be downloaded as one file or progressively fetched in pieces. The IAB Tech Lab Podcast Technical Measurement Guidelines v2.3 define byte range as the portion of media requested in a given request. The guideline notes that a low range may signal a pre-download that should not enter valid counts.
Partial delivery lets a player fetch what it needs without pulling the complete episode immediately. One listening action can therefore leave several rows in a server log. Those rows are request evidence, not several listeners and not automatically several downloads.
This is one reason raw traffic is larger than the total shown in a podcast dashboard. Read what counts as a podcast download for the full filtering and aggregation sequence.
The two-byte probe is not a download
Some apps first send Range: 0-1, asking for only the first two bytes, to check whether the media server supports byte-range delivery. The IAB bot and bogus-request filtering section says to disregard that two-byte probe because it does not represent a valid download. One or more larger range requests may follow it.
Do not apply that rule to every partial request. A real progressive download can arrive in several slices. The distinction depends on the amount of content delivered, request handling, filters, and deduplication rather than the mere presence of a Range header.
The IAB HTTP request and file-threshold rules say a qualifying download needs the file header plus enough episode content to play for one minute. A partial 206 response may count when the combined requests cover that threshold and pass network-address and user-agent deduplication. Reassembling request evidence may be necessary when a listener skips ahead.
How several requests become one reported download
A sensible measurement path looks like this:
- Exclude probes and request types that transfer no qualifying media.
- Inspect byte ranges or bytes served to estimate delivered content.
- Apply the episode-specific content threshold.
- Filter bots and other ineligible traffic.
- Aggregate matching requests inside the provider's measurement window.
The standard's play-pause-play example says that one download divided into several file requests remains one unique download. Unique podcast downloads explains that aggregation layer. The download measurement guide shows what to record when you compare providers.
A range request also differs from an HTTP status code. The range describes which bytes the client asked for. The status describes how the server answered. Keep both fields, because a request alone does not prove that the server delivered the requested media. That separation matters when diagnosing retries, failed seeks, or requests that returned less data than expected.
Why hosts and prefixes may report different totals
A host can inspect its server response and bytes served. A URL-prefix provider usually records the initial request, then redirects the app to the host. The IAB URL-prefix measurement section explains that later partial requests may go directly to the host and bypass the prefix. The two systems can therefore observe different pieces of the same delivery path.
A mismatch does not prove that either dashboard is broken. Confirm whether each provider sees response bytes, how it handles partial delivery, which threshold it applies, and how it aggregates requests. Keep the provider and method attached to every reported total.
If byte-range data is unavailable, the IAB threshold section allows an advanced correction for partial delivery only when the system discloses how it compensates for the missing data. Ask for that methodology before comparing its numbers with native host logs.
The podcast analytics guide helps assign host, prefix, and in-app metrics separate jobs. Use the same source and reporting window for trend decisions rather than switching to whichever dashboard shows the larger number.
Use Podder Analytics to track a consistent episode-delivery series, then keep host-side range and response details beside any prefix report.
FAQ
Does every podcast range request count as a download?
No. A two-byte 0-1 probe is excluded, and partial requests must still pass the provider's delivery threshold, filtering, and deduplication rules.
Why does a podcast app request only part of an episode?
Partial requests support progressive delivery, seeking, pausing, and resuming without forcing the app to fetch the entire media file at once.
Can several range requests become one podcast download?
Yes. If one playback session fetches an episode in several qualifying pieces, the measurement process should aggregate and deduplicate those requests rather than count every piece separately.
See who's actually listening.
Podder gives you audience demographics, per-episode analytics, and chart tracking. The Chartable alternative that goes deeper.
Start free