Auto-downloads and better stats

[jamescridland]

The number of total downloads is important for a podcaster - it gives them the impetus to continue. If there's a way to get download numbers more accurate, it helps everyone.

A percentage of auto-downloads are never listened-to. This is not particularly helpful, and it occurs to me that there might be a backwards-compatible method of improving statistics, to allow better understanding of how much is being auto-downloaded and never listened-to, and producing more accurate data.

A _type attribute on downloads

When auto-downloading, add a _type=autodownload parameter to the end of the audio URL. So a download might be to https://example.com/podcast.mp3?_type=autodownload.

When someone plays the auto-download on their device, make a HEAD request to the same audio URL, with _type=play when the device next gets access to the internet. So, a HEAD request to https://example.com/podcast.mp3?_type=play

For legacy hosts

Nothing changes. Under IAB rules, the HEAD request would never count as a download (it’s a HEAD request, it has no body length at all).

For modern hosts

Ignore downloads with _type=autodownload from your statistics; but capture ?_type=play HEAD requests. This way, you'll get better understanding of what was actually played.

There are no privacy implications here - it’s just another connection to a podcast host.

Unless you use a ULID (unique listen ID) there’s no way to connect the play with the autodownload. Even if you use a ULID, you'll only get potentially two connected IP addresses: the address where that show was autodownloaded, and the address when it was played. An app developer might opt to only sending those HEADS when the app next auto-downloads episodes, thus minimising any connection between IP addresses (given most apps auto-download on wifi, not cellular, and normally auto-download on charge).

Of course, nobody really wants to know the extent of auto downloads that are happening... ;)\

For metadata downloads...

If you're using a PRELOAD=METADATA in your embedded player, you could add a _type=metadata to the file request, and then remove that when the listener presses play. However, that would appear as a download in most cases for legacy hosts.

Anyway, just an idea.

[johnspurlock]

It would be an interesting world to live in - but would require all apps to really care about podcasting stats, in that they'd have to doggedly send those HEAD requests asap after a play (might be under a bridge, cell/low-battery, app backgrounded) so they'd need to immediately save this to storage and ensure 100% followup later only for the purposes of stats. Otherwise stats would be under counted! They'd also have to ensure the HEAD requests busted through the local UrlRequest cache (Apple's sqlite-based one) for native apps or browser cache for webapps and actually made it to the server. Again, all just to be nice. Making a server call just to log user-initiated playback feels kind of like RAD.

The current status quo is sort of balanced (in a way) in that both sides get what they approximately need at the same time, and both begrudgingly accept the tradeoffs.

Web apps would be, per usual, behind the eight ball here. Sticking a url into an audio tag does not require that media url to support CORS, which is nice. Making a fetch call to the same url (for the HEAD request) does, which is not nice. Not all enclosure/prefix urls are available over CORS - last time I looked, very few of them are. So they they'd have to proxy the HEAD to a server with a different UA and not only a different IP, but a different ASN/global location.

Changing the url of an audio tag in JS as you suggest would result in a reset of the audio player, and a re-fetch from the server (won't be cached by the browser) so not efficient for the client side - downloading the same thing twice! Oh and any prefix redirects.

Finally, I'm not sure if you can reset the audio player url and start the player all within the scope of a user click (which was made based on another audio url). Browsers have constrained scope over the years for when they allow javascript .play() calls to cut down on annoying background or otherwise user-confounding autoplayers. Might be something you could test in a simple web page.

[theDanielJLewis]

(I'm just now catching up to read this.)

I like this idea. It's simple and effective. I think it could even have some flexibility to handle things like passing percentage completion data.

But I just know what Marco and some other app developers will say. They'll refuse to do it because it provides more potential to track audiences. 🙁