30 saniyelik özet

Tracking plan, ürün içinde hangi davranışların hangi koşullarda ve hangi bilgilerle kaydedileceğini tanımlayan ölçüm planıdır. Event taxonomy ise bu olayların adlandırılmasını ve sınıflandırılmasını düzenleyen ortak yapıdır. Birlikte kullanıldıklarında ürün, mühendislik, pazarlama ve analitik ekipleri aynı veriyi aynı anlamla okuyabilir. Product Owner, yani ürünün değerini artırmaktan sorumlu rol, önce cevaplanacak iş sorusunu netleştirir. Ardından bu soruyu yanıtlamak için gerekli olayları ekiple tanımlar. Çok veri toplamak, doğru soruya güvenilir cevap verebilmekle aynı şey değildir.

Neden önemli?

Yeni bir kayıt akışının başarılı olup olmadığını değerlendirdiğinizi düşünün. Bir ekip kayıt düğmesine basılmasını, başka bir ekip hesabın oluşturulmasını, pazarlama ekibi ise e-posta doğrulamasını başarı kabul ediyor olabilir. Raporlar farklı sonuçlar verdiğinde sorun kullanıcı davranışında değil, ölçüm tanımında olabilir.

Bu belirsizlik ürün kararlarına doğrudan yansır. İyi çalışan bir akış gereksiz yere değiştirilir veya tamamlanmamış bir işlem başarı olarak görülür. Ekipler veriyi açıklamak için zaman harcar; yöneticiler hangi rapora güveneceklerini sorgular. İş analisti için de gereksinimi yazmak yeterli olmaz: Gereksinimin karşılandığını hangi davranışla değerlendireceğimiz açıklanmalıdır.

Ölçüm planı, bu tartışmaları uygulama geliştirilmeden önce yapma fırsatı verir. Ürün ekibi soruyu, mühendislik olayın nerede güvenilir biçimde üretilebileceğini, analitik ekibi ise verinin nasıl yorumlanacağını konuşur. Pazarlama da edinilen müşterinin ürün içinde ne yaptığını aynı tanımlar üzerinden değerlendirebilir.

Yönetim açısından fayda, yalnızca daha düzenli raporlar değildir. Bir yatırımın hedeflenen sonucu üretip üretmediği daha sağlam değerlendirilebilir. Ancak ölçümün sınırları açık kalmalıdır. Kaydedilmeyen davranışlar, eksik kullanıcı kimlikleri ve sonradan değişen olay tanımları değerlendirmeyi etkileyebilir. Bu nedenle bir raporun yanında kapsamını ve bilinen veri sorunlarını da anlamak gerekir.

Terim nedir?

Event, ürün içinde gerçekleşen bir eylemi veya durum değişikliğini temsil eden olay kaydıdır. Property, bu kayda bağlam sağlayan özelliktir; kullanılan platform veya işlemin türü buna örnek olabilir. Tracking plan, olayın adını, anlamını, tetiklenme koşulunu, özelliklerini ve toplandığı kaynağı ortak bir belgede tanımlar.

Event taxonomy, olay ve özellik adlarının tutarlı olmasını sağlar. Aynı davranışın farklı ekiplerde farklı adlarla kaydedilmesini veya aynı adın farklı anlamlarda kullanılmasını azaltır. Instrumentation ise bu tanımlara göre ölçüm kayıtlarını üretecek kodun ürüne eklenmesidir.

Plan, cevaplanacak müşteri ve ürün sorularından hareketle hazırlanmalıdır. Bir olayın analitik sisteme ulaşması tek başına doğru ölçüldüğünü göstermez. Tanımlanan davranışı doğru anda temsil etmesi de gerekir. Planın ekipler için erişilebilir olması, uygulama sırasında ortak referans olarak kullanılmasını kolaylaştırır.

Kavramsal kaynak: Twilio Segment, What is a tracking plan?

Gerçek vaka: Creative Market’in ölçüm hatalarını kaynağında yönetmesi

Twilio’nun yayımladığı Creative Market müşteri hikâyesi, tasarım ürünleri sunan pazaryerinde tutarsız verilerin pazarlama ve analitik araçlarına yayıldığını anlatır. Ekiplerin paylaşabileceği, kolay güncellenen ortak bir ölçüm tanımı bulunmaması da sorunun parçasıdır.

Vakada ürün ve büyüme analisti Akshay Singh, yanlış uygulanan olaylarla deney sonuçlarını ölçtüklerini belirtir. Hata fark edildiğinde verinin düzeltilmesi, kodun yeniden doğrulanması ve deneyin tekrarlanması gerekebilmiştir. Böylece ölçüm sorunu, yalnızca rapor hazırlamayı değil, öğrenme sürecini de etkilemiştir.

Creative Market, Segment Protocols ile merkezi bir tracking plan oluşturur. Gelen verinin bu plana uygunluğu denetlenir; geçersiz veya planlanmamış kayıtlar için uyarılar alınır. Tanımlar diğer ekiplerin de başvurabileceği ortak bir referansa dönüşür.

Bu vakadan çıkarılabilecek ders, ölçüm tanımının bir belge olarak kalmaması gerektiğidir. Uygulamayla karşılaştırılmalı ve sapmalar görünür olmalıdır. Kaynak bir sağlayıcının müşteri anlatısıdır; burada aktarılan süreç, bütün şirketler için aynı sonucu garanti eden bağımsız bir karşılaştırma değildir.

Kaynak: Twilio, Protocols creates clean, reliable data that Creative Market can trust.

