Pemeriksaan sebelum setiap kampanye dan ambang batas audit email Brew: pemotongan 102 KB, tautan mati, teks alt, dukungan klien email, dan panjang teks.
Daftar periksa QA sebelum mengirim adalah daftar singkat pemeriksaan yang Anda jalankan pada setiap email sebelum dikirim. Kampanye yang rusak biasanya terkirim dengan tombol yang masih mengarah ke #, gambar hero yang diganti dengan PNG 4 MB pada pukul 18.00, atau tata letak dua kolom yang diabaikan Outlook klasik. Masing-masing hanya butuh satu menit untuk ditemukan sebelum pengiriman, dan tidak bisa diperbaiki setelahnya.
Bulan ini kami membangun ulang audit email Brew berdasarkan pemeriksaan-pemeriksaan ini, masing-masing dengan ambang batas yang pasti. Anda bisa menjalankannya secara manual, dengan atau tanpa Brew.
Temuan dikelompokkan berdasarkan tingkat keparahan, dengan satu kesimpulan kesiapan.
Tautan yang rusak membuat pengiriman sia-sia. Pastikan:
#, example.com, atau {{url}} yang belum diisihttpsbrew.new/pricing yang mengarah ke tempat lain terlihat seperti phishingKlik setiap tautan di email uji yang sudah diterima, bukan di editor. ESP Anda menulis ulang tautan untuk pelacakan klik saat pengiriman, sehingga rantai pengalihan dan parameter pelacakan yang rusak baru terlihat di sana.
Jangan pernah biarkan pemeriksa otomatis membuka tautan berhenti berlangganan atau tautan preferensi. Sebagian penyedia menganggap setiap permintaan ke URL tersebut sebagai permintaan berhenti berlangganan. Selain itu, halaman penghalang bot yang ditampilkan kepada pemeriksa tidak membuktikan bahwa tautannya mati. Klik sendiri tautan itu.
Gmail memotong pesan dengan HTML lebih dari sekitar 102 KB dan menyembunyikan sisanya di balik tautan “Lihat seluruh pesan”. Akibatnya, footer, tautan berhenti berlangganan, dan alamat surat-menyurat ikut tersembunyi, sehingga email pemasaran yang terpotong diam-diam berubah menjadi masalah kepatuhan.
Ambang batas kami:
Kami memberi peringatan pada 80 KB karena pelacakan klik mengganti tautan pendek dengan URL pengalihan yang lebih panjang, dan sebagian ESP menambahkan markup. Email berukuran 98 KB di editor Anda bisa tiba sebagai 105 KB.
Penyebab pembengkakan yang umum: gaya inline yang diulang di setiap elemen, sisa komentar dari pembuat email, bagian seluler dan desktop duplikat yang disembunyikan, serta gambar base64 yang disematkan.
Setiap gambar harus:
alt, atau alt="" jika hanya dekoratifwidth dan height, agar tata letak tetap terjaga saat gambar dimuat atau saat gambar diblokirSatu gambar besar di atas sebaris teks tidak terbaca saat gambar dinonaktifkan, tidak dapat dipahami pembaca layar, dan menjadi sinyal spam bagi sebagian filter. Tulis judul dan penawaran sebagai teks asli, bukan di dalam gambar.
Flexbox, grid, position, gambar latar, dan SVG inline masing-masing rusak di setidaknya satu klien email utama. Can I email melacak dukungan untuk setiap fitur dan klien, dan merupakan referensi tunggal terbaik.
Paling waspadai Outlook. Di Gmail dan Apple Mail, tampilan biasanya hanya menurun sedikit tanpa terlihat rusak. Outlook klasik di Windows merender dengan mesin tata letak Word, mengabaikan banyak pengaturan lebar CSS, membuang gambar latar, dan menghapus padding dari tombol yang dibuat sebagai tautan bergaya.
Kami menandai sebuah fitur untuk satu keluarga klien, seperti Gmail atau Outlook, hanya jika setidaknya dua klien dalam keluarga itu tidak mendukungnya. Temuan itu menjadi peringatan hanya jika Outlook merusaknya tanpa cadangan. Selebihnya berstatus info. Jika tidak begitu, setiap email akan mendapat dua puluh peringatan klien, dan orang akan mengabaikan semuanya.
Pemeriksaan yang murah dan cepat:
lang pada <html>, agar pembaca layar melafalkan teks dengan benar<title>h1 ke h4WCAG 2.2 adalah acuannya. Sebagian besar masalah email berkaitan dengan kriteria WCAG tentang alternatif teks, kontras, bahasa halaman, dan heading.
Buat subjek kurang dari sekitar 60 karakter dan 9 kata, atau ponsel akan memotongnya. Hindari penulisan SEMUA HURUF KAPITAL, “RE:” atau “FWD:” pada email yang bukan balasan, serta tanda seru beruntun.
Buat teks pratinjau kurang dari sekitar 90 karakter, tanpa mengulang subjek. Jika dibiarkan kosong, banyak klien email akan menampilkan “Lihat di browser” sebagai gantinya.
Merge tag tanpa nilai cadangan akan mengirim “Halo ,” kepada setiap orang yang tidak memiliki nama depan. Pembaca akan mengingatnya.
Setiap angka harus punya sumber yang bisa Anda tunjukkan, terutama di draf pertama buatan AI, yang mudah menghasilkan angka dengan penuh percaya diri. Cara menulis email marketing dan panduan subjek email membahas pemilihan kata lebih dalam.
Email komersial memerlukan tautan berhenti berlangganan yang berfungsi dan alamat surat-menyurat yang valid sesuai ketentuan CAN-SPAM. Pengirim massal ke Gmail dan Yahoo juga memerlukan header berhenti berlangganan sekali klik, yang dibahas dalam Aturan yang tetap berlaku saat agen mengirim email Anda.
Email transaksional dikecualikan dari sebagian aturan pemasaran, tetapi tidak dari daftar periksa ini. Bukti pembayaran dengan tautan mati tetap akan berujung menjadi tiket dukungan.
Hapus elemen yang dibuang atau diblokir klien email:
<script>, <form>, dan <iframe>data:background-color, agar teks tetap terbaca jika gambar gagal dimuatAwali dengan doctype. Tanpa doctype, sebagian klien merender dalam quirks mode dan jarak antarelemen bergeser.
Audit email Brew menjalankan daftar ini dari:
POST /v1/emails/audit atau alat audit_emailLihat dokumentasi audit dan referensi API untuk semua field.
Pemeriksaan instan yang gratis berjalan otomatis untuk setiap aturan yang hanya membutuhkan HTML: placeholder, ukuran, teks alt dan dimensi gambar yang hilang, urutan heading, lang dan <title>, panjang subjek dan teks pratinjau, merge tag tanpa nilai cadangan, serta markup yang diblokir.
Jalankan audit menambahkan pemeriksaan yang memerlukan akses jaringan atau penilaian:
Setiap penilaian AI disetel agar setidaknya 95% temuan yang dimunculkannya benar pada email milik kami sendiri. Peninjau AI yang sering membunyikan alarm palsu lebih buruk daripada tidak ada sama sekali.
Audit lengkap membutuhkan 5 kredit. Jika ada pemeriksaan wajib yang tidak tersedia, Anda mendapatkan audit parsial gratis tanpa skor, karena skor yang melewatkan sebagian pemeriksaan akan menyesatkan.
Setiap audit menghasilkan skor 0 hingga 100 dan sebuah status: siap, perlu ditinjau, atau belum siap (di aplikasi ditampilkan sebagai Siap dikirim, Perlu ditinjau, dan Ada masalah). Setiap temuan memiliki tingkat keparahan, yaitu Kritis, Kesalahan, Peringatan, atau Info, ditambah bukti seperti status HTTP dari tautan yang mati.
Skor dimulai dari 100. Setiap temuan kritis mengurangi 20 poin, setiap kesalahan 10 poin, setiap peringatan 3 poin, dan info tidak mengurangi apa pun. Hanya tiga temuan pertama per aturan yang dihitung.
Contoh: tombol yang ditautkan ke #, tautan footer yang mengembalikan 404, dua gambar tanpa teks alt, subjek sepanjang 68 karakter, dan flexbox yang diabaikan dua klien Yahoo.
| Temuan | Tingkat keparahan | Poin |
|---|---|---|
| Tautan tombol berupa placeholder | Kritis | −20 |
| Tautan footer mengembalikan 404 | Kesalahan | −10 |
| Gambar tanpa teks alt (×2) | Peringatan | −6 |
| Subjek lebih dari 60 karakter | Peringatan | −3 |
| Flexbox diabaikan 2 klien Yahoo | Info | 0 |
| Skor | 61 |
Satu saja temuan kritis atau kesalahan berarti “belum siap”; jika hanya ada peringatan, statusnya “perlu ditinjau”. Perbaiki dua tautan tersebut, dan email ini mendapat skor 91 dengan status perlu ditinjau. Penilaian yang jujur: email ini sebenarnya aman dikirim, dan sisanya layak mendapat waktu satu menit.
Perbaiki di chat menyerahkan temuan berstatus peringatan dan yang lebih parah kepada agen Brew, lalu menjalankan ulang pemeriksaan instan gratis pada hasil perbaikannya.
Audit tidak memblokir pengiriman. Jika ada temuan kritis, dialog kirim meminta Anda memilih Tetap kirim dan mencatat keputusan untuk mengabaikan temuan tersebut. Pengiriman lewat API, MCP, dan otomatisasi melaporkan temuannya, lalu tetap berjalan. Itulah default yang tepat. Sebagian email yang tidak disukai audit tetap perlu dikirim, dan alat QA yang menyandera pengiriman pada akhirnya akan dimatikan.
Audit tidak menulis ulang HTML Anda. Perbaikan adalah langkah terpisah yang Anda mulai sendiri.
Audit tidak menguji penempatan kotak masuk, membuat tangkapan layar tampilan, atau memeriksa mode gelap. Untuk mode gelap, buka email uji di ponsel Anda dengan mode gelap aktif. Cara ini akan menangkap logo yang menghilang di latar hitam.
Di dialog kirim, 15 menit. Setelah itu, atau jika emailnya berubah, panel akan meminta Anda menjalankannya ulang. Lewat MCP, Anda bisa membaca ulang laporan yang tersimpan selama 7 hari tanpa biaya.
Tidak. Audit memeriksa email itu sendiri. Penempatan juga bergantung pada reputasi domain, autentikasi, dan tingkat keluhan, yang dibahas dalam panduan keterkiriman.
Bisa, lewat API atau MCP. Kirim emailHtml atau emailJsx sebagai pengganti ID email Brew, dan dapatkan laporan yang sama sebelum email itu masuk ke ESP Anda. Jika Anda me-remix templat dari galeri dan mengekspornya ke ESP Anda, audit email tersebut di Brew sebelum mengekspornya.
Siapa pun yang memiliki akses ke merek tersebut bisa menjalankannya: admin organisasi dan anggota yang ditambahkan ke merek itu. Brew tidak memiliki peran yang hanya bisa melihat.
