A/B testi: planı önceden yazılan, sonucu güvenle okunan deney.

Bu A/B testi rehberini, sitesinde ya da uygulamasında yaptığı bir değişikliğin işe yarayıp yaramadığını ölçerek bilmek isteyen pazarlama, ürün ve e-ticaret ekipleri için yazdık. Anlattığımız kurallar Google Search Central, Google Analytics ve Firebase belgelerine, Microsoft’un deney platformu ekibinin (ExP) yayımladığı yazılara, Optimizely’nin yardım merkezine ve ABD Ulusal Standartlar ve Teknoloji Enstitüsü’nün (NIST) istatistik el kitabına dayanıyor; kaynaklar sayfanın altında numaralı olarak listeleniyor. Ürün adlarını ve özellikleri Eylül 2026 itibarıyla kaynaktan doğruladık. Kendi saha gözlemlerimizi “Uzman notu” başlığıyla ayrı işaretledik.

Bir testte işimiz üç katmanda ilerler: hipotezi, ölçütleri ve örneklemi testten önce yazan tasarım; varyantı titremeden ve arama motoru kurallarına uygun biçimde yayına alan uygulama; sonucu p değeri, güven aralığı ve örneklem oranı kontrolüyle okuyan karar.

A/B testi nedir, neyi kanıtlar?

A/B testi, bir sayfanın ya da akışın iki veya daha fazla sürümünü aynı dönemde rastgele bölünmüş ziyaretçilere gösterip hangi sürümün hedef eylemi daha yüksek oranda ürettiğini ölçen kontrollü bir deneydir. Google, A/B testini bir değişikliğin iki ya da daha fazla varyasyonunun sınanması olarak tanımlıyor; örneği, bir düğmenin yazı tipini değiştirip tıklamaların artıp artmadığına bakmaktır.¹ Aynı anda birden çok türde değişikliği sınayıp hem her değişikliğin etkisine hem de değişiklikler arasındaki olası etkileşime bakan deneye ise çok değişkenli test (multivariate test) deniyor.¹ Türkçe aramalarda “ab testi”, İngilizcede “split test” olarak da geçen yöntemin gücü rastgele bölmeden gelir: iki grup arasında değişiklik dışındaki her şey ortalamada benzer olduğu için gözlenen fark değişikliğe bağlanabilir.

Bir A/B testi, ölçülen dönemde ve kitlede iki sürüm arasındaki ortalama farkı kanıtlar; değişikliğin neden işe yaradığını tek başına kanıtlamaz. Test türlerini şöyle ayırıyoruz:

İyi bir test hipotezi ve ölçüt seti nasıl kurulur?

İyi bir hipotez tek bir değişikliği, beklenen etkisini ve bu etkiyi doğrulayacak ya da yanlışlayacak ölçütleri testten önce yazar. Microsoft’un deney platformu ekibi, hipotezin açık ve basit olmasını, karmaşık bir değişikliğin her biri kendi hipotezini taşıyan basit değişikliklere bölünmesini öneriyor.² Aynı yazıya göre hipotez, seçilen ölçütlerle kanıtlanabilir ya da yanlışlanabilir olmalı; markayı güçlendireceği iddia edilen bir değişikliği, markanın etkisini ölçen bir metrik yoksa kanıtlamak da yanlışlamak da zordur.²

Ölçütleri üç gruba ayırıyoruz. Birincil ölçüt kararı veren tek ölçüttür, çoğunlukla satın alma ya da talep gibi bir anahtar etkinlik. Koruyucu ölçütler (guardrail metrics) kazananın başka bir yerde zarar vermediğini gösterir: iade, hata oranı, sayfa yüklenme süresi. Veri kalitesi ölçütleri ise ölçümün kendisinin iki varyantta aynı çalıştığını denetler. Microsoft, kullanıcı memnuniyeti, koruyucu, özellik ve etkileşim ile veri kalitesi ölçütlerinden oluşan çekirdek bir setin, hangi özelliği hedeflerse hedeflesin bir üründeki bütün deneylerde hesaplanmasını öneriyor.² Hipotezin kaynağı çoğunlukla ısı haritası ve oturum kayıtlarındaki bir gözlemdir; bu tarafı Microsoft Clarity sayfamızda anlatıyoruz.

Örneklem ve test süresi neden testten önce sabitlenir?

