Event-Driven Marketing Automation: Cara Tim Indonesia Kabur dari Spaghetti Zapier

TL;DR: Event-Driven Marketing Automation memindahkan trigger dari rangkaian webhook satu-ke-satu menjadi satu event broker pusat yang didengar banyak tools. Untuk tim marketing Indonesia di skala 50 ribu kontak ke atas, pola ini menurunkan biaya integrasi, mempercepat eksperimen kampanye, dan menjaga audit log tetap rapi.

Lima tahun lalu, tim marketing yang punya tiga tools cukup pakai satu Zap per integrasi. Sekarang stack rata-rata berisi sepuluh tools, dan setiap tools butuh tahu tujuh event berbeda. Hasilnya: 70 Zap, dokumentasi minim, dan satu kontraktor freelance yang jadi single point of failure. Pola ini saya temui di hampir semua audit otomasi marketing klien selama enam bulan terakhir, terutama di SaaS B2B Indonesia yang baru menyentuh seri A.

Masalah Spaghetti Webhook

Setiap webhook satu-ke-satu menyembunyikan tiga risiko:

1. Tidak ada satu sumber kebenaran soal "siapa mendengar event apa".
2. Penambahan tool baru memaksa rewrite N webhook lama.
3. Retry dan dedup harus dipikirkan ulang per integrasi, sering pakai Idempotency Key seadanya.

Saat tim Vetmo ingin menambahkan WhatsApp Business API ke flow onboarding, ada delapan webhook yang harus diubah dan tiga di antaranya milik vendor lama yang sudah tidak responsif. Eksperimen kampanye yang harusnya seminggu jadi tiga minggu.

Apa Bedanya dengan Event-Driven

Event-Driven Architecture memindahkan logika dari "sistem A langsung panggil sistem B" menjadi "sistem A menerbitkan event ke broker, sistem B-Z mendengar event yang relevan". Broker boleh sederhana (Webhooks.fyi, Inngest, Zapier Tables, Supabase Realtime) sebelum naik ke Kafka atau AWS EventBridge.

Studi Kasus: Migrasi Atmo dari Zapier ke Inngest

Saat membantu Atmo memindahkan automasi onboarding LMS, tim mengganti 23 Zap menjadi 6 event utama: user.signed_up, course.enrolled, payment.succeeded, lesson.completed, subscription.cancelled, dan support.requested. Konsumer (email, WhatsApp, CRM, Meta CAPI, GA4 server-side, ad platform) berlangganan event yang relevan saja. Hasil tiga bulan setelah migrasi: waktu rilis kampanye baru turun dari rata-rata 9 hari menjadi 2 hari, dan tim marketing bisa eksperimen tanpa membuka tiket developer.

Kapan Belum Worth Migrasi

Kalau tim marketing punya kurang dari empat tools dan kurang dari sepuluh event yang dipakai aktif, EDA murni bisa over-engineering. Pendekatan campuran lebih masuk akal:

1. Tetap pakai Zapier atau Make sebagai surface low-code.
2. Sentralkan event di Supabase atau Segment sebagai single source of truth.
3. Hanya pindah ke broker khusus saat skala kontak menembus 50 ribu atau frekuensi event di atas 100 ribu per hari.

Pendekatan ini sejalan dengan riset Confluent State of Data in Motion 2024 yang menunjukkan adopsi EDA paling efektif setelah perusahaan punya minimal tiga sumber data internal yang stabil.

Pertanyaan Umum

Apakah EDA mengganti CDP seperti Segment atau RudderStack?

Tidak. CDP biasanya berperan sebagai event collector dan broker logis sekaligus. EDA murni berbasis Kafka cocok untuk tim engineering besar yang butuh kontrol penuh.

Apakah aman pakai Supabase Realtime sebagai broker?

Cukup untuk skala awal sampai menengah. Untuk volume di atas 1 juta event per hari atau butuh ordering ketat, naik ke Redpanda, NATS, atau Kafka.

Bagaimana cara mulai tanpa banyak coding?

Mulai dari mendefinisikan 5 sampai 7 event utama tertulis di satu dokumen. Banyak tim gagal bukan karena kurang tools, tapi karena tidak sepakat soal nama event.

Apa risiko terbesar EDA bagi marketer?

Visibility. Karena event jalan asinkron, marketer perlu dashboard atau audit log untuk memastikan tiap kampanye benar terkirim. Pasang observability sejak awal.

Apakah EDA cocok untuk UMKM?

Cocok versi ringan. Pakai n8n self-hosted dengan satu queue Redis. Biayanya di bawah Rp 500 ribu per bulan dan sudah memberi 80 persen manfaat EDA.

Penutup

Marketing automation yang bisa di-scale adalah marketing automation yang berani membuang webhook satu-ke-satu sebelum jumlahnya melebihi 30. EDA bukan soal teknologi, melainkan soal disiplin menamai event dan sepakat soal kontrak. Ketika tim sudah sepakat, penambahan tool baru jadi pekerjaan satu sore, bukan satu sprint.