Email is the most widely used personal communication channel on the globe, with over 3.8 billion people sending more than 280 billion messages each day. The technical standards that enable this massive message exchange are not ‘owned’ by anyone; by and large, they remain open Internet standards.

Google currently provides the most widely-used email client in the world — Gmail — with over 1.2 Billion users worldwide. Used for both individual gmail.com addresses, and the company’s G Suite business applications, Gmail is recognized for innovation, features, and ease of use. Gmail.com addresses are free; G Suite is a paid service, with over 3 million users driving over $100 Billion in revenue. 

In 2019, Google announced “AMP for Email”, offering a subset of the Accelerated Mobile Pages technology stack the company championed earlier for faster, richer mobile web pages as a route to innovation for email.

With AMP for Email, Google proposes enabling new capabilities for email, providing “modern app functionality” by implementing a restricted set of interactive components within email, running “on top of” HTML, CSS, and JavaScript. 

AMP for Email code standards are open source, under the purview of the OpenJS Foundation. Sending AMP emails requires sender registration and validation. To be clear, AMP for Email is not an Internet standard from the IETF; it is a technology solution created by a vendor. Use of AMP for Email — sending AMP messages to Gmail users, for example — requires registration with and approval from Google.

Other email client providers are considering the benefits AMP for Email might provide to their users. The most notable is Microsoft, whose official position is “AMP for email is a new email format that we are evaluating.” Others, including Mail.ru and the remnants of Yahoo mail, are farther along with adoption and public support. On the supply side, a number of email service providers have added AMP authoring support to their platforms.

This article analyzes the long-term implications of AMP for Email and examines some potential consequences of widespread adoption. My arguments are from an outside analyst perspective; I don’t work for Google and have no inside knowledge about their objectives.

I’m not “anti-Google”; I quite admire what the company has accomplished and make extensive personal and professional use of their business services and cloud-computing platform. I use Google’s search tools constantly. On balance, however, the potential endgame of AMP for Email and the effect that widespread adoption might have on email as a communications channel, concern me.

The Market Structure of Email 

Email is one of the last “free-range” Internet standards in common use — the mustang, if you will, eyeing the encroaching barbed wire. While that’s a fanciful image, I think the market structure of email in contrast with other Internet standards bears it out. 

Most Internet channels now have from one to a few commercial gatekeepers in a dominant position:

• Websites and blogs: Google
• Social: Facebook and LinkedIn
• Video: Google
• Advertising: Google and Facebook
• Music: Apple and Spotify.

Anyone can launch a website or blog, accessible by a browser, but practically speaking, search is what makes it visible and trafficked. Anyone can shoot a video, but to have it viewed en masse entails hosting it “for free”, generating ad revenue (and continued market dominance) for YouTube. Songs, photos – go down the list and it’s obvious that we’re moved beyond the Wild West / free-range stage for most channels and forms of content.

While they don’t necessarily dictate the technical standards of the channels, pragmatically speaking these dominant players have to be dealt with (at a cost of some sort) to use “their” channel. This is natural evolution — arguably even a natural structure for dynamic systems, visible in everything from rivers to lightning.

Then there’s email.

Unlike these other digital channels, email is still free-roaming and commercially unfenced. An individual can get an email address from a myriad of services or set up their own. A $25 Raspberry Pi device and $10 GoDaddy domain could — in theory but probably not in practice — be used as an email server. With permission, businesses can send messages directly to people with email addresses from any of thousands of platforms. 

Unlike other digital channels, no select-few gatekeepers levy a toll or control access. With 200+ email service providers, hundreds of CRMs, and an untold number of platforms from Accounting to Zoo Management that also send messages, email has remained relatively open and decentralized. A business can build a highly-effective email program on any of these platforms — they just need to earn permission and send useful, interesting content.

The mustang is getting old though; frontier market structure, frontier features. From the end-user’s perspective, email has not evolved significantly for quite some time. While email use and the volume of messages perpetually climbs, email itself seems frozen in time and technologically “stuck”.

