Funnel yang Bocor: dari Query SQL ke Hipotesis yang Bisa Diuji

Angka konversi turun 18% dalam sebulan, dan nggak ada yang tau bocornya di mana.

Ini cerita nyari kebocoran itu di data toko online perlengkapan rumah tangga, dari query pertama sampai hipotesis yang akhirnya dieksekusi.

Semua query di sini pakai PostgreSQL dan bisa kamu tiru dengan ganti nama tabelnya.

Kenapa grafik corong sering nggak ngasih jawaban?

Karena grafik corong cuma nunjukin di mana orang berhenti, bukan kenapa. Tahap dengan tingkat lolos paling rendah belum tentu tahap yang paling rugi, dan belum tentu bisa diperbaiki. Analisis funnel yang berguna berhenti di hipotesis yang bisa diuji minggu itu juga, bukan di gambar corong yang dipajang di dashboard.

Kunci lompatan dari angka ke hipotesis ada di satu gerakan: pecah tiap tahap per segmen, lalu cari selisih paling lebar antar segmen.

Gimana nentuin tahap funnel yang bener?

Tiap tahap harus berupa peristiwa yang jelas kejadiannya, bukan niat. "Tertarik sama produk" itu bukan tahap. "Klik tombol tambah ke keranjang" itu tahap.

Funnel di kasus ini empat tahap:

Tahap	Nama peristiwa	Artinya
1	lihat_produk	Buka halaman detail satu produk
2	tambah_keranjang	Klik tombol tambah ke keranjang
3	mulai_checkout	Masuk halaman pembayaran
4	bayar_sukses	Pembayaran terkonfirmasi

Empat sampai lima tahap itu jumlah yang enak. Kalau funnel kamu punya sembilan tahap, gabungin dulu jadi kelompok besar, baru pecah lagi setelah ketauan kelompok mana yang bermasalah.

Satu keputusan lagi sebelum nulis query: dihitung per sesi atau per pengguna. Toko ini barangnya murah dan dibeli dalam satu kunjungan, jadi per sesi masuk akal.

Gimana query funnel-nya dalam satu jalan?

Trik utamanya ngeringkas tabel peristiwa jadi satu baris per sesi dulu, dengan kolom berisi waktu paling awal tiap peristiwa. Setelah itu, urutan antar tahap gampang dicek dengan bandingin waktunya.

WITH tahap AS (
  SELECT
    session_id,
    MIN(waktu) FILTER (WHERE event = 'lihat_produk')     AS t_lihat,
    MIN(waktu) FILTER (WHERE event = 'tambah_keranjang') AS t_keranjang,
    MIN(waktu) FILTER (WHERE event = 'mulai_checkout')   AS t_checkout,
    MIN(waktu) FILTER (WHERE event = 'bayar_sukses')     AS t_bayar
  FROM peristiwa
  WHERE waktu >= DATE '2025-09-01'
    AND waktu <  DATE '2025-10-01'
  GROUP BY session_id
)
SELECT
  COUNT(*) FILTER (WHERE t_lihat IS NOT NULL)      AS lihat_produk,
  COUNT(*) FILTER (WHERE t_keranjang > t_lihat)    AS tambah_keranjang,
  COUNT(*) FILTER (WHERE t_checkout > t_keranjang) AS mulai_checkout,
  COUNT(*) FILTER (WHERE t_bayar > t_checkout)     AS bayar_sukses
FROM tahap;

Klausa FILTER di situ yang bikin querynya ringkas. Dia nyaring baris mana yang masuk ke tiap agregat, tanpa perlu nulis CASE WHEN berulang. Sintaks resminya ada di dokumentasi ekspresi agregat PostgreSQL.

Perhatiin tanda lebih besar di tiap baris. Itu yang mastiin tahap berikutnya beneran terjadi setelah tahap sebelumnya. Tanpa itu, orang yang buka halaman checkout dari tautan tersimpan bakal kehitung sebagai lolos, dan angka tahap tengah bisa jadi lebih besar dari tahap sebelumnya.

Angka pertama dari data toko

Hasil satu bulan, 41.230 sesi yang lihat produk:

Tahap	Jumlah sesi	Lolos dari tahap sebelumnya
lihat_produk	41.230	-
tambah_keranjang	9.482	23,0%
mulai_checkout	5.317	56,1%
bayar_sukses	2.108	39,6%