Örneklem ve süre testten önce sabitlenir, çünkü sabit ufuklu (fixed horizon) bir testte sonuç ancak planlanan örneklem dolduğunda ve tek sefer okunduğunda geçerlidir. Optimizely, bu yöntemde örneklemin testten önce hesaplanması gerektiğini, eksik veriye bakıp ona göre hareket etmenin yanlış pozitifleri artırdığını ve deneyi geçersiz kıldığını yazıyor.³ Aynı belge, hafta içi ve hafta sonu farkı gibi davranışları kapsamak için her testin en az bir iş döngüsü, yani yedi gün sürmesini öneriyor.³ Optimizely’nin yöntem karşılaştırmasına göre ardışık (Stats Engine) ve Bayesçi yöntemler bu kısıtı taşımaz: sonuçlar test boyunca izlenebilir, örneklemin önceden hesaplanması gerekmez.¹³ Firebase, tipik bir Remote Config deneyi için önerilen en kısa süreyi iki hafta olarak veriyor; deney verisi başlangıçtan itibaren en çok 90 gün işleniyor.⁴

Varyant başına gereken ziyaretçiyi temel dönüşüm oranı, saptanmak istenen en küçük fark, anlamlılık düzeyi ve istatistiksel güçten hesaplıyoruz; formülü ve trafik yetmediğinde izlenecek yolları CRO danışmanlığı sayfamızda anlattık.

Ziyaretçinin test boyunca aynı sürümü görmesi de tasarımın parçasıdır: Firebase Remote Config deneylerinde atama, varyant ağırlıklarına ve deney kimliği ile kullanıcının Firebase kurulum kimliğinden üretilen bir karmaya (hash) göre yapılır; deneye giren kullanıcı deney sürdükçe aynı varyantta kalır.⁴ Web’de atama çoğunlukla çereze dayanır; Microsoft, çerez tabanlı kimliklerin kararlı olmadığını, çerezini silen kullanıcının sonraki ziyarette öteki varyanta düşebileceğini yazıyor ve bu kimlikleri yalnız kısa süreli deneylerde kullanmayı öneriyor.²

Varyant tarayıcıda mı, sunucuda mı uygulanmalı?

Metin, görsel ve düzen değişikliklerini tarayıcı tarafında, fiyat, ödeme ve arama gibi iş mantığına dokunan değişiklikleri sunucu tarafında uyguluyoruz. Tarayıcı tarafındaki asıl risk, ziyaretçinin özgün sayfayı bir an görmesi, yani titremedir (flicker). Optimizely’ye göre test betiği eşzamansız (asynchronous) yüklendiğinde sayfa yavaşlamaz ama önce özgün sayfa, kısa süre sonra varyant görünebilir; bu titreme sonucu daha az güvenilir kılar ve ziyaretçi deneyimini bozabilir.⁵ Optimizely Web Experimentation bu yüzden titremeyi önlemek için eşzamanlı (synchronous) yüklenen bir kod parçacığı kullanıyor.⁵ Bunun da bedeli var: tarayıcı, head bölümündeki eşzamanlı kaynaklar yüklenene kadar normalde sayfayı boş gösterir.⁵

Google Optimize kapandıktan sonra sonuçlar GA4’te nasıl okunur?

Google Optimize kapandıktan sonra web testleri GA4 ile entegre üçüncü taraf bir araçta yürütülüyor; sonuçlar GA4’te varyant kitleleri ve Experience-variant ID boyutuyla okunabiliyor. Optimize ve Optimize 360, 30 Eylül 2023’ten beri kullanılamıyor; Google, AB Tasty, Optimizely ve VWO ile entegrasyonlar üzerinde çalıştığını ve herkesin kendi test aracını Google Analytics’e bağlayabilmesi için API’lerini herkese açtığını duyurdu.⁶ Deney başladığında GA4 her varyant için bir kitle oluşturur ve deney bitince bu kitleleri siler; varyant verisi ise Keşifler’de (Explore) ve BigQuery’de Experience-variant ID boyutuyla erişilebilir kalır.⁷

Deney bittiğinde veri BigQuery’ye aktarılabilir; istatistiksel çıkarım test aracında ya da BigQuery üzerindeki ayrı bir sorguyla yapılabilir.⁷ Firebase A/B Testing ise uygulamalar için sürüyor; 23 Ekim 2023 ve sonrasında başlatılan deneyler Optimize altyapısına dayanmıyor ve frekansçı (frequentist) çıkarım kullanıyor.⁶ Firebase A/B Testing’in ayrı bir BigQuery tablosu yoktur; deney ve varyant üyeliği Analytics olay tablolarında her olaya kullanıcı özelliği olarak yazılır ve deney verisi bu özelliklerle BigQuery’de çıkarılabilir.⁴