Those two things — open-range market structure and lack of visible innovation — bring us back to AMP for Email and Google’s strategy.

AMP for Email Viewed Through Aggregation Theory

Ben Thompson of Stratechery coined what he calls “Aggregation Theory” about five years ago. In brief, aggregation theory proposes that the Internet has turned the supply/distribution equation on its head. When distribution had a cost — printing newspapers or running broadcast stations — dominant players controlled both supply and distribution. With the Internet, distribution costs for digital goods are essentially free. The dominant Internet players — “Aggregators” — gain control over attention, interest, and habit; in short, dominance through aggregation of demand.

Aggregation Theory visual from  https://stratechery.com/2015/aggregation-theory/

 In Thompson’s words:

“The best example of an Aggregator is Google. Google offered a genuine technological breakthrough with Google Search that made the abundance of the Internet accessible to users; as more and more users began their Internet sessions with Google, suppliers — in this case websites — competed to make their results more attractive to and better suited to Google, the better to acquire end users from Google, which made Google that much better and more attractive to end users.

“Notably, unlike platforms, Google is not essential for either end users or 3rd party websites. There is no “Google API” that makes 3rd party websites functional, and there are alternative search engines or simply the URL bar for users to go directly to 3rd party websites. That Google is so influential and profitable is, first and foremost, because end users continue to prefer it.”  

—A Framework for Regulating Competition on the Internet

As Thompson has written in other columns and articles, making the consumer experience so much better that it becomes a dominant preference is the key to winning the Aggregator slot. Facebook aggregates the attention of its users; advertisers have to both pay and play by Facebook’s rules (and changes thereof) to reach them. Apple’s obsessive focus on the iPhone experience has won them most of the profits in mobile. With “the consumer in control”, as marketers like to say, the company that best satisfies the consumer monopolizes demand rather than supply. 

How does aggregation theory apply to email and AMP?

As noted, Google earned the dominant spot on the email client side of the equation with their continual innovations in Gmail. Free cloud email storage was initially an outrageous idea; thanks to Gmail, it’s mainstream. Seamlessly syncing email across devices used to be difficult; Gmail erased the thought. Searching thousands of messages, foldering, “filtering” — the feature set just keeps expanding. Over time and guided by data from many experiments and a few key acquisitions (Inbox), Gmail has become the email client of choice. Doubt that? Ask a millennial what email client they use and prefer.

In aggregation terms, Google has nailed the functional consumer experience of the email client.

But up to now, the content that actually creates the value of that experience has not come from Google.

That seems like a hair-splitting distinction, but it isn’t. Let’s put it this way. If you had a Gmail client, and never got any email, would you use it?  Not much, I suspect. It isn’t the email client experience that brings you to the Gmail tab, but the email in the client. What your friends and colleagues write in messages, and what your accepted merchants design in the way of offers and content, are the key experiences. 

However, if the experience of Gmail message content becomes noticeably superior to “regular” email content, the potential for Aggregation rears its head. That’s the heart of what I think Google has in mind with AMP for Email. Dominant market share of the client alone hasn’t made them an aggregator of the email channel — at least, not a capital-A Aggregator or Super-Aggregator per Ben Thompson’s formulations. 

Let’s parse that in a bit of detail.

Is Google in a control position for email already? Partially, yes. For example, Google automatically adds a “Promotions” tab (aka folder) to the Gmail client. It’s not an email standard; adding this folder is Google’s decision. Google algorithms decide what messages go in that tab, and what messages go in the Inbox. Email marketing professionals somewhat dread having campaigns routed to the Promotions tab, because people are far less likely to look at Promotions messages than Inbox traffic (As much to the point — being routed to Promotions, or not, starts them down the exhausting guess-Google’s-algorithms road already worn smooth by web SEO budgets).

Between email overload and choice fatigue, Gmail users basically don’t bother arguing with the notion. Although there are controls to defeat or manage Promotions routing, people rarely know of them or use them intentionally (Simply dragging a message from Promotions to Inbox signals Google to route future messages from that sender to the Inbox). Google algorithms decide, and will continue to decide, what messages come to the immediate Inbox attention of Gmail users.