Varsayımsal örnek: İlk raporunu oluşturan müşteri hesabı

Şirketlere raporlama hizmeti veren bir ürün ekibi, yeni müşterilerin ilk kullanılabilir raporlarına ulaşmasını kolaylaştırmak ister. Mevcut ölçümde yalnızca rapor oluşturma düğmesine basılması kaydedilir. Ancak düğmeye basan kullanıcı veri bağlantısı hatası alabilir veya boş bir raporla karşılaşabilir. Bu kayıt, hedeflenen sonucun gerçekleştiğini göstermeye yetmez.

Ürün sahibi, veri ekibi ve mühendislerle birlikte “ilk kullanılabilir rapor” tanımını netleştirir. Test hesapları kapsam dışında tutulur. Ölçüm kullanıcı yerine müşteri hesabı düzeyinde yapılır; aynı şirketin farklı çalışanlarının hazırladığı raporlar yeni müşteri başarılarını çoğaltmaz.

Ekip, Data Source Connected olayını veri kaynağı bağlantısının sistem tarafından başarıyla doğrulanması sonrasında üretir. Report Generated olayı ise rapor üretimi tamamlandığında kaydedilir. Olayın özellikleri arasında müşteri hesabının kimliği, rapor türü, kaynak türü ve ölçüm tanımının sürümü bulunur. Raporun içeriği ve müşterinin serbest metinleri analitik kaydına eklenmez.

Kullanıcı ekranındaki tıklama ayrı bir olaya dönüşür. Böylece talebin başlatılması ile işlemin tamamlanması karşılaştırılabilir. Başarılı üretim kaydı için sunucu, yani işlemin sonucunu yöneten sistem bileşeni, kaynak olarak seçilir. Aynı tamamlanma kaydının yeniden gönderilmesi halinde tekrar sayılmaması için kayıt kimliği ve tekrarları ayırt etme kuralı belirlenir.

Ekip, başarılı işlem, bağlantı hatası ve yeniden deneme senaryolarını ölçüm açısından değerlendirir. Ardından iş sistemindeki tamamlanmış raporlarla analitik kayıtlarını karşılaştırır. Fark bulunduğunda hemen kullanıcıların akışı terk ettiği sonucuna varmaz; önce veri toplama ve aktarma sorunlarını araştırır. Yeni rapor ekranı yayımlandığında olayların anlamının değişip değişmediği de incelenir. Geçmişle karşılaştırmanın hangi dönemlerde geçerli olduğu kayıt altına alınır.

Yaygın üç hata

  1. Her tıklamayı ölçüm ihtiyacı saymak

Tıklamalar bazı soruları yanıtlayabilir, ancak iş sonucunun yerine geçmez. Bir teklifin gönderilmesini ölçmek istiyorsanız gönder düğmesine basılması yeterli olmayabilir. Önce hangi karar için veriye ihtiyaç olduğunu belirleyin; ardından o kararı destekleyen davranışları seçin. Kullanılmayan kayıtlar bakım ve yorumlama yükü oluşturur.

  1. Aynı adı farklı tamamlanma koşullarına vermek

Web uygulaması bir işlemin başlatılmasını, mobil uygulama tamamlanmasını aynı adla kaydediyorsa birleşik rapor yanıltıcı olabilir. Adlandırma standardıyla birlikte tetiklenme koşulu da ortaklaştırılmalıdır. Bir özellik alanının metin mi, sayı mı olduğu ve boş kalmasının ne anlama geldiği de tanıma eklenmelidir.

  1. Yayından sonra planı güncellememek

Yeni bir ekran, arka plandaki işlem sırasını değiştirebilir. Olay adı aynı kalsa bile temsil ettiği davranış değişebilir. Ölçüm planının sahibi, değişikliğin hangi raporları etkilediğini değerlendirmelidir. Geçmiş veriyi yeni tanımla yorumlamak yerine tanım değişikliği ve karşılaştırma sınırı açıkça kaydedilmelidir.

Mini uygulama / şablon

Cevaplanacak iş veya ürün sorusu
—
Veriye dayanarak alınacak karar
—
Olay adı ve iş anlamı
—
Kesin tetiklenme koşulu
—
Kaydın üretileceği sistem
—
Zorunlu özellikler ve veri türleri
—
Kullanıcı ve müşteri hesabı kimlik kuralları
—
Kapsama alınacak ve dışarıda tutulacak işlemler
—
Tekrarlanan kayıtları ayırt etme yöntemi
—
Toplanmayacak içerik ve veri alanları
—
İlgili metrik ve hesaplama tanımı
—
Uygulama ve tanım sorumluları
—
Doğrulama senaryoları
—
Tanım sürümü ve değişiklik tarihi
—

Şablonu önce tek bir önemli ürün sorusu için doldurun. Başarı ve hata senaryolarında hangi kayıtların oluşacağını ekiple konuşun. Geliştirme kabul koşullarına ölçümün iş anlamına uygun üretilmesini ekleyin. Yayından sonra yalnızca olayların geldiğini değil, beklenen işlemlerle uyuştuğunu da değerlendirin. Veri hatası bulunduğunda etkilenen raporları ve dönemleri belirtin; düzeltmenin geçmiş kayıtları kapsayıp kapsamadığını açıklayın. Böylece sonraki ürün kararı, görünüşte tutarlı fakat anlamı belirsiz bir grafiğe dayanmaz.

İlgili terimler

Product Analytics, Instrumentation, Data Governance, Event Properties, Identity Resolution, Funnel Analysis, Activation, Retention, Data Quality, Acceptance Criteria