Panoda veri çok, cevap yok: ürün analitiği ve olay takibi nasıl kurulur?

Hangi olayları toplamalıyız sorusunun cevabı araçta değil, cevap aradığınız sorularda duruyor. Amplitude'ün ölçüm planlama rehberi odaklı bir üründe 20 olay civarının yeterli olabileceğini, özellik yoğun bir üründe 200'ün daha doğru olacağını söylüyor. Segment'in rehberi aynı yere çıkıyor: az sayıda olay, zengin özelliklerle. Sahada gördüğümüz tablo genelde bunun tersi. GA4 kuruluyor, gelişmiş ölçüm açılıyor, kod tarafında bir yığın olay tetikleniyor ve altı ay sonra "kullanıcı hangi adımda vazgeçiyor" sorusuna hâlâ cevap verilemiyor. Çünkü o adımlar hiçbir zaman olay olarak tanımlanmamış. Veri toplanmış, soru cevapsız kalmış.

Önce beş soru, sonra olay listesi

Amplitude'ün taksonomi planlama rehberi sıralamayı net koyuyor: önce iş hedefleri, sonra hedefleri ölçen metrikler, en sonda o metrikleri üreten olaylar. Çoğu projede bu sıra ters işliyor, geliştirici ekrana bakıp "burada bir olay atalım" diyor ve taksonomi kodun şeklini alıyor, işin şeklini değil.

Bir abonelik ürününde beş soru şöyle görünebilir. Kayıt olan hesapların yüzde kaçı ilk yedi gün içinde ilk gerçek işini tamamlıyor? Deneme süresinde hangi özelliğe dokunanlar ücretliye geçiyor? Kurulum sihirbazının hangi adımında bırakılıyor? Davet edilen kullanıcıların yüzde kaçı gerçekten giriş yapıyor? İptal edenler son 30 günde ürünü kaç kez açmış?

Bu beş sorunun gerektirdiği olay listesi genelde on beş kalemi geçmez. Liste kısa olduğu için de gerçekten uygulanır. MVP kapsamını belirlerken kullandığınız mantığın aynısı burada da işliyor: kesilen her olay, bakımını yapmayacağınız bir satırdır.

Sayfa görüntüleme huni kurmaz

Tek sayfalık bir arayüzde page_view size yalnızca adres çubuğunun değiştiğini söyler. Kullanıcının teklifi kaydedip kaydetmediğini, dosyanın yüklenip yüklenmediğini, üçüncü adımda doğrulama hatası alıp almadığını söylemez. Huni adımları açıkça olay olarak yazılmadıysa huni raporu da yoktur.

İyi haber şu: işin bir kısmı zaten bedava geliyor. GA4'ün gelişmiş ölçümü web akışlarında sayfa görüntüleme, sayfanın yüzde 90'ına inen kaydırma, siteden çıkan bağlantı tıklaması, site içi arama, dosya indirme, video etkileşimi ve form başlatma ile gönderme olaylarını kod yazmadan topluyor. Bunları elle yeniden yazmak için harcanan emek, ürüne özgü olaylardan çalınmış emektir. "Teklif Oluşturuldu", "Fatura Gönderildi", "Sipariş İptal Edildi" gibi olayları sizden başka kimse tanımlayamaz.

İsimlendirme: nesne artı eylem

Segment'in veri toplama rehberi basit bir kalıp öneriyor: önce nesneyi seç (Ürün, Sipariş, Rapor), sonra o nesne üzerinde yapılan eylemi ekle (Görüntülendi, Tamamlandı, İndirildi). Ortaya Product Viewed, Order Completed gibi okunabilir isimler çıkıyor. Segment olay adlarında Title Case, özellik adlarında snake_case öneriyor. Aynı rehberin üç yasağı da var: isim içine dinamik değer koymayın, özellik olabilecek bir şeyi olay adına gömmeyin, feature_1, feature_2 gibi dinamik özellik anahtarları üretmeyin.

Aracın kendi kuralları da var ve bunlar tartışmaya açık değil. GA4 tarafında olay adlandırma kuralları snake_case ister, ad 40 karakteri aşamaz ve session_start, first_open, first_visit, user_engagement, error gibi isimler rezerve edilmiştir. Parametre adları da alt çizgiyle ya da firebase_, ga_, google_, gtag önekleriyle başlayamaz. Hangi kuralı seçerseniz seçin, yazıya dökün. Aynı üründe iki farklı isimlendirme kuralının bulunması, hiç kural olmamasıyla aynı sonucu verir.

