Dijital Ürün Ölçüm Planı: Olay Sözlüğü Nasıl Hazırlanır?

Grafikten önce karar sorusunu yazın

“Daha çok kullanıcı var mı?” sorusunu daraltın. Yeni hesaplar ilk teklifini oluşturabiliyor mu? Mevcut müşteriler raporu dışarı yardım almadan bulabiliyor mu? Yönetici haftalık özeti kullanarak hangi kararı verecek? Ölçüm planı, bu sorulardan başlayıp gerekli olaylara inmeli; eldeki araçta hazır bulunan metriklerden başlamamalıdır.

GOV.UK ölçüm rehberleri, hizmetin amacı ve beklenen faydasıyla ölçütler arasında bağ kurmayı; davranış verisini kullanıcı araştırmasıyla birlikte değerlendirmeyi önerir. [1] İşlem tamamlama ile uçtan uca deneyimin farklı şekillerde ölçülebileceği de açıklanır. [2]

Niyet ve gerçekleşen sonuç için ayrı olaylar kullanın

“Kaydet düğmesine basıldı” ile “kayıt başarıyla oluşturuldu” aynı olay değildir. İlkinde kullanıcı niyeti, ikincisinde sistem sonucu vardır. Bir hata halinde yalnızca ilk olay oluşuyorsa başarısızlık görülebilir. İkisi aynı isimle gönderilirse başarı oranı hesaplamak güçleşir.

Örnek bir teklif uygulamasında taslak oluşturma, teklif gönderme ve alıcının incelemesi ayrı aşamalardır. Gönderme işlemi kuyrukta bekliyorsa “gönderildi” yerine “gönderim istendi” anlamını kullanın. E-posta sağlayıcısına teslim ile müşterinin okumasını birbirine karıştırmayın. Her durumun teknik kaynağı belirli olsun.

Olay sözlüğünün asgari alanları

Her olay için isim, açıklama, tetiklenme koşulu, tekillik kimliği, kaynak, sürüm ve sorumlu yazın. Olayı gönderirken müşteri mesajı veya belge içeriği gibi gereksiz verileri eklemeyin. “Hata oluştu” yerine sınıflandırılmış hata türü ölçülebilir; kişisel bilgiye gerek olmayabilir.

Aynı olayın tarayıcı ve sunucu tarafından gönderilmesi gerekiyorsa bunların nasıl uzlaştırılacağını tasarlayın. Kullanıcı sayısı ile hesap sayısı farklıdır; aynı şirketteki birçok çalışan tek müşteri hesabına bağlı olabilir. Raporlama birimini en başta belirlemek, sonradan çelişen başarı oranlarını azaltır.

Varsayımsal teklif akışı tablosu

Tablo, belirli bir analitik ürünün zorunlu şeması değil önerilen alan modelidir. Olay isimlerini seçerken ekipte herkesin aynı anlamı kullanmasını hedefleyin. Bir teknik değişiklik olayın anlamını değiştiriyorsa sessizce aynı adı kullanmak yerine sürüm ve geçiş notu ekleyin.

Yayın öncesi veri provası yapın

Başarılı akış, reddedilen işlem, tekrar tıklama ve bağlantı kopması için beklenen olay dizisini yazın. Test sonucunda oluşan olayları bu diziyle karşılaştırın. Hata durumunda sahte başarı gönderiliyorsa raporun güzel görünmesi kurulumun doğru olduğunu göstermez.

Yayın sonrasında operasyon kayıtlarıyla örnek mutabakat yapın. Aynı zaman aralığını ve saat dilimini kullanın. Veri toplama izinleri veya teknik kısıtlar nedeniyle eksik kayıt oluşabileceğini hesaba katın; eksikliği otomatik olarak kullanıcı davranışı diye yorumlamayın. Ölçüm kalitesindeki değişiklikleri ürün performansından ayrı raporlayın.

Sık sorulan sorular

Her tıklamayı ölçmeli miyim?

Hayır. Önce karar için gereken olayları seçin. Gereksiz olaylar bakım yükünü ve veri riskini artırabilir; anlaşılır bir sözlük daha değerlidir.

Tek başarı metriği yeterli mi?

Ana bir sonuç ölçütü yararlı olabilir, ancak hata, gecikme ve destek ihtiyacı gibi koruyucu ölçütlerle birlikte değerlendirilmelidir.