Last week Gmail changed the way they handle images in emails. Instead of Gmail making requests to servers every time images are loaded (this was the old way), Gmail image caching now caches email images temporarily. This helps Gmail display your emails faster, but initially it may have also impacted email marketing metrics.
So how does Gmail image caching impact your open rates?
Our technical team is here with the (geekier) details:
To speed up email rendering in Gmail, last week gmail started caching images. While Gmail’s image caching does not affect the way GoDaddy’s emails are displayed, it influenced the way we now track statistics. A change was required in order to track multiple views.
GoDaddy, like many other ESP’s, uses a small image to track stats for emails. Google saves image files from unique URLs temporarily and changes the image URLs in newsletters so they point to the cached images on googleusercontent.com. The reader’s browser then loads and displays Gmail’s cloned images. So when displaying the cached image, the request would no longer hit GoDaddy’s servers and additional views would be lost if we were using old tracking methods.
The Gmail image caching impact and solution
- Since Google recognizes that GoDaddy is serving an image, we were no longer able to track how many times a recipient opened an email, thus affecting the total views count. We only had the opportunity to see the first open by any recipient using the native web based Gmail interface. (see below for the fix).
- POP3 & IMAP clients were not affected according to our tests, but some Android & IOS clients could have suffered from similar problems. The user’s IP Address and user agent info could be lost. For those of you using the new iPhone app, geo tracking information was also influenced by this change. After some research and experimentation returning P3P mail headers with a zero content length resolves the problem:
Here are headers that are affected:
HTTP/1.1 200 OK
Date: Sat, 07 Dec 2013 14:49:19 GMT
Here’s the fix:
Changing the Content-Length and removing the content-type fixed it for us:
HTTP/1.1 200 OK
P3P: CP=”OTI DSP COR CUR IVD CONi OTPi OUR IND UNI STA PRE”
Date: Sat, 07 Dec 2013 14:46:13 GMT
Interestingly, removing the Content-Type Header has no effect but only returning Content-Length = 0 would result in an image that is not cached by Google.