Olay sayısı az, özellik sayısı bol olsun

Olaylar genel, özellikler ayrıntılı olmalı. Order Completed tek bir olaydır; kanal, para birimi, tutar, ödeme yöntemi, indirim kodu ve kalem sayısı onun özellikleridir. Aynı nesneye ait olaylarda aynı özellik setini taşımak, sonradan kıyas yapabilmenin tek yolu.

Pratik kural: her olay için zorunlu özellikleri ve tiplerini önceden yazın. Tutar sayı mı metin mi, para birimi üç harfli kod mu simge mi, tarih yerel saat mi UTC mi? Bu kararlar yazılmadığında aynı alan üç farklı formatta dolmaya başlar ve altı ay sonra kimse temizleyemez. Aynı hastalığın raporların neden tutmadığı tarafındaki karşılığını daha önce yazmıştık.

Ölçüm planı bir Excel dosyası değil, sözleşmedir

Ölçüm planını depoya koyun, sürümleyin ve değişikliğini kod incelemesinden geçirin. Dosya bir yerlerde duran tabloysa ilk sprintte eskir.

Asıl fark, planın toplama katmanında uygulanıp uygulanmadığında ortaya çıkıyor. Snowplow'da her olay bir JSON şemasına bağlıdır ve şemaya uymayan olaylar hattan ayıklanır; veri ambarına girmez. Segment Protocols ve PostHog'un şema zorlaması benzer işi yapar. Avo gibi araçlar planı JSON Schema olarak dışa aktarıp tipli sarmalayıcı kod üretir, böylece olay adı yazarken otomatik tamamlama devreye girer ve hafızaya güvenmek zorunda kalmazsınız. Küçük bir ekipte bu kadarına gerek olmayabilir; o zaman en azından olayları tek bir tipli fonksiyondan geçirin, çağrıları kodun her yerine dağıtmayın.

Aracın sessiz sınırları

GA4 kullanıyorsanız bu rakamları bilmeden plan yapmayın. Olay toplama sınırları: olay başına 25 parametre, 40 karakter olay adı, 100 karakter parametre değeri, mülk başına 25 kullanıcı özelliği. Yapılandırma sınırları: 50 olay kapsamlı özel boyut, 30 anahtar olay, 10 milyon olayı aşan sorgularda keşif raporlarında örnekleme.

İki sınır özellikle can yakıyor. Birincisi kardinalite: GA4 bir boyutta günlük 500'den fazla farklı değer gördüğünde değerleri "(other)" satırına toplamaya başlıyor. Sipariş numarası ya da kullanıcı kimliği gibi alanları özel boyuta koymak bu yüzden işe yaramaz. İkincisi saklama: standart mülklerde veri saklama varsayılan olarak 2 ay, en fazla 14 aydır. Geçen yılın aynı dönemiyle kıyas yapacaksanız ayarı 14 aya çekin ve ham olay verisi için BigQuery dışa aktarımını açın. Yıllık karşılaştırmayı aracın arayüzüne bırakmayın.

Tarayıcıdan gelen veri eksik gelir

Safari'nin izleme korumasında kalıcı istemci taraflı çerezler, yani document.cookie ile yazılanlar, yedi günlük ömre sıkıştırılır. Sunucunun Secure ve HttpOnly olarak gönderdiği oturum çerezleri bu kapsamın dışındadır. Sonraki sürümde kural çerez dışı depolamaya da genişletildi: kullanıcı siteyle etkileşmeden yedi günlük Safari kullanımı geçtiğinde localStorage dahil site verisi siliniyor.

Buna reklam engelleyicilerin tamamen düşürdüğü istekleri de ekleyin. Tarayıcıdan toplanan sayılar gerçeğin kendisi değil, alt sınırıdır. Ürün kararlarını buradan vermek bir yere kadar sorun değil, ama ciro, abonelik ve iade gibi para olaylarını tarayıcıya emanet etmeyin. O olayların kayıt kaynağı sunucunuzdur.

Sunucudan olay göndermenin kendi kuralları var