A/B testi Google Arama sıralamasını etkiler mi?

Küçük değişiklikleri kurallara uygun biçimde sınayan bir A/B testi, Google Arama sıralamasını çoğu zaman az etkiler ya da hiç etkilemez; Google, düğme boyutu, rengi ya da eylem çağrısı metni gibi küçük değişikliklerin arama sonucu parçacığına ve sıralamaya çoğu zaman az etki ettiğini ya da hiç etki etmediğini yazıyor.¹ Risk, kurulum biçimindedir; Google’ın test sırasında önerdiği uygulamalar şunlar:¹

• Gizleme (cloaking) yok: Googlebot’a bir URL seti, insanlara başka bir set gösterilmez; sunucu mantığıyla ya da robots.txt ile yapılsa da spam politikalarına aykırıdır ve sitenin sıralamada düşürülmesine ya da sonuçlardan çıkarılmasına yol açabilir.
• rel=”canonical”: ayrı URL’li testlerde bütün varyant adresleri özgün adresi kanonik olarak gösterir; Google bu durumda noindex yerine kanonik bağlantıyı öneriyor.
• 302 yönlendirme: özgün adresten varyanta yönlendirmede kalıcı 301 değil, geçici 302 kullanılır; JavaScript ile yapılan yönlendirme de kabul ediliyor.
• Çerez: Googlebot genellikle çerez desteklemez; test çerezle yönetiliyorsa Googlebot, çerez kabul etmeyen tarayıcıların gördüğü sürümü görür.
• Süre: test gerektiği kadar sürer; bitince kazanan sürüm siteye işlenir, varyant adresleri, test betikleri ve işaretlemesi en kısa sürede kaldırılır.

Google, gereksiz uzun süren bir deneyi, özellikle tek bir varyant kullanıcıların büyük bölümüne gösteriliyorsa, arama motorlarını yanıltma girişimi olarak yorumlayıp işlem yapabileceğini belirtiyor.¹

A/A testi neyi doğrular?

A/A testi, iki özdeş sürümü karşılaştırarak test aracının, rastgele atamanın ve ölçümün doğru çalıştığını doğrular; gerçek bir değişiklik olmadığı için beklenen sonuç “fark yok”tur. Optimizely A/A testini kalibrasyon testi olarak da adlandırıyor ve deney yapılandırmasını doğrulayan bir veri güvenilirliği ve kalite güvencesi adımı olarak tanımlıyor.⁸ Aynı belgeye göre A/A sonuçlarının çoğu istatistiksel olarak sonuçsuz çıkmalıdır; ama anlamlılık bir olasılıktır, kesinlik değildir ve özdeş sürümler arasında da rastlantısal bir fark görülebilir.⁸

Bu olasılığın büyüklüğünü anlamlılık düzeyi belirler. Firebase’in tanımıyla p değeri, gerçekte fark yokken en az gözlenen kadar büyük bir farkın yalnız rastlantıyla oluşma olasılığıdır ve 0,05’in altındaki p değeri anlamlı sayılır.⁴ Buna göre 0,05 düzeyinde yürütülen ve planlanan örneklemde bir kez okunan A/A testlerinin yaklaşık %5’inde, kurulum doğru olsa bile “anlamlı” sonuç çıkması beklenir; tek bir anlamlı A/A sonucunu hata kanıtı saymıyor, incelenecek bir işaret olarak ele alıyoruz.

Anlamlılık ve güven aralığı nasıl okunur?

İki dönüşüm oranı arasındaki farkın rastlantıyla açıklanıp açıklanamayacağına iki oran z testiyle bakıyor, farkın olası büyüklüğünü ise güven aralığıyla raporluyoruz. NIST/SEMATECH istatistik el kitabı, örneklemler yeterince büyük olduğunda iki oranın eşitliğinin, binom dağılımına normal yaklaşımla kurulan bir z istatistiğiyle sınanabileceğini yazıyor:⁹

El kitabı, küçük örneklemler için Fisher kesin olasılık testini iyi bir seçenek olarak gösteriyor.⁹ Firebase A/B Testing de dönüşüm gibi ikili ölçütlerde oran z testi, gelir gibi sürekli ölçütlerde eşit olmayan varyanslı t testi kullanıyor ve p değerlerini, varyantın temel sürümden büyük olduğu yöndeki tek yönlü teste göre hesaplıyor.⁴ Optimizely’nin sabit ufuk yöntemi ise göreli farkı sınıyor ve p değerini iki yönlü hesaplıyor.³ Bu yüzden iki araç aynı veriye farklı p değeri gösterebilir.

