Gmail started caching images (see wordtothewise.com and my post on emailmarketing.de): It saves image files from unique URLs temporarily and changes the image URLs in newsletters so that they point to the cached images on googleusercontent.com. The user’s browser then loads and displays Gmail’s cloned images. For marketers, this may lead to reduced tracking and marketing opportunities. Here is why.
Marketing issues from Gmail’s image caching
When Gmail loads images into the cache, the user’s device and geo information gets lost. An open will originate from a Mountain View IP address like 220.127.116.11. And the user agent, which normally holds the user’s device information, looks like ‘Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:18.104.22.168) Gecko/2009021910 Firefox/3.0.7 (via ggpht.com)’. This messes up your geo reporting map. It also limits opportunities to display customized banners to users on different devices (e.g. iOS versus Android) and users from different parts of the world (e.g. IP from Germany versus IP from the US).
Furthermore, images lie now static in Gmail’s cache- for hours or forever. Exchanging images on your webspace will not be visible to Gmail users until the cache is renewed. Think for example of offers, which are no longer valid, and of broken or wrong images that you want to switch. You can’t.
This also affects real time multivariate creative optimization and open tracking. When the tracking pixel is cached, another open from one tracking URL hits the cache, not the tracking server of your mailing software. This may lead to a decreasing number of total opens or, in extreme cases, to counting unique opens only.
Healing multiple opens tracking
As reported by Andrew from emailexpert.org, reduced open tracking does not affect every service. CampaignMonitor for example seems to be immune, whereas MailChimp tracks only unique opens as long as the tracking pixel lives in Gmail’s cache.
What do both do different? One could think of using different or additional means to track opens like requesting a CSS file or a sound file. But both seem to use just an invisible tracking image, which is placed at the end of an email.
Here is the HTTP header information from a CampaignMonitor tracking pixel:
HTTP/1.1 200 OK Server: csw Cache-Control: private P3P: CP="OTI DSP COR CUR IVD CONi OTPi OUR IND UNI STA PRE" Date: Sat, 07 Dec 2013 14:46:13 GMT Content-Length: 0
Here is the header information from a MailChimp tracking pixel:
HTTP/1.1 200 OK Server: nginx Date: Sat, 07 Dec 2013 14:49:19 GMT Content-Type: image/gif Content-Length: 35 Connection: keep-alive
I think the crucial difference is that the MailChimp server returns a resource of type ‘image’. That’s what Gmail is looking for. And that’s what Gmail caches. The CampaignMonitor server does – at first glance – not return an image. Gmail ignores it, and every call hits the CampaignMonitor server so that every open is counted.
Ergo: If you want to measure your total opens, don’t let your tracking URL return a resource
of type ‘image’ with a predefined content-length greater than zero.
Oops, my bad. Seems as if it was the content-length that mattered in my little test, not necessarily the content-type. Returning type ‘image’ with a length of 1 gets cached. Returning type ‘image’ with zero length is not cached. The same may work with undefined content-lengths. According to Andrew, SmartFocus and Lyris are not affected either. Their tracking pixels return a resource of type ‘image’ (see lyris, see SmartFocus), but no content-length header information. Anyway, tracking multiple opens is still possible. You’ll find out how, I’m not nerd ‘nough to nail it. 😉
Gmail changed their caching procedures in the past days. As Movable Ink points out, senders should be able to track multiple opens by transmitting a no-cache header, now.