Track mass email campaigns

Question

Litmus released an email analytics service last month (may 2010).
See here: http://litmusapp.com/email-analytics

They boast a very cool "read rate" tracking: they can track normal reads, Skims, and Glanced/Deleted.

How can they track skims and glanced/deleted? This to me seems impossible :)

They also track forwards and prints. Prints are easy (they include a css @media print query with a bg image).

But forwards? I think this might be a combo between subsequent opens and different IPs/reffering URLs. However, this means that if I open my mail and re-read it from another computer, it counts as a forward. Any ideas on this one?

To summarize: Litmus Email Analytics says they can track email reads, skims, glanced/deleted, prints and forwards. How do they do it (skims, glanced/deleted and forwards)?

Tracking code: This is the code. You create a unique code for each list/campaign combination (so that you can track campaigns..) then you put the following html/css code before the tag of your email message.

<style>@media print{
 #_t { 
    background-image: url('https://a6.emltrk.com/XX0000XX?p');}
 }
 div.OutlookMessageHeader, table.moz-email-headers-table, blockquote #_t {
    background-image:url('https://a6.emltrk.com/XX0000XX?f')
   }
</style>
<div id="_t"></div>
<img src="https://a6.emltrk.com/XX0000XX" style="display:none" width="1" height="1" border="0" />

---

Test results:

With Gmail, print tracking works. Yahoo! somehow fails. Glances/Deleted actually works, I've tested.

Superstitious

If they IMG SRC a CGI-generated animated GIF (like a clock), they can measure how long the CGI is sending data to the reader and use that for skim/glance? – Educatee

If that were true, then if you would load the IMG URL in a browser... shouldn't it simply keep loading until you close the page? That isn't the case. PS: I've edited the initial post with the tracking code they give you. – Superstitious

Seriously, any input on this will be appreciated. I'm dead curious as to how they do this. Will keep testing and updating the initial post. – Superstitious

I've been testing more and the CGI gif seems like the only way. Browsers don't react that much to it... besides, it seems that it's just loading for a few seconds. – Superstitious

Answer 1

The code works in the following way:

<style>
/* Print stylesheet */
@media print{
    #_t { 
        background-image: url('https://a6.emltrk.com/XX0000XX?p');
    }
}
/* Forward stylesheet */
div.OutlookMessageHeader, table.moz-email-headers-table, blockquote #_t {
    background-image:url('https://a6.emltrk.com/XX0000XX?f')
}
</style>

<!-- Extra DIV -->
<div id="_t"></div>

<!-- Main Image -->
<img src="https://a6.emltrk.com/XX0000XX" style="display:none" width="1" height="1" border="0" />

There is an image that gets loaded when the email is viewed. This counts the "opens" statistic.

There is also an extra div (with the id _t) which is referenced from a stylesheet. The @media print section applies a background image when the email is being printed. The url of the image has the additional p attribute, which probably tells Litmus that the email is being printed.

The forward statistic is calculated in a similar manner: a background image is loaded when certain elements are present. Outlook matches the div.OutlookMessageHeader, something else (looks like Thunderbird perhaps, given the moz) matches table.moz-email-headers-table, and everything else matches blockquote #_t (using the additional DIV again). These elements are created by the email client when the forwarded email is being composed. The image is this time loaded with the f flag, which tells Litmus to calculate the forward statistic.

These statistics must be taken with a grain of salt, however: most email clients will block images of any kind until the user decides to show them. Most webmail clients will completely strip out any stylesheets, which makes the print and forward statistics irrelevant for clients like Gmail, Hotmail, and Yahoo! Mail.

I hope this makes sense! I haven't quite figured out the glanced/deleted statistic yet. When I do, I'll be sure to let you know.

Shell

Thanks for your answer. I had figured out the print tracking, and I understand your explanation regarding forwards. However you're right about the webmail clients: they don't allow for stylesheets - but you could embed the css inside the message (which may count as a spam trigger). Skims/glances can only be tracked with the slow-loading .gif, I'm pretty sure of that. As for deletes, still no idea - Litmus just seems to be tracking them exactly like skims, which makes sense. – Superstitious

I think deletes/skims just mean that the message was closed after a under a certain amount of time. They would track that with the .gif file as well. If the request for the gif was closed before it had finished loading, then the user skimmed or deleted it. Kind of a simple assumption, but I guess it works. – Shell

I do believe people might have achieved the "Read Rate" functionality for most of the platforms and thanks to this thread we did it too BUT tracking the Forward and Print has given me hard times, after spending much time doing R&D now I do believe all the limitations mentioned by Litmus stands still litmus.com/help/analytics/limitations – Mart

Answer 2

I think a nice way to track the time someone has the e-mail open is to simulate a very slow connection.

You can simply build a tracking handler which returns the tracking image byte by byte. After every byte flush the response and sleep for a period of time.

If you encounter a stream closed exception the client has closed the e-mail (deleted or changed to another e-mail who knows).

At the time of the exception you know how long the client 'read' the e-mail.

Hope this helps ;-)

Autarchy

This is a good idea. The only problem I have is that if I send 30k emails and get 1000 people to open them at almost the same time... that creates 10-20seconds of concurrent connections per person.... thats a lot of concurrent connections for a long time. Any ideas around this? – Hatfield

Answer 3

I wonder if for skims if it could request an image, but the src script sleeps for a few seconds, then does a 302 redirect to itself. It could count the number of times it got redirected, and stop redirecting after a certain amount of times to make sure the browser doesn't prompt with the redirect loop warning (but maybe browsers don't do that warning for images anyway, I've never tested it).

Roof

Yup, that's pretty much how they do it. – Departure

With gmail's new image caching/proxy this is out the window. – Roof

@JeremyWeir, Supposedly you can specify no-cache on your images now (see emailmarketingtipps.de/2013/12/07/…) so gmail should work. – Hatfield