Pahami email pemasaran dan transaksional yang dipicu peristiwa, dengan model praktis untuk payload pemicu, publikasi, dan kelayakan yang diperiksa belakangan.
Email yang dipicu berawal dari sesuatu yang terjadi: pendaftaran, invoice yang gagal dibayar, ekspor yang selesai, atau peristiwa lain yang bisa dijelaskan sistem Anda. Peristiwa itu memberikan konteks untuk sebuah pesan.
Pemicu tidak menentukan apakah pesannya bersifat pemasaran atau transaksional. Yang menentukan adalah tujuan pesan dan hubungan dengan penerimanya. Bukti pembayaran dan tawaran upgrade bisa berasal dari produk yang sama, tetapi tetap membutuhkan aturan pengiriman yang berbeda.
Pilih nama yang menggambarkan suatu tindakan atau kondisi yang sudah terverifikasi. Deklarasikan field yang dibutuhkan email dan uji payload yang representatif. Hindari peristiwa yang maknanya berbeda-beda tergantung layanan mana yang mengirimnya.
Misalnya, peristiwa pesanan selesai bisa membawa alamat penerima, nomor referensi pesanan, dan tautan ke pesanan tersebut. Jangan masukkan data sensitif atau data yang tidak perlu ke dalam payload. Referensi API mendokumentasikan bentuk permintaan yang didukung.
Model otomatisasi Brew menghubungkan pemicu ke langkah-langkah seperti mengirim email. Buat dan tinjau drafnya, lalu publikasikan otomatisasi tersebut sebelum berharap peristiwa di lingkungan produksi akan menjalankannya. Artikel Otomatisasi email AI membahas alur siklus hidup mana yang perlu dibangun lebih dulu, dari pendaftaran hingga reaktivasi.
Rangkaian sambutan yang mempromosikan produk termasuk pemasaran. Bukti pembelian atau pesan keamanan akun yang diminta pengguna bisa termasuk transaksional. Pesan campuran memerlukan penilaian tujuan utama; menambahkan sedikit promosi tidak otomatis menjawab pertanyaan hukumnya, ke arah mana pun.
Pastikan informasi akun yang penting mudah ditemukan. Gunakan tujuan domain pengirim yang sesuai dan uji perilaku langganannya. Baca panduan email transaksional untuk memahami perbedaannya serta persyaratan penyedia yang ditautkan di sana.
Untuk pemasaran, verifikasi izinnya dan patuhi status berhenti berlangganan serta pengecualian. Peristiwa yang cocok bukanlah izin untuk mengirim email kepada siapa pun yang alamatnya kebetulan muncul di payload.
Misalkan Anda ingin mengingatkan pengguna uji coba yang belum menyelesaikan penyiapan setelah enam hari. Peristiwa pendaftaran hanya tahu kondisi saat pendaftaran. Peristiwa itu tidak bisa memprediksi apakah pengguna akan menyelesaikannya besok.
Untuk pemeriksaan hari keenam di Brew, langkah Filter atau Percabangan bersyarat bisa membaca field kontak Brew terkini lewat contact.<name>. Definisikan dan sinkronkan field aktivasi dan langganan, lalu periksa keduanya setelah langkah tunggu. Field peristiwa seperti payload.activated tetap berisi nilai dari peristiwa aslinya. Jika status yang dibutuhkan berada di luar Brew, minta aplikasi Anda memeriksanya pada hari keenam dan mengirim peristiwa pengingat baru hanya jika pengguna masih memenuhi syarat.
Aturan yang sama berlaku jika kondisinya adalah “belum membeli” atau “masih di paket gratis”. Artikel rangkaian uji coba menjelaskan pola di sisi aplikasi.
Uji permintaan peristiwa, eksekusi otomatisasi, dan email yang diterima. Sertakan field yang kosong, percobaan ulang, penerima uji yang privat, dan perubahan status yang seharusnya mencegah pengiriman berikutnya.
Untuk penyedia yang terhubung, gunakan nama peristiwa mereka yang sebenarnya. Halaman Stripe mencantumkan peristiwa yang didukung Brew dan menjelaskan mengapa pengaturan Sinkronkan nama lengkap tidak berkaitan dengan memublikasikan otomatisasi.
Setelah jalurnya berfungsi, jaga agar rangkaiannya tetap mudah dipahami. Sekumpulan kecil peristiwa yang eksplisit dan pesan yang sudah ditinjau lebih mudah dikelola daripada satu otomatisasi panjang yang kondisinya tidak bisa dijelaskan siapa pun.
