A/B testi kaç kullanıcı ister? Trafiğiniz yetmiyorsa ne yapmalısınız?

A/B testinin kaç kullanıcı istediği fikir meselesi değil, hesaplanabilir bir sayıdır. Yüzde 80 güç ve yüzde 5 anlamlılık eşiğiyle çalışan standart kural, her varyant için 16σ²/δ² kullanıcı ister. Dönüşüm oranı yüzde 3 olan bir sitede yüzde 10'luk göreli bir iyileşmeyi, yani 3,0'ı 3,3'e çıkaran bir değişikliği görebilmek için kol başına yaklaşık 52 bin, toplamda 100 binin üzerinde ziyaretçi gerekir. Aylık trafiğiniz bunun altındaysa doğru cevap "testi biraz daha uzun çalıştıralım" değildir. Gücü yetersiz bir test sonucu belirsiz bırakmaz, yanlış yöne götürür ve bunu istatistiksel anlamlılık rozetiyle birlikte yapar.

Gereken kullanıcı sayısını kendiniz hesaplayın

Formül göründüğünden basit: n = 16σ²/δ². Baştaki 16 sabiti (1,96 + 0,84)² × 2 işleminden geliyor. 1,96 yüzde 5 anlamlılık eşiğinin, 0,84 yüzde 80 gücün karşılığı, çarpı iki de iki kolun ayrı ayrı gürültü taşımasından. Dönüşüm gibi ikili bir metrikte varyans σ² = p × (1 − p) ile bulunur. δ ise yakalamak istediğiniz mutlak fark.

Dönüşümü yüzde 3 olan bir site için kol başına gereken kullanıcı sayısı şöyle çıkıyor:

• Yüzde 20 göreli iyileşme (3,0 → 3,6): yaklaşık 12.900
• Yüzde 10 göreli iyileşme (3,0 → 3,3): yaklaşık 51.700
• Yüzde 5 göreli iyileşme (3,0 → 3,15): yaklaşık 207.000
• Yüzde 2 göreli iyileşme (3,0 → 3,06): yaklaşık 1,29 milyon

Asıl dikkat edilecek yer listenin kendisi değil, satırlar arasındaki kat farkı. Gereken örneklem δ'nın karesiyle ters orantılı olduğu için, yakalamak istediğiniz etkiyi yarıya indirdiğinizde gereken trafik dörde katlanır. Trafiği kısa vadede artıramıyorsanız elinizdeki tek gerçek kaldıraç budur: daha büyük değişiklikler test edersiniz. Formülün türevi ve bu bölümdeki örneklerin kaynağı, Kohavi, Deng ve Vermeer'in KDD 2022'de yayımlanan A/B Testing Intuition Busters makalesi.

Gücü yetersiz test belirsiz değil, yanıltıcıdır

Yaygın yanlış, az trafikli bir testin yalnızca "daha az kesin" bir sonuç vereceğini sanmaktır. Olan şey bu değil. Düşük güçte anlamlı çıkan sonuçların önemli bir kısmı tamamen gürültüdür ve araç bunu size kazanan diye gösterir.

Aynı makale şu hesabı veriyor: fikirlerinizin yüzde 10'u gerçekten iyileştirme ise (Booking.com, Google Ads ve Netflix için bildirilen başarı oranı bu civarda), yüzde 80 güçle düzgün kurulmuş testlerde bile anlamlı çıkan sonuçların yüzde 22'si yanlış pozitiftir. Güç yüzde 20'ye indiğinde oran yüzde 52,9'a çıkar. Kazandı dediğiniz testlerin yarısından fazlası aslında hiçbir şeydir.

Daha kötü bir ihtimal daha var. Gelman ve Carlin'in gösterdiği gibi, güç yüzde 10'un altına düştüğünde etkinin işaretini ters okuma olasılığı yüzde 50'ye yaklaşır. Yani metriği aşağı çeken bir değişikliği, yukarı çekiyor diye yayına alırsınız.

Somut bir örnek. Aralık 2021'de "dönüşümü yüzde 337 artıran tasarım" başlığıyla paylaşılan gerçek bir test var. Kontrol kolunda 82, deney kolunda 75 ziyaretçi, p değeri 0,009, görünür güç yüzde 97. Kulağa sağlam geliyor. Oysa testin yüzde 10'luk bir değişikliği yakalama gücü yüzde 3'tü ve anlamlı sonucun yanlış pozitif olma riski yüzde 63 olarak hesaplandı. Makalenin yazarları Airbnb, Booking, Amazon ve Microsoft'ta koştukları on binlerce testte dönüşümü bu mertebede artıran hiçbir değişikliğe rastlamadıklarını yazıyor. Pratik eşik şu: A/B testi, makul büyüklükteki etkileri ölçmek için en az binlerce, tercihen on binlerce aktif kullanıcı ister.

