Skip to main content
You’re incorrectly identifying up to 50% of your user agents

You’re incorrectly identifying up to 50% of your user agents

Written By

Bryan Barletta

Know the Author

September 21, 2020

Chances are you’ve seen a podcast download report showing podcast players like Chrome and Safari. But those aren’t the players, just the way some episodes are being streamed. Device user agent gets you 50% of the way toward correctly identifying your audience. That other 50%? It requires a little more effort for a lot more results.

The Pitfall of Device User Agents

Last week we dug into the Open Podcast Analytics Workgroup (OPAWG), specifically to focus on their completely open and free to use database of device user agents. OPAWG also offers a repository for RSS user agents.

User agents, for podcast audio, tell the podcast host what player you’re using. That could be Spotify, Apple Podcasts… or Chrome. Yes, even web browsers are considered players.

So, while you may be listening to Spotify through Chrome, the user agent your podcast host sees just tells your podcast host that you’re using Chrome.

Knowing you’re using Chrome to play the audio is fine – but knowing that this play is really coming from Spotify, or Castbox, or RadioPublic, is better for marketing as well as targeting.

It also means that some platforms show inaccurate numbers in many podcast host dashboards. Google Podcasts, for example, has a much higher than average amount of web plays since play buttons for it appear in standard Google searches: but they’ll just appear as a browser, too.

Not to mention that whenever you “stream” a podcast (not download or subscribe, just hitting play) on any iOS/iPadOS device, the default device user agent shows as AppleCoreMedia. This is a streaming library that developers can choose to use if they want to, or they can choose to build their own.

For some shows or ad campaigns, streams from Apple devices or web plays might not be much more than 10% of their traffic. For others, it can be as high as 50%.

So how do we solve it?

Enter: RSS User Agents

Apart from Apple Podcasts, most major podcasting players have a central server that checks all the RSS feeds in their podcast directory of choice, at a set frequency (hourly, daily, set time of day, etc). When that server identifies that there’s an update on the RSS feed, it communicates with the player on your device to let you know there’s new content available.

A hosting provider can look at who the RSS request is coming from. by using the RSS user agent, and respond to the request in a more customised way.

Maybe one platform only allows HTML in the ‘description’ field, so you can get the episode notes to display better if you tweak that. Maybe you normally send AAC files, but one platform only accepts MP3. Maybe the display of your show notes on one app would look better with double line-spaces between paragraphs. Maybe one platform would prefer much lower bitrate files.

Many hosts already use different RSS feeds for different platforms – but the trouble with this is that you don’t always have that control. Some platforms take feeds from the iTunes API; and by producing many different URLs for your RSS feed, you break a central idea behind the internet – that of canonical links: one URL for each piece of content.

Tagging the RSS Request

If you can identify who the RSS request is coming from, you can respond back to the request in a tailored way for each app – and get a better understanding of the consumption in that app’s entire ecosystem.

Our own James Cridland of Podnews started cataloguing RSS user agents in OPAWG, where much of this data is available for exactly this reason.

Most RSS user agents seem to follow standard best practices which mean that you’ll see a clear URL identifying who is making the request. When the host gets an RSS request, all they have to do is look for the RSS user agent, and attach that service’s name to each episode’s audio URL. They can add a simple querystring to the audio – /audio/example.mp3?from=overcast.

Now every single time that audio is downloaded or streamed, regardless of whether it’s in-app or on a web player, the episode is marked with which platform requested it; in addition to the player’s user agent.

If a play happens on a web player, the user agent might say “Chrome”, but the audio file is still marked with the Overcast service name, so we can be sure it was played on the Overcast platform.

Running the numbers

One of the advantages of working with James Cridland is that he likes to host everything himself, which means he has access to all of his own data.

James has started using RSS user agents to tag the audio as discussed above, using the OPAWG database to identify them. The results were pretty fantastic.

