Biar angka kamu bisa dipercaya sebelum jadi bahan meeting.

Kebanyakan “masalah data” itu bukan masalah data. Itu masalah tracking yang nggak ada yang notice sampai dashboard tiba-tiba teriak. Habis itu seminggu lenyap buat rapat, debat, dan “hot take” yang ujungnya tetap: kita nggak yakin angkanya bener.

Tracking QA itu cara berhenti dari siklus itu. Nggak glamor. Tapi ini alasan kenapa angka kamu layak dipakai buat keputusan.

Tujuan (dibikin simpel)
Tracking QA bukan “data sempurna”. Targetnya “reliability yang diketahui”.
Kamu pengen tahu:

• event mana yang bisa dipercaya,

• mana yang rusak,

• dan apa yang berubah.

Itu aja sudah cukup buat mencegah insight palsu dan kerja sia-sia.

Minimum QA stack (tanpa tools fancy)
Kamu cuma butuh:

1. Daftar pendek “critical events” (yang jadi fondasi KPI kamu).

2. Query/checklist yang bisa diulang tiap minggu / tiap release.

3. Kebiasaan: QA dulu, baru analisis. Bukan sebaliknya.

Kalau punya warehouse bagus. Kalau belum, export juga bisa. Yang penting konsisten.

Daftar critical events (contoh)

• signup_completed

• onboarding_step / onboarding_complete

• key_action (activation)

• purchase / subscription_start

• refund / chargeback (kalau revenue KPI)

Checklist QA (jalanin urut ini)

1. Volume sanity check (per hari)
   Kamu bukan lagi cari “trend”. Kamu cari “break”.

• drop mendadak ke nyaris nol: kemungkinan tracking mati

• spike mendadak: kemungkinan double fire, retry, bot/internal

• flatline di satu platform: event berhenti firing di situ

Kalau volume terlihat aneh, stop. Jangan “jelasin”. Verifikasi dulu.

SQL: volume harian critical events

select
  date_trunc('day', event_time)::date as day,
  event_name,
  coalesce(source, 'unknown') as source,
  count(*) as events
from events
where event_name in ('signup_completed','onboarding_complete','key_action','purchase')
  and event_time >= now() - interval '14 days'
group by 1,2,3
order by 1 desc, 2, 3;

2. Duplicate check (silent killer)
   Duplicate bikin funnel dan rate “kelihatan wajar”, padahal bohong. Itu yang bikin berbahaya.
   Sinyal paling gampang: event_count naik, distinct_user tetap.

SQL: event_count vs distinct_user (deteksi double fire)

select
  date_trunc('day', event_time)::date as day,
  event_name,
  count(*) as event_count,
  count(distinct user_id) as distinct_users,
  (count(*)::numeric / nullif(count(distinct user_id), 0)) as events_per_user
from events
where event_name in ('signup_completed','key_action','purchase')
  and event_time >= now() - interval '14 days'
  and user_id is not null
group by 1,2
order by 1 desc, 2;

SQL: duplicate groups (dedup key contoh: user_id + event_name + event_time + object_id)

select
  date_trunc('day', event_time)::date as day,
  event_name,
  count(*) as duplicate_groups
from (
  select
    event_name,
    user_id,
    event_time,
    coalesce(object_id,'-') as object_id,
    count(*) as c
  from events
  where event_time >= now() - interval '7 days'
    and user_id is not null
  group by 1,2,3,4
  having count(*) > 1
) d
group by 1,2
order by 1 desc, 2;

3. Missing properties check
   Critical events butuh critical properties. Begitu props penting banyak null, analisis kamu berubah jadi tebak-tebakan.
   Minimal cek:

• user_id (atau stable identifier)

• source/platform

• app_version (kalau mobile)

• event_time (harus valid)

• key dimensions yang kamu pakai (country, plan, method) hanya kalau KPI kamu bergantung pada itu

SQL: missing required fields rate (contoh key_action)

select
  date_trunc('day', event_time)::date as day,
  coalesce(source,'unknown') as source,
  count(*) as total,
  sum(case when user_id is null then 1 else 0 end) as missing_user_id,
  sum(case when object_id is null then 1 else 0 end) as missing_object_id,
  sum(case when action_type is null then 1 else 0 end) as missing_action_type
from events
where event_name = 'key_action'
  and event_time >= now() - interval '14 days'
