Geleneksel olarak, ürün analistleri tek bir oturum içinde zaman damgasına göre olayları sıralı bir şekilde filtreleyerek SQL sorguları ile huniler oluşturuyorlardı. Bu yaklaşım, etkileşimlerin tek bir tarayıcı ve çerez ile bağlantılı olduğu web analitiği döneminde şekillendi ve kullanıcı yolunun kesinlikle doğrusal olduğu varsayıldı. Klasik araçlar, Google Analytics 360 veya Yandex.Metrica gibi, huninin monotonluğunu öngören bir mimari oluşturuyordu, her bir sonraki adımın önceki adımın zaman penceresinde gelmesi gerekiyordu. Ancak mobil ekosistemlerin ve çok kanallılığın gelişimiyle, bu yöntem yanlış sonuçlar vermeye başladı, karar vermenin gecikmiş fenomenini ve bir hedef eylemi sırasında cihazlar arasında geçişi göz ardı ediyordu.
Modern SaaS ürünlerinde, huni tek yönlü bir boruya dönüşmüyor. Kullanıcı, bir akıllı telefon üzerindeki checkout'u başlatabilir, eylemi erteleyebilir, iki gün sonra dizüstü bilgisayardan fiyatları karşılaştırmak için geri dönebilir ve ödeme işlemini bir e-posta hatırlatması sonrasında bir tablet ile tamamlayabilir. Standart drop-off rate, 30 dakikalık bir oturum içinde adımlar arasındaki fark olarak hesaplanır ve “boşluk” ilk kesimde kaydedilecektir, oysa gerçek dönüşüm daha sonra gerçekleşecektir. Bu, “dar bir yer” hakkında yanlış sonuçlara yol açmakta ve yanlış adımı optimize etmeye yönelik gereksiz A/B testlerine başlamaktadır. Analistin görevi, gerçek bir reddi gecikmiş dönüşümden ayırmak ve kullanıcıyı etkileşim yüzeyinden bağımsız olarak tanımlamayı sağlamaktır.
Kullanıcı merkezli huni analizi uygulamak gerekli olup, bunun için probabilistic device graph ve survival analysis kullanılarak adımlar arasındaki zamanı modellemektir. Rigid SQL hunisi yerine, durum grafi üzerine inşa edilmiş bir Sankey diyagramı kullanılır; burada düğümler ürün ekranları ve kenarlar, zaman-çürütme bileşenini dikkate alan ağırlıklı geçişlerdir. Kesintisiz tanımlama için, doğrusal eşleme kimlik doğrulama ile uygulanmaktadır ve davranışsal parmak izlerine dayalı probabilistic linking ile tamamlanmaktadır (hareket sıklığı, kaydırma desenleri, coğrafi konum) %95 güven eşiği ile. Kritik kesinti, maksimum drop-off yerine, Cox proportional hazards modeli içindeki en büyük hazard rate düşüşü ile tanımlanır; bu, sansürlenmiş verileri (henüz dönüşüm görmemiş fakat tamamen ayrılmamış kullanıcılar) hesaba katmayı sağlar. Görselleştirme için Amplitude'da Path Analysis veya Mixpanel'de özelleştirilmiş Notebooks kullanılmakta ve ‘holding constant’ modunda intent düzeyinde, ilk olayın zaman damgası yerine kohort sabitlemesi sağlanmaktadır.
Bir B2C online kurs pazaryerinde, checkout yeniden tasarlandıktan sonra “ödeme yöntemi seçimi” adımında açıklanamaz bir dönüşüm düşüşü gözlemlendi. Klasik analiz, bir saat içinde %40 drop-off gösterdi ve ürün takımı arayüzün başarısız olduğunu düşünerek değişiklikleri geri almaya acele etti.
İlk düşünülen yaklaşım, 30 dakikalık bir oturum penceresi ve katı bir olay sıralaması ile sıkı bir SQL hunisi oluşturmaktı. Artılar: Uygulama kolaylığı ve ClickHouse üzerinde yüksek hesaplama hızı. Eksiler: Yöntem tamamen mobil-denetim geçişlerini ve satın alma erteleme davranışını göz ardı ediyor, yanlış bir dönüşüm kaybı kaydediyordu.
İkinci seçenek — standart cross-device izleme için Google Analytics 4’ü ve Google Signals’ı kullanmaktı. Artılar: hazır altyapı ve reklam panelleri ile yerleşik entegrasyon. Eksiler: yüksek trafik altında veri örneklemesinin agresifliği ve anonim trafiği güvenilir bir şekilde oturumlarla birleştirme imkânının olmaması; bu, yüksek misafir ziyaretler payına sahip ürünümüz için kritik bir durumdu.
Üçüncü seçenek — dbt ve Python tabanlı özelleştirilmiş bir çözümle, her kullanıcıya bir durum (browsing, comparing, checkout_started, payment_pending, completed) atanarak bir state-machine funnel geliştirdik; geçişler cihazlar ve çekim kanalları bazında Kaplan-Meier estimator yöntemi ile analiz ediliyordu. Artılar: uyarlanabilir dönüşüm penceresi (7-14-30 gün) belirleme imkânı ve gerçek kaybedilen ilgiyi hangi adımda olduğunu tespit etme olanağı, sadece geçici bir gecikme değil. Eksiler: data engineering için yüksek talepler ve probabilistic linking kalitesinin elle doğrulanması gerekliliği.
Üçüncü seçenek tercih edildi, çünkü ürün karmaşık bir çok cihazlı hunisine sahipti ve karar verme döngüsü uzun sürüyordu. Kaybettiğimiz kullanıcıların %60’ının ödeme adımında, başka bir cihazla 72 saat içinde geri döndüğünü ve satın almayı tamamladığını keşfettik. Gerçek bottleneck, checkout arayüzü değil, “ödemeyi erteleme ve e-posta hatırlatması yapma” seçeneğinin eksikliğiydi; bunu hızlı bir şekilde uygulamaya koyduk.
Sonuç: dönüşüm tahminindeki doğruluk %62’den %89’a yükseldi ve “problematik adımlar” ile ilgili yanlış pozitif sinyaller %70 oranında azaldı. Bu, ürün ekibinin var olmayan UX sorunlarıyla mücadele etmek yerine gerçek büyüme noktalarına odaklanmalarını sağladı.
Gözlem penceresini ne şekilde doğru ayarlamak gerekir, eğer ürün düzensiz bir kullanım paterni (örneğin ayda bir) içeriyorsa, geçerli dönüşümleri kaybetmemek ama çok uzun bir kuyruk yüzünden analizi de sarmamaktır?
Cevap: Burada, gerçekten dönüşüm gerçekleştiren kullanıcıların adımlar arasındaki zaman dilimlerinin yüzde değerlerine dayanan aktif gözlem penceresi (active observation window) kullanmak kritik öneme sahiptir; sabit bir takvim aralığı yerine. Dönüşüm süresi dağılımı oluşturulmalı ve başarılı dönüşüm için kesme noktası olarak 90. veya 95. percentil seçilmeli; geri kalan sansürlenmiş veri sayılmalıdır. Survival analysis'da right-censoring kullanmak önemlidir; çünkü 30 gün içinde dönüşüm gerçekleştirmeyen ama 31. günde geri dönen bir kullanıcı, ilk 30 gün içinde kaybolmuş olarak sayılmamalıdır. Farklı intent katmanlarında pencereleri segmentlere ayırmak da gereklidir: deneme kullanıcısı için pencere 7 gün olabilir, kurumsal bir lider için 90 gün; bu aksi takdirde metriklerin kıyaslanamaz olmasına yol açar.
Neden standart “unique visitors / step completion” dönüşüm sayımı yaklaşımı, tekrar deneme (retry) olasılığı olan ürün hunilerinde sonuçları çarpıtır, ve bunu nasıl hesaba katabiliriz?
Cevap: Bu metrik survivorship bias 'dan etkilenmektedir; çünkü sadece adımda ilerleyenleri dikkate alır, hata ile karşılaşan ve ayrılanları göz ardı eder. SaaS ürünlerinde karmaşık bir onboarding ile kullanıcı belgeleri yüklemeye üç kez çalışabilir, teknik bir hata ile karşılaşabilir ve ancak dördüncü denemede başarılı olabilir. Standart huni bunu 4 ziyaret ve 1 dönüşüm olarak sayacak ve gerçek UX sorununu bulanıklaştıracaktır. Attempt-based funnel'a geçmek gereklidir; burada analiz birimi oturum değil, intent-attempt — hedefe ulaşma için belge niteliği taşıyan bir denemedir. Tekrar deneme girişimlerini gruplandırmak için event_id uygulanmalı ve attempt’ler üzerinde tamamlanma oranı ve denemeler arasındaki hata oranı analiz edilmelidir. Bu, arayüzdeki sürtünmeyi altyapının rastgele teknik kesintilerinden ayırmayı sağlar.
Kullanıcının niyetleri üzerine belirgin veriler olmadığında ara adımlardaki rastgele görüntülemenin (accidental drop-off) bilgilendirilmiş raddeden (informed churn) ayrılmasını sağlayan yöntemler nelerdir?
Cevap: Ana gösterge, ayrılmadan önceki micro-conversions ve engagement depth analizidir. Eğer kullanıcı, adımda 3 saniyeden az süre kalmışsa (kriter dwell time) ve herhangi bir scroll ya da interaction event gerçekleştirmediyse, bu accidental drop-off olup sürtünme analizinden çıkartılmalıdır; bunun için heuristic filtering veya clustering (örneğin, özellik vektöründe K-means ile: time_on_step, number_of_clicks, scroll_depth) kullanılabilir. Bilgilendirilmiş raddede, eşik analizi gibi bazı davranış kalıpları ortaya çıkar: alternatif fiyatların incelenmesi, geri ödeme koşulları hakkında SSS okuma, pencere kapatma simgesine hover yapma. Bir iptal etme eğilimi modelini oluşturmak gereklidir; bu, açıkça aboneliği iptal eden kullanıcıların davranışına göre eğitilmeli ve mevcut drop-off’lara uygulanmalı, kaybın ciddiyetini ağırlıklandırmak için. Ayrıca, katı sayısal varsayımları doğrulamak amacıyla nitel veri üçgenleme (qualitative data triangulation) yapılması gerekir: Hotjar veya FullStory gibi ısı haritalarıyla oturumların örneklemesi, kaybın doğası hakkında nicel hipotezleri doğrulamak için.