Trafiğiniz yetmiyorsa beş seçenek

• Küçük rötuşları test etmeyi bırakın. Buton rengi kıyaslaması sizin trafiğinizde asla sonuçlanmaz. Akışın tamamını değiştiren, yüzde 20 mertebesinde etki beklediğiniz işleri test edin. Kol başına 12.900 kullanıcı çoğu orta ölçekli site için ulaşılabilir bir hedef.
• Metriği değişikliğe yaklaştırın. Ödeme sayfasındaki bir düzenlemeyi toplam ciro üzerinden ölçmek yerine, ödeme adımını tamamlama oranı üzerinden ölçün. Varyans düşer, gereken örneklem azalır. Bedeli peşinen kabul edin: yakın metrik iyileşirken iş sonucu yerinde sayabilir.
• Kararı testten ayırın. Ölçemeyeceğiniz değişiklikleri özellik bayraklarıyla kademeli yayına alın. Burada amaç kazancı ölçmek değil zararı sınırlamaktır: yüzde 5 kullanıcıya açarsınız, hata oranına ve destek taleplerine bakarsınız, geri alma düğmesi hazır durur.
• Nitel araştırmaya geçin. Beş ile sekiz kullanıcıyla yapılan moderatörlü oturum "A mı B mi daha çok satar" sorusunu cevaplamaz. "Kullanıcı bu formda neden duruyor" sorusunu bir haftada cevaplar, ki çoğu zaman asıl ihtiyacınız budur.
• Bazı kararları veriyle vermeyin. Ölçülemeyecek kadar küçük farklar için uzun tartışma yapmak, kararın kendisinden pahalıdır. Kararı ucuz ve geri alınabilir tutun, ilerleyin.

Testin ortasına bakıp karar vermek testi bozar

Sonuçlara her gün bakıp "anlamlı oldu mu" diye kontrol etmek ve ilk anlamlı anda durdurmak, yanlış pozitif oranını sessizce şişirir. Evan Miller'ın klasik hesabında, her gözlemden sonra bakılan bir testte gerçek yanılma oranı yüzde 5 değil yüzde 26,1 çıkıyor. On kez bakıyorsanız yüzde 1 sandığınız eşik gerçekte yüzde 5'tir.

İki meşru çözüm var. Ya örneklem büyüklüğünü ve bitiş tarihini önceden belirler, ara sonuçlara karar vermek için bakmazsınız. Ya da bunun için tasarlanmış bir yöntem kullanırsınız: sıralı test ve her an geçerli p değerleri, sürekli bakma ihtimalini istatistiğin içine katar ve bugün çoğu deney aracında açılıp kapanabilen bir seçenektir. Bedava değildir, aynı kesinlik için bir miktar fazladan örneklem ister.

Hangi metriğe bakacağınıza testten önce karar verin

Testin başarı tanımı tek bir karar metriği olmalı ve bu metrik kısa vadede oynatılabilen bir sayı olmamalı. Bing'in kendi örneği iyi bir uyarı: arama sonuçlarının alaka düzeyini düşürmek kısa vadede sorgu sayısını da reklam tıklamasını da artırır. İki metrik birden yükselir, ürün kötüleşir, kullanıcı birkaç ay sonra gider.

Karar metriğinin yanına birkaç koruma metriği koyun. Bunlar iyileşmesini beklemediğiniz ama bozulmasına izin vermeyeceğiniz sayılardır: sayfa açılış süresi, hata oranı, iade talebi, destek bileti sayısı. Hız özellikle önemli, çünkü ölçülebilir bir bedeli var; Bing'de yapılan ölçümde her 100 milisaniyelik gecikme farkı gelirde yüzde 0,6'lık etki yaratıyordu. Core Web Vitals ölçümlerinizi koruma metrikleri listesine ekleyin. Metrik tanımlarında ekip içinde anlaşmazlık varsa testten önce tek bir kayıt kaynağında uzlaşın; sonuç geldikten sonra yapılan tanım tartışması testi tümden çöpe atar.

Sonuca güvenmeden önce üç kontrol