group by 1,2
order by 1 desc, 2;

Kalau tiba-tiba 30% event kehilangan user_id, funnel/cohort kamu bukan “sulit”. Selesai. Jangan dipaksain.

4. Funnel order check
   Funnel ngasumsikan urutan. Tracking sering nggak sopan.
   Gejala:

• step 3 muncul sebelum step 2

• “complete” ada tanpa “start”

• event datang telat dan ngacak cerita

SQL: cek urutan event per user (contoh funnel: signup -> onboarding_complete -> key_action)

with e as (
  select
    user_id,
    event_name,
    min(event_time) as t
  from events
  where event_name in ('signup_completed','onboarding_complete','key_action')
    and event_time >= now() - interval '14 days'
    and user_id is not null
  group by 1,2
),
p as (
  select
    user_id,
    max(case when event_name='signup_completed' then t end) as t_signup,
    max(case when event_name='onboarding_complete' then t end) as t_onboarding,
    max(case when event_name='key_action' then t end) as t_key
  from e
  group by 1
)
select
  count(*) filter (where t_onboarding < t_signup) as onboarding_before_signup,
  count(*) filter (where t_key < t_onboarding) as key_before_onboarding,
  count(*) filter (where t_key is not null and t_signup is null) as key_without_signup
from p;

5. Platform coverage check (web vs iOS vs Android)
   Tracking jarang rusak “semua”. Biasanya rusak di satu tempat.
   Split minimal:

• source/platform (web/iOS/Android/server)

• browser group (Safari vs Chrome) kalau web

• app_version (latest vs previous) kalau mobile

SQL: coverage per platform/source

select
  date_trunc('day', event_time)::date as day,
  coalesce(source,'unknown') as source,
  event_name,
  count(*) as cnt
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;

6. Identity stitching check (anonymous -> logged-in)
   Kalau produk kamu ada login, identity itu sumber mismatch paling sering.
   Failure mode umum:

• anonymous session nggak nyambung ke user_id setelah login

• user_id berubah across device

• client vs server pakai ID beda

QA paling efektif: ambil sample kecil, trace end-to-end.

SQL: trace 50 user (cek event penting ada dan konsisten)

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,
  s.created_at,
  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
from sample s
left join events e
  on e.user_id = s.user_id
 and e.event_time between s.created_at - interval '1 day' and s.created_at + interval '7 days'
group by 1,2
order by s.created_at desc;

7. Release/change log check (jawab “kenapa sekarang?”)
   Saat ada anomaly, pertanyaan pertama bukan “apa arti chart ini?”, tapi “apa yang berubah?”
   Nggak butuh sistem ribet. Catatan tanggal juga cukup: release, tracking change, experiment toggle, analytics config.

Template catatan (copy-paste):

• YYYY-MM-DD: Release vX.Y (onboarding flow update)

• YYYY-MM-DD: Tracking change (rename event, add prop, dedup key)

• YYYY-MM-DD: Experiment on/off (variant affects funnel step)

Kalau QA fail, lakukan ini (bukan coping analysis)

1. Label data: “unreliable after DATE/TIME”

2. Tentukan dampak terbesar: KPI mana kena? platform mana?

3. Patch fix paling kecil yang balikin trust (stop double fire, fix missing trigger, enforce required props)

4. Re-run QA

5. Baru analisis

Kalimat “kita belum bisa percaya data setelah tanggal ini” lebih profesional daripada kesimpulan confident tapi salah.

Apa itu “good” (realistis, bukan cosplay perfection)

• critical events stabil dari minggu ke minggu

• kalau ada perubahan, kamu bisa jelasin cepat (bukan nebak)

• funnel nggak rusak diam-diam

• weekly review mulai dari keputusan, bukan dispute

Rutinitas mingguan kecil (15–30 menit)
Setiap minggu:

• volume check

• duplicates check

• missing props check

• platform split

• catat perubahan (release/tracking)

Setiap release:

• re-check funnel end-to-end pakai sample session nyata

Kalau data jadi dasar keputusan, QA itu bukan opsional. Itu biaya buat jadi serius.

Kalau kamu suka checklist yang bikin data “waras” sebelum dipakai, follow aja. Kalau tim kamu butuh template QA + query yang disesuaikan sama event schema kamu, booking call singkat juga bisa.