發布第 12 集：是時候為電子郵件採用 AMP 了嗎？

已發表: 2019-11-29

在這一集中的交付中，主持人 Jason Rodriguez 回顧了（近）兩年的 AMP for Email 及其對行業的影響，並試圖回答電子郵件營銷人員是否應該接受 Gmail 的最新創新的問題。

情節抄本

歡迎來到 Delivering，這是一個關於電子郵件設計、策略、文案、開發和電子郵件營銷行業的播客。我是你的主人，傑森羅德里格斯。 Litmus 為您提供投遞服務，這是專業人士信任的唯一平台，可幫助您每次都自信地發送電子郵件。超過 600,000 名營銷專業人士使用 Litmus 的工具來更快地構建、測試和分析更好的電子郵件活動。

前往 litmus.com 開始您對 Litmus 的 7 天免費試用，並立即開始發送更好的電子郵件。

請務必訂閱在 iTunes 或 Spotify 上交付以收聽未來的劇集，並使用標籤#DeliveringPodcast 在 Twitter 上加入對話。

—

去年 2 月，Gmail 團隊宣布了一項名為 AMP for Email 的新計劃。在最初的博客文章中，谷歌稱其為“使人們消磨時間的最受歡迎的地方之一現代化的機會”以及“開發人員創建更具吸引力、互動性和可操作性的電子郵件體驗的強大方式”。每天發送 2700 億封電子郵件。儘管該公告與一些介紹性文檔相關聯，但除了 Pinterest 和 Booking.com 等公司正在使用 AMP 來創建那些更具交互性的體驗這一事實之外，該帖子還沒有詳細說明。

儘管“今年晚些時候”推出電子郵件 AMP 的信息有限且時間表模糊，但電子郵件行業立即被有關 Gmail 團隊最新功能的博客文章和 Twitter 討論所主導。

意見不一。

一些電子郵件營銷人員稱讚該公告是該行業向前邁出的驚人一步。其他人則著眼於實施、對谷歌總體 AMP 項目的公開批評，以及谷歌在沒有太多警告的情況下使用 Gmail 功能和關閉產品的歷史，並感嘆該公告是朝著錯誤方向邁出的一步。

我承認我堅定地落入了後者的陣營。在谷歌宣布後幾天在我的個人網站上發表的一篇博文中，我說：

從邏輯上講，我只是沒有看到 Google 獲得了使 AMP for Email 在 ESP 和其他電子郵件客戶端上工作所需的採用。我絕對認為 Gmail 團隊應該努力為他們的用戶帶來交互式和動態的電子郵件，但他們應該在改進對正確 HTML、CSS 和 JavaScript 的支持（如果他們能做到的話）的背景下這樣做。

自從最初的 AMP for Email 發布以來，近兩年發生了很多變化。我想用這一集“交付”來重新解決 AMP 及其對電子郵件營銷人員、開發人員和訂閱者的影響，並嘗試回答這個問題，“現在是時候將 AMP 用於電子郵件了嗎？”

我想我們應該從定義開始的第一件事。什麼是電子郵件 AMP？

在最基本的層面上，AMP for Email 是一種新的標記規範，可以添加到傳統的 HTML 電子郵件之上，以在收件箱中提供額外的功能。

有人對您的 Google 文檔發表評論時收到電子郵件通知嗎？請注意您現在如何直接在 Gmail 中回複評論，無需離開收件箱即可提供反饋？這就是用於電子郵件的 AMP。

AMP 允許您在收件箱中添加交互性，從基本的圖像輪播到評級、動態更新的內容，甚至高級回調到您自己的服務器。所有這一切都是使用 AMP 標記實現的，它看起來像 HTML，但卻是一種新規範。該代碼編寫在單獨的電子郵件文件中，使用額外的 MIME 類型（在現有的 HTML 和已隨營銷電子郵件發送的文本類型之上）交付，並且需要一些額外的工具來測試和發送。

雖然目前還沒有太多基於 AMP 的電子郵件出現，但 Pinterest、Booking.com 和 Indeed 等公司一直在使用 AMP 做一些很酷的事情。過去兩年，這三個人甚至在我們自己的會議 Litmus Live 上發言，分享了他們使用 AMP 的經驗。

Pinterest 已經創建了一些很酷的電子郵件，人們可以直接在活動中瀏覽、保存和組織圖釘。預訂現在可以實時顯示和更新旅行交易和詳細信息。來自 Indeed 的 Janie Clarke 和 Rohan Kapoor 展示了他們今年在 Litmus Live Boston 所做的很多工作，包括一封電子郵件，求職者可以在收件箱中查看詳細信息並開始申請流程。

希望該描述可以輕鬆回答下一個問題，“您為什麼要使用 AMP？”。 AMP 可讓您在電子郵件中完成以前不可能或很難實現的事情。儘管電子郵件交互性由 HTML 和 CSS 提供支持已經存在多年，但 AMP 有效地將事情提升到了一個新的水平。

