Tracking newsletter read time with AMP

A year or so ago, I noticed the Washington Post had started to send their breaking news email notifications with AMP.

AMP, or Accelerated Mobile Pages, is a Google web framework designed to create lightweight experiences that — Google being Google — you could still chuck a lot of ads into.

Nowadays, as a web framework, it is mostly dead, but it lives on through email, where a few companies use it to send what Google calls ‘Dynamic email’. These emails have the superpower of being able to load in new data, or dynamically update their content. This is how Google Docs sends you comment notifications that update with repliese, and it’s how the Washingtion Post gives you a time interval since the event happened in their breaking news emails.

This led me to wonder: could AMP be used to enable better read-time tracking in email newsletters, even though AMP support is limited primarily to Gmail and Yahoo Mail?

So what if you could leverage AMP to do something that everyone wants to do in newsletters but can’t: better analytics.

Read time

To fully understand the magnitude of this opportunity, we first need to examine the current status quo for read time tracking in email.

Read time on the web is usually calculated with some javascript that runs on the page to detect when various actions occur, like scrolling, and summing up all the time spent by the user between entering the page and their last action. This doesn’t work in email because famously no javascript is supported. No dynamic scripting at all is supported, and everything has to be a combination of HTML and (usually inline) CSS.

Read receipts (which have become less reliable since Apple’s Mail Privacy Policy and Google’s image proxy) instead use a small unique image in each email, and a remote server records a request for that image as an indication that the email has been opened.

The best read time tracking you can get without javascript works similarly. A small unique image, but this time the remote server deliberately throttles data out to a very slow rate. It’s pretty error prone, and doesn’t work with things like image proxying. Any numbers you get back will be wildly inaccurate.

Enter AMP

AMP allows you to include some very specific kinds of interactivity in email. They have a list of components that are supported including cool things like dynamic lists, and autocomplete fields. This is how you can respond to a comment in your Google Doc from your Gmail app.

One of those elements is a carousel for images. Common to the web, carousels progressively slide or fade through images in a finite list. One of the magic things about the carousel in AMP is that the images are loaded progressively.

With this in mind, an experiment occurred to me. Could you create a carousel of X number of images, loading every Y seconds, and get up to X * Y duration tracking for your email? If you bucketed read times into something like ten seconds you would suddenly get a decent chunk of very valuable information as to whether your Substack essays are actually landing with readers as they spend a minute reading or if people are nope-ing out immediately.

Matt TK Taylor @tk.gg

Reading the amp email documentation, I have a pretty good feeling you could track time spent in email newsletters on Gmail through using a pixel-sized autoplay carousel and unique keyed images per user. You'll get buckets of five seconds. Anyone built this feature or prototyped it? #newsproduct

October 22, 2024 at 10:23 AM UTC

So I did end up prototyping this and it worked! Here’s a short video going through the feature:

Yes the first and last slide load at the same time as you load, but then, every five seconds on the dot a new request, the next slide, with a unique identifier.

You can test this too by running the code, putting yourself an AMP email together, and sending yourself a test AMP email.

How to use this

There’s a few things you’d need to do to enable this: firstly you’d need to get your sender approved to send AMP emails. It turns out that Google doesn’t allow just anyone to do this, and you need to send examples of the kinds of emails you’re going to send to them first to get your sending domains allowlisted.

Secondly you’ll need to actually build the tracking software yourself and deploy it at scale. My prototype is not going to be anywhere near enough, and if you’re going to do that you may as well at the same time take over the responsibility of open rate tracking from your ESP.

Each user and each send to that user is going to need a unique hash to identify that send and that user, and you’ll need to append this to the request for each of the images you include in your carousel. The rest can stay functionally the same as the prototype, but that’s quite a big ask.

Anyway, I don’t suspect I’ll actually convince anyone to do this further than the test that I’ve put together. It’s quite a lot of work. But I would love to hear about anyone with plans to give it a go. Please do reach out.

You can view the prototype proof-of-concept code on my GitHub here.