GA4'e sunucudan olay gönderirken Measurement Protocol kullanılıyor ve dokümantasyonun işaret ettiği ayrıntılar atlanınca olaylar sisteme düşer ama raporlarda beklediğiniz gibi görünmez: client_id zorunludur, oturum bazlı raporlara girmesi için session_id ve engagement_time_msec gönderilmelidir. İstek başına en fazla 25 olay, gövde 130 kB'ın altında olmalıdır.

Reklam platformlarında da aynı olayı hem tarayıcıdan hem sunucudan göndermek standart hâle geldi. Meta'nın Conversions API'si yinelenen kayıtları event_id ve event_name eşleşmesiyle birleştiriyor ve bunu ilk olayın ulaşmasından sonraki 48 saat içinde yapıyor. Pratik karşılığı tek cümle: olay kimliğini bir kez üretin, tarayıcıya ve sunucuya aynısını verin. İki taraf iki farklı kimlik üretirse dönüşüm sayınız sessizce ikiye katlanır.

Kimlik: anonim ziyaretçiden hesaba

Kullanıcı giriş yapmadan önce rastgele bir anonim kimlikle, giriş yaptıktan sonra kalıcı bir kullanıcı kimliğiyle izlenir. Kayıt anında bu ikisini birleştirmezseniz, dönüşen kullanıcının kayıt öncesi davranışını kaybedersiniz ve huninin en değerli kısmı kopar.

Kimlik olarak e-posta veya telefon kullanmayın, kendi veri tabanınızdaki iç kimliği gönderin. Analitik araca kişisel veri taşımamak hem şema hem risk tarafında sizi rahatlatır. Birçok ülkede analitik amaçlı izleme için açık rıza da gerekir; bu izni kodda gerçek bir durum olarak tutun, yani rıza yoksa olay kuyruğu dolmasın. Banner'ı koyup olayları yine de göndermek, hem hukuken hem veri kalitesi açısından en kötü seçenek.

Ölçüm sessizce bozulur

En sık karşılaşılan arıza, bir düzenleme sırasında olayın kod yolundan düşmesidir. Buton bileşeni yenilenir, olay çağrısı taşınmaz, kimse fark etmez. Üç hafta sonra huni raporuna bakan pazarlama ekibi dönüşümün düştüğünü sanır.

Çözüm basit ve ucuz: her olay için günlük hacim takibi yapın, hacim beklenen aralığın dışına çıktığında uyarı gitsin. Her olayın bir sahibi olsun. Anlamı değişen olayı sessizce yeniden tanımlamayın, yeni bir sürüm olarak ekleyin; eski seriyle yeni seriyi aynı grafikte toplamak, tanımı değiştiğini bilmeyen herkesi yanıltır. Kullanılmayan olayları da yılda bir temizleyin. Üç yıl önce kaldırılan bir özelliğin olayı hâlâ planda duruyorsa plan okunmuyor demektir.

GA4 her ürün sorusunu cevaplamaz

GA4 oturum ve pazarlama odaklı bir araç. Kohort bazlı elde tutma, kullanıcı seviyesinde huni, özellik benimsenme oranı gibi sorularda ürün analitiği araçları ya da kendi veri ambarınız daha rahat çalışır. Ham olay verisi ambardaysa soruyu SQL ile sorabilirsiniz, arayüzün izin verdiği kadarıyla değil.

Trafiği düşük ürünlerde bu daha da önemli. A/B testi çalıştırmak için yeterli kullanıcınız yoksa elinizde kalan tek güvenilir yöntem, davranışı doğru ölçmek ve nitel geri bildirimle birleştirmektir.

Bu haftaya sığan dört adım

• Cevap almak istediğiniz beş soruyu yazın. Soru listesi yoksa olay listesi de olmaz.
• Bu sorulardan 10 ila 15 olay çıkarın; her olay için zorunlu özellikleri ve tiplerini tek bir tabloya yazıp depoya koyun.
• Para olaylarını sunucudan gönderin ve olay kimliğini tarayıcıyla paylaşın, böylece reklam platformlarındaki çift sayım kapanır.
• GA4 saklama süresini 14 aya çekin, uzun geçmişe ihtiyacınız varsa BigQuery dışa aktarımını açın ve kritik olaylara günlük hacim alarmı kurun.