22

This email analytics company offers an 'engagement metric' that shows how much time someone spends looking at an email, whether the email is printed or deleted.

They also claim it works in pretty much all email clients, be it web, desktop or mobile.

Looking at an example for the tracking code (first link), I can see how they track prints, but how do they track how long you have been reading the email and whether or not you delete it?

Email tracking code

makerofthings7
  • 50,090
  • 54
  • 250
  • 536
Cleber Goncalves
  • 403
  • 3
  • 7
  • 7
    Can you replace the image with the code, after changing the urls? – TankorSmash Mar 13 '15 at 17:37
  • 1
    eye tracking css?, cool :) – Felipe Pereira Mar 13 '15 at 19:06
  • 1
    If you watch the [video](http://www.emailonacid.com/blog/details/C13/emailology_getting_started_with_email_analytics#video) at the end of the [article](http://www.emailonacid.com/blog/details/C13/emailology_getting_started_with_email_analytics) you can see that there actually quite a bit of `styles` that are generated. Bottom line is that you do not have the entire picture here. You can very simply signup for the free trial and reverse engineer the code yourself but personally, I'm too lazy to stop eating my taco and grab my credit card... – Matthew Peters Mar 14 '15 at 00:21
  • 1
    They're quite creative in terms of violating user privacy... if only they used that creativity to do something users would actually enjoy. –  Mar 14 '15 at 05:38
  • 1
    @TankorSmash The site didn't offer code to copy, unless you sign up, only that image. Do you want me to retype it here after hiding the real URLs? Any particular reason for that? – Cleber Goncalves Mar 14 '15 at 08:46
  • 1
    Good email clients will not load external files by default. – CodesInChaos Mar 14 '15 at 15:04

2 Answers2

29

The email includes references to an externally-hosted images, like http://example.com/[tracking_id].png, where the tracking company controls the server hosting the image. The company records how and when each unique image URL is loaded by a mail client.

As you've noted, print operations can be logged by a tracking image in the @media print CSS directive. This assumes that the tracking image will not be loaded until the user actually prints the email.

Length of viewing time could theoretically be tracked by a slowly-loading image. The server would keep the HTTP response permanently unfinished, and it is only terminated when the user navigates away from the email. The server can log how long it took for the client to terminate the connection. However, I haven't observed this slow-load behavior in HTTP. It might be possible to do something similar with TCP sockets, which might be kept open even after the HTTP request completes (since the image is served with Connection: keep-alive), but my initial research suggests that the TCP connections may be kept alive after navigating away from a page that requested that keep-alive resource.

Excluding this possibility, it appears that the code you've included doesn't track time spent looking the email. Possibly time-tracking is a premium feature not enabled for this tracker.

The only other (mildly ridiculous) possibility I could consider is that the /F resource is somehow loaded when a navigation action is performed (i.e., the navigation action causes a manipulation to the document structure that causes the CSS rule to apply). If this (quite out-there) theory is the case, time-tracking will only work on Web-based mail, though.

Finally, they don't have ability to detect deletions. That article simply assumes that a user who has spent less that 2 seconds looking at an email has deleted it.

apsillers
  • 5,780
  • 27
  • 33
  • 7
    It also relies on HTML email being enabled and the images being loaded. I know in my client, I don't do either by default. – Mike Mar 13 '15 at 19:12
  • 2
    I knew all the other answers, but the slowly-loading image one is new to me. Fiendishly clever. – Bobson Mar 13 '15 at 20:25
  • 4
    The "slow-loading image" is a clever idea, but it doesn't appear to be what's actually going on here. If you try downloading the image at the URL listed in the question (`https://eoapxl.com/Dpdr2Dw110/`), the analytics company doesn't seem to be doing what you described. That URL doesn't lead to a slowly-loading image: instead, it loads a 43-byte 1x1 GIF that downloads immediately and contains nothing special. Am I missing something? Do you have some evidence for the "slow-loading image" hypothesis? – D.W. Mar 13 '15 at 20:25
  • 1
    As for the rest of the answer, the OP says they know how this enables them to track opening of the email and whether it is printed; they want to know how the company knows how long the email was open. So it looks to me like this answer doesn't seem to answer the question: it has a clever idea that this company doesn't actually seem to be using, plus some other comments that are accurate and good background but aren't what the question was asking. Clever thinking, though. – D.W. Mar 13 '15 at 20:26
  • @D.W. Nope, you are correct that this is 100% speculation. I emailed it to myself on Yahoo mail and didn't see any slow loading there either. I've slimmed the cruft, added an even more ridiculous theory (with caveats about how unlikely it is) and admitted the possibility that maybe this code doesn't actually do what the site says (maybe some other code used by the company does). Also, possibly time-tracking is a premium feature that doesn't apply to this tracking ID? – apsillers Mar 13 '15 at 20:59
  • @D.W. Also, I want to look into `Connection: keep-alive` and see how a server could possibly track the termination of the long-lived TCP connection, even after the HTTP request completes. – apsillers Mar 13 '15 at 21:04
  • 1
    The image's download time has nothing to do it; when you hit that URL it could trivially generate a server-side session, serve you the image, and then just maintain a sleep loop until you close the session. – Kyle Hale Mar 13 '15 at 21:12
  • 2
    @KyleHale Could you clarify what kind of session you're talking about (e.g., TCP)? In particular, I don't see how the server knows when to close the session based on a navigation action in the client. – apsillers Mar 14 '15 at 03:49
  • @apsillers In PHP, for example, you can register a shutdown function that gets invoked right before the exit() command on the server side. So user closes page, PHP unloads whatever it has in memory, kills threads and connections, etc, then calls its registered shutdown functions, then exits. – Kyle Hale Mar 14 '15 at 05:06
  • @apsillers And not a TCP session, a "session" in web dev world is just maintained state across requests, either via cookies or URL parameters. In this case, even though your request is complete, your session lives on and as identifiable server side, and the sleep loop updates some variable in the session saying how long it's been active ie the image is open ie viewing activity. – Kyle Hale Mar 14 '15 at 05:11
  • 3
    @KyleHale sure, but an HTTP session does not (necessarily) have a defined end. Doing so would require the client to send the server a request which explicitly prompts it to discard the session, which is not something one can expect from an email client. So the server receives nothing that would tell it how long the client keeps that email open. – David Z Mar 14 '15 at 05:48
  • Agree with @DavidZ, the HTTP session will have to timeout before php can kill it. – Cleber Goncalves Mar 14 '15 at 08:41
  • 1
    @KyleHale Could you clarify what you envision happening *on the network level* when the user closes the email that lets the server know the session is over? DavidZ has captured my "I don't see how the server knows when to close the session" concerns. A session maintained between requests is useless, because there may only be one request when the user opens the email and no further request when the user closes it. You could keep the initial request alive, long-polling style, but that's exactly what I'm suggesting with the "slow load" approach. – apsillers Mar 14 '15 at 11:03
3

I get these questions from clients on a regular basis. The fundamental problem is that any email tracking technology requires cooperation from the client. The other answer dissected the image tracking so I won't repeat it here, other than to point out that the client must load the image from their server (said server is now on my block list).

Web-based email clients will fight you tooth-and-nail on css issues, so they probably have an inline option or just tailor delivery based on the recipient's MX record. Desktop clients usually have a "download images" option, very easy to turn off.

So, it's possible to know (or guess) what the reader did with your message IF they cooperate with you. If 40% of your messages come back as "unread" it doesn't mean they weren't read, it just means the client didn't tell you if they were read. Similarly I can see a virus scanner grabbing everything to process it being interpreted as "read and deleted".

paul
  • 195
  • 1
  • 2