Firebase fark için %95 güven aralığı gösterir; aralık sıfırı içeriyorsa varyant ile temel sürüm arasında anlamlı bir fark saptanmamıştır.⁴ Bu sayfadaki hesaplayıcı da iki varyantın ziyaret ve dönüşüm sayısından göreli farkı, iki oran z testinin p değerini ve %95 güven aralığını verir. Birden çok varyant aynı temel sürümle karşılaştırılıyorsa her karşılaştırma yeni bir yanlış pozitif fırsatıdır; Optimizely, bu çoklu karşılaştırma sorununun yanlış pozitif keşiflerin denetlenmesini gerektirdiğini yazıyor.³

Örneklem oranı uyumsuzluğu (SRM) nasıl yakalanır?

Örneklem oranı uyumsuzluğu (sample ratio mismatch, SRM), varyantlara düşen ziyaretçi sayısının testte ayarlanan orandan istatistiksel olarak anlamlı biçimde sapmasıdır; bu sapma varsa sonuç okunmadan önce nedeni bulunmalıdır. Microsoft’ta her A/B testi, etkisi analiz edilmeden önce bu kontrolden geçmek zorunda; şirketin 2020’de yayımladığı yazıda aktarılan analize göre A/B testlerinin yaklaşık %6’sında SRM vardı.¹⁰ Microsoft’a göre yalnız orana bakmak yetmez, çünkü oran örneklem büyüklüğünü taşımaz ve ki-kare gibi bir istatistiksel test gerekir; yanlış alarmı azaltmak için kullandığı eşik p < 0,0005’tir.¹⁰

Microsoft, SRM nedenlerini deneyin aşamalarına göre şöyle sınıflandırıyor:¹⁰

Microsoft’un aktardığı bir MSN testinde, döner alandaki kart sayısını 12’den 16’ya çıkaran varyant etkileşimi düşürmüş göründü ve SRM uyarısı verdi; varyantla çok etkileşen kullanıcıları bir bot algılama algoritması analizden çıkarmıştı, sorun giderilince sonuç tersine döndü.¹⁰ Eksik kullanıcılar nadiren rastgele bir gruptur; çoğu zaman değişiklikten en çok etkilenenlerdir.¹⁰

Kazanan nasıl yayına alınır, ilk 30 gün nasıl ilerler?

Kazanan üç koşul birlikte sağlandığında yayına alınır: birincil ölçütte anlamlı fark, bozulmayan koruyucu ölçütler ve güven aralığının alt ucundaki olası kaybın kabul edilebilir olması. Firebase de öndeki varyantı yalnız birincil hedefe göre belirlediği için yayından önce ikincil ölçütlere, beklenen kazanca ve güven aralığının alt ucu gibi aşağı yönlü riske bakılmasını öneriyor.⁴ Microsoft karar öncesinde her varyanttaki kullanıcı sayısının beklenen trafik payına uyup uymadığına ve değişikliğin ölçütlerde beklenen izi bırakıp bırakmadığına bakıyor; sayfaya içerik ekleyen bir varyantta sayfa boyutunun ve yüklenme süresinin buna uygun değişmesi gibi.¹² Kazananı test aracında bırakmıyor, sitenin koduna işliyor; varyant adreslerini ve test betiklerini kaldırıyoruz.¹

İlk 30 gün şu sırayla ilerler:

1. 1. hafta · Ölçüm ve araç: ölçüt olayları, GA4 bağlantısı ve BigQuery dışa aktarımı denetlenir; gerekirse A/A testi başlar.
2. 2. hafta · Hipotez sırası: hipotez kayıtları yazılır, örneklem ve süre hesaplanır; trafiğin yetmediği hipotezler ayrılır.
3. 3. hafta · Uygulama: ilk varyant kurulur; titreme, hız ve Google Arama kuralları yayından önce kontrol edilir.
4. 4. hafta · Yayın ve izleme: test yayına alınır, ilk günlerde SRM kontrolü yapılır; sonuç ancak planlanan örneklem ve süre dolunca okunur.

Bir test ortağıyla çalışmaya başlamadan önce dört sorunun yanıtını netleştirmek işe yarar: kararı hangi ölçüt veriyor, örneklem testten önce nasıl hesaplanıyor, SRM kontrolü yapılıyor mu, kaybeden testler nasıl raporlanıyor. Sitenizde hangi değişikliğin önce sınanacağını birlikte konuşmak isterseniz aşağıdan size uygun bir görüşme günü seçebilirsiniz.