Satu dokumen yang ngunci definisi, bikin angka konsisten, dan bikin meeting KPI berujung keputusan (bukan debat ulang).

TL;DR

• Debat metrik biasanya karena definisi beda, bukan karena orang “nggak pinter”.

• Sumber data beda (GA4 vs DB vs warehouse) tanpa aturan = angka jadi alat debat.

• Edge case yang nggak ditulis (refund, dedup, timezone) bikin KPI bolong.

• KPI Doc itu kontrak lintas tim, bukan dokumentasi pajangan.

• Tracking harus bisa diaudit: event rapi, ID stabil, timestamp waras, properti wajib jelas.

• QA kecil tapi rutin lebih murah daripada panik pas meeting penting.

• Weekly KPI harus punya output: action + owner + validasi. Kalau tidak, buang KPI-nya atau buang meeting-nya.

Masalah nyata: debat metrik bikin tim lambat

Kalau kamu sering dengar kalimat-kalimat ini:

• “Conversion rate yang bener yang mana?”

• “iOS drop. Ini bug tracking atau user beneran turun?”

• “Dashboard kemarin 2.1%, hari ini 1.7% padahal ga ada release.”

Itu bukan sekadar beda angka. Itu tanda sistem pengukuran kamu belum punya “bahasa bersama”. Akhirnya keputusan jadi lambat karena semua orang nunggu “angka yang pasti”, padahal yang bikin nggak pasti adalah definisi dan tracking-nya sendiri.

Kalau trust ke angka turun, tim bakal balik ke feeling, atau milih angka yang cocok buat argumennya. Data jadi dekorasi.

[Catatan cepat] Kalau KPI berubah tanpa perubahan produk/traffic yang jelas, curigai definisi, mapping event, atau QA. Jangan langsung nyalahin “user behavior”.

Akar masalah (kenapa debat metrik nggak pernah selesai)

1. Semantic drift (definisi ngambang)
   “Active user” bisa berarti login, transaksi, atau sekadar buka app. Semua orang merasa benar karena tidak ada kontrak tertulis.

2. Source of truth kabur
   GA4 bilang A, database bilang B, event server bilang C. Tanpa aturan, diskusi berubah jadi kompetisi keyakinan.

3. Edge case tidak ditulis
   Refund, retry, bot/test, late events, timezone, clock skew. Kalau edge case tidak ditulis, definisi KPI itu “definisi dengan lubang”.

4. Tracking tidak auditable
   Event name beda antar platform, user_id tidak stabil, properti penting sering kosong, timestamp ngaco. Kamu tidak bisa percaya sesuatu yang tidak bisa kamu cek.

5. Tidak ada cadence QA + loop keputusan
   QA cuma jalan saat panik. Angka jadi “kejutan” yang muncul di rapat paling salah.

KPI Doc sebagai “kontrak mingguan”

KPI Doc adalah dokumen yang menjawab tegas:

• KPI ini dipakai buat keputusan apa?

• Dihitung dari mana (source of truth)?

• Formula, filter, dan mapping event-nya apa?

• Edge case ditangani gimana?

• Siapa owner definisinya?

• Kalau berubah, versi + tanggal efektifnya apa?

Intinya: satu KPI, satu owner, satu aturan main. Dokumen ini bukan buat cantik. Buat dipakai tiap minggu.

Framework solusi (6 langkah, versi tim kecil)

1. Pilih KPI inti yang benar-benar dipakai

Mulai dari 5–12 KPI inti. Kalau KPI tidak memicu keputusan mingguan, itu KPI pajangan.

2. Tulis KPI Doc versi 0.1 (ringkas tapi lengkap)

Jangan nunggu sempurna. Versi 0.1 cukup: definisi, formula, source, event mapping, edge case, owner, cadence.

3. Kunci source of truth + aturan rekonsiliasi

Contoh aturan yang sehat:

• Warehouse events = sumber utama KPI produk (activation/retention/conversion).

• GA4 = konteks acquisition/top funnel tertentu.

• Kalau angka beda, KPI Doc harus bilang: “yang dipakai untuk keputusan adalah X, karena Y.”

4. Rapikan event taxonomy minimum

Mulai dari event yang dipakai KPI inti. Minimal wajib:
event_name, user_id, event_time, source, properti wajib.

5. Pasang QA otomatis (harian) + review (mingguan)

Minimal checks: completeness per platform, duplikasi, missing required props, drift distribusi, sanity range/outlier.

6. Versioning + change log (biar historinya jujur)

Boleh ubah definisi, tapi jangan diam-diam. Ada versi, alasan, tanggal efektif, dan catatan dampak.

[Catatan cepat] Tanpa versioning, kamu bukan memperbaiki KPI. Kamu menulis ulang sejarah.

Contoh mini: Activation Rate (contoh ilustrasi)

Definisi

Activation Rate = persentase user yang menyelesaikan onboarding dan melakukan key_action dalam 7 hari setelah signup.

• Unit: user

• Cohort: signup_date

• Filter: exclude test/internal

• Refresh: harian

Formula

Activated Users (cohort D) / Signups (D)

Event mapping (wajib)

• signup: user_id, event_time, source, method

• onboarding_complete: user_id, event_time, flow_version

• key_action: user_id, event_time, action_type, object_id

Edge cases (ditulis, bukan diingat)

