How to email someone your podcast: the AUDIO tag in email
So, you have a podcast, and you’d like to send people a clip of it, or maybe even the trailer.
You can embed audio in an HTML web-page. You can author nice-looking emails in HTML. So, can you embed an audio player in an HTML email?
What better way to help people listen to your stuff than to send it to them in an email, with a little play button that just plays the audio?
Wouldn’t that be brilliant?
Except…
You can’t do much in email
Most audio players require JavaScript, or an IFRAME. Neither JavaScript or IFRAMEs are supported in most email programs.
So, no - there’s no chance of embedding your podcast host’s fancy embeddable player in your email.
But there is something you can do, for maybe half of your users.
HTML audio is only supported on one email platform
The <audio> element is standard HTML. And… yes, it’s supported, but only by one email platform.
The good news is: that email program is Apple Mail (on iPhone, iPad and Mac OS). Litmus, an email testing suite, says that in August Apple’s market share was 58% of all email opens.
Most of that traffic goes through Apple Mail Privacy Protection, incidentally: so all the data can be automatically anonymised by Apple, especially the IP address of the user.
(Don’t forget that people can open their Gmail, or their office email, inside Apple Mail; and it’s the mail program that determines what’s supported here).
So HTML audio works for 50%+ of all emails?
Indeed. So perhaps it’s worth working out, for podcasters, how to send emails with audio built-in. Let’s get to it.
<audio controls preload="none" src="https://podnews.net/audio/podnewspromov2.m4a">
Your email client can't play audio
</audio>The above piece of HTML will produce a player that looks like this:
… at least, it looks like that in your browser.
The attributes mean:
controls- this makes the controls visible. You need this here, because you can’t control the audio with JavaScript or in any other way.preload="none"- this asks Apple Mail to never preload the audio. This is important for podcasts, because if you start preloading the audio, it might count as a proper download, and it isn’t.srcis the audio. We’re using AAC audio here, because we know that AAC audio is supported by all Apple devices, and the quality is better at lower bitrates.
You can’t officially style this player at all. In our tests, though, if you set style="width:50px;" then iOS/MacOS appears to cut the player down to a simple play button and that’s all. Which is probably perfect for your email.
What happens in all the other email programs?
The wording “Your email client can 't play the audio” in the code above is what is visible in Gmail or anything else that can’t deal with the audio tag. For consistency, you could put an image of a player in here that would open a page on your own website. So, if you fancied it, you could do something like…
<audio controls preload="none" rc="https://podnews.net/audio/podnewspromov2.m4a">
<a href="https://podnews.net/listen">
<img src="https://podnews.net/static/eg/player.png">
</a>
</audio>…and that player.png graphic will only show up if the email program doesn’t deal with the <audio> tag. It shows up in, for example, Gmail on the web or on Android.
Or, you could simply leave it blank. If the player appears, great - and if it doesn’t, that’s fine too.
Won’t it mess up my podcast stats?
If you link to the MP3 file on your podcast hosting company, then it should be measured just like any other show.
And if you’re using a prefix tracker like OP3 or Podtrac, it should measure plays that way too.
So, no - it is a normal download.
But won’t it be scanned by corporate email scanners?
Good question. We thought we’d test this.
So, on Fri Sep 15, the email version of the Podnews newsletter contained a link to the audio version of the day’s news, in an audio player only visible to email services that supported it. We removed it from our website and RSS feed, so it was only visible from our email; and we gave it a unique name so we could measure it separately.
We hoped to measure whether people clicked on it to listen to it - and what did they do that on?
And we also wanted to see whether we could tell if it was being automatically clicked-on, perhaps by an email scanning program. Even though we’d said preload="none", would a bot download it anyway?
Is it downloaded by mail scanners?
We sent 29,297 emails, starting at 11:00 GMT. Our software reported that the emails had all been sent at 11:43 GMT. That doesn’t mean that all emails were delivered by that time; just that they’d left our servers by then.
Checking our stats, we saw:
- 100 audio requests by 11:30:26
- 100 audio requests by 11:46:58
- 100 audio requests by 12:00:32
By 12:15 6,140 people had opened their email, and we’d seen 330 audio requests.
That appears to be a 5.3% rate. That seems to suggest that email scanners were not downloading this file on receipt (which is how they normally check links).
The data
The full request data
You can see the full redirect data from OP3 here (as a PDF); and you can also query OP3 to download it for yourself - it’s open, after all.
When we checked (Monday 18 Sep at 01:00), the audio had been hit 1,274 times, from 926 unique IP addresses.
Of the 1,274 requests, 632 (49.6%) were a range request asking for bytes 0-1.
The “Mozilla/5.0” user agent that requested files 710 times is standard Apple Mail on iPhone. We don’t see anything downloading the audio that isn’t some form of web browser on an Apple device, with the exception of Outlook on Android.
The full server data
Redirect data doesn’t always give the full story - because the redirect data doesn’t always show how much was downloaded.
But, we host our podcast ourselves. So, here’s our full server logs (with IP addresses hashed, of course).
From our server stats, we come to 927 unique IP addresses (virtually identical to OP3's data).
We saw 2,123 requests. 642 of those were below 750 bytes, so that leaves 1,481 requests that were actually downloading the audio.
Looking at clients that were actually downloading the audio (some in a chunked way), we think we achieved 1,071 downloads from this. There’s nothing that suggests that these are being automatically downloaded.
Our email software
We use Sendy, and have an anonymous open tracker embedded in our email, so we can test quite well whether there are any deliverability issues with sending an <audio> tag in email.
Our open rate for Tue/Wed/Thu’s newsletters varied between 45.4% and 45.9%. This one was slightly lower at 44.2%. Fridays are normally lower than the rest of the week, though, and it’s the newest newsletter we’ve send, so will have a lower open rate than every other. We don’t think it had an impact on deliverability.
Other things we learnt
We also discovered that the audio tag is also supported by other programs: some versions of Microsoft Outlook on the Mac, Spark, Superhuman, and Mimestream. (In short - if the email app is using Apple’s webkit rendering engine, it’s supported). Further, it appears supported on Outlook on Android.
Using Apple Mail on iPhone, if you start playing the audio, it continues playing in the background until you stop it. You can switch away from that message, and even from Apple Mail completely, and the audio continues to play. (You can stop it either by coming back to the email and pressing pause; or by pulling up the audio controls.)
Conclusion
If you have an email mailing list for your podcast, there’s nothing to lose from putting an audio tag in it with the audio from your latest podcast.
While it does only work in Apple devices (and, predominantly, Apple Mail), since it appears to degrade properly, you can use it without any penalty in your emails. It’s an ideal way to promote your show.
So, in your emails, we’d recommend you use:
A big link to your website, which contains more about your podcast and how to follow it on your favourite podcast player
And underneath, an AUDIO control containing the show you want them to listen to.
And, who knows - maybe an AUDIO tag in your email signature with your podcast’s trailer?
