Will AMP for Email survive the Privacy Wave — consumer awareness, public scrutiny, regulatory action, and changes in the technical landscape around data and control? I think not.
Being in email is a bit like driving an old car. You love the thing — admit it — but the big screens and shiny toys in newer models are k-i-i-i-nda cool. Ever since websites started going interactive, email folks have been jonesing for some kind of “interactivity” of their own.
AMP for Email is the latest, and (in some ways) most ambitious attempt to scratch that itch. AMP for Email does enable cool interactive functions and content controls that are new for email. There’s been some traction, and a small ecosystem of companies that have supported adoption.
Despite this, takeup of AMP for Email has not been robust. April Mullen of Sparkpost, in a recent MediaPost article, noted that “About 0.4% of our sending customers sent AMP mails over the past week.”
At a slightly broader level, the same MediaPost article noted issues with the umbrella AMP advisory committee. Web developer Jeremy Keith resigned from that committee in late August 2021, citing a fundamental concern that AMP is a Google product, not an open-source project.
I don’t think open-source-or-not is really the focal issue with AMP for Email, though; open-source is one thing, and standard is quite another. (I went “on the record” over a year ago with some reservations about AMP for Email. In case you’re curious — Google never responded.)
Is AMP for Email an “email standard.”? No.
The standards body for Internet “stuff” is the IETF (Internet Engineering Task Force). They create, publish, update, and end-of-life the published standards for the most complex system in the world, the Internet.
If your company is designing an email client and you want to use IMAP, the IMAP standards are on IETF.org. If you’re considering adopting BIMI, the draft BIMI standard is on IETF.org. If you search “AMP for Email” on datatracker.ietf.org, though, you’ll get “No documents match your query.” (Same for Accelerated Mobile Pages. I don’t know whether AMP, or AMP for Email, were ever submitted or considered at the IETF. I doubt it, but that’s not really material.)
Glacially-slow battles over standards — including Internet standards — have enormous long-term consequences. Fortunes have been won or lost over the long term.
In the first decade or so of widespread Internet adoption, for example, Microsoft stayed somewhat infamously on the take-it-or-leave-it side of IETF standards. The Redmond mantra in the late 90’s was “embrace and extend.” With sufficient market power, non-standard (spelled “proprietary”) innovations sometimes become de facto standards. Case in point — some of us are old enough to remember websites that worked “best” with Internet Explorer. That de facto brought de cash to Redmond, for a time.
As the digital space has matured, companies have gotten cagier about playing the standards game — but the basic pattern is still there. Some innovations are worth keeping proprietary; some may serve your company’s interest better as standards. Open-sourcing is an interesting middle ground, but the same dynamics are still at play. A company can open-source something and profit handsomely from the move; Kubernetes is a great case in point.
The broader social and legal context in which the digital space operates is maturing, though, and (arguably) starting to catch up. We’re limiting the technically possible for other reasons, such as privacy, national security and so on. For shorthand, let’s just talk in terms of the Privacy Wave.
Like everything, email — but especially email — is trending more toward “private.” (For example, Apple’s making a ruckus about email privacy, but the Apple.com website has pixels and cookies galore!)
The problem is, at a technical level, AMP for Email could be used for exactly the kind of feedback mechanisms that Apple (for one) has decided do not belong in email. As Ryan Phelan said recently, “You thought image pixels did a lot of spying…running Javascript/AMP in email = 100x that.”
It’s not that AMP for Email was designed specifically for “spying” — but Dunn’s Maxim says that if there’s a compute/scripting engine in an endpoint, marketers will start using it for their own nefarious purposes. (Just made that up — whaddya think??)
I also don’t see Apple ever enabling AMP for Email in their native client; it would completely contradict their privacy stance. So, in round numbers, that means @50% of Gmail opens will never enable AMP interactivity. I just don’t see AMP for Email surviving that on top of the other privacy trends.
There is a broader question here worth pointing out; how could “interactive email” come about? (Leave aside whether it should, whether it’s worthwhile, and so on.) Is there a technical path that would enable interactivity yet preserve user control and privacy? Are there companies who would benefit from this enough to devote the people and long-term involvement to pave that path through the IETF? Or is there an “industry body” for email that could spearhead such a movement?
Not everyone is clamoring for interactivity in email; I’m not convinced it’s going to happen. Real-time content has been available to email marketers for over a decade, and take-up of that has been rather slow.
I actually applaud Google for taking the shot, reservations or not. Big companies that keep trying bold stuff should be celebrated. Yeah, there’s a ‘Google Graveyard’, but (a) every company has a little pet sematary of their own, and (b) putting stuff out there in public, as Google has, is arguably a better test of product viability than internal committees.
We may see AMP for Email in that graveyard at some point, but — for now, at least — we have a way to see if scratching that interactive-email itch is really worth the effort.
Photo by Daniel Herron on Unsplash