# Otomatisasi email marketing: mulai dari pemeriksaan status

URL kanonis: https://brew.new/id/blog/email-marketing-automation-guide
Penulis: Thomas Park
Dipublikasikan: 2026-08-19
Diperbarui: 2026-09-29

Otomatisasi email adalah keputusan berulang tentang kapan sebuah pesan dikirim. Editor hanyalah salah satu bagiannya. Peristiwa, status pelanggan saat ini, dan aturan penghentian sama pentingnya dengan teks email.

Sebelum menggambar rangkaian, tuliskan alasan setiap pesan perlu ada dan apa yang bisa membuatnya tidak lagi pantas dikirim saat waktunya tiba.

## Tentukan pemicu dan datanya

Pendaftaran, pembelian yang selesai, pembayaran yang gagal, atau pencapaian di produk bisa memulai otomatisasi. Beri peristiwa itu makna yang jelas. “Pengguna aktif” itu ambigu; “laporan pertama diekspor” adalah sesuatu yang bisa dicatat dan diuji oleh aplikasi.

Sertakan hanya data yang dibutuhkan pesan, dengan ID yang stabil dan stempel waktu jika relevan. Tentukan sistem mana yang menjadi pemilik setiap nilai. Pengiriman peristiwa bisa dicoba ulang, jadi gunakan perilaku idempotensi yang didukung integrasi Anda dan uji pengiriman ganda.

[Integrasi Stripe](/id/browse/integrations/stripe) menyediakan peristiwa langganan dan pembayaran yang terdokumentasi. Peristiwa kustom dari aplikasi bisa mencakup pencapaian yang khas untuk produk Anda.

## Bedakan langkah tunggu dari pemeriksaan kelayakan

Langkah tunggu mengubah kapan langkah berikutnya dijalankan. Langkah itu sendiri tidak memperbarui fakta yang diketahui otomatisasi.

Dalam alur Brew yang dipicu peristiwa, langkah Filter dan langkah Percabangan bersyarat membedakan data peristiwa dari data kontak. Kondisi pada `activated` atau `payload.activated` membaca peristiwa aslinya. Payload pendaftaran yang berisi `activated: false` mungkin sudah usang keesokan harinya. Kondisi pada `contact.activated` membaca field kontak Brew milik penerima yang terkini saat langkah kondisi itu dijalankan, termasuk setelah langkah Tunggu.

Untuk pengingat penyiapan, deklarasikan field kontak boolean `activated`, jaga agar tetap tersinkron dari aplikasi Anda, lalu letakkan filter `contact.activated equals false` setelah langkah tunggu. Field yang kosong tidak sama dengan field yang bernilai false, jadi uji keduanya. Letakkan kondisi sebelum setiap pengingat berikutnya yang bergantung pada status ini; pembaruan kontak atau peristiwa baru tidak otomatis membatalkan eksekusi yang sudah berjalan.

Pembacaan data kontak ini tidak mengirim kueri ke database produk atau penyedia penagihan Anda. Jika kelayakan bergantung pada aktivitas yang tidak disinkronkan, invoice tertentu, atau isi keranjang saat ini, jadwalkan pemeriksaan itu di aplikasi Anda. Saat waktunya tiba, baca data acuan, lalu kirim peristiwa baru bagi kontak yang memenuhi syarat hanya jika pengingat itu masih masuk akal.

[Panduan konversi uji coba](/id/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events) membahas kedua pendekatan tersebut. [Referensi otomatisasi](https://docs.brew.new/create-emails/build-an-automation#check-state-before-later-reminders) menjelaskan path field yang dipakai dalam kondisi.

## Mulai dengan satu rangkaian yang berguna

Otomatisasi sambutan bisa mengantarkan materi atau langkah berikutnya yang dijanjikan saat pendaftaran. Notifikasi pembayaran bisa menjelaskan peristiwa penagihan yang benar-benar terjadi. Email pencapaian produk bisa membantu seseorang memanfaatkan hasil dari apa yang baru saja mereka selesaikan.

Buat versi pertama cukup kecil agar mudah diperiksa. Untuk setiap pesan, catat audiens, pemicu, field yang wajib ada, tindakan yang diharapkan, dan kondisi yang seharusnya mencegah pengiriman. Sertakan status langganan dan perilaku pengecualian dalam tinjauan tersebut.

Di Brew, otomatisasi yang sudah dipublikasikanlah yang mengendalikan eksekusi. Membuat atau mengedit draf tidak sama dengan memublikasikannya. Pengaturan integrasi dan status otomatisasi memiliki tugas yang berbeda; misalnya, pengaturan **Sinkronkan nama lengkap** pada integrasi Stripe mengatur pembaruan nama, bukan apakah otomatisasi berbasis peristiwa dijalankan.

## Uji perubahan status

Uji eksekusi normal, field opsional yang kosong, peristiwa duplikat, kontak pemasaran yang sudah berhenti berlangganan, dan pelanggan yang statusnya berubah sebelum pengingat jatuh tempo. Untuk kondisi kontak, perbarui field di Brew selama langkah tunggu berlangsung, lalu pastikan kondisi berikutnya melewati pengingat tersebut. Untuk pengingat yang dijadwalkan aplikasi, pastikan aplikasi tidak mengirim peristiwa baru saat pelanggan sudah tidak memenuhi syarat.

Periksa email yang benar-benar diterima, bukan hanya catatan eksekusinya. Periksa tautan, merge tag, domain pengirim, dan versi persis yang dipublikasikan. Permintaan pemicu yang berhasil saja tidak membuktikan bahwa pesan yang tepat sampai ke kotak masuk yang tepat.

## Tinjau otomatisasi seiring perubahan produk

Rangkaian evergreen bisa diam-diam menjadi usang saat langkah penyiapan, harga, atau akses produk berubah. Tetapkan penanggung jawab untuk setiap rangkaian dan tinjau rangkaian itu setelah ada rilis yang relevan.

Ukur hasil yang dituju sekaligus efek yang tidak diinginkan. Jika tujuannya penyelesaian penyiapan, lacak tindakan itu bersama keluhan dan permintaan berhenti berlangganan. Gunakan [panduan metrik](/id/blog/email-metrics-that-matter) agar Anda tidak menganggap pembukaan sebagai bukti bahwa otomatisasi itu membantu.