Menyampaikan Episode 12: Apakah sudah waktunya untuk merangkul AMP untuk Email?

Dalam episode Delivering ini, pembawa acara Jason Rodriguez melihat kembali (hampir) dua tahun AMP untuk Email, implikasinya bagi industri, dan mencoba menjawab pertanyaan apakah pemasar email harus merangkul inovasi terbaru Gmail atau tidak.

Transkrip Episode

Selamat datang di Delivering, podcast tentang desain email, strategi, copywriting, pengembangan, dan industri pemasaran email. Saya tuan rumah Anda, Jason Rodriguez. Pengiriman dipersembahkan oleh Litmus—satu-satunya platform yang dipercaya oleh para profesional untuk membantu Anda mengirim email dengan percaya diri, setiap saat. Lebih dari 600.000 profesional pemasaran menggunakan alat Litmus untuk membuat, menguji, dan menganalisis kampanye email yang lebih baik dengan lebih cepat.

Kunjungi litmus.com untuk memulai uji coba Litmus gratis selama 7 hari, dan mulai mengirim email yang lebih baik hari ini.

Pastikan untuk berlangganan Menyampaikan di iTunes atau Spotify untuk mendengarkan episode mendatang dan bergabung dengan percakapan di Twitter menggunakan tagar #DeliveringPodcast.

—

Pada bulan Februari tahun lalu, tim Gmail mengumumkan inisiatif baru yang disebut AMP for Email. Dalam posting blog asli, Google menyebutnya sebagai “kesempatan untuk memodernisasi salah satu tempat paling populer di mana orang menghabiskan waktu mereka” serta “cara yang ampuh bagi pengembang untuk menciptakan pengalaman email yang lebih menarik, interaktif, dan dapat ditindaklanjuti” untuk lebih dari 270 miliar email dikirim setiap hari. Meskipun pengumuman tersebut terkait dengan beberapa dokumentasi pengantar, postingan tersebut tidak menjelaskan detail selain fakta bahwa perusahaan seperti Pinterest dan Booking.com menggunakan AMP untuk menciptakan pengalaman yang lebih interaktif tersebut.

Meskipun informasi terbatas dan garis waktu yang tidak jelas seputar AMP untuk Email yang diluncurkan “akhir tahun ini”, industri email langsung didominasi oleh posting blog dan diskusi Twitter tentang fitur terbaru dari tim Gmail.

Pendapat dicampur.

Beberapa pemasar email memuji pengumuman itu sebagai langkah maju yang luar biasa bagi industri ini. Yang lain melihat implementasinya, kritik yang sangat publik terhadap proyek AMP menyeluruh Google, dan sejarah Google dengan fitur Gmail dan mematikan produk tanpa banyak peringatan, dan meratapi pengumuman itu sebagai langkah ke arah yang salah.

Saya akan mengakui bahwa saya jatuh dengan kuat ke kubu yang terakhir. Dalam posting blog di situs pribadi saya yang diterbitkan beberapa hari setelah pengumuman Google, saya berkata:

Secara logistik, saya hanya tidak melihat Google mendapatkan adopsi yang dibutuhkan untuk membuat AMP untuk Email berfungsi di seluruh ESP dan klien email lainnya. Saya benar-benar berpikir tim Gmail harus bekerja untuk menghadirkan email interaktif dan dinamis kepada penggunanya, tetapi mereka harus melakukannya dalam konteks meningkatkan dukungan untuk HTML, CSS, dan JavaScript yang tepat (jika mereka dapat mengembangkannya).

Banyak yang telah berubah dalam hampir dua tahun sejak pengumuman AMP for Email yang asli. Saya ingin menggunakan episode Delivering ini untuk membaca ulang AMP, implikasinya bagi pemasar email, pengembang, dan pelanggan, dan mencoba menjawab pertanyaan, “Apakah sudah waktunya untuk merangkul AMP untuk Email?”

Saya kira hal pertama yang harus kita mulai adalah definisi. Apa itu AMP untuk Email?

