Rehber
A/B testinde örneklem büyüklüğü ve anlamlılık nasıl hesaplanır?
A/B testinde örneklem büyüklüğü dört girdiyle test başlamadan hesaplanır. Formül, varsayımsal bir örnek, erken bakmanın bedeli ve sonucu okumadan önce yapılacak kontroller.
A/B testinde örneklem büyüklüğü, iki sürüm arasındaki belirli bir farkı yeterli olasılıkla yakalamak için her sürüme girmesi gereken kullanıcı sayısıdır. Test başlamadan dört girdiyle hesaplanır: mevcut dönüşüm oranı, yakalamak istediğiniz en küçük etki, anlamlılık düzeyi ve istatistiksel güç. Anlamlılık ise ancak bu sayıya ulaşıldığında ve önceden belirlenen eşikle okunur.
Hesap için hangi dört girdiye ihtiyacınız var?
- Taban oran. Kontrol sürümünün bugünkü dönüşüm oranı. Test edeceğiniz sayfa ve kitle için son birkaç haftanın verisinden alın.
- En küçük yakalanabilir etki (MDE, minimum detectable effect). GrowthBook belgesi bunu, metriğin varyansı ve örneklem büyüklüğü verildiğinde gücün en az %80 olduğu en küçük etki diye tanımlıyor. Mutlak (3,0'dan 3,3 puana) ya da göreli (%10 artış) yazılabilir; hangisini kullandığınızı her yerde belirtin.
- Anlamlılık düzeyi (α). Evan Miller'ın hesaplayıcısı bunu, gerçekte fark yokken fark bulunan durumların yüzdesi olarak tanımlar. GrowthBook belgeleri nominal düzey olarak %5'i kullanır.
- Güç (1-β). Aynı hesaplayıcıya göre, etki gerçekten varsa en küçük etkinin yakalandığı durumların yüzdesidir. GrowthBook MDE'yi %80 güce göre hesaplar.
Girdiler arasındaki ilişki sabittir. Daha küçük bir etkiyi, daha düşük bir α ile ya da daha yüksek güçle yakalamak istiyorsanız daha çok kullanıcı gerekir. Taban oran da hesabı değiştirir: Düşük oranlı bir metrik, aynı göreli etki için daha büyük örneklem ister. GrowthBook'un önerisi açıktır: Güç analizini deney başlamadan yapın, çünkü testin ne kadar süreceğini o belirler.
Örneklem büyüklüğü nasıl hesaplanır?
Hızlı tahmin için Evan Miller'ın pratik kuralı iş görür: n = 16 × σ² / δ². Burada δ yakalamak istediğiniz en küçük farktır, σ² beklenen varyanstır. Dönüşüm oranı gibi bir oran ölçüyorsanız varyans p × (1 - p) olur.
Varsayımsal örnek: Ödeme sayfanızın dönüşüm oranı %3 ve %10'luk göreli bir artışı, yani 3,0'dan 3,3'e çıkışı yakalamak istiyorsunuz. δ = 0,003 ve σ² = 0,03 × 0,97 = 0,0291 olur. Buradan n = 16 × 0,0291 / 0,000009, yani yaklaşık 51.700 çıkar. Bu sayı sürüm başınadır; Evan Miller'ın hesaplayıcısı da sonucu sürüm başına raporlar. İki sürümlü testte toplam ihtiyaç yaklaşık 103.000 ziyaretçidir. Sayfa günde 2.000 ziyaretçi alıyorsa test yaklaşık 52 gün sürer; hafta içi ve hafta sonu davranışını dengelemek için bunu sekiz haftaya yuvarlamak mantıklıdır.
Bu sonuç çoğu ekibi şaşırtır ve formülün asıl dersini gösterir: δ'nin karesi paydadadır. Yakalamak istediğiniz farkı yarıya indirirseniz gereken örneklem dört katına çıkar. Düşük trafikli sayfada küçük ince ayarlar yerine daha belirgin değişiklikleri sınamak bu yüzden daha gerçekçidir. Hangi fikrin önce sınanacağını CRO test önceliklendirme yöntemleriyle belirleyebilirsiniz.
Daha kesin hesap için NIST/SEMATECH istatistik el kitabı oranlara ait formülü verir: z değerleri anlamlılık ve güçten, p0 ve p1 iki orandan gelir, δ aralarındaki farktır. El kitabının örneğinde p0 = 0,10 ve p1 = 0,20 alınıyor, tek yönlü %5 anlamlılık ve %10 kaçırma riskiyle yaklaşık 102 gözlem çıkıyor. Süreklilik düzeltmesiyle sayı 112'ye yükseliyor. Bu örnek tek bir oranı hedef bir değerle karşılaştırır; iki sürümü karşılaştıran testte iki örneklemli biçim kullanılır. Pratikte hesabı bir hesaplayıcıya ya da test aracınızın güç analizine bırakın, ama girdileri siz seçin.
Testi adım adım kurun
- Birincil metriği ve birimi yazın. Tek bir başarı metriği seçin. Birim genellikle kullanıcıdır, oturum değil.
- Taban oranı ölçün. Aynı sayfa ve kitle için son haftaların verisini kullanın.
- MDE'yi iş değerine göre belirleyin. "Bu farkı yakalamak testin maliyetine değer mi?" sorusunu yanıtlayın.
- Örneklemi ve süreyi hesaplayın. Sonucu günlük trafiğe bölün ve tam haftaya yuvarlayın.
- Atamayı rastgele ve sabit tutun. Kullanıcı test boyunca aynı sürümü görsün. Bölme oranını testin ortasında değiştirmeyin.
- Bakma kuralını önceden yazın. Ya hesaplanan örnekleme ulaşana kadar karar vermeyin ya da sıralı test kullanın.
- Bitişte önce veri kalitesine bakın. Örneklem oranı uyuşmazlığını kontrol edin, sonra anlamlılığı.
- Sonucu aralıkla raporlayın. Tek bir "kazandı" yerine etkinin güven aralığını ve iş etkisini yazın.
Sonuca erken bakmak neden yanıltır?
Anlamlılık hesabı, örneklem büyüklüğünün önceden sabitlendiğini varsayar. Sonuca her gün bakıp eşik geçildiği ilk anda testi durdurmak bu varsayımı bozar. Evan Miller'ın örneğinde gerçekte hiçbir etkisi olmayan bir değişiklik, her gözlemden sonra %5 düzeyinde sınanıp anlamlı çıktığı anda ya da 150 gözlemde durdurulduğunda yanlış pozitif oranı %26,1'e çıkıyor. Bu, kâğıt üzerindeki düzeyin beş katından fazladır. Yazar bunu en kötü senaryo olarak niteliyor, ama yön değişmez: Ne kadar sık bakar ve erken durursanız o kadar çok sahte kazanan bulursunuz.
İki çıkış yolu var. Birincisi, hesapladığınız örnekleme ulaşmadan karar vermemek. İkincisi, ara bakışa izin veren bir yöntem kullanmak. GrowthBook'un sıralı test belgesi, erken bakmanın yanlış pozitif oranını nominal %5 düzeyinin çok üstüne taşıdığını yazıyor ve sıralı testi, sonuçlara istediğiniz kadar bakarken yanlış pozitifleri beklenen oranın altında tutmanın yolu olarak anlatıyor. Bedelini de belirtiyor: Sıralı test, sabit örneklemli teste göre daha geniş güven aralıkları üretir. Belgeye göre özellik yalnız frekansçı (frequentist) istatistik motorunda var. Hangi yolu seçtiğinizi test başlamadan yazın.
Sonucu okumadan önce neyi kontrol etmelisiniz?
İlk kontrol örneklem oranı uyuşmazlığıdır (SRM, sample ratio mismatch). Trafiği eşit böldüğünüz halde sürümlerdeki kullanıcı sayısı bu orandan anlamlı biçimde sapıyorsa veri bozuktur. Microsoft Research'ün yazısına göre Microsoft'ta A/B testlerinin yaklaşık %6'sında SRM görülüyor. Tespit için ki-kare testi kullanılıyor ve Microsoft temkinli bir eşik olarak p değerinin 0,0005'in altında olmasını esas alıyor. Yazıda sayılan nedenler arasında yalnız bir sürümde yapılan yönlendirme, hatalı kullanıcı kimlikleri, sürümlerin dengesiz açılması ve analizde taraflı filtreler var.
Varsayımsal örnek: Eşit bölünmüş bir testte kontrol 50.000, değişiklik 48.800 kullanıcı aldı. Fark küçük görünür, ama ki-kare değeri yaklaşık 14,6 ve p değeri yaklaşık 0,0001'dir. Bu, Microsoft'un eşiğinin altında kalır. Dönüşüm farkı ne olursa olsun önce sapmanın nedeni bulunmalıdır.
SRM temizse sonucu okuyun. p değeri eşiğin altındaysa farkı rastlantıyla açıklamak zordur, ama bu farkın büyük ya da iş için önemli olduğu anlamına gelmez. Bu yüzden etkiyi güven aralığıyla birlikte raporlayın. Dar ve tamamen sıfırın üstünde kalan bir aralık ile sıfıra dayanan geniş bir aralık aynı kararı desteklemez. Reklam kreatiflerinde aynı mantığın nasıl uygulandığını kreatif testi yazısında bulabilirsiniz.
Sık yapılan hatalar
- Örneklemi sonradan seçmek. "Anlamlı çıkınca durdururuz" bir plan değildir.
- Haftayı bölmek. Hafta içi ile hafta sonu davranışı farklıysa üç günlük test bir dönemi değil bir anı ölçer.
- Çok metriğe bakıp kazanan seçmek. Yirmi metriğe bakarsanız biri tesadüfen eşiği geçebilir. Birincil metriği önceden yazın.
- SRM'yi atlamak. Bozuk bölmeyle elde edilen kazanç gerçek bir kazanç değildir.
- Düşük trafikte küçük etki aramak. Hesap aylar sürecek bir test gösteriyorsa daha belirgin bir değişiklik ya da nitel araştırma seçin.
- Kazananı aralıksız ilan etmek. Tek sayı belirsizliği gizler ve beklentiyi şişirir.
Bir sonraki testten önce test kartı hazırlayın
Bir sonraki A/B testinize başlamadan önce tek sayfalık bir kart doldurun: birincil metrik, taban oran, MDE, anlamlılık düzeyi, güç, sürüm başına örneklem, beklenen süre ve bakma kuralı. Sayıları bir hesaplayıcıyla bulun ve kartı testi onaylayacak kişiyle paylaşın. Süre makul değilse testi başlatmadan MDE'yi ya da sayfayı değiştirin. Test bittiğinde önce SRM'ye, sonra sonuca bakın ve kararı aynı karta yazın. Bu kartı deney altyapınıza bağlamak isterseniz growth engineering sayfası ölçüm ve deney tarafının nasıl kurulduğunu anlatır.