1. Clock skew: key_action tercatat sebelum signup
   Aturan: tetap valid hanya jika selisih ≤ 24 jam (toleransi). Selebihnya invalid.

2. Signup missing tapi user_id ada
   Aturan: jangan auto-backfill; masuk kategori tracking_gap.

3. Double fire / retry
   Aturan: dedup pakai kunci (user_id, event_name, event_time, object_id) bila tersedia.

Kesalahan umum (anti-pattern)

1. “Tambah dashboard biar jelas.” → Dashboard tanpa kontrak cuma mempercepat debat.

2. “Semua properties optional.” → Kalau semuanya opsional, datanya tebak-tebakan.

3. “Owner KPI = semua orang.” → Artinya tidak ada yang jaga definisi.

4. “Definisi bebas berubah kapan aja.” → Boleh, tapi wajib versi + tanggal efektif.

5. “GA4 adalah kebenaran tunggal.” → Tool analytics itu sumber, bukan kitab suci.

6. “QA nanti aja kalau ada yang komplain.” → Kamu bakal sadar di meeting paling salah.

Template KPI Doc

kpi_key: "activation_rate"
kpi_name: "Activation Rate"
decision_usage: ["Evaluasi onboarding mingguan"]
owner: "Data"
stakeholders: ["Product", "Growth"]

definition: "User yang onboarding_complete dan key_action dalam 7 hari setelah signup."
unit: "user"
cohort: "signup_date"
window_days: 7

formula:

• numerator: "distinct user_id activated"

• denominator: "distinct user_id signup"

source_of_truth:

• primary: "warehouse.events"

• secondary: "analytics_tool (context only)"

• reconciliation_rule: "Untuk keputusan, pakai primary."

event_mapping:

• signup: required ["user_id","event_time","source","method"]

• onboarding_complete: required ["user_id","event_time","flow_version"]

• key_action: required ["user_id","event_time","action_type","object_id"]

filters: ["exclude_test","exclude_internal","timezone_consistent"]

edge_cases:

• "clock_skew<=24h: ok; else invalid"

• "signup_missing: tracking_gap, no auto-backfill"

• "dedup_key: (user_id,event_name,event_time,object_id)"

qa:

• daily: ["completeness_by_platform","duplicate_spike","missing_required_props"]

• weekly: ["distribution_drift","late_event_rate"]

version: 1
effective_date: "YYYY-MM-DD"
change_log: ["v1: initial definition"]

Mini Event Taxonomy (format)

• event_name

• purpose

• fired_when

• required_props

• id_keys (user_id, session_id, object_id, order_id)

• source (web/ios/android/server)

• common_failures

• owner

Checklist QA Tracking (10)

1. Completeness per platform stabil (web/iOS/Android/server).

2. user_id jarang null dan pola konsisten.

3. Timestamp tidak banyak yang “dari masa depan” (timezone beres).

4. Missing rate required props dipantau.

5. Duplikasi event tidak melonjak mendadak.

6. Distribusi source/device/country tidak drift ekstrem tanpa sebab.

7. Late events dipantau (event datang telat > N jam).

8. Test/internal account terfilter konsisten (rule tertulis).

9. Event naming konsisten (tidak ada variasi casing/underscore liar).

10. KPI punya sanity range dan alarm outlier.

Checklist eksekusi mingguan

Sebelum meeting (10 menit):

• QA harian aman atau ada catatan merah yang jelas.

• Ambil delta KPI inti (minggu ini vs lalu).

• Siapkan pertanyaan “kenapa berubah?”, bukan “angkanya berapa?”.

Saat meeting (20–30 menit):

• Delta → pilih 2 driver utama.

• Putuskan 1 action (owner + deadline).

• Tentukan 1 validasi minggu ini (QA check atau eksperimen).

Sesudah meeting (5 menit):

• Tulis keputusan (biar bisa dibaca semua).

• Kalau definisi berubah, update KPI Doc (naik versi + alasan + tanggal efektif).

[Catatan cepat] Output meeting itu keputusan tertulis. Kalau tidak ada, meeting kamu cuma ngobrol.

Snippet SQL (cek completeness per platform)

select
  date_trunc('day', event_time) as day,
  source,
  count(*) as cnt
from events
where event_name = 'key_action'
  and event_time >= now() - interval '14 days'
group by 1,2
order by 1 desc, 2;

Snippet Python (alarm drift sederhana)

from collections import Counter
import math

def kl(p, q, eps=1e-9):
    keys = set(p) | set(q)
    tp, tq = sum(p.values()) + eps, sum(q.values()) + eps
    return sum(((p.get(k,0)+eps)/tp) * math.log(((p.get(k,0)+eps)/tp)/((q.get(k,0)+eps)/tq)) for k in keys)

yesterday = Counter({"ios": 1200, "android": 800, "web": 400})
baseline7 = Counter({"ios": 6500, "android": 5200, "web": 3100})

score = kl(yesterday, baseline7)
if score > 0.08:
    print("ALERT drift:", round(score, 4))
else:
    print("OK drift:", round(score, 4))

Kalau kamu suka tulisan yang fokus ke KPI, tracking, dan keputusan mingguan (bukan teori), follow aja buat catatan praktis berikutnya. Kalau tim kamu sering debat angka dan butuh audit cepat (definisi, event mapping, QA cadence), kamu bisa booking call singkat. Kita cek biang keroknya dulu, rapihin yang paling mahal, baru naik level.