像 Mark Robbins 和 Rebel 團隊（最近被 Salesforce 收購）這樣的人花了很多時間為電子郵件活動添加高級交互性。從簡單的圖像輪播開始，最終演變成動態 Twitter 提要以及電子郵件中的全面調查和結賬體驗。所有這些主要是由所謂的“複選框黑客”提供的。電子郵件開發人員利用 HTML 複選框的工作方式來跟踪電子郵件中的狀態，並根據訂閱者在電子郵件中的操作有條件地顯示和隱藏內容。結合通過 URL 參數傳遞信息、使用 CSS 和一些服務器端腳本動態更新內容，電子郵件開發人員可以使用相當多的權力。

但是創建這些電子郵件需要專門的技能組合、充足的測試，並且理解交互性並不適用於所有電子郵件客戶端。對於很多團隊來說，交互性是遙不可及的。

AMP 的承諾是，現在任何人都可以使用相對簡單、輕量級的標記語言訪問高級交互性和功能，熟悉 HTML 的人應該很容易上手。通過幾行代碼，電子郵件營銷人員現在可以在任何電子郵件活動中包含手風琴、動畫、輪播、燈箱、調查、提要、民意調查、評級等，並使用默認的 HTML 和 CSS 版本作為後備。

AMP 承諾增強功能，並由此增加訂閱者的參與度。對於迫切希望利用大多數訂閱者在電子郵件中花費的 11 秒的電子郵件營銷人員來說，AMP 看起來是一個了不起的工具。

有了這樣的承諾，您為什麼不想將 AMP 用於電子郵件？

對我來說，批評分為兩類：實施和碎片化。

從實施的角度來看，電子郵件的 AMP 還沒有完全成熟。正如我之前提到的，支持基於 AMP 的電子郵件的代碼位於一個單獨的文件中，該文件需要第三種 MIME 類型與 HTML 和純文本電子郵件一起交付。截至目前，只有少數電子郵件服務提供商實際支持發送第三種 MIME 類型。雖然預計該名單在未來幾年會增加，但對許多人來說，缺乏支持是不可能的。

即使您的 ESP 確實支持 AMP MIME 類型，您也還沒有走出困境。將 AMP 用於電子郵件需要一些額外的技術設置，包括與您的郵件一起傳送的特定於 Google 的標頭，以及針對發件人的嚴格安全設置，例如在發送 AMP 郵件時使用 DKIM、DMARC、SPF 和 TLS 加密。不幸的是，AMP 網站上沒有詳細記錄這些內容，這讓許多電子郵件營銷人員在測試消息時感到困惑。

AMP 代碼本身也需要嚴格的驗證，如果您遺漏了必要的標記，就會退回到 HTML 版本。儘管 HTML 和 CSS 會努力呈現它們所能呈現的內容，但 AMP 會在遇到錯誤時有效地關閉。幸運的是，AMP 團隊已經發布了一個可靠的在線遊樂場和驗證器構建和測試 AMP 驅動的活動。

對於實際顯示 AMP 支持的電子郵件的電子郵件客戶端，支持同樣有限。截至目前，AMP 僅在桌面版 Chrome 和 Firefox 中受支持，而幾天前，在 iOS 和 Android 上的 Gmail 移動應用程序中也支持 AMP。在 Gmail 生態系統之外，AMP 處於測試階段，並逐漸向 Yahoo! 用戶推出。郵件和 Outlook.com，以及 Mail.ru。
對於其他所有人，AMP 驅動的電子郵件可能不會很快出現。

儘管根據我們的研究，Gmail 是第二受歡迎的電子郵件客戶端，而 Yahoo! Mail 和 Outlook.com 都在前十大最受歡迎的電子郵件客戶端中，仍有數百萬用戶使用替代品。對於這些人來說，AMP 出現的可能性很小，特別是對於使用舊版 Outlook 等舊版電子郵件客戶端的大眾來說，這些客戶端通常只獲得安全更新，而不是新功能。

在哲學層面上，AMP 給已經非常分散的生態系統帶來了更多的碎片化。流行使用的電子郵件客戶端和 ESP 有數十個（如果不是數百個）——所有這些在呈現支持電子郵件的代碼時都遵守自己的規則。

不僅電子郵件中完全缺乏 HTML 和 CSS 的標準，而且電子郵件營銷人員對這兩種語言的技能也千差萬別。雖然一些團隊樂於編寫精簡、可訪問且交互式的 HTML 和 CSS，但其他團隊仍在使用過去十年未更新的模板和技術。

引入第三種標記，一種主要由一家公司控制並可能在未來發生變化的標記，是有問題的。難道 Google 的大量資源不能更好地用於改進電子郵件客戶端對 HTML 和 CSS（網絡上的標準化語言）的支持嗎？當我們已經可以用現有標準完成這麼多工作時，為什麼還要引入另一個標準供人們實施呢？為什麼不像 Salesforce 最近通過在 Salesforce Marketing Cloud 中引入由 HTML 和 CSS 而不是 AMP 提供支持的交互式內容塊來擁抱 HTML 和 CSS 的交互性呢？

