SWEDISH PODCAST MEASUREMENT STANDARDS

SWEDISH PODCAST MEASUREMENT STANDARDS

The Swedish Podcast Measurement Standard is created by a working group including Kantar, Sveriges Annonsörer, Sveriges Radio, Acast, Bauer Media, Podspace and Perfect Day Media.

The purpose of this standardization is to introduce transparent and consistent podcast audience metrics across podcasts, platforms, publishers and service providers. The standardization offers all podcast stakeholders a defined set of metrics making it possible to track listening consistently over time and to equally compare podcasts and podcast networks.

The standardized methodology is implemented by the group's (platform) members of the technical committee and audited by a third-party handled by Kantar Media Audit.

The Swedish Podcast Measurement Standards are harmonized with guidelines from IAB Tech Lab; IAB Podcast Measurement Technical Guidelines 2.0.

The methodology includes two metrics making it possible to evaluate audience reach and activity across podcasts, platforms and publishers. All filters applying to Listens/Downloads also apply to Reach/Listeners.

The group is in contact with podcast standardization initiatives globally, mainly IAB Tech Lab (US). Technology is in constant development and digital distribution is global, thus the Swedish working group has all intentions to participate globally and if needed adjust these standards over time.

Poddindex technical committee

Mattias Björkman - Bauer Media, Chairman of this committee
Gustaf Helleday - Acast
Lolo Tode Palm & Frida Kvarnström - Sveriges Radio
Edward Jewson - Podspace / Bowtie
Johan Dahlberg - Perfect Day Media
Peter Mackhé - Sveriges Annonsörer
Maria Grip - Kantar
Lars Björkman - Kantar

Version 3 released 2021-05-20

1. Introduction

Measurement Standard versions

Version 1 was released 2017-11-15 when Poddindex.se was launched.

Version 2 was released 2018-01-17, in which clarification regarding all filters applying Listens also apply Reach was added. As well as change in duration filtering from 10 sec to 60 seconds harmonizing Reach metric with IAB Podcast Measurement Technical Guideliness 2.0.

Podcast Definition

For the purpose of this paper Podcast is defined as all editorial audio content that can be consumed On Demand, including audio productions that have been distributed via radio as well as productions exclusively distributed On Demand.

How Listeners Access Podcasts

Podcasts are accessed through a wide range of applications, websites and devices, in this paper called ‘clients’. These clients distribute podcasts directly or through RSS feeds. The RSS protocol makes it possible for a client to subscribe on a podcast updating and consuming it from publishers without further technical integration.

This has led to superior accessibility where publishers can distribute podcasts through a range of platforms, not limited to proprietary clients. As a result Apple Podcaster is the biggest client for podcasts listening in Sweden, pre installed in all iPhones with most podcasts and publishers represented. Listening is however fragmented on various websites, applications and digital appliances, including proprietary publisher platforms such as Sveriges Radio Play (SR), Acast (Acast) and Podplay (Bauer Media).

The most common form of accessing a podcast in Sweden is downloading the file during listening. This is called progressive download, and in daily speech streaming. In strict technical terms it’s not true streaming since the connection to the server is not necessarily persistent, but most clients do use progressive download instead of true streaming since it provides the best user experience balancing fast and stable playback.

Server Side Measurement

The fragmented distribution across multiple clients has led to the development of new measurement technologies where both audience and ad serving is measured through servers streaming the podcast rather than clients consuming it. Server side technology has huge advantages in cross platform measurement and monetization but poses new challenges when it comes to data quality.

Like all digital measurements there is always a risk that content or ads can be requested by non-human traffic. Counting the number of raw requests to the server could thus generate far higher numbers than actual requests made by true listeners. It can easily overstate delivery by a factor of 4x or more. This can be solved using filters making sure traffic is as human as possible.

2. Metrics

Poddindex includes two metrics, reach and listens, making it possible to evaluate audience reach and activity across podcasts, platforms and publishers. All filters applying to Listens also apply to Reach. Poddindex urges service providers to apply filtering as stated in the IAB Podcast Measurement Technical Guidelines Version 2.0 to produce these metrics.

A detailed technical specification on guideline implementation by each service provider is documented in section Appendix 1 of this paper.

Teknisk Medieräckvidd = Technical Reach / "IAB Listeners":

