This page summarizes how Flightcast counts podcast downloads and unique listeners. It is a public overview, not the full Document of Methodology. Flightcast follows the IAB Podcast Measurement Technical Guidelines (v2.2) for download and unique-listener counting. Flightcast is not formally IAB-certified.
Publishers who embed the Flightcast player, or who build their own players, should also read the Player Recommendations.
Downloads are deduplicated in a rolling 24-hour window per listener and episode. Counted downloads are then reported in UTC calendar-day buckets.
A unique listener is the combination of IP address and User-Agent. IPv4 addresses are used in full. IPv6 addresses are truncated to a /64 prefix before hashing. The IP and User-Agent are then hashed with SHA-256. Flightcast does not use cookies, user IDs, or session IDs to identify unique listeners.
Before a request can count as a download, Flightcast filters out non-listener traffic. That includes bots and spiders (using OPAWG-based user-agent lists), preload and prefetch signals, disallowed HTTP methods and statuses, Apple Watch user agents that the guidelines treat as automatic downloads, and non-listener IP classifications from IPinfo Plus. Inclusion and exclusion lists exist for remaining edge cases and are revalidated on a 90-day cadence.
Flightcast records when an ad has been delivered as part of a valid download ("ad delivered"). It also records when an app begins to receive an ad ("ad started") for streamed ads and for programmatic ads in downloaded files. The Impressions in the Ads Run Report, the ads analytics pages and campaign goals are delivered ads.
Some Flightcast reports include figures that are not part of the IAB Podcast Measurement Technical Guidelines.
The Ads Run Report and the ads analytics pages split ads delivered over streaming into "RSS Streaming (video)" and "RSS Streaming (audio)". In apps that fetch audio and video separately, a delivered ad counts as video when the app requested every segment of the ad's video from our servers within one listening session, within 24 hours before or after the delivery, and as audio otherwise, including when the listener switched from video to audio during the ad. The video count is produced by the same service that produces delivered ads. Deliveries made before this service counted video are split into audio and video afterwards from the same server request logs. The split is decided 24 hours after delivery and does not change after that. The Ads Run Report shows the ad as "RSS Streaming" until it includes its split, 25 to 26 hours after delivery. The ads analytics pages count the ad as video once the service that produces delivered ads has confirmed that the app requested every segment of the ad's video from our servers within one listening session, and as audio until then, so their audio count for the last 25 to 26 hours can still move to video. Reports without the split show every streaming ad as "RSS Streaming". Video requests made more than 24 hours after delivery are not counted. Apps that receive audio and video as one combined stream are counted as video. The split shows what the app requested. It does not show that the ad was seen or played, how long it was on screen, or that anyone was looking, and it is not a viewability measurement. For an audio creative the video is a Flightcast placeholder.
Impressions reported by Spotify are grouped into "Spotify (audio)" and "Spotify (video)" by the format of the ad booked on Spotify. This is the booked format. It is not based on video requests seen by Flightcast and is not comparable to "RSS Streaming (video)".
The documented methodology is kept in lock-step with the implementation. Changes are recorded in a dated changelog. Flightcast performs periodic self-audits of the measurement system.
To request the full Document of Methodology PDF, email support@flightcast.com.
© 2024 Flightcast. All rights reserved.