Viewed sideways, folder placement of inbound email apes the search engine strategy that won Google the web and applies it to the nominally private world of your email. If your web page doesn’t make Page 1, visits drop; if your message doesn’t make the Inbox…?

Just as brand marketers have been playing keep-up-and-pay for their website to be found via search algorithms, email marketers are starting to play the somewhat futile game of keep up for their messages to be “found” via Promotions algorithms. 

Under present regulations and definitions of monopoly, since consumers are opting for the Gmail client experience, there’s probably little point in crying foul over this. But as an indicator of the strategic outcomes for the much deeper game of AMP for Email, it’s sobering. A huge company with cash flow from a monopoly position can afford to put expensive development resources into long-term bets. Those are rarely bets for the generic “good of the Internet” — in fact, they have a fiduciary responsibility to invest those bets on innovations that will ultimately improve their business.

What Might AMP Adoption Gain Google?

I’ve laid out technical risk issues about AMP for Email in a separate essay; in brief, to my mind it’s “a half step with whole risks.”  Whatever the nominal security mechanisms, AMP turns email into a Turing machine, with the JavaScript language and DOM as the potential “attack surface” for undesired operations. Leaving those technical flags aside...where might AMP take email in terms of market structure?

Viewed from Google’s vantage point, I think AMP for Email looks something like this:

We’ve got the dominant email client, and the largest set of email-client users in the world. The email message experience has lagged behind the experience and capabilities available in other channels; email messages are barely functional and not really interactive.

If we create a technical innovation that provides functional and interactive capability, and make that capability work best on our client, we will likely gain even more users. We can open-source the technical standard to get broad take-up, but in a fragmented “Wild West” market like email, there are few companies with both the development resources and client market share to match the experience we can offer.

A limited scripting language in the client creates the platform for a better experience, and also for more-granular user data. If the standard is widely successful, we secure the first-mover position in “interactive email”, and we are in the superior position to exert technical control over the standard, open-source or not. To address concerns about adding scripting to email, we can argue that limiting the scripting language makes it less risky.

Does AMP Fit the Email Marketing Cycle?

Yet despite its rustic feature set, email remains the most effective digital marketing channel. Without “app-like functionality”, limited interactivity, and feeble-at-best media tools in comparison to the Web, email still manages to be the best way for businesses to engage their markets and customers.

Email marketers’ perspectives on AMP, in general, tend to focus on the new capabilities it enables — more/better interactivity, richer visual experiences and the potential for in-email actions and transactions.

Put another way, the marketing and positioning of AMP suggests that finally email marketers can do some cool stuff that’s difficult (or impossible) today. But I’d suggest that AMP is actually a poor fit for the capabilities most needed for email marketing, and an even poorer fit for the organizations that do the email marketing work. It’s a super-narrow technical funnel that’s ultimately good for Gmail’s ecosystem dominance, but it doesn’t solve the problems that businesses would most like to solve with email, or suit the resources and organizational structure they bring to bear on it.

Generalizing considerably, I’d argue that the online marketing/business cycle (+org structure, +resources) usually look something like this:

Website teams and email teams are usually separate; their expertise, technologies, budget, and other resources don’t overlap much (Doubt that?  If your email lists are separate from your website customer records, that’s a pretty good indicator). If a company is big enough to have software development resources in marketing, they are more likely to focus on the web site than email.

Email is the most effective driver of engagement and attention, but (generalization) much of the time the desired outcome of email campaigns is getting customers back to the web site. Websites do a better job gathering customer data; the data “picture of the customer” on the email team is usually separate and less detailed than that on the web site.

Case in point: the email system at my preferred outdoor retailer (of 10+ years) “knows” my email address, but apparently not my gender or preferred activities. The website “knows” that I’ve purchased mainly fishing-related gear and clothing for males, but I still get generic emails which are not personalized for gender or buying preferences.

