TL;DR
Reverse ETL adalah proses ngirim data yang udah diolah di data warehouse balik ke tool operasional kayak CRM, email marketing, atau spreadsheet tim. Arahnya kebalikan dari ETL biasa yang narik data dari aplikasi ke warehouse. Gunanya biar hasil analisis kepake orang yang kerja tiap hari, bukan berhenti di dashboard. Contohnya segmen pelanggan hasil query SQL dikirim otomatis ke tool blast WhatsApp, jadi tim bisa langsung follow up tanpa nunggu tim data ekspor manual.
Reverse ETL adalah proses ngirim data yang udah diolah di data warehouse balik ke tool operasional yang dipakai tim tiap hari.
Kamu udah ngitung segmen pelanggan pakai SQL. Hasilnya rapi di warehouse. Tapi tim marketing kerjanya di tool blast WhatsApp, dan mereka nggak bisa buka warehouse.
Jadi tiap Senin kamu ekspor CSV, kirim lewat chat, dan mereka impor manual. Reverse ETL ngeberesin loop itu supaya jalan otomatis.
Reverse ETL adalah proses nyalin data hasil olahan dari data warehouse ke aplikasi bisnis, misalnya CRM, tool email, atau papan tugas tim sales. Arahnya kebalikan dari ETL biasa yang narik data dari aplikasi masuk ke warehouse. Tujuannya biar hasil analisis bisa dipakai langsung di tempat kerja orangnya.
Namanya kedengeran teknis, tapi idenya sederhana. Warehouse jadi sumber kebenaran, lalu potongan yang relevan dikirim ke tool yang butuh.
Contoh potongan yang sering dikirim: skor risiko churn per pelanggan, status langganan, total belanja seumur hidup, dan label segmen.
Karena dashboard nggak bikin orang bertindak. Dashboard bikin orang tau.
Tim sales nggak buka Looker Studio sebelum nelepon pelanggan. Mereka buka CRM. Kalau label pelanggan berisiko cuma ada di dashboard, informasi itu nggak nyampe ke momen keputusan.
Ada tiga masalah nyata yang diberesin reverse ETL:
Alurnya empat langkah dan urutannya selalu sama.
Tool yang biasa dipakai buat langkah ini termasuk Hightouch dan Census. Kalau tim kamu udah pakai dbt buat modelnya, transformasi tabelnya bisa nyambung langsung. Dokumentasi resminya ada di dbt Docs.
Buat tim kecil, reverse ETL nggak harus pakai tool berbayar. Script Python yang jalan tiap malam dan nulis ke Google Sheets udah masuk kategori yang sama.
Toko_berkah punya 4.812 pelanggan terdaftar dari program member kartu belanja. Data transaksinya masuk ke warehouse tiap malam dari sistem kasir.
Query di bawah ini bikin tabel segmen yang jadi bahan kiriman ke tool operasional.
WITH ringkasan AS (
SELECT
pelanggan_id,
MAX(tanggal) AS transaksi_terakhir,
COUNT(*) AS jumlah_transaksi,
SUM(total) AS total_belanja
FROM transaksi
WHERE tanggal >= CURRENT_DATE - INTERVAL '365 days'
GROUP BY pelanggan_id
)
SELECT
pelanggan_id,
transaksi_terakhir,
jumlah_transaksi,
total_belanja,
CASE
WHEN transaksi_terakhir >= CURRENT_DATE - INTERVAL '30 days'
AND jumlah_transaksi >= 5 THEN 'setia'
WHEN transaksi_terakhir < CURRENT_DATE - INTERVAL '60 days'
AND jumlah_transaksi >= 3 THEN 'hampir hilang'
WHEN jumlah_transaksi = 1 THEN 'baru sekali'
ELSE 'biasa'
END AS segmen,
CURRENT_TIMESTAMP AS diperbarui_pada
FROM ringkasan;Hasilnya kayak gini:
| Segmen | Jumlah pelanggan | Rata-rata belanja per transaksi |
|---|---|---|
| setia | 531 | Rp 214.000 |
| hampir hilang | 612 | Rp 187.000 |
| baru sekali | 2.104 | Rp 96.000 |
| biasa | 1.565 | Rp 131.000 |
Angka yang bikin pemilik toko kaget: segmen hampir hilang isinya 612 orang, dan mereka rata-rata belanja Rp 187.000 sekali datang. Itu 2 kali lipat dari pelanggan yang baru belanja sekali.
Kalau setengah dari 612 orang itu balik sekali aja, tambahannya sekitar Rp 57 juta. Nilai segitu nggak akan kesentuh kalau tabelnya cuma nongkrong di warehouse.
Setelah tabel ini disinkron tiap malam ke tool blast, tim toko bisa kirim promo ke kolom segmen langsung tanpa nunggu ekspor. Dasar pemikiran pengelompokannya ada di segmentation, dan pola perilaku per kelompok waktunya di cohort analysis.
Ngirim semua kolom. Tool operasional jadi penuh field yang nggak dipakai, dan orang bingung mana yang harus dilihat. Kirim 4 kolom yang jelas kegunaannya.
Kunci pencocokan yang berantakan. Nomor HP yang formatnya campur 08 dan +62 bakal bikin sebagian pelanggan nggak ketemu pasangannya. Rapikan dulu formatnya di warehouse.
Nimpa data yang diisi manusia. Kalau tim sales nulis catatan di field yang sama, sinkronisasi bakal ngehapus catatan mereka. Pakai field terpisah khusus data hasil sinkron.
Nggak ada kolom waktu perbarui. Tanpa kolom kayak diperbarui_pada, nggak ada yang tau data itu segar atau udah basi 3 minggu.
Sinkron data yang kualitasnya belum dicek. Salah di warehouse cuma bikin dashboard keliru. Salah yang disinkron bikin pelanggan dapat promo yang salah. Jalanin cek kualitas data pakai SQL sebelum sinkron pertama.
Kalau timmu di bawah 10 orang dan semua orang kerja di satu spreadsheet yang sama, kamu belum butuh. Nambah tool cuma nambah tempat rusak.
Kamu mulai butuh waktu tiga tanda ini muncul bareng: ada minimal dua tool operasional yang butuh data sama, ekspor manualnya lebih dari sekali seminggu, dan ada orang yang ngeluh angkanya beda antar tool.
Sebelum itu, jadwalin query lalu tulis hasilnya ke Google Sheets. Itu udah nyelesaikan 80% masalahnya dengan biaya nol.
Bedanya di arah aliran datanya. ETL narik data dari aplikasi kayak sistem kasir atau CRM masuk ke data warehouse buat dianalisis. Reverse ETL ngambil hasil olahan di warehouse dan ngirimnya balik ke aplikasi itu. ETL bikin kamu bisa nganalisis, reverse ETL bikin hasil analisisnya kepake orang lapangan. Dua-duanya jalan bareng di tim data yang udah mapan.
Nggak wajib. Tool kayak Hightouch atau Census bikin sinkronisasi lebih gampang diatur dan dipantau, tapi kamu bisa mulai dari script Python terjadwal yang baca hasil query lalu nulis ke API tool tujuan atau ke Google Sheets. Buat tim kecil dengan satu atau dua tujuan sinkron, cara manual ini cukup dan biayanya nol. Pindah ke tool berbayar waktu jumlah tujuannya nambah dan pemantauannya mulai repot.
Sesuaikan sama seberapa cepat orang bertindak atas datanya. Kalau tim follow up pelanggan sekali sehari, sinkron harian tiap subuh udah cukup. Sinkron tiap jam masuk akal cuma buat kasus kayak deteksi transaksi mencurigakan. Sinkron terlalu sering nambah biaya query di warehouse tanpa nambah manfaat. Mulai dari harian, naikkan cuma kalau ada keluhan nyata soal data basi.
Pisahin fieldnya. Bikin field khusus yang isinya cuma diisi sistem, misalnya segmen_warehouse dan belanja_365hari, lalu biarkan field catatan tetap milik tim. Sebagian tool CRM punya pengaturan buat ngunci field dari edit manual. Tulis juga di dokumentasi internal mana field yang otomatis dan mana yang manual, biar nggak ada yang ngedit field sinkron dan bingung kenapa berubah lagi besoknya.
Label segmen pelanggan dan tanggal transaksi terakhir. Dua kolom ini yang paling sering langsung ngubah tindakan orang, dan gampang dipahami tanpa penjelasan. Kolom skor yang rumit kayak probabilitas churn sebaiknya nanti, setelah tim percaya sama kolom yang sederhana dulu. Aturan praktisnya, kirim kolom yang bisa dijelasin ke tim sales dalam satu kalimat.
Analisis yang berhenti di dashboard cuma ngubah pengetahuan. Analisis yang nyampe ke tool kerja ngubah tindakan.
Reverse ETL bagian dari alur itu, dan kamu bisa mulai tanpa beli apa-apa. Satu tabel hasil, satu kunci pencocokan, satu jadwal harian.
Coba ambil satu query segmen yang udah kamu punya, tambahin kolom diperbarui_pada, lalu jadwalin hasilnya nulis ke satu sheet yang dibuka tim tiap pagi. Kalau kamu mau ngerapiin dulu sisi historis datanya, lanjut ke SQL SCD Type 2.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.
Nambah 30 hari ke tanggal invoice, ngurangin sebulan buat cari periode lalu, ngitung selisih hari antar order. Semua itu aritmetika tanggal, dan SQL punya operator INTERVAL buat ngerjainnya.