RFM dengan Postgres dan Supabase: Segmentasi Pelanggan E-commerce Indonesia Tanpa CDP Mahal di 2026

TL;DR: Segmentasi RFM bisa dijalankan di Supabase dengan satu query Postgres pakai NTILE 5, tanpa perlu CDP atau tool segmentasi mahal. Hasilnya berupa kode tiga digit per pelanggan yang langsung bisa dipakai untuk kampanye reaktivasi dan retensi. Untuk e-commerce Indonesia dengan jumlah order menengah, pendekatan ini menurunkan biaya analitik dan mempercepat eksekusi kampanye.

Saat membantu Nalesha membangun ulang funnel e-commerce parfum mereka, satu hal yang sering muncul adalah pertanyaan klasik: pelanggan mana yang sebenarnya layak diberi diskon? Tanpa segmentasi, semua pelanggan diperlakukan sama. Champions yang sudah loyal dapat diskon yang sebenarnya tidak mereka butuhkan, sementara pelanggan At Risk yang hampir hilang malah tidak diapa-apakan. Dalam beberapa proyek terakhir, saya melihat tim marketing UMKM Indonesia melompat ke tool segmentasi mahal sebelum mencoba solusi yang sebenarnya sudah tersedia di stack mereka.

RFM Segmentation adalah pendekatan paling efisien untuk e-commerce yang baru mulai serius dengan retensi. Modal awalnya hanya tabel order yang bersih dan akses ke database Postgres. Tidak butuh CDP, tidak butuh integrasi pihak ketiga, tidak butuh agency tambahan.

Kenapa RFM Cocok untuk E-commerce Indonesia

Dibandingkan segmentasi berbasis behavior tracking yang butuh data pixel dan SDK lengkap, RFM hanya butuh data transaksi. Untuk mayoritas e-commerce Indonesia yang masih bergantung pada Tokopedia, Shopee, atau platform sendiri di Next.js dan Supabase, data order biasanya sudah rapi. Tantangannya bukan ketersediaan data, melainkan eksekusi: bagaimana mengubah tabel orders menjadi segmen yang bisa di-query oleh tim CRM tanpa harus menunggu data engineer.

Pendekatan RFM juga lebih mudah dijelaskan ke stakeholder non-teknis. Saat saya presentasi ke klien Nalesha, kalimat "pelanggan ini terakhir beli 14 hari lalu, sudah belanja 6 kali, total 3,2 juta rupiah" jauh lebih mudah dipahami daripada cluster berbasis machine learning. Konsep ini juga sejalan dengan Cohort Analysis untuk validasi silang.

Query Postgres untuk Skor RFM

Berikut struktur query yang saya pakai. Semua bobot setara, threshold pakai NTILE 5 untuk distribusi merata.

WITH rfm_base AS (
  SELECT
    customer_id,
    EXTRACT(DAY FROM NOW() - MAX(order_date))::int AS recency_days,
    COUNT(*) AS frequency,
    SUM(net_amount) AS monetary
  FROM public.orders
  WHERE order_date >= NOW() - INTERVAL '24 months'
    AND status = 'paid'
  GROUP BY customer_id
),
rfm_scored AS (
  SELECT
    customer_id,
    recency_days, frequency, monetary,
    NTILE(5) OVER (ORDER BY recency_days DESC) AS r_score,
    NTILE(5) OVER (ORDER BY frequency ASC) AS f_score,
    NTILE(5) OVER (ORDER BY monetary ASC) AS m_score
  FROM rfm_base
)
SELECT
  customer_id, r_score, f_score, m_score,
  (r_score::text || f_score::text || m_score::text) AS rfm_code,
  CASE
    WHEN r_score >= 4 AND f_score >= 4 AND m_score >= 4 THEN 'Champions'
    WHEN r_score >= 3 AND f_score >= 3 THEN 'Loyal'
    WHEN r_score <= 2 AND f_score >= 3 THEN 'At Risk'
    WHEN r_score <= 2 AND f_score <= 2 THEN 'Hibernating'
    ELSE 'Potential'
  END AS segment
FROM rfm_scored;

NTILE pada Recency dibalik (ORDER BY recency_days DESC) supaya pelanggan yang baru beli dapat skor 5. Frequency dan Monetary diurutkan ASC sehingga skor lebih tinggi sama dengan nilai lebih tinggi. Hasil akhirnya berupa tabel yang bisa langsung dipakai sebagai source di tools BI atau email marketing.

Memetakan Segmen ke Aksi

Skor saja tidak berguna kalau tidak terhubung ke playbook. Berikut pemetaan yang saya pakai untuk klien e-commerce kelas menengah:

Praktik ini menurunkan CAC efektif karena budget retensi diarahkan ke segmen yang ROI nya jelas. Studi industri seperti yang dirangkum Klaviyo Benchmarks menunjukkan email reaktivasi ke segmen At Risk biasanya menghasilkan revenue per recipient 3 sampai 5 kali lebih tinggi daripada blast generik. Angka pasti bervariasi per industri.

Implementasi di Supabase

Di Supabase, query di atas bisa disimpan sebagai materialized view yang di-refresh harian via cron Edge Function. Hasilnya disinkronkan ke tools email marketing seperti Mailchimp atau internal admin di Next.js. Untuk Nalesha, kami menjadwalkan refresh tiap dini hari dan men-trigger kampanye otomatis berdasarkan perubahan segmen, terutama transisi Champions ke At Risk yang biasanya jadi sinyal awal churn.

Materialized view juga membuat dashboard internal lebih cepat karena perhitungan NTILE tidak perlu diulang tiap kali admin membuka panel segmentasi. Pola ini sejalan dengan rekomendasi Supabase Performance Guide untuk operasi agregat berskala menengah.

Pertanyaan Umum

Apakah RFM bisa dijalankan tanpa Postgres?

Bisa, di spreadsheet sekalipun. Tapi NTILE Postgres jauh lebih cepat dan reproducible saat data order sudah lebih dari 50 ribu baris.

Berapa frekuensi refresh yang ideal?

Harian untuk e-commerce aktif. Mingguan cukup untuk bisnis dengan siklus transaksi panjang seperti kursus atau program konsultasi.

Apakah skor RFM perlu bobot berbeda?

Untuk produk margin tinggi, Monetary bisa diberi bobot lebih besar. Untuk produk konsumsi rutin, Frequency lebih dominan. Mulai dengan bobot setara, sesuaikan setelah 2 sampai 3 siklus kampanye.

Bagaimana RFM berinteraksi dengan AI Search?

Tidak langsung. RFM adalah pengukuran internal pelanggan eksisting, sementara AI Search bicara akuisisi. Dua-duanya saling melengkapi: AI Search membawa pelanggan baru, RFM memastikan mereka tidak hilang.

Penutup

Segmentasi RFM bukan teknik baru, tapi tetap relevan karena memberikan ROI yang jelas dengan biaya implementasi minim. Untuk e-commerce Indonesia di 2026, mulai dari sini lebih masuk akal daripada langsung berinvestasi di Composable CDP yang infrastrukturnya berat. Pakai sebagai fondasi, lalu tambah lapisan personalisasi saat volume data dan tim sudah siap.