I had hoped to blog about something else today, but this still seems to be a big concern for a number of people. There are a lot of questions running around, some of which we don’t have answers to, others of which we have answers based on some evidence.
It’s important to remember that we’ve seen Gmail roll things out and then roll things back and do phased transitions during deployment. What various people are reporting about images and caching and headers are accurate at the time they are tested. But they may not be accurate tomorrow or in a week or in a month.
I’ve also discovered through this process that a lot of different providers use significantly different image tracking in order to record image loads. Some of these techniques seem to be more resistant to Google’s new image loading process than others.
Why is this all so important?
Image tracking has become a fundamental part of email marketing. It’s something that can be measured, and so a lot of marketers evaluate the effectiveness of an email send based partially on open rate.
How does open tracking work?
For open tracking, ESPs inject a uniquely tagged image into the email. When the recipient opens an email and has images on, the email client calls to the sender server and asks the sender server for all the images in the email. When the tagged image is returned to the recipient, the server records an “open.”
How does caching break open tracking?
Caching means that only the first load of an image is provided by the sender’s server. Subsequent loads of an image are served by the caching proxy. Caching proxies are nothing new; they just haven’t affected email enough in the past for us to have to talk about it.
Why are some people reporting zero problems?
The first load of a unique image always happens. Some folks don’t measure repeat opens, so they’re not even noticing any changes in their reporting thus are saying they’re seeing no problems.
What else is image tracking used for?
Image tracking can also be used for device detection by reading the “user-agent” string that each device returns. Gmail is currently rewriting the “user-agent” string thus breaking all device detection. The string is unique enough that it would be possible to tag those opens as “opened through gmail web interface.” Gmail may decide to pass through the user agent in the future, the HTTP standard does allow for that.
Image tracking can also be used for geolocation. Some senders use the location of an IP address to return images relevant to a user’s location. The accuracy of geolocation is totally dependent on the accuracy of the IP to location database used; it is a best guess of the user’s location. Gmail is currently not passing through the user’s IP address when requesting the original image. I don’t expect them to start, given they also don’t reveal user IPs when Gmail web users send mail. This falls in the same category of privacy protection.
Is there a workaround?
I have heard of a few people claiming they have a fix. The problem is all of the fixes I have seen involve doing things that violate the HTTP RFCs. For instance, the “fix” or “workaround” discussed at E-Mail Marketing Tipps is to not send back an image at all. This is working now to track repeat opens, but Gmail may adapt and block this as well. It’s also possible that Gmail may decide people trying to “work around” Gmail’s cache should be blocked outright for violating the HTTP spec.
Where can I find more information?
Other blog posts on the issue, including research on what people have seen.
- Litmus: Gmail Adds Image Caching: What You Need to Know
- Return Path: Google’s Image Caching – Much Ado about Not Much?
- Email Marketing Tipps: Gmail’s image caching: How it affects email marketing & how to heal your opens tracking
- Zettasphere: Google Gmail change Breaks Email Open Tracking
- ExactTarget: Gmail Now Caching Images
- MailChimp: How Gmail’s Image Caching Affects Open Tracking
- EmailExpert: Gmail Breaks Email Marketing Again
- Frenzy Commerce: Gmail image changes: everything email marketers need to know
RSS - Posts
[…] technical details have been posted by Laura Atkins (Word to the Wise), Jeff Batte (DEG) and Andrew Bonar (Email Expert) who reports that some but […]
That’s a very critical change and many email marketing/tracking services must have got disrupted. Can having expiry date to HTTP will help here..?
I’ve seen tests that indicate Gmail is currently ignoring expiry and no-cache headers. That doesn’t mean the cache never expires, just that it seems to be expiring on Gmail’s time not based on the HTTP headers.
The “why are some people seeing Zero problems” doesn’t read like that answer is finished. Is there more?
I think the fear of being blocked is overstated. As a legitimate permission based email marketer it is extremely unlikely that Gmail would have them “blocked outright” for potential RFC ‘violations’.
There is also a workaround available for geo-location tracking.
Device.. not as far as I am aware
Fixed it, Andrew. That was part of an edit and I didn’t remove enough. Yesterday I was going to talk more about what people were seeing and was talking to a bunch of folks yesterday about it. Unfortunately a lot of what the internal ESP people are telling me contradicts what their PR departments (and a lot of bloggers) are saying is FACT at those ESPs. I decided not to get in the middle of that particular mess because if account managers are telling customers and the public that “we’re not affected” and your technical people are telling me “of course we’re affected” there is no good to come from making it public. Discretion. Valor.
I saw what happened once when an internal political / technical battle about email delivery made it into the popular press. It was ugly and people lost their jobs. I’m not going to be part of that.
I cannot comment to other ESP’s but what I have been reporting as fact at Campaign Monitor is certainly official (http://www.campaignmonitor.com/blog/post/4118/how-gmails-image-display-changes-will-affect-your-reports). I have tested it just and it still works (recording multiple opens from the same recipient within a 15 second window from the same device).
Where does it say in the HTTP RFC you cannot provide an empty image/data-length=0 ?
From what I have read “Any Content-Length greater than or equal to zero is a valid value”
Section 4.4 says: “When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body.”
If you’re not sending anything (content-length=0) then I see no problem with saying that content-length=0. If you’re sending (or attempting to send) an actual image, then your content-length MUST (in the RFC specific sense of ‘must’) reflect the actual number of octets you’re sending.
Thanks for clarifying. We are sending nothing and stating content-length=0
Therefore no violation of HTTP RFCs from what I can tell
Violations aside, if you process the image request but don’t actually send an image, doesn’t that result in a “broken image” icon showing in the recipient’s email?
“doesn’t that result in a “broken image” icon showing in the recipient’s email?”
Only if the image is visible to start with.