The measurement of uniqueness is important to all stakeholders in order to know the reach of a given podcast or set of podcasts. It’s also a prerequisite for frequency measurement and filtering. It consists of data that represents a unique identifier who downloads content (for immediate or delayed consumption). Podcast consumption takes place on a variety of platforms and the method for identifying uniqueness can be adapted depending on the platform. In general, it is calculated as a unique combination of IP-address and User Agent, but cookies, device id and user id can be used as well.

At Poddindex technical media reach is stated in the timeframe of a week and across all podcast episodes. The reach of a service provider is stated as unique identifiers across all episodes and podcasts within that service provider (i.e. not cumulated podcast reach).

The technical reach metric is called Räckvidd/"IAB Listeners" on Poddindex, and “Listeners” in IAB guidelines. Full technical specification on IAB guidelines is found here.

Technical reach is equivalent to media reach, and should not be confused with ad reach.

Starter / Nedladdningar = Listens / "IAB Downloads":

In combination with reach we need to measure the activity by each unique identifier. For example, the frequency in which each unique consume a podcast. It consists of a unique file request that was downloaded over 60 seconds of audio (for immediate or delayed consumption). To ensure relevant traffic a frequency filter is applied to listens where only one listen per unique, episode and day is included. Listens are higher than reach since one unique identifier can start several episodes on any given day, or the same episode on different days.

At Poddindex listens are stated in the timeframe of a week and across all podcast episodes. The listens of a service provider is stated as the total amount of listens across all episodes and podcasts within that service provider.

The listen metric is equivalent to Starts of episodes (min. 60 sec) and downloads on Poddindex, refered to “Downloads” in IAB guidelines. Full technical specification on IAB guidelines is found here.

3. Sample Audit

In order to achieve higher transparency and quality assurance, a sample audit model is implemented for Poddindex-connected service providers ("Plattform").

The standardized methodology described in this paper is based on server data and thus integrated with podcast distribution. Podcast platforms and publishers use different systems for distribution which means that there might be slight variations in how the methodology is implemented between service providers.

The very purpose of the standardization is to introduce transparent and consistent podcast audience metrics. Therefore, each certified service provider specifies what system is being used and how the standardization is implemented, see appendix 1.

Each system is audited by Kantar Media Audit to assure aligning results between audit and what is published on Poddindex. The audit concept is called Sample Audit since it is based on random sampling of podcasts in log files, provided to Kantar Media Audit by the service providers. Acceptable level of discrepancy is + - 10%.

Process of audit

The service providers deliver server logs according to established requirements specification, aggregated compiled per week, to Kantar Sifo AB, on request 3 to 4 times per year.

The log files form the basis for a selection of podcasts to review. When a selection of podcasts has been reviewed, the service provider will be notified about the result of the audit.

The log files are delivered through a FTP owned by Kantar Sweden. Analysis of the log files are made in collaboration between Kantar Sweden and Kantar Norway.

Results are shared with the service providers individually and are not to be published by Kantar.

Frequency of Audit

Kantar Media Audit will request data for a specific week for all podcasts per service provider. The weeks thus become random over the year, but the same for all service providers.

Approximately 8 - 20 podcasts per service provider and year will be selected by Kantar Media Audit for sample audit.

4. Measurement of Ad Delivery

The scope of this standardisation is limited to metrics for audience measurement. In it’s essence the methodology for podcast audience measurement do however also apply for podcast audio advertising, although some differences are worth noting.

Podcast audio advertising is delivered and measured through two main technologies.

Ads integrated in Content

These ads are integrated in the episode file and thus measured through the audience metrics described in this paper.

This technique is now seldom used for ad delivery, but more often used in editorial partnerships and native content.

Ads Dynamically Inserted in Content

These ads are inserted when the request is made and thus delivered similar to other streamed media in the form of pre-, mid- or post-rolls. They are delivered either by the server or the client stitching ads to the requested file.

In this technique advertising- and campaign reach should be measured through the same methodology as described in this paper. A campaign's podcast reach should thus be defined as the number of unique identifiers the podcast ad has been served to during a given time.

The main metric and often basis for pricing (CPM) of dynamic ad delivery is impressions. Although impressions are similar to listens they have somewhat different attributes, mainly that several impressions can be delivered in one listen (e.g. one pre-roll and mid-roll). To achieve accuracy the Impression tracking should include duration filtering as well as frequency filtering described in this document. Details and values in such filtering can however differ due to ad duration, capping- and frequency rules set by the publisher.

In similarity to all digital advertising it’s recommended to ask the podcast provider or publisher which ad system is used and to include third party ad tracking.