這使我們對 AMP for Email 提出了最後的批評。這些問題的答案是控制。儘管 AMP 是一個開源項目，但出於所有意圖和目的，它完全由 Google 控制。正如我們在網絡版 AMP 中看到的那樣，Google 已將 AMP 用作推動廣告商支出的一種方式。 AMP 驅動的網站在 Google 搜索結果中被優先考慮，甚至還有一個 amp-ad 組件可以讓公司輕鬆利用 Google Ads。誰能說，在不久的將來，Gmail 收件箱中的 AMP 電子郵件優先於其他所有廣告系列？這種鎖定雖然對 Google 有利，但對其他電子郵件客戶端、發件人和訂閱者來說卻是危險的。

這一切都讓我們回到本集開頭提出的主要問題：是時候採用 AMP 電子郵件了嗎？

在討論 AMP 之前，有一些重要的問題要問你自己和你的團隊。

您真的可以發送基於 AMP 的電子郵件嗎？您的受眾是 Gmail 重度用戶嗎？您是否有時間和資源來學習新的標記語言和測試新的活動？您的電子郵件程序中是否有 AMP 的實際用例，或者您只是在追趕最新的時尚？

每當電子郵件行業推出新功能或新技術時，我都會想起電子郵件名人 Fabio Carneiro 的 Twitter 帖子。面對我上面提到的批評，我認為值得一讀。這是法比奧在 2015 年一直說的話：

坦率地說，如果電子郵件開發人員停止為他們編碼，電子郵件客戶端就會現代化的想法是不負責任和愚蠢的。
這種想法讓您的普通收件人陷入電子郵件客戶端提供商和電子郵件開發人員之間的交火中，這很愚蠢。
我們不會僅僅因為我們希望事情變得更好而讓人們受苦；用戶不是貨幣，他們應該得到更好的待遇。
我們編寫代碼是為了在我們擁有的環境下提供最佳體驗。改善這種環境不應以用戶體驗為代價。
如果電子郵件開發人員不得不對客戶提供商大喊大叫，直到他們臉色發青，只是希望事情會有所改變，那麼……
那是演出的一部分。為長期的戰鬥做好準備。

我對 AMP for Email 的批評與 Fabio 的觀點相悖。雖然我並不特別同意 Google 為電子郵件添加交互性的方法，但我確實看到了對越來越期待電子郵件的消費者和訂閱者的好處。無論好壞，谷歌絕對是一家規模龐大的公司，而 Gmail 則是該行業中同樣重要的參與者。人們使用 Gmail。他們在推出時會看到這些功能。當他們直接從收件箱回復對 Google 文檔的評論時，他們已經習慣使用 AMP（即使他們不知道它是什麼）。他們希望他們的工具按照他們想要的方式工作。

作為開發人員，我希望 Google 能夠採用 HTML 和 CSS 等標準，這兩種標準都可以通過現有的任何 ESP 交付，而無需我們進行額外設置。

作為消費者，我非常喜歡 AMP 的想法並將其用於諸如 Google Docs 評論之類的事情。像許多其他人一樣，我在 Google 的世界中根深蒂固，Gmail 和 GSuite 提供的絕對便利令人難以忍受——儘管我越來越擔心監視資本主義，並且如此依賴一家公司。

因此，回到我們最初關於電子郵件營銷人員是否應該接受 AMP 的問題。答案是：是的，可能。如果你可以的話。

當然有挑戰。當然，還有倫理問題。但歸根結底，我們是為我們的訂閱者工作，而不是我們自己。如果 AMP 有一個有效且引人注目的用例，那麼我們應該研究我們是否擁有開始發送 AMP 電子郵件的基礎設施和資源。而且，隨著 AMP 向更多平台推出，越來越多的訂閱者將期待更豐富的體驗，以幫助他們完成他們需要做的事情，盡可能減少摩擦。

回到 AMP 宣佈時，我寫道，“我只是沒有看到谷歌得到它需要的採用，使 AMP 電子郵件在 ESP 和其他電子郵件客戶端上工作。” 我並不孤單。我們中的大多數人都看到了未來 AMP 將採用 Grid View 或 Inbox by Gmail 的方式。沒有未來 AMP 真正起步並存在於野外。

但它就在那裡。它即將到來，Google 將帶領所有人——ESP、電子郵件客戶端和訂閱者等。

AMP for Email 可能不是豐富收件箱的最佳解決方案，但它不再是我們可以忽略的解決方案。我很興奮——如果有點猶豫——看看它如何改變電子郵件營銷格局和訂閱者對收件箱中可以做什麼的期望。

—

Litmus 為您提供遞送服務。

Litmus 是唯一可以幫助您每次都自信地發送電子郵件的平台。超過 600,000 名營銷專業人士使用 Litmus 的工具來更快地構建、測試和分析更好的電子郵件活動。

前往 litmus.com 開始您對 Litmus 的 7 天免費試用，並立即開始發送更好的電子郵件。

請務必訂閱在 iTunes 或 Spotify 上交付以收聽未來的劇集，並使用標籤#DeliveringPodcast 在 Twitter 上加入對話。