Tahap dengan tingkat lolos paling rendah jelas yang pertama, cuma 23%. Tapi angka itu wajar buat toko online. Orang lihat-lihat dulu itu perilaku normal.

Yang bikin curiga tahap terakhir. Orang yang udah masuk halaman pembayaran itu orang yang niat beli. Kehilangan 60,4% dari mereka itu mahal.

Gimana nemuin di mana bocornya?

Pecah tahap yang mencurigakan per segmen, satu segmen dalam satu waktu. Mulai dari tiga yang paling murah dicek: perangkat, kanal masuk, dan hari.

SELECT
  perangkat,
  COUNT(*) FILTER (WHERE t_checkout > t_keranjang) AS checkout,
  COUNT(*) FILTER (WHERE t_bayar > t_checkout)     AS bayar,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE t_bayar > t_checkout)
          / NULLIF(COUNT(*) FILTER (WHERE t_checkout > t_keranjang), 0)
  , 1) AS persen_lolos
FROM tahap
GROUP BY perangkat
ORDER BY checkout DESC;

NULLIF di penyebut itu penting. Tanpa dia, segmen yang jumlah checkout-nya nol bakal bikin querynya gagal karena pembagian dengan nol.

Hasilnya:

Perangkat	Mulai checkout	Bayar sukses	Lolos
Android	3.104	842	27,1%
iOS	1.436	771	53,7%
Desktop	777	495	63,7%

Selisih 26,6 poin persen antara Android dan iOS di tahap yang sama persis. Itu bukan perbedaan selera, itu tanda ada yang rusak.

Pecahan berikutnya per hari nunjukin angka Android jatuh dari sekitar 52% ke 26% mulai tanggal 9 September, lalu bertahan di situ. Penurunan mendadak dengan tanggal jelas hampir selalu berarti ada yang berubah di sistem, bukan perubahan perilaku orang.

Dari angka ke hipotesis yang bisa diuji

Hipotesis yang berguna nyebut tiga hal: siapa, di mana, dan kenapa. Dari data di atas, tiga kandidat muncul.

1. Ada yang rusak di halaman pembayaran versi Android sejak 9 September. Diuji dengan buka halamannya di perangkat Android, dan cek catatan rilis aplikasi di tanggal itu.
2. Metode pembayaran yang populer di pengguna Android lagi bermasalah. Diuji dengan pecah lagi angkanya per metode bayar.
3. Ada kampanye iklan baru yang narik banyak pengunjung Android berkualitas rendah mulai tanggal itu. Diuji dengan pecah per kanal masuk, dan cek apakah jumlah checkout-nya ikut melonjak.

Urutan pengujiannya dari yang paling murah. Buka halaman pembayaran di HP Android itu lima menit. Ngerancang A/B testing itu dua minggu. Jangan mulai dari yang mahal.

Di kasus ini, jawabannya ada di hipotesis kedua. Satu penyedia dompet digital yang dipakai 44% pengguna Android ngubah alur konfirmasinya, dan tombol kembali ke toko nggak muncul di sebagian perangkat. Orangnya udah bayar, tapi statusnya nggak pernah balik ke sistem toko sebagai sukses.

Perkiraan nilai transaksi yang nyangkut selama 22 hari: Rp 187 juta.

Kesalahan umum waktu bikin analisis funnel

Ngitung peristiwa tanpa ngecek urutannya. Ini yang bikin tahap tengah kelihatan lebih besar dari tahap sebelumnya. Selalu bandingin waktu antar tahap.

Nyampur sesi dan pengguna dalam satu funnel. Tahap awal dihitung per sesi, tahap akhir per pengguna. Angkanya jadi nggak bisa dibandingin. Pilih satu, sebutin di judul tabelnya.

Jendela waktu yang ngegantung. Kalau kamu ambil data sampai kemarin, sesi yang mulai kemarin sore mungkin belum sempat bayar. Potong jendelanya di titik yang aman, atau kasih tenggat konversi yang jelas.

Berhenti di angka total. Angka total hampir nggak pernah nunjukin penyebab. Pecah per segmen, minimal per perangkat dan per kanal, sebelum bikin kesimpulan apa pun.

Bandingin ke tolok ukur industri. Definisi tahap tiap perusahaan beda. Pembanding paling berguna itu dirimu sendiri bulan lalu, dan segmen lain di data yang sama.