APPENDIX 1 - Implementation

The following service providers have implemented the standardized methodology in the following manners;

SVERIGES RADIO

System Used: In house
Implementation of listens:
- Duration filter http GET code 206: Progressive downloads measured after 60 seconds.
- Duration filter http GET code 200: A download is measured once 60 seconds are downloaded.
- Filter for frequency: The number of listens are limited to 1 per unique identifier and content and day.
- Bot detection: Based on IAB Botlist
Implementation of reach (unique identifier):
- First party app: Unique combination of IP + User Agent
- First party web: Unique combination of IP + User Agent
- Third party player: Unique combination of IP + User Agent
Implementation of Ad Delivery:
- Not applicable

ACAST

System Used: In house
Implementation of listens (IAB Compliant):
- Duration filter http GET code 206: Progressive downloads measured after 60 seconds (metadata excluded)
- Filter for range requests http GET code 206: Only range request starting on byte 0 is counted
- Duration filter http GET code 200: A download is measured once 60 seconds are downloaded
- Filter for frequency: The number of listens per file is limited to 1 per unique identifier and day
- Bot detection: Based on IAB Botlist
Implementation of reach (unique identifier):
- First party app: User ID
- Embedded player: Unique combination of IP + User Agent
- Third party player: Unique combination of IP + User Agent
Implementation of Ad Delivery:
- Ad needs to be part of a valid download.
- Ad needs to be fully requested

BAUER MEDIA - Podplay

System Used: Audience measurement: In house. Ad delivery and measurement: AdsWizz.
Implementation of listens:
- Duration filter http GET code 206: Progressive downloads are included when 60 seconds of audio is downloaded.
- Duration filter http GET code 200: Downloads are included when 60 seconds of audio is downloaded.
- Filter for metadata: Non audio elements are excluded when calculating the duration filter.
- Filter for frequency: The number of listens per file is limited to one per unique identifier and calendar day.
- Bot detection: User Agent exclusion is based on botlist https://github.com/opawg/user-agents
Implementation of reach (unique identifier):
- First party signed in users: Listener ID
- First party app: Device ID/Advertising ID
- First party web: Cookie
- Third party players: Unique combination of IP and User Agent
System used for Ad Delivery and Measurement:
- AdsWizz

POD.SPACE

System Used: In house
Implementation of listens
- Duration filter http GET code 206: Progressive downloads measured after 60 seconds
- Filter for range requests http GET code 206: Only range request starting on byte 0 is counted
- Duration filter http GET code 200: A download is only counted as a listen when the entire file is downloaded.
- Filter for frequency: The number of listens per file is limited to 1 per unique identifier and calendar day.
- Bot detection:
Implementation of reach (unique identifier):
- Embedded player: Cookie / Unique combination of IP + User Agent
- Third party player: Unique combination of IP + User Agent
Implementation of Ad Delivery:
- Identical methodology as the audience measurement
- Ad needs to be fully requested
- Ads are optionally embeded using in house ad stitching technology

APPENDIX 2 - Technical Specification for Audit

The audit concept is called Sample Audit since it is based on random sampling of log files, provided to Kantar Media Audit by the service providers.

The service providers deliver server logs according to this requirements specification.

Log file requiered fields and format

To comply with the measurement functionality the log file needs to contain the following fields in the exact order as stated below. With the exception of bitrate, this can be communicated seperately.

Timestamp (incl. date)

http status code

http method

IP-address

user agent

URL

bytes served

RSS

bitrate

Functions of each field:

Timestamp: Full timestamp, UTC. Including date with separation.
http status code: Used for filtering out HTTP 200, 206 and 304 requests.
http method: Used for filtering out HTTP GET requests.
IP-address: Used to identify device. Represented either by a 4 octet IP-address or a unique hashed value. Kantar Validating system will automatically hash full IP-addresses if not received hashed, to comply with GDPR.
User Agent: Used to identify device in combination with IP.
URL: Relative path for the podcast MP3 file.
Bytes Served: Used to identify size of the requested file. For HTTP status code 200, this is indicated by a singular value. Currently on interval request from client server, but due to a possible transition to bytes-served, a separate field will be added.
RSS: Used to identify the podcast.
Bitrate: The number of bits that are conveyed or processed per unit of time.

___________________________________________________________________________________________________

ARCHIVE

Appendix 1 - Implementation until Spring 2020

Acast

