SWEDISH PODCAST MEASUREMENT STANDARDS

SWEDISH PODCAST MEASUREMENT STANDARDS

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

The purpose of this standardization is to introduce transparent and consistent podcast audience metrics across podcasts, publishers, platforms, and service providers. The standardization offer 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 members and audited by the third party organisation Sveriges Annonsörer.

The group is in contact with podcast standardization initiatives globally, mainly IAB US through IAB Sweden. 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.

Group members

Carl Wåreus (Group Leader)
Peter Mackhé (Sveriges Annonsörer)
Anna Johansson (Sveriges Radio)
Per Sirén  (Sveriges Radio)
Joakim Johansson (Sveriges Radio)
Fredrik Hermansson (Acast)
Niklas Berglöf (MTG Radio)
Mattias Björkman (Bauer Media)
Erik Barraud (AdsWizz)

Version 2 released 2018-01-17. Added clarification that all filters applying Listens also apply Reach. Change in duration filtering from 10 sec to 60 sec harmonizing Reach metric with IAB Podcast Measurement Technical Guideliness 2.0.

1. Introduction

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.

The Swedish Podcast audience

Swedish podcast listening has grown with 36% during the last two years and now amounts to 1,6 million Swedes weekly (20%) and 3,3 million Swedes monthly (40%). Unique podcast content not published on radio has the fastest growth with 62% during this period.

Over 70% of all listeners are between 20-49 years of age, with an audience peak in the age group 20-34. Although the reach has increased across all regions podcast listening is still higher in larger cities with just over 50% of the audience in Stockholm, Gothenburg and Malmö. Over 80% of listening is on mobile devices. Source: Orvesto Konsument 2017:2

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 iTunes-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), RadioPlay (Bauer Media) and I Like Radio (MTG).

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.

Metrics

This methodology include two metrics making it possible to evaluate audience reach and activity across podcasts, platforms and publishers.

  • Listens: In combination with reach we need to measure the activity by each unique listener. For example the frequency in which each unique consume a podcast.
  • Reach: 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.

Measurement of time consumed is not included in this methodology and not yet a widely used metric for podcast audience measurement. Podcast providers are working on an estimate for time consumed and the inclusion of such a metric must be clearly labeled to differentiate from reach and listens.

2. Measurement of Listens

A listen is a started or downloaded podcast. While the metric aims to capture that a podcast is heard it can't be guaranteed. Compared to technical viewability used in display and video advertising one could say that a podcast downloaded while listening has 100% technical hearability, while a downloaded podcast for later listening has unknown technical hearability. We estimate that 70% of all podcast consumption in Sweden is downloaded during listening. On proprietary publisher platforms over 90% and on iTunes Podcaster between 40-60%.

When measuring podcast downloads and/or starts one cannot look at the raw number of request to the server. Like all digital measurements there is always a risk that request are done by non-human traffic. In server side measurement this traffic is not only created by bots, but also by clients creating several requests for one single listener and play.

In this methodology we address this issue by several filter types. The combination of these filters are making sure traffic is as human as possible.

Filters for progressive download (http GET code 206)

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.

  • Duration filter http GET code 206: A listen should only be counted when the listener has listened to the podcast for at least 60 seconds. This can also be defined as 1 200 000 bytes of downloaded audio data which is approximately 60 seconds for an MP3 file with a bitrate between 128 kbps - 192 kbps according to below table.

Sound Quality

Duration of 10 seconds in bytes

64 kbps

480 000

128 kbps

960 000

192 kbps

1 440 000

320 kbps

2 400 000

  • Players with pre-loading: Although a duration filter is used it has been noted that players with heavy pre-loading might create non legit listens. Players with pre-loading above an equivalent of 60 sec recording time should thus not be used.

In addition to duration filtering the methodology must take into account that progressive downloads might produce several requests in one single session. This should be avoided by either only include requests if the range starts at 0, or by making sure only one single request per session is counted.

  • Filter for range requests http GET code 206: Only include requests if the range starts at 0 or by making sure only one single request per session is counted