Pada tingkat yang paling mendasar, AMP for Email adalah spesifikasi markup baru yang dapat ditambahkan di atas email HTML tradisional untuk memberikan fungsionalitas tambahan di kotak masuk.

Pernah mendapatkan pemberitahuan email ketika seseorang mengomentari Google Doc Anda? Perhatikan bagaimana Anda sekarang dapat berkomentar kembali langsung di Gmail, memberikan umpan balik tanpa harus meninggalkan kotak masuk Anda? Itulah AMP untuk Email yang sedang beraksi.

AMP memungkinkan Anda menambahkan interaktivitas di kotak masuk, dari carousel gambar dasar hingga peringkat, konten yang diperbarui secara dinamis, dan bahkan panggilan lanjutan kembali ke server Anda sendiri. Semua ini terjadi menggunakan markup AMP yang terlihat seperti HTML tetapi merupakan spesifikasi baru. Kode tersebut ditulis dalam file email terpisah, dikirim menggunakan jenis MIME tambahan (di atas HTML dan jenis teks yang sudah ada yang sudah dikirim dengan email pemasaran), dan memerlukan sedikit alat tambahan untuk menguji dan mengirim.

Meskipun belum terlalu banyak email bertenaga AMP yang terlihat di alam liar, perusahaan seperti Pinterest, Booking.com, dan Memang telah melakukan beberapa hal keren dengan AMP. Orang-orang dari ketiganya bahkan telah berbicara di konferensi kami sendiri, Litmus Live, dua tahun terakhir, berbagi pengalaman mereka dengan AMP.

Pinterest telah membuat beberapa email keren di mana orang dapat menelusuri, menyimpan, dan mengatur pin secara langsung dalam kampanye. Pemesanan sekarang dapat menampilkan dan memperbarui penawaran dan detail perjalanan secara realtime. Dan Janie Clarke dan Rohan Kapoor dari Indeed memamerkan banyak pekerjaan yang telah mereka lakukan di Litmus Live Boston tahun ini, termasuk email tempat para pencari kerja dapat melihat detail dan memulai proses lamaran di kotak masuk.

Semoga uraian tersebut membuat menjawab pertanyaan berikutnya, “Mengapa Anda ingin menggunakan AMP?”, menjadi mudah. AMP memungkinkan Anda melakukan hal-hal dalam email yang sebelumnya tidak mungkin atau sangat sulit untuk diterapkan. Meskipun interaktivitas email telah ada selama bertahun-tahun yang didukung oleh HTML dan CSS, AMP secara efektif membawa banyak hal ke tingkat berikutnya.

Orang-orang seperti Mark Robbins dan tim di Rebel—yang baru-baru ini diakuisisi oleh Salesforce—telah menghabiskan banyak waktu untuk menambahkan interaktivitas tingkat lanjut ke kampanye email. Apa yang dimulai dengan carousel gambar sederhana akhirnya berkembang menjadi hal-hal seperti umpan Twitter dinamis dan survei lengkap serta pengalaman checkout dalam email. Semua itu sebagian besar didukung oleh apa yang disebut "peretasan kotak centang". Pengembang email memanfaatkan cara kotak centang HTML bekerja untuk melacak status dalam email dan secara kondisional menampilkan dan menyembunyikan konten berdasarkan apa yang dilakukan pelanggan di email. Dikombinasikan dengan meneruskan informasi melalui parameter URL, konten yang diperbarui secara dinamis menggunakan CSS dan beberapa skrip sisi server, pengembang email memiliki cukup banyak kekuatan yang mereka miliki.

Tetapi membuat email tersebut membutuhkan keahlian khusus, pengujian yang cukup, dan pemahaman bahwa interaktivitas tidak berfungsi di semua klien email. Untuk banyak tim, interaktivitas berada di luar jangkauan.

