Biyometrik ödemenin dönüşüm üzerindeki etkisini analiz etmek için kullanıcı düzeyinde rastgeleleştirme ile A/B testi yapılmalıdır. Ana metrik: temel — satın alma dönüşüm oranı (conversion rate), kontrol metrikleri — ortalama sepet tutarı, huninin derinliği (initiate checkout → payment success), 7. gün geri kazanım oranı. Ayrıca, yenilik etkisini ortaya çıkarmak için cihazlara (iOS/Android) ve yeni/dönüş yapan kullanıcıların kohortlarına göre segmentasyon gereklidir.
Deneyin minimum tasarımı: %50/%50 bölünme, en az 2 tam iş döngüsü (14 gün) süresi, test gücü (power) ≥ %80 ve anlamlılık seviyesi (alpha) = %5. Ayrıca, etkinin zamanla istikrarlı olup olmadığını doğrulamak için SQL kullanarak kohort analizi ve istatistiksel hipotez testleri için Python (SciPy, Pandas) kullanılır.
Sorun:
Fintech başlangıcı, iOS uygulamasında Apple Face ID ile ödeme entegrasyonu planlıyordu. Ürün ekibi dönüşümde %15 artış bekliyordu, ancak iş tarafı geliştirmedeki zaman maliyetlerinden endişe ediyordu (2 sprint). Analistin görevi, alternatif açıklamaları (mevsimsellik, pazarlama faaliyetleri, iOS güncellemesi) hariç tutarak özelliğin gerekçesini sunmak veya çürütmekti.
Göz önünde bulundurulan çözümler:
İlk çözüm — yayından önce ve sonra (pre-post analysis) dönüşüm oranının karşılaştırılması. Artılar: minimal zaman yatırımı, kullanıcıları izole etme gereksinimi yok. Eksiler: özelliğin etkisini dış faktörlerden (örneğin, eşzamanlı bir reklam kampanyasının başlatılmasıyla) ayırmak imkânsız, yanlış pozitif sonuç çıkarma riski yüksektir.
İkinci çözüm — Difference-in-Differences (DiD) yöntemi ile bir kısmi deney. iOS kullanıcıları (Face ID’nin ortaya çıkacağı) ile Android kullanıcılarını (kontrol grubu) karşılaştırmayı planlıyordu ve uygulama öncesi eğilimleri göz önünde bulunduruyordu. Artılar: uygulama içinde bölme için teknik uygulama gerektirmez, gözlemlenen verilerle çalışır. Eksiler: platformlar arasında paralel eğilimler üzerinde kritik bir varsayım, iOS ve Android'in farklı kullanıcı kitlesi nedeniyle sıkça ihlal edilir, karışıklık olduğunda yorumlama zorluğu.
Üçüncü çözüm (seçilen) — LaunchDarkly ile özellik bayrakları kullanarak tam A/B testi. iOS kullanıcılarının %50'si Face ID'ye erişim sağladı (deneme grubu), %50'si eski yöntemle ödeme yaptı (kontrol). Örneklem büyüklüğü R içerisinde pwr kütüphanesi kullanılarak hesaplandı: temel dönüşüm oranı %8, beklenen MDE (Minimum Detectable Effect) %12, power=0.8 ve alpha=0.05 ile her grup için ≥ 12.000 kullanıcı gerekiyordu. Deney, haftanın farklı günlerini kapsayacak şekilde 3 hafta sürdü.
Sonuç:
Deneme grubundaki dönüşüm oranı %11,3 arttı (8,1%'den 9,0%'a), p-değeri = 0.002 (iki yönlü z-testi). Ancak, kohort analizi, etkinin yalnızca yeni kullanıcılar için istatistiksel olarak anlamlı olduğunu (+%18), mevcut kullanıcılar için değişikliklerin kaydedilmediğini gösterdi. Sonuç olarak, özelliğin %100 kullanıcıya açılması seçildi, fakat pazarlama materyalleri yeni kullanıcıları çekmek için yeniden hedeflendi ve bu, projenin ROI'sini başlangıç modeline kıyasla %40 artırdı.
Yenilik etkisini (novelty effect) nasıl sürdürülebilir metrik iyileştirmesinden ayırırsınız?
Adaylar genellikle A/B testini istatistiksel anlamlılık elde ettiklerinde sonlandırırlar, etkinin sürdürülebilirliğini kontrol etmeden. Yenilik etkisini ortaya çıkarmak için metriklerin günlük birikim grafiklerini (cumulative metric curves) oluşturun ve heterojenlik analizi yapın: ilk 3 gündeki etkiyi son haftadaki etkiyle karşılaştırın. SQL kullanarak kohort analizi yapın: deneydeki katılım tarihlerine göre trafiği ayırın (cohort_date) ve eski kohortlar için uplifti koruyup korumadığını kontrol edin. Etki zamanla azalırsa, bu klasik bir yenilik etkisidir; kullanıcılar genellikle yalnızca meraktan özelliği dener, ancak uzun vadeli davranışlarını değiştirmezler.
Ürün analitiğinde istatistiksel anlamlılık (statistical significance) ile pratik anlamlılık (practical significance) arasındaki fark nedir?
Büyük örneklemlerde, %0,5'lik bir dönüşüm artışı istatistiksel olarak anlamlı olabilir (p < 0,05), ama eğer özelliği destekleme maliyeti, ek satın alımlardan elde edilen geliri aşarsa, iş açısından anlamsızdır. Deneyden önce MDE (Minimum Detectable Effect) — iş değeri olan minimum etki boyutunu belirlemek gerekir. Bu, (Beklenen Gelir/Geri Dönüşüm × Ek Geri Dönüşümler) — Özellik Maliyeti olarak hesaplanır. Eğer gerçek uplift MDE'nin altında ise, p-değeri = 0,01 olsa bile, özellik yayılmamalıdır. Hesaplamak için Python (statsmodels.stats.power) veya çevrimiçi hesaplayıcılar kullanın.
Kullanıcı özelliği görüyor ama kullanamıyorsa (network effect veya bir grup üzerindeki teknik arıza) durumu nasıl ele alırsınız?
Bu, contaminaion veya spillover etkisi problemidir. Klasik örnek: test grubunda kripto para ile ödeme aktif hale getirildi ama hizmet sağlayıcı %30 zamanından yoksundu. "Niyet edilmiş tedavi" (intent-to-treat, ITT) analizi, kullanmaktan bağımsız olarak düğmeyi gören herkes üzerindeki etkiyi değerlendirir. Değerlendirmenin saflığı için CACE (Complier Average Causal Effect) veya instrumental variables (enstrümantallar) yöntemi kullanın; burada "gruba atanma" özelliğin gerçek kullanımını değerlendiren bir araçtır. SQL içinde iki aşamalı regresyon veya gerçek işlem günlükleri ile JOIN kullanarak uygulanır, sunucu hataları olan kullanıcıları etkinlik analizinden çıkarır, ancak grupların dengeliğini kontrol etmek için rastgeleleştirmede tutar.