Of a sample of 3,880 total podcast plays:

  • Only 2,193 provided an identifiable device user agent (56%)
  • 3,492 could be identified from the RSS user agent (90%)
  • For the 179 AppleCoreMedia records (5%), only 85 (47%) were from Apple Podcasts.
  • 457 records (12%) were from web browsers and could be correctly identified with this method.

If we just narrowly look at AppleCoreMedia and web browsers alone, Podnews is now able to identify 16% more of their users listening platforms than before. And that’s just the start.

Sharing the data down the line

To make sure we’re all using the same data, prefix URL partners like Chartable and Podtrac will need to ensure that these values are taken into account when matching episode audio URLs.

Podcast hosts will need to provide that value to tracking and attribution partners like Podsights and Claritas, as they’ll be completely blind to it unless it’s shared. As most tracking partners already have “ua=“ in their tag, it would make sense for them to add “rua=“ for the RSS user agent and for the hosting providers to include a macro to populate the value from the audio episode url.

One thing we absolutely need to ensure is that podcast hosting platforms don’t alter any part of the audio URL. In Podnews’s tests, two podcast platforms were altering audio query strings; another removed them altogether.

Growing the space

There are over 105 identified RSS user agents in the OPAWG repository at the time of writing this article. The more people exploring this method of identification, the faster and more accurately we can all identify all the RSS user agents correctly, and request the value is correctly set by podcast apps and directories.

Most of these RSS user agents are going to be easily identifiable, but we’ll definitely see some questionable requests. The more we identify the RSS and device user agents correctly, the more the outliers stick out. As a community, we can ask those seeing odd values to improve their feed or identify.

We can and should begin to use our new-found targeting power to give different audio to our listeners, encouraging them to find another podcast platform if those platforms are bad actors.

Increasing visibility into what player the user is actively engaging with in both web and streaming, where we were previously blind, is a massive win.

Homework

The goal of Sounds Profitable is to educate and empower each of you. If we’ve had a chance to talk directly, you know that I am truly passionate about both adtech and podcasting. We learn through asking tough questions and discussing the answers. Armed with today’s new knowledge, I want to help you ask more questions. Please consider supporting Sounds Profitable through our Patreon.

  • What user agent lookup database does your hosting, analytics, or tracking provider use?
    • Does that database also include RSS user agents?
  • Does your hosting platform provide you a different RSS feed per platform you submit to? (Spotify, Player.fm, etc)
    • If not, do they use the RSS user agents to better respond to each request?
  • Does your hosting provider show web browsers and AppleCoreMedia as podcast players?
    • What has been their advice been on how to view those values?
  • Is your hosting provider open to using OPAWG data and implementing this improvement for greater visibility?

New Sponsors!

It’s our goal to highlight the amazing people and companies that are helping Sounds Profitable grow. This week marks our third mailer, and we’d like to personally thank our first sponsor, Midroll Media, a leader in the podcast advertising network space.

We’d also like to thank our first three individual contributors:

  • Dave Zohrob of Chartable
  • Richard Palmer of Triton Digital
  • Aaron Dowd of Podcasting with Aaron

It costs $5k a year for a “startup” to join the IAB, so our goal is to join in 2021 as Sounds Profitable, in an attempt to provide an unbiased opinion in the audio tech lab meetings. Every sponsorship helps us get one step closer to that goal!

About the author

Bryan Barletta (He/Him) is the founder of Sounds Profitable, and a widely-cited expert in adtech, sales, and monetization of podcasting. He founded Sounds Profitable in 2020 after a successful career working with some of the leading companies in advertising technology, including AdTheorent, Claritas, and Megaphone. Barletta helped to design some of the tools in use by podcast platforms today for attribution, measurement, and serving audio ads, and uses that expertise to help clients and sponsors get the most from their sales and advertising efforts. He founded Sounds Profitable initially as a platform to help educate persons working in the podcast industry about advertising and sales technology, but has since expanded the brand to become the industry’s premiere source for education, advocacy, and insights designed to grow the entire space. He is an avid gamer and father of two boys, neither of whom have their own podcast, yet.