That web-vs-email division of duties poses this question: if this retailer decides that “app-like functionality” in email is going to grow their business, where exactly is that supposed to fit organizationally? Who will be doing the AMP for Email software development? Where’s the data to drive these functions? What, ultimately, would I be doing via interactive email that grows business? 

Is the idea that I’d be buying a new fly rod without leaving my email client, by means of an AMP for email carousel? Compelling soundbite, but far-fetched at best. Is all of the data, security, transaction and identity painstaking assembled on the web site going to be forklifted into my inbox? AMP scripting doesn’t allow for that.

Perhaps the idea is that I’ll be able to browse fly rods without leaving my inbox, and then buy from the website if I find a suitable selection. Well...OK...the email team doesn’t even know I fish as of today, so they’ve got a huge amount of work to do just to get the right pictures & preferences in that AMP carousel. That work wasn’t (apparently) worth doing today in outbound emails; why is that equation different with a carousel in the client?

But It’s an Improvement in Email, So It’s Good!  Right?

Superior execution winning market dominance is the game of capitalism; this is fair play under the present rules. But I don’t think Google dominating the email channel as they have others is completely inevitable. There are factors in the game that aren’t fully accounted for yet.

Email traffic is an oddball mix of personal, business, commercial, transactional and (above all) unwanted SPAM traffic. Whether it’s a personal inbox or a business mailbox, most people end up with the mix, and manage it as best they can. But the purpose of different kinds of messages affects the form and function of those messages.

AMP for Email proposes to give email clients “app-like functionality.”  That is a bit of a misnomer; it would probably be more accurate to say “web-like functionality.”  The currently approved AMP components include forms, UI controls, media, and dynamic content — implemented like and with some of the capabilities of a modern web page.

That last phrase - “a modern web page” — says a great deal about the likely uses and users of the functions that AMP for Email would enable. 

Person-to-person email may use AMP functionality if it’s available in the client, but consumers aren’t likely to do any AMP “coding” on their own — any more than they are likely to do web development for each other. It’s hard enough to write a succinct, compelling email message - who has time to code them??

AMP for Email could create a platform for “tools for users” — in fact, I think that’s one of the key aims. The proposition there is not that consumers would write AMP components, but that they could use AMP-enabled functions to do new things, person-to-person. If you’ve used Gmail and received calendar invitations, you already have some idea what this might look like. Gmail already provides simple actions like one-click confirmation for calendar appointments.

AMP for Email would enable a broader range of these functions by introducing a (limited) programming toolset into email. Those limitations, I would argue, signal quite a bit about the intentions behind AMP. The intimacy and broad reach of email make “interacting” more via email a natural notion. 

I like the fact that accepting a meeting on my Google Calendar can be done without leaving my Gmail client. I can envision many other useful functions — so can you, I’m sure. If they only work in Gmail, or if they work best in Gmail, there’s an invisible price for that convenience.

Improving the things consumers might do with AMP-enabled person-to-person messages is only part of the equation. The other domain that widespread adoption of AMP would affect directly is business-to-consumer email.

To quote Ben Thompson visually, again:

Platforms facilitate a relationship between users and 3rd-party developers:

“Aggregators intermediate the relationship between users and 3rd-party developers:

https://stratechery.com/2019/a-framework-for-regulating-competition-on-the-internet/

Is AMP for Email a platform, or is it an Aggregator tactic?  On balance, it looks far more the latter to me. 

Thompson posits that Aggregators have these characteristics:

• Direct relationship with users
• Zero marginal costs for serving users
• Demand-driven multi-sided networks with decreasing acquisition costs.

The first two are fairly self-evident for this case, I think. The third one, less so. Thompson’s argument is that, with digital goods, “supply” is abundant (or infinite), and “users reap value through discovery and curation.” He continues:

“once an aggregator has gained some number of end users, suppliers will come onto the aggregator’s platform on the aggregator’s terms, effectively commoditizing and modularizing themselves.”