1. Örneklem oranı uyuşmazlığı (SRM). Dağıtımı 50/50 kurdunuz ama kollarda 821.588 ve 815.482 kullanıcı var. Oran 50,2/49,8, kulağa yakın geliyor. Bu büyüklükte bu farkın tesadüf olma olasılığı 500 binde birin altında. Microsoft'ta yapılan KDD 2019 çalışması deneylerin yaklaşık yüzde 6'sında SRM buldu. SRM varsa sonuç düzeltilmez, geçersiz sayılır ve önce dağıtımdaki hata bulunur.
2. A/A testi. Aracınızı kendisine karşı çalıştırın, iki kola aynı deneyimi verin. Sistem doğru kuruluysa denemelerin yaklaşık yüzde 95'inde anlamlı fark bulmaması gerekir. Microsoft bu basit yöntemle yüzlerce geçersiz deneyi ve hatalı formül kullanımını yakaladı.
3. Bot ve aykırı değer kuralları. Bing'de isteklerin yarısından fazlası botlardan geliyor. Amazon bir testinde kütüphane hesaplarının toplu kitap siparişlerinin sonucu çarpıttığını fark etti. Kural açık: temizlik kuralları testten önce yazılır ve iki kola birebir aynı uygulanır. André'nin 2021 tarihli çalışması, aykırı değer temizliğini her kolda ayrı yapmanın yanlış pozitif oranını yüzde 43'e kadar çıkarabildiğini gösterdi.

Süreyi tam haftalar üzerinden planlayın

Hafta içi kullanıcısı ile hafta sonu kullanıcısı aynı kitle değildir. Bu yüzden test en az bir tam hafta çalışır, uzatılacaksa tam hafta katlarıyla uzatılır. Salı günü anlamlılığa ulaşan test salı günü durdurulmaz.

İkinci sebep yenilik etkisi. Yeni bir şeyi gören kullanıcı ona ilk günlerde fazladan dokunur, sayı şişer, sonra normale döner. Tersi de olur: arayüzü yeniden öğrenmesi gereken yerleşik kullanıcı ilk hafta yavaşlar, sonra toparlar. İlk haftanın rakamı kalıcı etkinin kötü bir tahminidir ve dönen kullanıcıların alışması birkaç haftayı bulabilir. Arayüz değişikliklerinde iki hafta makul bir alt sınır.

Çıkan rakam sizi şaşırttıysa muhtemelen yanlıştır

Deneyimli veri bilimcilerin uyduğu kural Twyman yasasıdır: ilginç ya da farklı görünen her rakam genellikle yanlıştır. Şaşırtıcı sonuç kutlanmaz, tekrarlanır. Aynı test ikinci kez koşulduğunda aynı yönü gösteriyorsa konuşmaya değer.

Beklentiyi doğru kurmak için şu oranlar işe yarıyor. Microsoft genelinde test edilen fikirlerin üçte biri hedefledikleri metriği iyileştiriyor, üçte biri hiçbir şeyi değiştirmiyor, üçte biri zarar veriyor. Bing'de pozitif çıkan deney oranı yüzde 15, Booking.com, Google Ads ve Netflix için bildirilen rakam yüzde 10 civarı, Airbnb aramada yüzde 8. İyi ekipler bile fikirlerinin çoğunda yanılıyor. Harvard Business Review'da anlatılan Bing örneği madalyonun diğer yüzü: 2012'de reklam başlıklarının gösterim biçimini değiştiren basit bir fikir, program yöneticileri düşük öncelikli bulduğu için altı ay bekledi. Test edildiğinde geliri yüzde 12 artırdı ve yıllık karşılığı yalnızca ABD'de 100 milyon doların üzerine çıktı.

Testi başlatmadan önce şunları yazın

Bir sayfalık bir not yeterli. Testten önce yazılır, test sırasında değiştirilmez:

• Hipotez ve değişikliğin tam olarak ne olduğu
• Karar metriği ve koruma metrikleri
• Yakalanmak istenen en küçük etki ve bu büyüklüğün gerekçesi
• Kol başına örneklem ve buna karşılık gelen tahmini bitiş tarihi
• Erken durdurma kuralları, yalnızca zarar durumu için
• Dışlama kuralları: bot, şirket içi IP, aykırı değer eşikleri
• Sonuca kimin, hangi eşikle karar vereceği

Bu notu yazarken gereken örneklemin sizin trafiğinizde üç ay süreceğini görürseniz, testin yapılmayacağını baştan öğrenmiş olursunuz. Bu, üç ay sonra elinizde yanlış pozitif bir kazananla kalmaktan iyidir.