Bir dashboard'da en can sıkıcı hata türü budur: iki ekran aynı metriği gösteriyor, isimleri aynı, ama sayılar tutmuyor. Toplantıda birisi fark ediyor ve o andan itibaren ekranların hiçbirine güvenilmiyor — doğru olan da dahil.
İlk refleks hesaplamayı kontrol etmek oluyor. Neredeyse her seferinde yanlış yer.
Sorun kapsamın tanımında
Bir metrik üç şeyden oluşuyor ve isim bunların hiçbirini içermiyor:
- Küme: Hangi kayıtlar sayılıyor? Test kayıtları dahil mi? Silinmiş olanlar? Belirli bir alt kırılıma ait olanlar?
- Zaman: Hangi tarih alanına göre filtreleniyor? Kaydın oluşturulma tarihi mi, güncellenme tarihi mi, ilgili olayın gerçekleştiği tarih mi?
- Durum: Hangi aşamalar "başarılı" sayılıyor? Bu liste iki ekranda aynı mı?
İki ekran farklı sayı gösteriyorsa, bu üçünden en az biri farklıdır. Hesaplama formülü genellikle ikisinde de doğrudur; sadece farklı kümeler üzerinde doğrudur.
En sık karşılaşılan üç ayrışma
Farklı tarih alanı. Bir ekran kaydın sisteme düştüğü tarihe, diğeri son güncellenme tarihine bakıyor. Ay sonunda güncellenen mayıs kaydı, birinde mayısta diğerinde haziranda görünüyor.
Farklı durum listesi. "Başarılı" sayılan aşamalar bir ekranda üç, diğerinde iki tane. Bir aşama sonradan eklenmiş, ama sadece bir sorguya.
Sessiz filtre. Bir ekranda kullanıcının önceden seçtiği bir daraltma açık kalmış. Sayı yanlış değil, sadece dar bir kümenin doğru sayısı.
Üçünün de ortak yanı şu: hiçbiri hatalı kod değil. Hepsi eksik anlaşma.
Anlık durum mu, o tarihteki durum mu?
Bu, dönemsel raporlarda en çok yanılgı üreten ayrım ve genellikle hiç konuşulmuyor.
Anlık analiz kayıtların şu andaki durumuna bakıyor: "Mayısta gelen kayıtların bugün kaçı tamamlanmış?"
Seçili dönem analizi kayıtların geçmiş bir tarihteki durumunu yeniden kuruyor: "Mayısta gelen kayıtlar, 15 Mayıs'ta hangi aşamadaydı?"
İkisi de doğru sorular ama aynı soru değiller. Karıştırıldığında ortaya sistematik bir yanlış çıkıyor: geçmiş bir dönemi bugünün aşama dağılımıyla okumak, o dönemde henüz olgunlaşmamış kayıtları başarısız gibi gösteriyor. Yeni gelmiş bir kayıt doğal olarak ilk aşamada; ona bakıp "bu ayın performansı düşük" demek, sürecin kendisini değil geçen süreyi ölçmek oluyor.
Teknik olarak fark, tek bir tabloya bakmakla bir geçmiş tablosuna bakmak arasında:
-- Anlık: kaydın bugünkü aşaması
SELECT stage, COUNT(*) FROM records
WHERE created_at >= '2026-05-01' AND created_at < '2026-06-01'
GROUP BY stage;
-- Seçili dönem: kaydın o tarihteki aşaması
SELECT h.stage, COUNT(*)
FROM records r
JOIN stage_history h ON h.record_id = r.id
WHERE r.created_at >= '2026-05-01' AND r.created_at < '2026-06-01'
AND h.valid_from <= '2026-05-15'
AND (h.valid_to IS NULL OR h.valid_to > '2026-05-15')
GROUP BY h.stage;
İkincisi ancak aşama değişikliklerinin geçmişini tutuyorsan mümkün. Bu yüzden karar mimariye ait: geçmişi tutmuyorsan, dönemsel analiz yapamıyorsun — sadece bugünün fotoğrafını geçmişe uygulayabiliyorsun ki bu da yanlış cevap veriyor.
Ortak filtre bir sözleşmedir
Çok kanallı lead yönlendirme ve analiz üzerine çalıştığım sistemde bu problem tekrar tekrar karşıma çıktı. Çözüm tek bir formülü düzeltmek değildi; filtreyi ekranlar arasında bir sözleşmeye dönüştürmek oldu.
Pratikte şu anlama geliyor: tarih aralığı, kırılım, sorumlu kişi, kaynak gibi seçimler her sekmede aynı anlamı taşıyor ve aynı kümeyi üretiyor. Bir ekran kendi başına ek bir daraltma yapmıyor. Aynı filtreyi kullanan her ekran, aynı kayıt kümesini değerlendiriyor.
Bunun bir sonucu var: filtre artık bir arayüz detayı değil, paylaşılan bir tanım. Yeni bir ekran eklerken de aynı yapıya bağlanması gerekiyor; kendi sorgusunu yazması değil.
Aynı mantık metriğin kendisi için de geçerli. "Başarılı sayılan aşamalar" listesi tek bir yerde tanımlanıyor ve bütün sorgular oradan besleniyor. Yeni bir aşama eklendiğinde tek bir yer değişiyor — sekiz ayrı sorgu değil.
Detay ekranı filtreyi devralmamalı
Küçük ama önemli bir davranış: bir karttaki sayıya tıklayıp detay açtığında, o detayın kapsamı kartın kapsamıyla birebir aynı olmalı. Başka bir sekmede yapılmış daraltıcı bir seçimin sessizce taşınması, kullanıcının gördüğü sayıyla açtığı listenin uyuşmamasına yol açıyor.
Bu yüzden detay açılışında filtreyi bilinçli olarak varsayılana döndürmek, "kullanıcının son seçimini hatırlamak"tan daha doğru bir davranış oluyor. Kullanıcı tıkladığı sayının dökümünü görmek istiyor; başka bir yerde bıraktığı ayarın etkisini değil.
Paydayı da tanımla
Oranlarda ikinci bir tuzak var: payı tanımlayıp paydayı unutmak.
Dönüşüm (%) = (başarılı kayıt / toplam kayıt) × 100
Buradaki "toplam" ne? Gelen tüm kayıtlar mı, yoksa yalnızca ulaşılabilmiş olanlar mı? İkisi de anlamlı metrik üretiyor ama çok farklı sayılar veriyor ve ikisi de "dönüşüm oranı" diye adlandırılabiliyor.
Çözüm ikisini birden göstermek ve adlarını ayırmak: "gelen → başarılı" ve "ulaşılan → başarılı". İki ayrı sütun, iki ayrı isim. Aynı isimle iki farklı payda kullanmak, en baştaki güven sorununu geri getiriyor.
Ayrıca payda sıfırken ne olacağı da tanımlanmalı. Sıfıra bölme hatası vermek yerine oranı sıfır kabul etmek, raporun bozulmadan çalışmasını sağlıyor.
Kontrol listesi
Yeni bir metrik ya da ekran eklerken sorduklarım:
- Bu metriğin kümesi, zaman alanı ve durum listesi nerede tanımlı?
- Aynı tanımı kullanan başka ekranlar var mı, onlar da aynı yerden mi besleniyor?
- Bu anlık bir sayı mı, dönemsel bir sayı mı? Ekranda bu ayrım görünüyor mu?
- Oransa paydası ne ve adı bunu yansıtıyor mu?
- Filtre değişince bu ekran diğerleriyle aynı yönde mi hareket ediyor?
Son madde en pratik testi veriyor: bir filtreyi değiştirdiğinde bütün ekranlar tutarlı biçimde hareket ediyorsa, kapsam ortak demektir. Biri sabit kalıyorsa, kendi sorgusunu yazıyor demektir.
Kapanış
Bir rakamın doğru olması yetmiyor; hangi kapsam üzerinden hesaplandığının anlaşılabilir olması gerekiyor. Sorgulanabilir olmayan bir sayıyı savunmak da mümkün olmuyor.
İki ekran aynı metrik için farklı sayı gösteriyorsa, önce hesaplamaya değil tanıma bak. Sorun büyük ihtimalle orada.
