Susun rangkaian konversi uji coba dari tindakan pengguna di produk Anda: peristiwa aktivasi, satu tugas per email, cek kelayakan, dan uji kondisi keluar.
Email konversi uji coba seharusnya merespons apa yang sudah dilakukan pengguna. Orang yang belum membuat proyek butuh bantuan penyiapan. Orang yang memakai produk setiap hari butuh penjelasan yang jelas tentang paket berbayar. Mengirim hitung mundur yang sama kepada keduanya berarti mengabaikan perbedaan itu.
Panduan ini memisahkan desain rangkaian dari logika aplikasi yang menentukan siapa yang seharusnya menerima setiap email.
Pilih satu tindakan yang menunjukkan bahwa pengguna sudah mencapai hasil berguna pertama dari produk Anda. Buat cukup spesifik agar backend Anda bisa mencatatnya: proyek dibuat, impor selesai, atau rekan tim diundang. Kunjungan halaman jarang cukup jika berdiri sendiri.
Catat waktu pendaftaran, akhir masa uji coba, aktivasi, dan status pembayaran di sistem yang menjadi sumber fakta-fakta tersebut. Perlakukan field kontak di platform email sebagai data hasil sinkronisasi, bukan sebagai bukti bahwa alur yang dimulai lebih awal membaca status terbaru.
| Pesan | Kapan berguna | Kelayakan yang diperiksa saat waktunya tiba |
|---|---|---|
| Sambutan | Setelah pendaftaran atau verifikasi | Akun ada dan boleh menerima pesan ini |
| Bantuan penyiapan | Sekitar dua hari kemudian, disesuaikan dengan produk Anda | Belum teraktivasi |
| Tindakan berguna berikutnya | Setelah aktivasi | Sudah teraktivasi dan belum menyelesaikan tindakan itu |
| Uji coba berakhir | Sebelum batas akhir masa uji coba yang sebenarnya | Masa uji coba masih aktif dan akun belum berbayar |
| Sapaan terakhir | Setelah masa uji coba berakhir, jika sesuai | Masih belum membayar, memenuhi syarat, dan diizinkan menerima email pemasaran |
Waktu-waktu ini adalah titik awal untuk diuji, bukan jeda dengan performa terbaik yang sudah terukur. Sebutkan batas akhir masa uji coba yang sebenarnya dan apa yang terjadi selanjutnya. Jangan mengarang kelangkaan atau menyiratkan akan ada tagihan jika tidak ada metode pembayaran yang tersimpan.
Dalam alur Brew yang dipicu peristiwa, kondisi pada payload.activated membaca peristiwa aslinya, sedangkan kondisi pada contact.activated membaca field kontak Brew milik penerima yang terkini saat langkah Filter atau Percabangan bersyarat dijalankan. Untuk melewati pengingat penyiapan setelah aktivasi, deklarasikan field boolean tersebut, jaga agar tetap tersinkron dari produk Anda, lalu periksa contact.activated equals false setelah setiap langkah Tunggu yang relevan. Nilai yang kosong tidak sama dengan false; uji keduanya secara terpisah.
Pembacaan ini memakai data kontak yang tersimpan di Brew, bukan database aplikasi Anda atau permintaan langsung ke Stripe. Menerima peristiwa aktivasi atau pembayaran tidak otomatis membatalkan eksekusi yang sudah berjalan. Diagram otomatisasi membutuhkan kondisi sebelum setiap pengiriman yang bergantung pada status.
Untuk fakta di luar Brew, minta aplikasi Anda menjadwalkan sebuah tugas. Saat waktunya tiba, baca data akun atau invoice terkini, lalu kirim peristiwa kustom Brew yang terpisah hanya jika penerima masih memenuhi syarat. Sertakan data terkini yang dibutuhkan untuk personalisasi dalam peristiwa baru tersebut.
Sebagai contoh, pengingat yang dijadwalkan aplikasi bekerja seperti ini:
Signup committed → fire welcome event
Reminder job becomes due → read current account
Already activated or paid → finish without firing an email event
Still eligible → fire setup-reminder event with current dataGunakan ID pemicu sebenarnya yang dikembalikan Brew dan skema yang dideklarasikan untuk pemicu tersebut. Ikuti panduan penyiapan otomatisasi dan kontrak payload bertipe. Gunakan mekanisme idempotensi yang terdokumentasi untuk pengiriman peristiwa yang dicoba ulang.
Jika Stripe mengelola masa uji coba, peristiwa langganannya memberikan konteks penagihan. Integrasi Stripe menyediakan pemicu peristiwa yang didukung, termasuk customer.subscription.trial_will_end. Aktivasi produk tetap menjadi wewenang aplikasi Anda, kecuali Anda mengirim informasi itu secara terpisah.
Untuk pengingat terkait pembayaran yang dikirim belakangan, periksa data Stripe terkini. Pembaruan kartu yang berhasil bukan bukti bahwa sebuah invoice sudah dibayar. Koordinasikan dengan email dari Stripe sendiri agar pelanggan menerima satu pemberitahuan untuk setiap tujuan.
Mulailah dari situasi penerima yang sebenarnya. Jelaskan satu tindakan yang berguna dan tautkan langsung ke tindakan itu. Email penyiapan bisa menawarkan contoh singkat dan alamat untuk membalas. Email paket berbayar sebaiknya menjelaskan batas atau fitur yang relevan dan harga yang sebenarnya, dengan tautan ke halaman harga terkini.
Pastikan persetujuan pemasaran, perilaku berhenti berlangganan, dan tujuan domain selaras dengan pesannya. Pendaftaran uji coba tidak membenarkan email promosi yang tidak berkaitan.
Uji apa yang terjadi jika kontak teraktivasi atau membayar sebelum setiap pemeriksaan kelayakan. Untuk kondisi kontak, perbarui field Brew yang relevan selama masa tunggu dan pastikan pengingatnya dilewati. Untuk pemeriksaan yang dijadwalkan aplikasi, pastikan akun yang tidak memenuhi syarat tidak menghasilkan peristiwa pengingat. Uji juga percobaan ulang, perpanjangan masa uji coba, penghapusan akun, berhenti berlangganan, dan field yang kosong. Periksa log aplikasi sekaligus riwayat eksekusi di Brew.
Evaluasi aktivasi dan konversi ke paket berbayar dengan data produk Anda, dan kegagalan pengiriman dengan platform email. Tingkat buka saja tidak menunjukkan apakah rangkaian ini membantu pengguna uji coba. Lihat desain rangkaian sambutan untuk contoh dan MCP vs REST untuk pembagian implementasinya.
