A/B test itu gak “bohong” karena statistiknya jahat. Biasanya bohong karena kita yang bikin dia gampang bohong: definisi metrik ngambang, tracking bocor, randomization gak beres, atau kita ngintip hasil tiap jam terus panik sendiri.

Gue pakai aturan sederhana biar eksperimen tetap waras. Gak sempurna, tapi cukup bikin hasilnya bisa dipakai tanpa drama.

1) Mulai dari pertanyaan yang bisa dijawab

Bukan “fitur ini bagus gak?”, tapi:

• Perubahan apa yang kita harap terjadi?

• Di metrik apa?

• Dalam window berapa hari?

• Risk apa yang gak boleh lewat? (guardrail)

Kalau pertanyaannya kabur, hasilnya bakal kabur juga.

2) Kunci metrik utama + guardrail sebelum mulai

Sebelum tombol “launch” ditekan, tulis:

• primary metric (satu aja, jangan serakah)

• 1–3 guardrail (mis. refund, crash rate, latency, churn proxy)

• definisi event + filter + timezone + dedup

Ini bukan formalitas. Ini biar kamu gak ganti aturan main pas hasilnya gak sesuai harapan.

3) Pastikan randomization beneran random

Minimal cek:

• split mendekati target (mis. 50/50)

• balance sederhana (country/device/plan gak timpang parah)

• tidak ada user pindah grup (bucketing stabil)

Kalau dari awal grupnya udah “beda orang”, nanti kamu debat selamanya soal apakah itu efek fitur atau efek komposisi.

4) Jagain tracking: A/A kecil itu murah banget

Kalau bisa, jalankan A/A test singkat: dua grup sama-sama versi yang sama.
Harusnya “hasilnya nol-nol aja” (dalam batas wajar). Kalau A/A udah aneh, A/B kamu tinggal menunggu masalah.

5) Jangan bikin eksperimen jadi lomba “cek hasil tiap jam”

Ngintip itu wajar. Tapi kalo tiap jam kamu cek p-value lalu stop pas “udah signifikan”, itu cara cepat bikin hasil palsu kelihatan valid.

Yang gue lakuin:

• tentuin minimal runtime dulu (mis. 7 hari atau 2 siklus mingguan)

• pakai stopping rule yang disepakati (atau minimal “jangan stop karena hasilnya cantik”)

• lihat tren + stabilitas, bukan cuma satu angka

6) Segmentasi itu alat bantu, bukan mesin pembenaran

Segmentasi penting, tapi jangan dipakai buat nyari “menang” setelah overall kalah.
Kalau mau segmentasi serius, tentuin dulu segmen prioritas (mis. new users vs returning), baru interpretasi.

7) Hasil bagus pun tetap butuh sanity check

Sebelum declare win:

• cek apakah perubahan masuk akal (effect size gak absurd)

• cek apakah guardrail aman

• cek apakah event yang ngukur primary metric gak berubah definisi/coverage-nya

Kadang yang “naik” itu cuma tracking jadi lebih rajin nge-fire event.

Bonus: checklist 5 menit sebelum declare hasil

• Primary metric & guardrail sesuai definisi awal

• Randomization & balance oke

• Tracking health oke (missingness/freshness)

• Runtime cukup (cover weekday/weekend)

• Keputusan jelas: ship / iterate / stop

A/B test yang “gak bohong” itu bukan yang selalu kasih jawaban enak. Tapi yang bikin kamu yakin: kalo kamu ship, itu karena efeknya beneran ada, bukan karena kamu keburu seneng lihat angka hijau.