To put that in an example: in 2014 German publisher Axel Springer decided not to accept Google’s terms of use for Google News (provide story excerpts). Their position was that Google was benefiting from their content. Axel Springer’s web traffic plummeted immediately, and within a few weeks, the company relented, providing the requested headlines and snippets and (in effect) commoditizing and modularizing their business to suit the dominant aggregator.

While this smacks of an alarmist forecast, consider this dynamic in relation to AMP and email at some hypothetical future point.

If AMP-enabled content becomes popular enough with Gmail users — themselves a majority of email users — what’s to stop Google from saying “We don’t accept email from platforms unless it includes the AMP body part.” That would be supported by the usual argument — users prefer the experience — but on the supplier side...commoditization and modularization. Email service providers (ESPs) would basically have little choice but to drop everything and devote development resources to adding AMP compliance. Those unable to would risk being deserted by marketers.

Whether any other inbox providers come along on this fence-laying expedition is pretty much beside the point; the main benefits would flow to the dominant aggregator.

Industry Action — Or Not?

As noted above, this is the game of markets. AMP for Email is making some headway in the market, but at a relatively modest pace. Google, of course, has implemented support for AMP in their email clients at their own pace. Other email clients have not; while Microsoft expressed interest, Outlook AMP support is experimental (“developer preview”). Apple Mail for Mac and iOS have — probably unsurprisingly — made no commitment.

AMP requires technical support for the additional AMP body part; some major email deliverers (SparkPost, SendGrid) have jumped on board, but this is a relatively invisible technical issue. Email editor support had been relatively light — AWeber & MessageGears are on board — but appears to be picking up with Bee’s addition of AMP editing/creation (Will this prompt body-part adoption for the email ‘back ends’ for Bee shops?).

Net, this is early days — a few industry early adopters, a fair amount of ‘buzz’ (some organic, some not), and more talk than action on the whole. I think it would be difficult to argue that AMP in its present state is a ‘killer app’ — the kind of experience that makes jaws drop and coffers open. It’s promising, and interesting, but judging from panels and audiences at recent email marketing events, it’s not a slam dunk.

But companies in the email ecosystem do have decisions to make (including mine!). Is AMP compelling enough for vendors to justify AMP-specific product investments, and for marketers/agencies to contemplate adding a 3rd rail to email production (text, HTML and now AMP). Are the systems, APIs, and data in place to do truly compelling, ROI-producing things within the constraints of the standard?  At this point, all of those questions have highly situational answers.

TL/DR, or The Bottom Line

My opinion is that AMP for email is an unnecessarily weak and constrained solution — Flash for email, as I said elsewhere.  Wholesale adoption of a vendor-defined and vendor-limited solution would be a poor evolution for a highly successful set of open Internet standards.  It would either be the beginning of the end of free-range email, or a bifurcation of the email channel — “are you on email or Gmail?”  

At the same time, the fact that a vendor solution is getting traction isn’t just about the vendor; it’s a reflection of the relatively static state of email as a standard.  As widespread, effective and useful as email is, it hasn’t changed very much in quite a while. I’m not personally involved in the IETF, but new email RFCs in the past decade have been pretty scarce. If email is to evolve as an open standard, the IETF seems like the right forum. 

My personal bet is that AMP isn’t really going to stick.  It’s a bit too narrow, and a bit too vendor-specific. Awareness of privacy and security issues has shifted dramatically, and I’d expect the end-users of email to be rightfully concerned about the risks of a ‘smarter’ email format.  Somewhat ironically, I also think Google has done email a favor with this particular business experiment. It has established that there is some appetite for evolution of email’s basic functions. Perhaps the industry will take up that challenge with a broader solution; time and the market will tell. 

Personal bias, perhaps, but I think leaving some open range with a few mustangs is a good thing. 

I will follow this up with a final piece, suggesting a possible direction for that solution.

My thanks to April Mullen of Sparkpost for
a spirited pro/con panel discussion at the recent
Email Innovations Summit that helped refine
my thinking on these issues.