System Used: In house
Implementation of listens:
- Duration filter http GET code 206: Progressive downloads measured after 60 seconds (metadata excluded)
- Filter for range requests http GET code 206: Only range request starting on byte 0 is counted
- Duration filter http GET code 200: A download is only counted as a listen when the entire file is downloaded
- Filter for frequency: The number of listens per file is limited to 10 per unique identifier and hour
Implementation of unique identifier:
- Acast Apps: User ID
- Acast Embed player: Cookie
- Third party player: Unique combination of IP + User Agent
Implementation of Ad Delivery:
- Identical methodology as the audience measurement.

Bauer Media

System Used: AdsWizz
Implementation of listens
- Duration filter http GET code 206: Progressive downloads measured after 60 seconds (regardless of bitrate)
- Filter for range requests http GET code 206: All requests done by the player throughout the listening session will be collected under the same session avoiding counting more than one listen per session. For players that do not respect HTTP protocol and dynamic sessions static sessions are created based on podcast, IP, User agent and time (24h validity).
- Filter for metadata http GET code 206: All non audio elements are excluded when calculating the duration filter.
- Duration filter http GET code 200: A download is only counted as a listen when the entire file is downloaded.
- Filter for frequency: The number of listens per file is limited to 1 per unique identifier and hour. This is lower than the required value 10 and used to improve the efficiency of range request filtering based on session data.
Implementation of Ad Delivery:
- Identical methodology as the audience measurement.
- In addition further delivery capping per ad and unique identifier possible.
Implementation of unique identifier:
- Signed in RadioPlay users: Listener ID
- RadioPlay app: Device ID/Advertising ID
- RadioPlay web: Cookie
- Third party player: Unique combination of IP + User Agent

POD.SPACE

System Used: In house
Implementation of listens
- Duration filter http GET code 206: Progressive downloads measured after 60 seconds
- Filter for range requests http GET code 206: Only range request starting on byte 0 is counted
- Duration filter http GET code 200: A download is only counted as a listen when the entire file is downloaded.
- Filter for frequency: The number of listens per file is limited to 10 per unique identifier and hour
Implementation of Ad Delivery:
- Ads if applicable is integrated in content, and measured the same way as audience”
Implementation of unique identifier:
- Third party player: Unique combination of IP + User Agent
- I Pod.space web player: Cookie / Unique combination of IP + User Agent

SVERIGES RADIO

Since Sveriges Radio is a non-commercial organization, an exception was given to deviate from the methodology as long as deviations are described and actions are taken to create comparable results in the audit process.

System Used: In house
Implementation of listens:
- Filter for range requests http GET code 206: Not applicable because all requests get redirected with code 302 to our external content delivery network where range requests happen without us being able to track them. Since Sveriges Radio is a non-commercial organization, an exception has been given to deviate from any rules requiring information from range requests.
- Filter for frequency: A request is immediately counted as a listen, provided no listen has been counted for that User IP within the last 15 seconds and no request has come from that unique identifier within the last 5 minutes (regardless of whether it has been counted as a listen or not).
- Exception sverigesradio.se: A listen is counted after 5 seconds. Cookie prevents repeated starts.
Implementation of unique identifier:
- Sveriges Radio Apps: Unique combination of IP + User Agent
- Sverigesradio.se: Unique combination of IP + User Agent
- Third party player: Unique combination of IP + User Agent
Implementation of Ad Delivery:
- Not applicable

VIAPLAY GROUP RADIO - I Like Radio

System Used: AdsWizz
Implementation of listens:
- Duration filter http GET code 206: Progressive downloads measured after 60 seconds (regardless of bitrate)
- Filter for range requests http GET code 206: All requests done by the player throughout the listening session will be collected under the same session avoiding counting more than one listen per session. For players that do not respect HTTP protocol and dynamic sessions static sessions are created based on podcast, IP, User agent and time (24h validity).
- Filter for metadata http GET code 206: All non audio elements are excluded when calculating the duration filter.
- Duration filter http GET code 200: A download is only counted as a listen when the entire file is downloaded.
- Filter for frequency: The number of listens per file is limited to 1 per unique identifier and hour. This is lower than the required value 10 and used to improve the efficiency of range request filtering based on session data.
- Bot detection:
Implementation of reach (unique identifier):
- First party app: Device ID/Advertising ID
- First party web: Cookie
- Third party player: Unique combination of IP + User Agent
Implementation of Ad Delivery:
- Identical methodology as the audience measurement.
- In addition further delivery capping per ad and unique identifier possible.