Last month at WWDC, one of Apple’s smaller announcements caught my attention. It’s called Mail privacy protection:
Mail Privacy Protection helps protect your privacy by preventing email senders from learning information about your Mail activity. If you choose to turn it on, it hides your IP address so senders can’t link it to your other online activity or determine your location. And it prevents senders from seeing if you’ve opened their email.
Effectively, turning this feature on blocks open-tracking pixels. These tracking pixels have long been the way that email marketers, including us, learn whether or not a subscriber opened an email that they were sent.
It’s typically accomplished by including a transparent 1×1 pixel image in your newsletter. If the image is loaded, the database records an “open”, which might just mean incrementing an integer, but could also mean storing information such as the user agent or IP address in which the email was opened from.
Last year, the new email service Hey.com made blocking “spy pixels” one of their differentiating features. This was really the first time that I personally took a step back and thought about the privacy implications of something that historically had been an unquestioned part of how email marketing worked.
In 2012 when I built our internal newsletter system, we didn’t even think twice about building in open tracking. It was a standard feature in all services out there. Our old newsletter software had it. So it just made sense for us to have it.
However, Apple’s announcement was the tipping point that finally led to an internal discussion about the pros and cons of pixel tracking. We decided to remove it from Detailed Image’s newsletters, and last week the changes went live.
I should also point out that open rate data is directional at best. It never approaches being perfectly accurate like click through data can be. Users can block images in their mail client, services that use an image proxy can read the image without a person actually opening the email, and so on.
It wasn’t quite as open and shut case as some might think. Open-rate data can be useful even if it isn’t perfect. Here’s what we were using it for:
- Mail client data – this can be determined using the user agent, which we did save each time a user opened (we did not save IP address). Knowing which clients your users are opening email with is incredibly helpful for design purposes, especially because email is notoriously hard to design for.
- Subject-line split tests – the ultimate test of a subject line is “was it good enough to cause the user to open the message?” We do a lot of subject line split-tests, and open-rate was the primary metric that we’d use to determine success.
- List purges – we have a system that automatically unsubscribes people from our list if they go a certain amount of time without opening or clicking on a newsletter.
Those are fairly benign use cases, however a new customer doesn’t know that. And, despite being important, they’re not mission-critical pieces of data, and they can’t be relied upon to be accurate (even more so now with Apple’s new feature).
An added bonus was lightening the load on our server. Each time a user or a mail service requested that image, we had to update the database record associated with that newsletter. Occasionally an image proxy would go haywire and hit our server all at once (for example, if we had 5,000 Yahoo subscribers and Yahoo’s image proxy loaded all 5,000 tracking pixels at once, that could overwhelm the database by triggering 5,000 queries).
We want to be on the right side of history when it comes to privacy. We didn’t want to leave this as a default while everyone else removed it first. We didn’t want mail apps notifying customers that a tracking pixel had been blocked from our brand, and therefore have customers mistakenly associate us with invasive tracking practices. It became clear that it was the right thing to do.
- Apple Pay and Google Pay Now Live – Step 2 of Our Braintree Integration
- We Recently Migrated Detailed Image to Braintree Payments: The Good & Bad From This Large, Unplanned Project
- Programming Debt Paid
- In-Depth: Overhauling Our Dropship System
- Memorial Day Madness – When Systems Get Pushed to the Limit