Return to Answer

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 be tracked by a slowly-loading image. The server keeps 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. I haven't observed this slow-load behavior, but I also haven't taken a low-level look at TCP sockets, which might be kept open even the HTTP request completes (since the image is served with Connection: keep-alive.

Excluding this possibility, it appears that the code you've included doesn't track time spent looking the email. (Possibly time-tracking 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.

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.

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 be tracked by a slowly-loading image. The server keeps 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.

Excluding this possibility, it appears that the code you've included doesn't track time spent looking the email. the only other 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 manipultatino to the document structure that causes the CSS rule to apply). If this is the case, time-tracking will only work on Web-based mail, though.

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.

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 be tracked by a slowly-loading image. The server keeps 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. I haven't observed this slow-load behavior, but I also haven't taken a low-level look at TCP sockets, which might be kept open even the HTTP request completes (since the image is served with Connection: keep-alive.

Excluding this possibility, it appears that the code you've included doesn't track time spent looking the email. (Possibly time-tracking 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.

These sorts of email tracking mechanisms usually rely on detecting when the client requests resources (especially images). The CSS doesn't do any tracking by itself, but it may cause interaction with a server that does do the actual tracking.

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. Each email is given a unique tracking id, reflected in the image's URL. The company records how and when each unique image URL is loaded by a mail client.

• In the simplest case, we can record whether or not an email was opened by checking whether the image URL was ever requested by any client.

• For logging print operations, the @media print CSS directive includes a separate tracking image. This assumes that the tracking image will not be loaded until the user actually prints the email.

• Length of viewing time could be tracked by a slowly-loading image. The server keeps 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.

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.

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 be tracked by a slowly-loading image. The server keeps 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.

Excluding this possibility, it appears that the code you've included doesn't track time spent looking the email. the only other 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 manipultatino to the document structure that causes the CSS rule to apply). If this is the case, time-tracking will only work on Web-based mail, though.

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.