Janji AMP adalah bahwa interaktivitas dan fungsionalitas tingkat lanjut kini dapat diakses oleh siapa saja dengan bahasa markup yang relatif sederhana dan ringan yang seharusnya mudah untuk memulai bagi siapa saja yang terbiasa dengan HTML. Dengan beberapa baris kode, pemasar email sekarang dapat menyertakan akordeon, animasi, korsel, lightbox, survei, umpan, jajak pendapat, peringkat, dan lainnya dalam kampanye email apa pun, dengan versi HTML dan CSS default sebagai pengganti.

AMP menjanjikan peningkatan fungsionalitas dan, dengan itu, peningkatan keterlibatan dari pelanggan. Untuk pemasar email yang sangat ingin memanfaatkan 11 detik yang dihabiskan sebagian besar pelanggan dalam email, AMP terlihat seperti alat yang luar biasa.

Dengan janji seperti itu, mengapa Anda tidak ingin menggunakan AMP untuk Email?

Bagi saya, kritik itu terbagi menjadi dua kategori: implementasi dan fragmentasi.

Dari perspektif implementasi, AMP untuk Email belumlah cukup. Seperti yang saya sebutkan sebelumnya, kode yang mendukung email berbasis AMP berada di dalam file terpisah yang memerlukan jenis MIME ketiga untuk dikirimkan bersama HTML dan email teks biasa Anda. Sampai sekarang, hanya beberapa penyedia layanan email yang benar-benar mendukung pengiriman jenis MIME ketiga tersebut. Meskipun daftar itu diperkirakan akan bertambah di tahun-tahun mendatang, bagi banyak orang, kurangnya dukungan bukanlah hal yang baru.

Bahkan jika ESP Anda mendukung jenis AMP MIME, Anda belum keluar dari masalah. Menggunakan AMP untuk Email memerlukan beberapa setelan teknis tambahan, termasuk header khusus Google yang akan dikirimkan bersama pesan Anda, dan setelan keamanan yang ketat untuk pengirim, seperti penggunaan enkripsi DKIM, DMARC, SPF, dan TLS saat mengirim pesan AMP. Sayangnya, semua ini tidak didokumentasikan dengan baik di situs AMP, membuat banyak pemasar email bingung saat menguji pesan.

Kode AMP itu sendiri juga memerlukan validasi yang ketat, kembali ke versi HTML jika Anda mengabaikan markup yang diperlukan. Sementara HTML dan CSS berusaha untuk merender apa yang mereka bisa, AMP secara efektif dimatikan jika terjadi kesalahan. Untungnya, tim AMP telah merilis taman bermain online yang solid dan validator yang membangun dan menguji kampanye yang didukung AMP.

Ketika datang ke klien email yang benar-benar menampilkan email yang didukung AMP, dukungan juga terbatas. Untuk saat ini, AMP hanya didukung di Chrome dan Firefox untuk desktop dan, beberapa hari yang lalu, di aplikasi seluler Gmail di iOS dan Android. Di luar ekosistem Gmail, AMP masih dalam versi beta dan perlahan diluncurkan ke pengguna Yahoo! Mail dan Outlook.com, serta Mail.ru.
Untuk semua orang, email yang didukung AMP mungkin tidak akan terjadi dalam waktu dekat.

Meskipun Gmail adalah klien email terpopuler kedua menurut penelitian kami, dan Yahoo! Mail dan Outlook.com keduanya berada di sepuluh besar klien email paling populer, masih ada jutaan pengguna yang menggunakan alternatif. Bagi orang-orang itu, kemungkinan AMP datang kepada mereka sangat kecil, terutama untuk massa yang menggunakan klien email lama seperti Outlook versi lama yang biasanya hanya mendapatkan pembaruan keamanan, bukan fitur baru.

Pada tingkat filosofis, AMP memperkenalkan lebih banyak lagi fragmentasi ke ekosistem yang sudah terfragmentasi secara besar-besaran. Ada lusinan, jika bukan ratusan, klien email dan ESP yang populer digunakan—semuanya mematuhi aturan mereka sendiri saat merender kode yang mendukung email.