Ngabaikan waktu antar tahap. Selain jumlah orang, lihat juga berapa lama jeda dari checkout ke bayar. Jeda yang tiba-tiba memanjang sering jadi tanda pertama ada yang rusak, dan biasanya kelihatan sebelum angka konversinya turun.

Urutan kerja yang bisa kamu tiru

1. Tulis definisi tiap tahap sebagai nama peristiwa yang jelas. Sepakati sama tim produk.
2. Pilih satuan hitungnya, sesi atau pengguna.
3. Ringkas tabel peristiwa jadi satu baris per satuan hitung.
4. Hitung tingkat lolos antar tahap yang berurutan, bukan terhadap tahap pertama.
5. Pecah tahap yang paling mencurigakan per perangkat, kanal, dan hari.
6. Cari selisih antar segmen yang paling lebar, bukan angka yang paling rendah.
7. Tulis tiga hipotesis, urutkan dari yang paling murah diuji.

Langkah kelima yang paling sering dilewat. Padahal di situ jawabannya biasanya ketemu. Bentuk pemecahan lain yang berguna adalah cohort analysis, terutama kalau kamu curiga yang berubah itu kualitas pengunjung baru, bukan halamannya.

FAQ

Analisis funnel itu apa dan kapan dipakai?

Analisis funnel ngukur berapa banyak orang yang lolos dari satu tahap ke tahap berikutnya dalam sebuah proses, misalnya dari lihat produk sampai bayar. Dipakai waktu kamu tau hasil akhirnya turun tapi belum tau turunnya di bagian mana. Hasil analisis ini nunjukin tahap mana yang paling banyak kehilangan orang, jadi perbaikanmu nggak nebak-nebak.

Kenapa jumlah orang di tahap tengah funnel-ku lebih besar dari tahap sebelumnya?

Biasanya karena kamu ngitung peristiwa tanpa mastiin urutannya. Orang bisa langsung buka halaman checkout dari tautan yang disimpan tanpa lewat halaman produk. Kalau query kamu cuma ngitung siapa yang pernah checkout, mereka ikut kehitung. Solusinya, tambahin syarat bahwa peristiwa tahap berikutnya harus terjadi setelah peristiwa tahap sebelumnya di sesi yang sama.

Lebih baik hitung funnel per sesi atau per pengguna?

Tergantung pertanyaannya. Per sesi cocok buat ngukur mulus atau nggaknya satu kali kunjungan, misalnya nyari halaman yang error. Per pengguna cocok buat produk yang orangnya balik beberapa kali sebelum beli, misalnya barang mahal. Kalau kamu pakai per sesi di produk yang siklus belinya panjang, angka konversimu bakal kelihatan jauh lebih buruk dari kenyataan.

Berapa tingkat konversi funnel yang normal?

Nggak ada angka normal yang berlaku umum, dan ngebandingin diri ke angka industri sering nyesatin karena definisi tahapnya beda-beda. Pembanding yang paling berguna adalah dirimu sendiri di periode sebelumnya, dan segmen lain di dalam datamu. Kalau konversi pengguna Android 2,4% sementara iOS 4,1% dengan definisi yang sama persis, selisih itu jauh lebih bisa ditindaklanjuti.

Setelah nemu tahap yang bocor, apa langkah berikutnya?

Tulis hipotesis yang nyebut siapa, di mana, dan kenapa, lalu tentuin cara ngujinya. Contohnya, pengguna Android gagal di halaman pembayaran karena tombolnya ketutup papan ketik. Uji paling cepat biasanya bukan eksperimen, tapi ngecek langsung: buka halamannya di perangkat yang sama, atau lihat pesan error di log. Baru kalau perbaikannya mahal, jalanin A/B testing.

Penutup

Tiga hal yang paling nentuin hasil analisis funnel.

Definisi tahap yang berupa peristiwa, bukan niat. Ini yang bikin angkamu bisa dipertanggungjawabkan.

Pemecahan per segmen. Angka total nyaris nggak pernah nunjukin penyebab, dan selisih antar segmen yang lebar hampir selalu berarti ada yang rusak.

Hipotesis yang diurutkan dari yang paling murah diuji. Buka halaman di HP itu lima menit, dan sering cukup.

Mau nerusin ke pertanyaan kanal mana yang nyumbang paling besar? Baca attribution multi-touch di SQL. Buat nyusun tampilan hasilnya, ada cheat sheet memilih grafik.

Ambil funnel kamu minggu ini, pecah tahap terakhirnya per perangkat. Lihat selisihnya berapa poin.