A proposal: do we need an Incognito Mode for podcast apps?

Podcast statistics and/or attribution services, like Chartable, Podsights, Backtracks, Blubrry stats, Podtrac and a few others, all currently work on a redirect basis.

Here’s roughly how one works. Your podcast app is given:

https://dts.statsco.com/redirect.mp3/podcasthost.com/episode5.mp3

…as the audio URL. But when it goes to download the audio from, in this case, dts.statsco.com, its servers say “It’s actually not here, it’s over there,” pointing to the podcasthost.com server. Technically this is called a 302 redirect.

StatsCo counts how many times it does this to give this podcast publisher a total number of downloads. It also looks at the user-agent to work out what type of device is asking for the audio. It’s a neat solution for calculating metrics.

Attribution

Some companies also perform attribution: they store the tiny amount of detail they get from your download (perhaps an IP address like 192.168.32.243).

Then, when you’ve heard the ad for an incredible mattress at a low price, the mattress company could place a little web-bug on their website with StatsCo. That would share the IP address of anyone who visits the website. If we see 192.168.32.243 in that list, we can relatively confidently state that this is that podcast listener, who is visiting the website because they have heard it on the podcast ad. This is entirely anonymous (the same IPv4 IP address like this is used by everyone in your household). Sounds Profitable has more on how much geo-information you can get from IP addresses.

Or, the mattress company could put the web-bug from StatsCo on the “Thank you for purchasing this mattress” page. That means that we can relatively confidently state that this is that podcast listener again, who heard the ad and liked the idea so much that she actually bought the mattress.

Since the attribution company could get her name and address from the mattress company as well, and could cross-tabulate this detail against the other podcasts that she listens to, and could sell that data to anyone who wanted a list of recent mattress-buyers, some people consider this attribution to be a privacy concern. (To be clear, that could only happen if the mattress company shared the data; and every attribution company I’ve seen absolutely does not want any of this PII information, but that doesn’t escape the fact that this could technically happen, even if contracts or the law prohibits it).

The drawbacks with this

If the webserver at dts.statsco.com stops working in the above example, then regardless of how reliable PodcastHost is, the listener will never be able to hear the show. There have been very isolated instances in the past where this has actually happened.

But if the webserver at dts.statsco.com is blocked by an ad-blocker, then, once more, the listener will never be able to hear the show.

One such ad-blocker is NextDNS, a DNS-based ad-blocker that allows you to block internet addresses from working on your own computer, home network, or phone. (This is an affiliate link; I use it and recommend it). Other solutions are Pi-hole.

There are lots of lists for these ad-blocking DNS servers: NextDNS links to more than 80 lists compiled by hard-working people all across the world. Web-bugs, like those mentioned above, are regularly blocked.

Some of those ad-blocking lists have dts.statsco.com in them, or their equivalent. It means that your computer, or phone, is unable to connect to the StatsCo server: and so the podcast app doesn’t work.

Overcast

After he got too many support queries about “why isn’t your podcast app working?” and traced it back to ad-blocking lists, Marco Arment, the developer of Overcast, made an 'experimental’ change to the way his app dealt with analytics redirects :  by simply ignoring them. Instantly, Overcast worked again.

It’s the right thing to do for listeners, who could access their favourite podcasts again. The only issue here is that it also meant that Overcast no longer appeared in podcasters’ stats.

Overcast is a top-5 podcast app, and some podcast publishers see 10-15% of all downloads coming from the app (partially because it’s very successful, and also partially because it only stops auto-downloading if your phone fills up).

Removing 10-15% of downloads from numbers podcasters can show to clients for sponsorships could be a bitter blow for some publishers.

Overcast rolled back this change, and it no longer bypasses redirect services.

PodLP

Thomas Barrasso, the developer of PodLP, followed, tweeting: “We’re joining Overcast, experimenting with removal of podcast stat service redirects due to issues with ad blockers and lack of IPv6 support, preventing many in places like India from listening.”

Some mobile networks in some countries are moving to IPv6-only environments, and that’s the case in India. If a website isn’t available in IPv6, then it doesn’t work. Podnews does work in IPv6, but very few podcast stats services or hosts do as yet.

Nevertheless, this also causes an issue for listeners: if their access to the podcast stats service doesn’t work, then they can’t listen to the podcast, irrespective of whether the host itself deals with IPv6 correctly.

But, once more, it means podcast publishers miss out.

Problematic

Skipping these podcast stats services altogether is problematic. It has the appearance of fewer downloads for publishers, and could mean less money for the people who produce this content.

It also means that the unwritten agreement between podcaster and podcast app has been broken - that apps should not alter RSS feeds or audio.

A possible solution: Incognito Mode

Just as a browser has an incognito mode, which means websites don’t have access to your existing cookies and information, so a podcast app could have 'incognito mode’ as an option to turn on.

☑ INCOGNITO MODE

Incognito Mode for a podcast app could recognise the existence of prefixes like those used above. Instead of following them from the podcast app itself, it could delegate that to the app’s cloud service - to proxy the call.

So, in the above example, StatsCo would still get a call from Overcast: but a call from Overcast’s main cloud server.

This would come from that IP address, not the user’s address. And my proposal here is that the user-agent would be modified to read Overcast/v3.0 IncognitoMode for 2a4b33c2c - the use of IncognitoMode with an anonymous hash of the individual user’s IP address.

That would enable StatsCo to be still able to count individual downloads, and still able to count unique users. However, it would identify that this user has opted out of attribution; and it would be impossible to attribute this user’s purchase of a mattress to the ad they heard on the podcast.

StatsCo would, incidentally, be also able to block users who have indicated they do not wish to be blocked.

It would also ensure that ad-blockers would not interfere with downloads; and could also be made to work correctly with IPv6 connections.

Full control for users and publishers

This gives full control to the user - whether they wish to have their listening attributed by the prefix company.

It also gives full control to the publisher - it does not interfere with raw statistics, and allows them control over whether they wish to honour a listener’s request not to be tracked further.

“Incognito Mode” could also be used by podcast hosts directly, by similarly modifying the user-agent in a standard way. That would, however, require trust that the podcast host would honour that request, since the user’s IP address would not be obfuscated.

Is this a way forward? You can discuss this post on Reddit in this thread.