Tidak hanya kurangnya standar HTML dan CSS dalam email, tetapi keterampilan pemasar email dengan kedua bahasa tersebut sangat bervariasi. Sementara beberapa tim merasa nyaman menulis HTML dan CSS yang ramping, mudah diakses, dan interaktif, yang lain masih menggunakan template dan teknik yang belum diperbarui dalam dekade terakhir.

Memperkenalkan rasa markup ketiga, yang sebagian besar dikendalikan oleh satu perusahaan dan kemungkinan akan berubah di masa depan, merupakan masalah. Bukankah sumber daya Google yang sangat besar akan lebih baik digunakan untuk meningkatkan dukungan untuk HTML dan CSS—bahasa standar di web—di klien email? Mengapa memperkenalkan standar lain untuk diterapkan orang ketika kita sudah dapat mencapai begitu banyak dengan standar yang ada? Mengapa tidak merangkul interaktivitas dengan HTML dan CSS seperti yang baru-baru ini dilakukan Salesforce dengan memperkenalkan blok konten interaktif di Salesforce Marketing Cloud yang didukung oleh HTML dan CSS, bukan AMP?

Itu membawa kita ke satu kritik terakhir terhadap AMP untuk Email. Jawaban atas pertanyaan-pertanyaan itu adalah kendali. Meskipun AMP adalah proyek sumber terbuka, untuk semua maksud dan tujuan, sepenuhnya dikendalikan oleh Google. Seperti yang telah kita lihat dengan AMP untuk web, Google telah menggunakan AMP sebagai cara untuk mendorong pengeluaran pengiklan. Situs web yang didukung AMP diberi prioritas dalam hasil penelusuran Google, dan bahkan ada komponen amp-ad yang memudahkan perusahaan untuk memanfaatkan Google Ads. Siapa yang mengatakan bahwa, suatu hari nanti, email yang didukung AMP diberikan preferensi di kotak masuk Gmail daripada setiap kampanye lainnya? Penguncian itu, meskipun baik untuk Google, berbahaya bagi klien email, pengirim, dan pelanggan lain.

Ini semua membawa kita kembali ke pertanyaan utama yang diajukan di awal episode ini: Apakah sudah waktunya untuk merangkul AMP untuk Email?

Sebelum bermain-main dengan AMP, ada pertanyaan penting untuk ditanyakan kepada diri sendiri dan tim Anda.

Bisakah Anda benar-benar mengirim email berbasis AMP? Apakah audiens Anda banyak menggunakan Gmail? Apakah Anda memiliki waktu dan sumber daya untuk mempelajari bahasa markup baru dan menguji kampanye baru? Apakah Anda memiliki kasus penggunaan yang sebenarnya untuk AMP dalam program email Anda atau apakah Anda hanya mengejar mode terbaru?

Setiap kali fitur atau teknik baru diluncurkan di industri email, saya diingatkan akan utas Twitter dari email termasyhur Fabio Carneiro. Dalam menghadapi kritik yang saya manfaatkan di atas, saya pikir ini layak untuk dibaca secara keseluruhan. Inilah yang dikatakan Fabio sepanjang tahun 2015:

Gagasan bahwa klien email akan dimodernisasi jika pengembang email berhenti membuat kode untuk mereka, sejujurnya, tidak bertanggung jawab dan konyol.

Ini adalah ide yang menempatkan penerima rata-rata Anda dalam baku tembak antara penyedia klien email dan pengembang email, yang konyol.

Kami tidak membuat orang menderita hanya karena kami ingin segalanya menjadi lebih baik; pengguna bukan mata uang, dan mereka layak mendapatkan perlakuan yang lebih baik.

Kami membuat kode untuk memberikan pengalaman terbaik yang dapat kami berikan dengan lingkungan yang kami miliki. Memperbaiki lingkungan itu seharusnya tidak mengorbankan UX.

Jika pengembang email harus meneriaki penyedia klien sampai wajah mereka membiru hanya dengan harapan keadaan akan berubah, yah…

Itu bagian dari pertunjukan. Bersiaplah untuk pertarungan panjang.

