Open Tracking
Implied permission
Codified into law in CASL, implied permission describes the situation where a company can legally mail someone. The law includes caveats and restrictions about when this is a legitimate assumption on the part of the company. It is, in fact, a kludge. There isn’t such a thing as implied permission. Someone either gives you permission to send them email or they don’t.
We use the term implied permission to describe a situation where the recipient didn’t actually ask for the mail, but isn’t that bothered about receiving it. The mail is there. If it has a particularly good deal the recipient might buy something. The flip side of not being bothered about receiving mail, is not being bothered about not receiving mail. If it’s not there, eh, no biggie.
Implied permission isn’t real permission, no matter what the law says.
Now, many deliverability folks, including myself, understand that there are recipients who don’t mind getting mail from vendors. We know this is a valid and effective way of marketing. Implied permission is a thing and doesn’t always hurt delivery.
However, that does not mean that implied permission is identical to explicit permission. It’s one of the things I think CASL gets very right. Implied permission has a shelf life and expires. Explicit permission doesn’t have a shelf life.
Implied permission is real, but not a guarantee that the recipient really wants a particular email from a sender, even if they want other emails from that sender.
Gmail image caching update
Late last year Gmail started caching images on their servers, breaking open tracking in some circumstances. This image caching was good for senders, in that images were back on by default. But it was also bad for senders because it broke dynamic content and didn’t allow for tracking of multiple opens by the same recipient.
According to a new blog post by Moveable Ink this issue has now been resolved and Google is respecting cache headers so senders who are using dynamic content or want to track multiple opens can do so.
FAQ about opens and Gmail caching
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.