SOLVED

Outlook Preview Pane - Counts as Open?

Go to solution
Highlighted
Level 10 - Champion Alumni

Re: Outlook Preview Pane - Counts as Open?

Any time an email - when images are turned on in an email client - contains a hidden tracking pixel and has the opportunity to ping the originating server (Marketo), it will be tracked as an open.  So yes, viewing the email in a preview pane will count as an open.  Which is why "opens" aren't a very reliable metric.  An email that someone deletes - but still has time to render quickly in the preview pane - will be counted as an open.  Which is why I would love to see a report like this available in Marketo someday - where it breaks down the types of opens by the length the email is being viewed:

pastedImage_0.png

View solution in original post

Highlighted
Anonymous
Not applicable

Re: Outlook Preview Pane - Counts as Open?

Second this!

Highlighted
Level 10 - Community Moderator

Re: Outlook Preview Pane - Counts as Open?

FYI, if you guys are interested in how such solutions usually work, it's pretty simple to build your own version of this in-house (though it's a huge infrastructure undertaking for a general analytics provider -- Marketo in this case -- to add this functionality for everyone).

The concept is simple: rather than accepting requests for the tracking pixel, sending the tiny 1x1 GIF back as quickly as possible, and closing the HTTP and TCP connections to free up those resources, instead the server "trickles" meaningless bytes of additional data back to the email client until the client decides to close (sometimes not cleanly) the HTTP/TCP connection.  The server will have a maximum wait time (like 2m maximum logged open time) after which it decides to stop measuring, but until that time it waits for the client to disconnect.

Once the server realizes the client has gone away (that's actually a sort-of technical term!), it counts how long it was able to successfully send bits of the never-completed "superpixel" and that's they derive how long the email was open.

The problem is that this architecture flies in the face of best practices for building high-traffic servers.  You normally need to end connections immediately after sending data to preserve the availability of your infrastructure (in the case of Munchkin, the servers sometimes forcibly disconnect even before sending data, since the response is not important to the browser, just the logging of the click/hit). Every open connection takes up critical resources.  If you serve images, you normally make them as small (compressed) as possible to get them out as fast as you can and close the connection.  So... the idea of leaving the connection open as long as the client wants it to be open can be catastrophic at scale.  Most webservers would get destroyed if every connection were allowed to linger for 2 minutes!

Anyway, for a single company's email load, you might be able to put something like this up on its own server.  It could be a single-page web app, probably in NodeJS or any other platform designed to maintain a high connection count. Then you could log the results to Marketo using some mkt_tok fun (it wouldn't be part of the click/open dashboard, of course, but you'd be able to action it).