Suppose you are sending mass emails (legitimately, no doubt) and want to know which % of recipients actually viewed the email. The standard trick here is to embed a 1×1 image into your email’s HTML source, with the <img src= pointing to a location on your Web server with part of the URL unique to the user (e.g., <img src="http://example.com/track/12345" /> where your mailing system knows that 12345 is associated with firstname.lastname@example.org). When the user opens your email, most email clients will send your server a request for that image*, and voila—you know that the recipient opened it. It’s also quite easy to determine which operating system + mail client combination was used to open the email, by inspecting the HTTP request headers.
But what if you want to track engagement time, i.e. the time the user actually spent reading your email**? This is a valuable metric that can tell you how your messages are working across different groups of users and how engagement times are translated into monetized actions.
This sounds more scary—but here’s another simple trick I’ve seen as recently as yesterday. Embed the same 1×1 image into your HTML source, but this time your Web server needs to be somewhat smarter. When it receives a request for the image, it should return a 302—Moved Temporarily response, with a new URL for the image. When the browser hits that new URL, your Web server returns yet another 302 with yet another URL. This continues until the client gives up—which is usually when the user closes your email.
|Client (browser, email client)||Server|
|GET /track/12345||302 Moved Temporarily
|GET /track/12345?n=1||302 Moved Temporarily
|GET /track/12345?n=2||302 Moved Temporarily
|…you get the idea…|
The server, on its end, knows the exact times of the requests received from the client and can track not only the fact that the email was opened, but also the engagement time, as defined above.
Is this a legitimate tracking mechanism? In the era of persistent cookies, cookies that stay with you even if you’re logged off the website, tracking that relies on ETags even if you have turned of all cookies and cleared your Flash and HTML5 local storage—it is probably a little naïve to talk about whether a simple image embedded in an email is a legitimate tracking technique, from a morality standpoint.
However, I think it makes sense to discuss the cost of this mechanism, from the client’s perspective. Unless the Web server throttles the request rate by delaying the response as much as possible, the client will issue requests as quickly as it can. Suppose that the RTT is 300ms, and suppose that each request-response exchange takes 1.5KB. That’s a transfer rate of 4.5KB/s, or 270KB per minute. Over a broadband connection at home this is not something to worry about. However, over a GPRS data connection with a limited data plan, or—heavens forbid—a roaming connection, this is a non-negligible amount of data.
Other considerations that come to mind are the CPU and network utilization from a power management perspective. When the email client keeps issuing requests, the network card is probably unable to enter a low power state even if everything else on the system is idle. On mobile devices, tablets, or laptops this may have an effect on battery life (although not as bad as playing Angry Birds :-)).
* Well, actually many email clients have a setting that blocks remote images. And of course there are plain-text email clients that don’t render HTML emails at all. But let’s focus on the users you can track.
** To be accurate, we will see how to determine the time elapsed from the moment the user opened your email to the moment she closed it or switched to another email. Tracking the time the user was actually reading the email requires more sophistication—perhaps eye-movement tracking through Webcam?—that is left as an exercise 🙂