Apr 30, 2025

Funnel Drop-Off yang Ternyata Cuma Bug Tracking

Funnels

Tracking

Conversion

Drop-off kelihatan kayak produk gagal. Seringnya cuma measurement yang rusak pakai muka serius.

Drop-off funnel itu serem karena kelihatan seperti produk lagi “jatuh”. Tapi kenyataan pahitnya: banyak drop-off bukan masalah produk. Itu masalah tracking yang nyamar jadi perilaku user.

Kalau kamu nganggep measurement yang rusak sebagai “behavior nyata”, kamu bakal:

  • kirim fix yang salah,

  • ngerayain kemenangan palsu,

  • buang minggu cuma buat debat angka.

Ini cara debug funnel kayak operator, bukan turis dashboard.

Quick test: “Gue berani taruhan uang nggak sama angka ini?”
Kalau kamu nggak berani taruhan uang, jangan ambil keputusan. Verifikasi dulu.

Funnel itu rapuh karena dia ngasumsikan:

  • step ke-track konsisten,

  • event cuma fire sekali per aksi,

  • urutan event masuk akal,

  • identity stabil dari step awal sampai akhir.

Rusak satu aja, funnel mulai bohong.

5 kebohongan funnel paling sering (dan kenapa bisa kejadian)
  1. Step yang hilang
    Satu step nggak ke-track di platform tertentu (iOS/Android), browser tertentu (Safari), atau variant halaman tertentu.
    Gejala: “tebing” tajam di satu step, tapi cuma untuk segmen tertentu.
    Fix: cek coverage by platform/route, jangan cuma total.

  2. Step yang double-fire
    Event nge-fire dua kali karena refresh, retry, atau ada dua listener.
    Gejala: count step jadi menggembung, conversion rate terlihat “masih masuk akal” padahal ngaco.
    Fix: debounce, idempotency key, dan kadang hitung distinct user.

  3. Event rename (drift diam-diam)
    Orang ganti event name/property, funnel logic nggak ikut update.
    Gejala: funnel rusak “random” setelah release.
    Fix: naming rules + event registry (table simpel pun cukup).

  4. Step out-of-order
    Client dan server events masuk urutannya beda dari journey user yang bener.
    Gejala: “completed” ada tanpa “started”, atau step 3 muncul sebelum step 2.
    Fix: tentukan event yang authoritative per step (client vs server) dan validasi ordering.

  5. Identity putus
    Anonymous events nggak nyambung ke logged-in events, atau user_id berubah di tengah flow.
    Gejala: drop gede antara “started” dan “completed”, terutama sekitar login/signup.
    Fix: aturan stitching identity yang jelas, lalu verifikasi pakai real sessions.

Cara debug funnel tanpa buang seminggu

Step 1: Pilih satu funnel, satu segmen
Jangan debug “seluruh funnel produk”. Pilih yang paling penting.
Contoh: “Signup → Activation (web only), last 7 days”.
Step 2: Tulis definisi step (wajib)
Setiap step harus bisa dijelasin dalam 1 kalimat:
  • event name

  • properti wajib

  • dihitung per user atau per event

  • sumbernya client atau server

Kalau kamu nggak bisa mendefinisikan step, funnel kamu sudah broken dari awal.

Contoh “step spec” (yang harus kamu punya)

funnel: signup_to_activation
segment: web_only_last_7_days

steps:
  - step: signup_completed
    event_name: signup_completed
    source: server   # client|server
    counted_as: user # user|event
    required_props: [user_id, event_time, source]
    notes: "signup dianggap valid kalau record user sudah tersimpan"

  - step: onboarding_complete
    event_name: onboarding_complete
    source: client
    counted_as: user
    required_props: [user_id, event_time, app_version]

  - step: key_action
    event_name: key_action
    source: server
    counted_as: user
    required_props: [user_id, event_time, action_type, object_id]
Step 3: Validasi pakai journey nyata (sample kecil, nilai tinggi)
Ambil 20–50 journey real dan trace end-to-end:
  • event fire nggak?

  • props wajib ada nggak?

  • fire sekali atau dobel?

  • identity konsisten nggak?

SQL: ambil sample journey dan cek step timestamps

with sample as (
  select user_id, min(created_at) as created_at
  from users
  where created_at >= now() - interval '2 days'
    and coalesce(is_internal,false) = false
    and coalesce(is_test,false) = false
  group by 1
  order by created_at desc
  limit 50
)
select
  s.user_id,
  min(e.event_time) filter (where e.event_name='signup_completed') as t_signup,
  min(e.event_time) filter (where e.event_name='onboarding_complete') as t_onboarding,
  min(e.event_time) filter (where e.event_name='key_action') as t_key,
  count(*) filter (where e.event_name='signup_completed') as c_signup,
  count(*) filter (where e.event_name='onboarding_complete') as c_onboarding,
  count(*) filter (where e.event_name='key_action') as c_key
from sample s
left join events e
  on e.user_id = s.user_id
 and e.event_name in ('signup_completed','onboarding_complete','key_action')
 and e.event_time between s.created_at - interval '1 day' and s.created_at + interval '7 days'
group by 1
order by 1;

Kalau c_* sering > 1, kamu punya double-fire/retry.
Kalau step hilang untuk banyak user, itu missing tracking atau identity putus.

Step 4: Slice drop-off (cari “bentuk” mismatch)
Jangan mantengin satu angka total. Pecah:
  • platform (web/iOS/Android)

  • browser group (Safari vs Chrome)

  • app version

  • route/variant halaman

  • new vs returning

Bug tracking biasanya bentuknya tajam dan aneh: satu platform, satu version, satu route.

SQL: coverage per platform/source untuk step tertentu

select
  date_trunc('day', event_time)::date as day,
  coalesce(source,'unknown') as source,
  event_name,
  count(*) as cnt,
  count(distinct user_id) as users
from events
where event_name in ('signup_completed','onboarding_complete','key_action')
  and event_time >= now() - interval '14 days'
group by 1,2,3
order by 1 desc, 2, 3;
Step 5: Fix measurement dulu, baru re-run funnel
Setelah fix:
  • re-run funnel

  • tempelin QA note: apa yang berubah, kapan, dan gimana verifikasinya

Kalau kamu nggak bisa jelasin kenapa funnel berubah, jangan dulu ngerayain.

Output yang harus kamu “ship” (bukan dashboard)
Yang beneran berguna itu:

  • step spec singkat (definisi + edge cases)

  • event coverage checklist (platform/route/version)

  • QA checklist funnel

  • snapshot before/after + timestamp

Dashboard optional. Trust wajib.

Aturan anti “kemenangan palsu”
Kalau funnel “membaik” tepat setelah tracking change, anggap itu measurement sampai terbukti bukan.
Product win yang beneran tahan QA. Tracking win hilang begitu ada satu pertanyaan lanjutan.

Funnels nggak butuh lebih banyak chart. Funnels butuh lebih sedikit kebohongan.


Kalau kamu suka tulisan yang ngajarin cara membunuh bug tracking sebelum dia membunuh minggu kamu, follow aja. Kalau kamu mau, gue juga bisa bikin step spec + QA queries yang pas sama schema event kamu (tanpa bikin proses ribet).

Create a free website with Framer, the website builder loved by startups, designers and agencies.