Podcasts is mainly distributed in the format of MP3-files which may contain additional non audio data referred to as metadata. This additional data include basic information such as title, publisher, and publishing date but are versatile and can also include larger seized information such as images. The size of such metadata might disturb the duration filter and should be excluded when calculating duration from bytes.

  • Filter for metadata http GET code 206: The size of a file's metadata should not be included when calculating the duration filter based on the byte limit.

Filter for Download (http GET code 200)

Another way of accessing podcasts is by downloading the file for later listening, simply called downloading. Downloading is widely used in countries with limited or expensive mobile data, since users want to download content before they go out of home. This behaviour has been in steady decline in Sweden which probably derives from the commoditization of mobile data.

It is true that some downloaded episodes will go unplayed, while some are played multiple times. It is however important to note that most clients with subscription features (iTunes Podcaster in particular) won’t download new episodes from a subscribed podcast if the user haven’t played that podcast recently. Most clients learn the user behaviour since it saves data costs for users as well as clients.

  • Duration filter http GET code 200: A listen should only be counted when the entire file is downloaded.

Filter for Frequency (http GET code 206 and http GET code 200)

Besides having filters for duration or amount of data downloaded, there should also be a frequency filter limiting the number of listens being generated from a unique identifier over a given time on a single file.

The purpose of the frequency filter is to create an accurate limitation of listens where bots, auto downloading, and spamming are excluded. The limitation is a balance between gaining as accurate data as possible while not blocking legitimate requests from listeners, especially listener sharing public IP addresses which do affect the frequency when the unique identifier is calculated from unique combinations of IP and User Agent.

  • Filter for frequency: The number of requests per file is limited to 10 listens per unique identifier and hour.

3. Measurement of Reach

Reach is an estimate of the number of unique listeners during a given time on a given podcast or a given set of podcasts. While the metric aims to capture unique individuals it is, with the exception of user id, limited to unique clients.

The reach metric is calculated as a unique listen. As such all filters applied to listens also apply to reach.

Unique Identifiers

Due to the fragmented consumption of podcasts the identification of uniqueness vary depending on client. These identifiers can be used:

  1. UserID: If the publisher and/or service provider has the ability to identify signed in users, the unique userID should be used as identifier.
  2. DeviceID: If the publisher and/or service provider owns the application where the podcast is consumed, the Device ID (Advertising ID on Android and iOS devices) should be used as identifier.
  3. Cookie: If the publisher and/or service provider owns the website where the podcast is consumed, a cookie should be used as identifier.
  4. IP and User Agent: If the client is not owned, and none of the above identifications are available, the server should estimate unique reach by a unique combination of IP and User Agent.

Unique identification through UserID, DeviceID, and Cookie is similar to most digital client side measurements, for example KIA-index. The unique combination of IP and User Agent is a server side technology and is in this methodology the minimum requirement for unique identification.

Technologies for unique identification is constantly evolving and podcast providers are working on an improved server side identification using new attributes and technologies. Any improvements and/or changes to this should be transparently communicated and accounted for making sure it is not overstating the unique reach in relation to above standards.

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 - Audit

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

The very purpose of the standardization is is to introduce transparent and consistent podcast audience metrics. Therefore, each certified publisher and/or service provider specifies what system being used and how the standardization is implemented. Each publisher and system is audited by Sveriges Annonsörer and are only approved if the results are in line (+-5%) with the predicted outcome.

For details on the certification process and how to apply for certification, contact Peter Mackhé  at peter.mackhe@annons.se.

Appendix 2 - Implementation

Following publishers and/or service providers have implemented the standardized methodology.

Sveriges Radio

Since Sveriges Radio is a non-commercial organization, an exception has been 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

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

MTG Sverige

  • System Used: AdsWizz
  • Implementation of unique identifier: Unique combination of IP + User Agent
  • Implementation of listens: TBA
  • Implementation of Ad Delivery: TBA

Nyhetsbrev

Håll dig uppdaterad.

Prenumerera på vårt nyhetsbrev.

Håll koll på vad som händer i den digitala världen genom att prenumerera på vårt nyhetsbrev. I och med att du prenumererar på vårt nyhetsbrev godkänner du att vi hanterar dina personuppgifter. Läs gärna våra riktlinjer för hantering av personuppgifter.

{{ errors }}