Olay İzleme
Olay izleme, düğme tıklamaları, form gönderimleri veya test tamamlamaları gibi belirli kullanıcı etkileşimlerini olay adı verilen ayrı veri noktaları olarak kaydetme uygulamasıdır. Her olay; değer, kategori veya puan gibi bağlam ekleyen parametreler taşıyabilir.
Önemli noktalar
- Olay; ad, zaman damgası, eyleyen, özellikler ve bağlam taşıyan değişmez bir olgudur.
- Tıklamada tetiklemek niyeti, sunucu onayından sonra tetiklemek gerçek sonucu ölçer.
- Düşük kardinaliteli ve tipi belli özellikler sorgulanabilir kalır; serbest metin ve ham sayılar kalmaz.
- Olayları, özellikleri, tipleri ve sahiplerini adlandıran bir izleme planı ekipler arası savrulmayı engeller.
- Olaylar geriye dönük doldurulamaz; bugün ölçülmeyen davranış gelecekteki analiz için yoktur.
Derinlemesine
Bir olay kaydı belirli bir biçime sahip bir olgudur: bir ad, bir zaman damgası, eylemi yapanın kimliği, o tek vakayı betimleyen özellikler ve sayfa, cihaz, kampanya gibi bağlam. Kodun belirli bir satırından yayılır, toplayıcıya gider ve yalnızca eklenerek saklanır, hiç üzerine yazılmaz. Asıl önemli olan bu değişmezliktir. lead_status gibi bir durum alanı üzerine yazıldığında geçmişini kaybeder; oysa status_changed olaylarından oluşan bir akış, yaşanan her değişimin sırasını ve zamanını olduğu gibi korur. Analizler bu yüzden her zaman akış üzerine kurulur, durum alanı üzerine değil.
Doğruluk büyük ölçüde yayma noktasını nereye koyduğunuza bağlıdır. Tıklamada tetiklemek niyeti ölçer, sunucu başarıyı onayladıktan sonra tetiklemek sonucu ölçer ve aradaki fark, dönüşüm sayılan her başarısız gönderimden ibarettir. Gerisini özellik tasarımı belirler: az sayıda, tipi belli, düşük kardinaliteli alan yıllarca kullanılabilir kalır; serbest metin ve sınırsız sayılar ise sorgulanamaz hâle gelir. Eklenen her olay ayrıca veri boyutu, depolama ve ileride onu açıklamak zorunda kalacak kişinin dikkati kadar maliyet taşır. Bu maliyet ilk gün görünmez, ikinci yılda fazlasıyla görünür hâle gelir.
Pratikteki çıktı bir izleme planıdır: her olayı, ne zaman tetiklendiğini, özelliklerini, veri tiplerini, izin verilen değerlerini ve sahibini listeleyen bir tablo. Her etkileşimi değil, huni kilometre taşlarını ölçün. Bir quiz hunisinde bunlar; bir başlangıç, soru indeksini ve yanıtlandı mı atlandı mı bilgisini taşıyan bir adım olayı ve puan bandını taşıyan bir tamamlamadır. İyi tanımlanmış üç olay, doğaçlama otuz olaydan daha çok soruya yanıt verir. Bu disiplini ayakta tutan şey plandır. Plan, ekipler ve araçlar değişse bile bu disiplini yıllarca ayakta tutar.
Olaylar davranışı anlatır, gerekçeyi değil. Dördüncü sorudaki ayrılma insanların nerede çıktığını söyler ama nedenini asla söylemez; veri yalnızca bir hipotez kurar ve bunu ancak kullanıcı araştırması ya da bir test çözer. Ölçümleme geriye de işlemez: geçen çeyrek tanımlamadığınız bir olayı bu çeyrek geri getiremezsiniz. Toplama betiklere ve onaya bağlı olduğundan mutlak sayılar her zaman bir alt sınırdır; bu yüzden adımlar arasındaki oranlar toplamlardan çok daha güvenilirdir. Bu nedenle mutlak değerleri değil oranları karşılaştırın. Toplamlar ise yalnızca kendi geçmişleriyle karşılaştırılabilir.
Pratikte örnek
Nasıl ölçülür
Herhangi bir analiz yapmadan önce ölçümlemeyi doğrulayın. Her olay için akışı bir kez baştan sona yürüyün, özellikleri dolu biçimde tek sefer tetiklendiğini onaylayın, ardından bir günlük toplanan olayı uygulama veritabanınızdaki karşılık gelen satırlarla karşılaştırın. Veritabanı sayısını aşan hacim mükerrer tetiklemeye, altında kalan hacim ise engelleyicilerden, onaydan ya da arayüzdeki bazı yolları ıskalayan bir tetikleyiciden kaynaklanan kayba işaret eder.
Güvendiğiniz olayları bundan sonra oran olarak okuyun. Huni boyunca adımdan adıma tamamlama, genel bir dönüşüm oranına kıyasla zayıf noktayı çok daha iyi yalıtır; iki olay arasındaki süre ise sayıların gizlediği tereddüdü açığa çıkarır. Özellikleri eksik ya da boş gelen olayların payını da bir sağlık metriği olarak izleyin; oradaki bir artış, bozulan raporlardan haftalar önce görünür ve kolayca alarma bağlanır.
Sık yapılan hatalar
Sonucu değil düğmeyi ölçümlemek, her raporu sessizce şişiren hatadır. Tıklama olayı tetiklenir, ardından istek zaman aşımına uğrar ya da doğrulama formu geri çevirir; dönüşüm sayısına hiç geçemeyen insanlar dahil olur. Yayma noktasını başarı durumuna taşıyın; ikisine de ihtiyacınız varsa denendi ve tamamlandı gibi ayrı adlar kullanın ki aradaki fark görünmez bir hata olmaktan çıkıp tanı konabilir bir metriğe dönüşsün. İki sayı arasındaki fark başlı başına bir kalite ölçüsüdür.
İkinci hata, anlamı adın içine tıkıştırmaktır. Ekipler tek bir olay ve bir segment özelliği yerine quiz_complete_marketing, quiz_complete_sales ve quiz_complete_v2 üretir; bundan sonra her rapor sürekli güncellenen bir varyant listesine muhtaç kalır. Adları sabit tutun, farkı özelliklere taşıyın. Aynı derecede yaygın olanı, her şeyi bir anda ölçümlemektir: onlarca olay yayına girer, kimse sahiplenmez ve bir yıl içinde hangisinin hâlâ doğru olduğunu kimse söyleyemez.
Sıkça sorulan sorular
Olay ile parametre arasındaki fark nedir?
Olay, quiz_complete gibi adlandırılmış eylemdir; parametre ise ona eklenen puan veya kategori değeri gibi ek bağlamdır. Parametreler, olayları daha hassas bölümlemenizi ve analiz etmenizi sağlar.
Olay izlemede veri katmanı nedir?
Veri katmanı, kullanıcı eylemlerini ve bağlamı açığa çıkaran, sayfadaki yapılandırılmış bir nesnedir; böylece Google Tag Manager gibi araçlar bunları okuyup olayları analiz ve reklam platformlarına iletebilir.
Bir olay nasıl adlandırılmalı?
Nesne ve eylemden oluşan tutarlı bir kalıbı geçmiş zamanla kullanın; quiz_started ya da lead_submitted gibi ve tek bir yazım biçiminde. Önemli olan öngörülebilirliktir: herkes bir olayın adını bakmadan tahmin edebilmelidir. Kitleleri, kampanyaları veya sürümleri adın içine kodlamayın; bunlar filtrelenebilecekleri yer olan özelliklere aittir. Kalıba uymayan adları kod incelemesinde geri çevirin.
Kaç olay izlemeliyim?
Sezginin önerdiğinden daha az. Huni aşamalarına karşılık gelen kilometre taşlarıyla başlayın; bir pazarlama sitesi için bu genellikle beş ile on beş arasındadır. Yeni bir olayı ancak besleyeceği kararı adlandırabildiğinizde ekleyin. Sınır hacim değil bakımdır; çünkü her olayın, hâlâ doğru çalışıp çalışmadığını bilen bir sahibi olmalıdır.
Olaylar tarayıcıdan mı sunucudan mı gönderilmeli?
Olay onaylanmış bir sonucu temsil ediyorsa sunucudan gönderin; kaydın gerçekten yazılıp yazılmadığını yalnızca sunucu bilir. Adımlar, tereddüt ve terk gibi sunucunun hiç görmediği etkileşim ayrıntıları için tarayıcıdan gönderin. Pek çok ekip ikisini birden yapar ve ortak bir kimlik üzerinden birleştirir; dönüşümlerde asıl kaynak sunucu kalır.
İzleme planı nedir?
İzleme planı; her olayı, tetiklendiği anı, özelliklerini, veri tiplerini, izin verilen değerlerini ve sahibini tanımlayan ortak belgedir. Uygulama, analiz ve raporlamanın kod okumadan aynı anlamda buluşması için vardır. Her yayından önce gözden geçirilmesi, iki ekibin aynı kullanıcı eylemi için farklı adlar yayınlamasını engelleyen şeydir. Plan yoksa aynı bilgi kod tabanına dağılır ve kimse tam listeyi göremez.
Yayına aldıktan sonra bir olayı değiştirebilir miyim?
Değiştirebilirsiniz ama geçmiş sizinle birlikte değişmez. Yeniden adlandırmak verinizi ikiye böler; adı değiştirmeden anlamını kaydırmak ise daha kötüdür, çünkü grafikler kesintisiz akarken tanım sessizce yer değiştirir. Anlam değişiyorsa yeni bir ad tanımlayın, ikisini kısa süre birlikte çalıştırın ve geçiş tarihini belgeleyin ki sonraki analizler bu dikişi doğru okusun.
Olay sayılarım araçlar arasında neden farklı?
Çünkü her araç farklı oturum mantığı, tekilleştirme, ilişkilendirme ve filtreleme uygular ve engelleyicilerle onaya farklı oranlarda pay kaptırır. Olayları sunucunuzdan alan bir araç, tarayıcı betiklerine dayanan bir araçtan genellikle daha fazla bildirir. Her soru için bir referans sistem belirleyin ve aynı toplamı beklemek yerine araçlar arasında eğilimleri karşılaştırın.