Kritik yang saya miliki terhadap AMP untuk Email bertentangan dengan poin Fabio. Meskipun saya tidak terlalu setuju dengan metode Google dalam menambahkan interaktivitas ke email, saya melihat manfaat bagi konsumen dan pelanggan yang semakin mengharapkan lebih banyak dari email. Baik atau buruk, Google adalah perusahaan yang sangat besar dan Gmail adalah pemain yang sama besarnya di industri ini. Orang menggunakan Gmail. Mereka melihat fitur ini saat diluncurkan. Mereka terbiasa menggunakan AMP—meskipun mereka tidak tahu apa itu—ketika mereka membalas komentar di Google Dokumen langsung dari kotak masuk. Mereka mengharapkan alat mereka bekerja seperti yang mereka inginkan.

Sebagai pengembang, saya berharap Google akan merangkul standar seperti HTML dan CSS, yang keduanya sudah dapat dikirimkan melalui ESP apa pun yang ada tanpa penyiapan tambahan di pihak kami.

Sebagai konsumen, saya sangat menyukai ide AMP dan menggunakannya untuk hal-hal seperti komentar Google Documents. Seperti banyak lainnya, saya tertanam kuat di dunia Google, dan kenyamanan yang disediakan oleh Gmail dan GSuite sulit untuk hidup tanpanya—meskipun kecemasan saya meningkat atas kapitalisme pengawasan dan ketergantungan pada satu perusahaan untuk banyak hal.

Jadi, kembali ke pertanyaan awal kami tentang apakah pemasar email harus menggunakan AMP atau tidak. Jawabannya adalah: Ya, mungkin. Jika kamu bisa.

Ada tantangan, pasti. Ada masalah etika, tentu saja. Tetapi pada akhirnya, kami bekerja untuk pelanggan kami, bukan untuk diri kami sendiri. Jika ada kasus penggunaan yang valid dan menarik untuk AMP, maka kita harus melihat apakah kita memiliki infrastruktur dan sumber daya untuk mulai mengirim email AMP atau tidak. Dan, saat AMP diluncurkan ke lebih banyak platform, semakin banyak pelanggan yang mengharapkan pengalaman yang lebih kaya yang membantu mereka menyelesaikan apa yang perlu mereka lakukan, dengan gesekan sesedikit mungkin.

Kembali ketika AMP diumumkan, saya menulis, “Saya hanya tidak melihat Google mendapatkan adopsi yang dibutuhkan untuk membuat AMP untuk Email berfungsi di seluruh ESP dan klien email lainnya.” Saya hampir tidak sendirian. Sebagian besar dari kita melihat masa depan di mana AMP berjalan seperti Grid View atau Inbox by Gmail. Tidak ada masa depan di mana AMP benar-benar muncul dan ada di alam liar.

Tapi itu ada. Itu akan datang, dan Google membawa semua orang ikut dalam perjalanan—ESP, klien email, dan pelanggan.

AMP untuk Email mungkin bukan solusi terbaik untuk memperkaya kotak masuk, tapi ini bukan lagi solusi yang bisa kita abaikan. Saya senang—jika sedikit ragu—untuk melihat bagaimana hal itu mengubah lanskap pemasaran email dan harapan pelanggan tentang apa yang dapat dilakukan di kotak masuk.

—

Pengiriman dipersembahkan oleh Litmus.

Litmus adalah satu-satunya platform yang membantu Anda mengirim email dengan percaya diri, setiap saat. Lebih dari 600.000 profesional pemasaran menggunakan alat Litmus untuk membuat, menguji, dan menganalisis kampanye email yang lebih baik dengan lebih cepat.

Kunjungi litmus.com untuk memulai uji coba Litmus gratis selama 7 hari, dan mulai mengirim email yang lebih baik hari ini.

Pastikan untuk berlangganan Menyampaikan di iTunes atau Spotify untuk mendengarkan episode mendatang dan bergabung dengan percakapan di Twitter menggunakan tagar #DeliveringPodcast.