Indonesian (Bahasa Indonesia) translation by graywest (you can also view the original English article)
Mari kita bayangkan Anda mengembangkan fitur baru atau aplikasi. Akhir sudah di depan mata. Semua infrastruktur rumit, database, api, tes sedang baik. Kemudian Anda menyadari ada poin kunci dalam sistem yang mana Anda harus mengirim email "transaksi"; reset password, email Selamat datang, kwitansi, faktur.
Anda tahu ada layanan dan api yang dapat Anda gunakan untuk menangani hal ini untuk Anda, tetapi ketika Anda mulai untuk melihat ke dalam mengirim email Anda menyadari itu akan lebih sulit daripada yang Anda pikir. Terutama jika Anda ingin menggunakan desain desain, manajer produk, atau Manajer Pemasaran Anda ada dalam pikiran.
Ini adalah skenario umum. Sebagai pengembang kita jarang berpikir tentang transaksional email sampai setelah membangun keluar produk. Tapi itu OK karena ada banyak solusi di luar sana yang telah Anda kembali. Sudah lama sejak Anda harus bergantung pada Menyiapkan infrastruktur email Anda sendiri untuk menangani mengirim, menerima, memantul, berhenti berlangganan dll.
Yang mengatakan, ada beberapa hal penting yang perlu Anda ketahui tentang membangun HTML email, mengirim email dan menjaga nilai reputasi baik pengirim. Daftar ini akan membantu Anda mempersiapkan untuk proyek berikutnya yang memiliki email transaksional. Kami akan mencakup:
- Apakah transaksi email?
- Memilih penyedia layanan Email Anda (ESP)
- Sebuah panduan untuk penghantaran dan reputasi
- Pengkodean responsif HTML Email
- Email sumber untuk pengembang
Catatan: tutorial ini adalah bagian dari seluruh seminggu dari konten email tentang Tuts + Web Desain-check out panduan belajar menguasai HTML Email untuk lebih!
Apakah transaksi email?
Anda bisa mengkategorikan email yang perusahaan dan apps kirim ke:
- Email transaksional
- Pemasaran email
Anda bisa melanggar ini turun lebih lanjut ke dalam sub-kategori, tetapi untuk apa yang kita berbicara tentang di sini Mari kita tetap dengan kedua.
Pemasaran email biasanya promosi di alam dan ditangani oleh tim pemasaran. Mereka termasuk newsletter bulanan, promosi musiman, perusahaan dan produk update rilis baru dll. Ada strategi konten dan siklus hidup di balik Kapan dan seberapa sering untuk mengirim mereka.
Email transaksional adalah mereka dipicu oleh perilaku pengguna dan biasanya dilaksanakan oleh pengembang atau tim produk. Pengguna melakukan sesuatu di app yang menyebabkan email akan dikirim. Ini termasuk:
- Email Selamat datang
- Konfirmasi email
- Pembuatan ulang sandi
- Faktur/penerimaan baru
- dll.
Sebagian besar email ini Anda akan mungkin mengirim diri sendiri, tetapi Anda juga dapat mengirimkan ini melalui pihak ke-3 Layanan, misalnya garis untuk penerimaan, Shopify untuk e-commerce.
Aturan untuk transaksional dan pemasaran email berbeda sedikit. GDPR mulai diberlakukan pada Mei 25 2018, sehingga siapa pun yang mengirim email pemasaran diperlukan untuk mengumpulkan izin eksplisit dari pelanggan dan menyimpan catatan izin. Seperti berdiri Anda tidak memerlukan izin yang jelas untuk mengirim email transaksional, misalnya tanda terima untuk seseorang yang baru saja membeli sesuatu dari toko Anda. Namun ada keuntungan untuk menjaga sejalan dengan peraturan GDPR yang tidak peduli apa jenis email Anda mengirim.
Memilih penyedia layanan Email Anda (ESP)
Hal ini sangat mungkin untuk mengatur server mail Anda sendiri dan mengelola mengirim email sendiri. Jika Anda berada di sebuah perusahaan besar seperti Google atau Facebook Anda bahkan mungkin memiliki tim infrastruktur email Anda sendiri didedikasikan untuk mendukung transaksi Surat.
Untuk sebagian besar dari kita, saya tidak menyarankan mendirikan dan memelihara server mail Anda sendiri. Ada banyak overhead yang terlibat dalam dukungan dan pemeliharaan. Sebaliknya, gunakan salah satu PSS luar sana. Mereka memiliki api yang besar untuk pengembang dan yang cukup murah, biasanya dengan tingkatan gratis yang berlimpah.
Masing-masing PSS ini adalah fitur yang kaya dengan segala sesuatu yang Anda butuhkan untuk mengelola pesan transaksi:
- Mengirim email melalui API atau SMTP.
- Menerima dan parsing email masuk.
- Metrik untuk mengirim, menerima, bangkit, dibuka, diklik email.
- Berhenti berlangganan dan penindasan daftar manajemen.
- Reputasi pemantauan.
- Manajemen loop umpan balik.
- GDPR kepatuhan dan banyak lagi.
Setelah Anda memilih ESP Anda waktu untuk mengatur hal-hal.
Sebuah panduan untuk penghantaran dan reputasi
Kotak pesan penyedia (seperti Gmail dan Outlook) melihat hal kecil yang disebut reputasi. Anda ingin reputasi yang baik untuk memastikan email masuk ke inbox Penerima. Jika Anda memiliki reputasi buruk kemudian email Anda akan baik pergi untuk spam atau penyedia email mungkin menolak dan itu akan terpental.
Menurut Talos, pada Juli tahun 2018 rata-rata harian jumlah spam dikirim secara global adalah 305.95 milyar. Anda tidak ingin pesan untuk jatuh ke dalam ember ini.
Hal-hal yang dapat berkontribusi terhadap reputasi buruk:
- Penerima menandai email Anda sebagai spam.
- Penerima tidak membuka atau terlibat dengan email Anda.
- Anda mengirim email terlalu banyak.
- Anda mengirim email dari alamat IP yang memiliki Skor yang buruk.
- Anda belum setup DKIM, SPF dan DMARC.
- Konten yang Anda kirimkan terlihat seperti spam.
Tiga metode otentikasi utama yang perlu Anda pertimbangkan adalah SPF (Sender Policy Framework), DKIM (DomainKeys diidentifikasi Mail) dan DMARC (otentikasi pesan berbasis Domain, laporan dan kesesuaian).
SPF adalah suatu cara bagi penyedia kotak pesan untuk mengotentikasi bahwa email sebenarnya datang dari domain Anda. Ianya TXT data DNS yang Anda harus menambahkan diri melalui manajemen DNS Anda.
1 |
domain.com. TXT "v=spf1 include:domain ~all"
|
DKIM menggunakan pasangan kunci publik/swasta masuk setiap pesan dengan tanda kriptografi yang unik, yang dirancang untuk mendeteksi email spoofing. Ketika Anda menekan kirim, ESP Anda akan menambahkan tanda tangan pribadi, maka pada duduk DNS Anda tanda tangan Anda umum, yang penyedia kotak pesan penerima akan memanggil untuk memastikan semua terlihat baik.
1 |
_domainkey.domain.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY"
|
DMARC tidak protokol otentikasi tetapi memungkinkan Anda untuk mengatur kebijakan untuk apa yang harus dilakukan dengan pesan yang tidak lulus SPF atau DKIM, apakah yang akan menolak atau karantina.
1 |
_dmarc.domain.com. TXT "v=DMARC1; p=reject; pct=100; rua=postmaster@domain.com"
|
Berikut adalah contoh bagaimana otentikasi email semua datang bersama-sama. Ini adalah disederhanakan, tetapi memberikan Anda sebuah ide dari cara kerjanya.
Reputasi adalah terikat domain pengirim dan alamat IP Anda menggunakan, sehingga Anda ingin ini menjadi statis. Memeriksa alamat IP Anda adalah metode paling dasar penyedia kotak pesan (Gmail, Outlook, Hotmail, Yahoo, AOL dll) memiliki ketika memeriksa reputasi Anda. Ketika Anda mengirim email lebih dari 50.000 per minggu Anda harus mempertimbangkan menggunakan dedicated IP sehingga Anda tidak berbagi dengan orang lain, memberikan Anda beberapa lebih isolasi. Dan perlu diingat Anda perlu "pemanasan" IPs. Anda tidak boleh mulai mengirim jutaan email dari IP dedicated baru segera. Kebanyakan PSS menawarkan fitur ini.
Hal lain untuk dipertimbangkan adalah menggunakan IPs dan subdomain yang terpisah untuk transaksional dan pemasaran email. Saya biasanya membuat sesuatu seperti send.mydomain.com untuk pemasaran dan notifications.mydomain.com untuk email transaksional.
Jangan kirim dari "no-Balasan @" alamat email. Pertama-tama kelihatannya buruk untuk penerima Anda seperti yang terlihat seperti Anda tidak peduli dan tidak ingin mendengar dari mereka. Kedua dari semua, itu adalah suatu hal yang besar ketika Penerima Balasan dan terlibat. Ini adalah apa yang penyedia kotak pesan ingin melihat.
Menggunakan alat seperti SenderScore dan SenderBase untuk memantau reputasi Anda.
Pengkodean responsif HTML Email
MIME Multipart
Ketika Anda mengirim email itu dibangun dari header dan bagian-bagian yang berbeda. Hal ini dikenal sebagai Internet multiguna Mail ekstensi (MIME). Ini menggabungkan teks biasa, HTML, dan/atau bagian lain dan daun kepada klien penerima untuk memutuskan apa dan bagaimana untuk menampilkannya.
- Header berisi nilai kunci pasang seperti yang asli pengirim, subjek, alamat balas-ke, dan sekelompok data menarik lainnya. Dalam tubuh Anda, Anda memiliki berbeda "bagian".
- text/plain adalah bentuk yang paling sederhana mengirim email dengan hanya teks dan tidak ada format.
- teks/html memungkinkan HTML. Ini adalah dimana email HTML Anda pergi.
- teks/watch-html untuk jam tangan, seperti Apple Watch, dan memiliki dukungan HTML terbatas.
- teks/x-amp-html adalah bagian baru yang membawa konten interaktif ke Gmail dengan AMP untuk Email.
Untuk sebagian besar email Anda akan mengirim bagian teks dan bagian HTML. Kotak pesan penyedia seperti untuk melihat kedua. Kabar baiknya adalah bahwa PSS menangani semua ini untuk Anda. Itu mungkin bukan sesuatu yang Anda harus berpikir tentang kecuali jika Anda mencoba untuk melakukan sesuatu yang lebih maju dengan email.
Jika Anda ingin tahu bagaimana semua itu terlihat, di Gmail Klik View asli (atau Tampilkan asli) dan ini akan menunjukkan Anda bagaimana membuat sosis. Piecing ini bersama-sama adalah cukup rumit yang merupakan alasan lain untuk menggunakan ESP yang melakukan semua ini untuk Anda.
Tabel dan Inline CSS
Ketika coding HTML email (masih) sebaiknya kita menggunakan tabel)<table>), tabel baris ()<tr>) dan sel-sel tabel ()<td>). Banyak klien email menjadi lebih baik tentang mendukung HTML dan CSS, tetapi Anda berisiko mereka berantakan di klien email tertentu.</td></tr></table>
Ada banyak klien email luar sana. Lakmus, pengujian alat, email saat ini mendukung lebih dari 90 klien di desktop, web dan mobile. Ini email klien semua menggunakan mesin rendering yang berbeda. Beberapa menggunakan Webkit, beberapa Internet Explorer, beberapa Microsoft Word. Dan mereka semua menambahkan beberapa rasa mereka sendiri gaya dan kelas-kelas di atas apa yang Anda berikan.
Baca lebih lanjut tentang mesin rendering email.
Dengan ini dalam pikiran Anda akan disarankan untuk bermain aman dan menempel beberapa aturan ketika coding untuk email.
- Penggunaan<table>Melainkan<div></div></table>
- Menggunakan warna-warna penuh heksadesimal #ff6600 bukan singkatan #f60
- Menggunakan padding bukan margin
- Menggunakan warna latar belakang bukan latar belakang
- Menggunakan inlined CSS bukan CSS tertanam
- Stick dengan sistem dan web font safe
- Menambahkan peran = "presentasi" untuk setiap meja sehingga itu yang jelas bagi pembaca layar tabel digunakan untuk tata letak
- Menggunakan tag HTML semantik, seperti<p>dan<h1>, mana yang berlaku</h1>
Sebagai contoh, di sini adalah bagaimana saya biasanya kode tombol untuk HTML email, menggunakan tabel luar untuk penyelarasan, dan sebuah meja batin untuk bentuk tombol.
Ini adalah solusi yang cukup antipeluru:
Menulis inline CSS dapat monoton, bukan untuk menyebutkan keras untuk mempertahankan, dan tidak scalable, terutama untuk tim besar. Ini adalah di mana Anda ingin menggunakan CSS inliner atau beberapa toolset otomatisasi untuk membantu Anda membangun dan inline template Anda. Kerangka kerja seperti MJML dan Inky memberikan pengembang template bahasa yang lebih ramah untuk bekerja dengan.
Catatan: Anda dapat menggunakan media query dan pernyataan bersyarat untuk target klien tertentu – dengan mereka Anda dapat memiliki layout yang khusus untuk Outlook atau membuat penggunaan font web klien Webkit. Memeriksa sumber terbuka ini sederhana responsif template email untuk mendapatkan Anda mulai atau membaca lebih lanjut tentang teknik-teknik ini untuk pengkodean lebih maju HTML email template.
Apakah saya benar-benar perlu menggunakan tabel dan Inline CSS pada tahun 2018?
Itu tergantung. Jika Anda ingin bermain aman dan pastikan email Anda antipeluru, kemudian ya.
Jika Anda memiliki wawasan baik Penerima Anda dan Anda tahu mereka menggunakan klien email yang memiliki dukungan untuk CSS tertanam dan model kotak, maka mungkin tidak. Anda pasti dapat mengambil risiko dan tidak mungkin masalah. Saya secara pribadi tetap dengan kebiasaan lama dan menggunakan tabel dan inline CSS tetapi banyak orang lain mulai bereksperimen dengan opsi "tidak inline".
Gambar, GIF, Video & Media
Beberapa klien (terutama Outlook) akan memblokir gambar rendering secara default, memaksa penerima untuk opt-in untuk melihat gambar Anda. Dengan itu dalam pikiran selalu memberikan gambar Anda bermakna ALT teks.
Anda akan ingin memberikan gambar berkualitas tinggi untuk retina layar (misalnya iPhone) karena itu gambar Anda harus setidaknya 2 x dimensi yang Anda ingin menampilkan mereka di. Dengan itu dalam pikiran, selalu memberikan gambar Anda lebar atribut untuk menghentikannya meluap pada beberapa klien.
1 |
<img src="https://your-cdn.com/image.png" alt="Descriptive text" width="600px" height="300px" border="0" style="display:block; max-width: 100%;"> |
Animasi GIFs didukung dalam kebanyakan klien. Video ini didukung pada iOS, Apple Mail dan Outlook.com. Anda dapat juga melakukan percobaan dengan emojis di baris subjek Anda untuk mendapatkan Penerima perhatian 🤯�
