A/B testi nedir? Kapsamlı uygulama rehberi

A/B testi, bir deneyimin iki sürümünü aynı dönemde farklı kullanıcılara rastgele gösterip önceden seçilmiş bir ölçüte göre karşılaştırma yöntemidir. A mevcut sürümü, B ise değişikliği içeren varyantı temsil eder. Amaç yalnızca daha yüksek görünen sayıyı seçmek değildir; değişikliğin gerçekten fark yaratıp yaratmadığını, bu farkın ne kadar belirsiz olduğunu ve iş hedefi açısından anlamlı olup olmadığını değerlendirmektir.

Bir başlık, fiyat sunumu, kayıt akışı, e-posta konu satırı veya ürün özelliği test edilebilir. Güvenilir bir test için hipotez, hedef metrik, kullanıcıların hangi birime göre rastgele atanacağı, gereken örneklem ve karar kuralı sonuçları görmeden belirlenir. Bu koşullar yoksa test, kontrollü deneyden çok sonradan yorumlanan bir karşılaştırmaya dönüşür.

A/B testi, kullanıcıları kontrol ve varyant gruplarına rastgele atayan bir çevrimiçi kontrollü deney tasarımıdır. A grubuna mevcut deneyim, B grubuna değiştirilmiş deneyim gösterilir. Atama test süresince tutarlı kalmalıdır; aynı kişi farklı oturumlarda iki farklı sürümü görürse ölçüm kirlenebilir. Gruplar aynı zaman aralığında çalıştığından kampanya, hafta içi/hafta sonu ve mevsim gibi dış koşulların etkisi iki kola daha dengeli dağılır.

Örneğin bir e-ticaret sitesinde ödeme sayfasındaki teslimat bilgisinin daha erken gösterilmesinin sipariş tamamlama oranını artırıp artırmadığını merak edebilirsiniz. A sürümü mevcut ödeme sayfası, B sürümü teslimat bilgisini daha yukarı taşıyan sayfa olur. Kullanıcıları aynı anda iki sürüme rastgele dağıtır, sipariş tamamlama oranını ana metrik olarak izlersiniz. Bu örnek varsayımsaldır; gerçek bir müşteri sonucu veya beklenen artış iddiası değildir.

A/B testi “önce” ve “sonra” sonuçlarını karşılaştırmakla aynı şey değildir. Yeni tasarımın bu haftaki performansını geçen ayın performansıyla kıyaslamak, aynı anda gerçekleşen kampanya, trafik kaynağı veya talep değişimini ayıramaz. Rastgele atama ve eşzamanlı kontrol grubu bu karıştırıcı etkenleri azaltır. Bu sayede farkın test edilen değişiklikle ilişkisini daha güvenilir biçimde tahmin edebilirsiniz; yine de ölçüm hataları ve yanlış uygulama olasılığı ortadan kalkmaz.

A/B testini benzer görünen yöntemlerden ayırmak için tabloya bakın. Fark, sadece kaç seçenek gösterildiğinde değil, hangi soruya cevap arandığında ve kullanıcıların nasıl dağıtıldığında da ortaya çıkar. Bu ayrımı erken yapmak, yanlış yöntemle cevap aramayı ve sonuçları hatalı yorumlamayı önler. Tasarımı baştan netleştirin.

Yöntem | Ne karşılaştırılır? | Ne zaman uygundur? | Temel sınır

A/B testi | Kontrol ve bir varyant | Tek bir değişiklik hakkındaki hipotez | Test dışı değişiklikler sonucu etkileyebilir

A/B/n testi | Kontrol ve birden fazla varyant | Birkaç önceden tanımlı alternatifi kıyaslamak | Her kola daha az trafik ve daha çok karşılaştırma düşer

Çok değişkenli test | Birden fazla öğenin kombinasyonları | Etkileşimleri de anlamak için yeterli trafik varsa | Kombinasyon sayısı hızla büyür

Önce-sonra kıyası | Farklı dönemlerdeki sonuçlar | İzleme veya keşif amaçlı kaba karşılaştırma | Nedensel etkiyi tek başına göstermez

Çok kollu haydut | Trafiğin zaman içinde performansa göre dağılımı | Uzun süreli dağıtım optimizasyonu | Klasik deneyle aynı tahmin hedefini sağlamayabilir

Tablo yöntem seçimini kolaylaştırır, ancak isimler aracı sağlayıcıya göre farklılaşabilir. Özellikle haydut algoritmaları trafiği daha iyi performans gösteren seçeneklere kaydırabilir; bu yaklaşım sürekli dağıtım optimizasyonu için kullanışlı olabilir. Bir varyantın ne kadar etkili olduğunu tarafsız biçimde tahmin etmeniz gerekiyorsa, test tasarımının bu hedefe uygun olup olmadığını istatistik ekibiyle netleştirin.

Test yapmaya, belirli bir kullanıcı sorunu veya iş hedefi olduğunda başlayın. Örneğin ziyaretçiler ürün sayfasını görüntülüyor ancak sepete ekleme adımına geçmiyorsa, davranış verisi ve kullanıcı araştırması olası nedeni gösterebilir. Test, bu bulgulardan çıkan somut bir değişiklik hipotezini değerlendirebilir. “Buton daha dikkat çekici olsun” gibi gerekçesiz bir fikir yerine, hangi engelin değişeceğini ve bu değişikliğin hangi davranışı etkilemesini beklediğinizi tanımlayın.

Her karar A/B testi gerektirmez. Trafiği düşük bir sayfada küçük farkları ölçmek çok uzun sürebilir; mevzuat, erişilebilirlik veya açık hata düzeltmeleri de deneyle ertelenmemelidir. Kullanılabilirlik testi, müşteri görüşmesi, oturum kaydı veya analitik inceleme önce yapılabilir. Bu yöntemler sorunun ne olduğunu anlamaya yardım eder; fakat rastgele atanmış bir kontrollü deneyin sunduğu nedensel kanıtın yerine geçmez.

Testin beklenen değeri, gerekli kaynak ve süreyle karşılaştırılmalıdır. Büyük bir ödeme akışını yeniden geliştirmek pahalıysa uygulamadan önce daha güçlü kanıt isteyebilirsiniz. Buna karşılık küçük bir e-posta başlığı değişikliğinin etkisi sınırlı maliyetle ölçülebilir. Önceliklendirme için kullanıcı etkisini, fırsatın büyüklüğünü, kanıtın gücünü, uygulama maliyetini ve testin ulaşabileceği örneklem hacmini birlikte düşünün.

İyi bir testin sırası nettir: sorunu tanımlayın, ölçümü doğrulayın, hipotezi ve karar ölçütlerini önceden yazın, sonra varyantı uygulayıp sonuçları planınıza göre değerlendirin. Aşağıdaki adımlar, pazarlama sayfasından ürün içi akışa kadar farklı kullanım alanlarına uyarlanabilir. Her adımda sorumlu kişi ve doğrulanabilir tamamlanma ölçütü belirlemek, testin yalnızca bir araç ekranında kurulup unutulmasını önler.

1. **Soruyu seçin.** Analitik, arama, destek veya araştırma verisinde tekrarlanan bir sürtünme bulun. Sorunu belirli bir sayfaya, segmente veya akış adımına bağlayın.
2. **Hipotezi yazın.** “X kullanıcısı Y sorununu yaşıyor. Z değişikliği, M metriğini şu yönde değiştirebilir; çünkü…” formatını kullanın. Gerekçeyi mevcut veriye dayandırın.
3. **Tek birincil metrik belirleyin.** Başarıyı hangi kullanıcı davranışının temsil edeceğini ve olayın nasıl sayılacağını tanımlayın. Birincil metriği sonuçları gördükten sonra değiştirmeyin.
4. **Koruyucu metrikleri ekleyin.** Örneğin sipariş artarken iade, hata, yükleme süresi veya ortalama sipariş değeri kötüleşiyor mu kontrol edin. Koruyucular ana başarı ölçütünün yerini almaz.
5. **Tasarımı ve atama birimini seçin.** Rastgeleleştirme ziyaretçi, kullanıcı, hesap veya oturum düzeyinde olabilir. Aynı birimin deney boyunca aynı varyantta kalması gerektiğini belirleyin.
6. **Örneklemi ve durdurma kuralını hesaplayın.** Başlangıç oranı, anlamlı bulacağınız en küçük etki ve istatistiksel ayarlar gereklidir. Aracın test türüne uygun bir hesaplama yöntemi kullandığını doğrulayın.
7. **Uygulamayı kalite kontrolünden geçirin.** Varyantları masaüstü ve mobilde açın; olayları, para birimini, yönlendirmeleri, kullanıcı atamasını ve raporlamayı küçük bir A/A veya test trafiğiyle kontrol edin.
8. **Sonucu ve öğrenimi kaydedin.** Farkın yönünü ve belirsizliğini, koruyucu metrikleri, kararın gerekçesini, tarihleri ve sonraki adımı deney arşivine ekleyin.

Adımlar, hipotez formatının tek doğru şablon olduğu anlamına gelmez. Amaç, ekipteki kişilerin aynı soruyu, metriği ve başarı koşulunu anlamasını sağlamaktır. Değişiklik farklı cihazlarda veya kullanıcı gruplarında farklı çalışabilecekse bu etkileşimi önceden düşünün. Çok sayıda sonradan seçilmiş alt grubu incelemek, tesadüfen ilginç görünen sonuçlar bulma riskini artırır.

Hipotez gözlenebilir olmalıdır. “Yeni tasarım daha modern görünecek” öznel kalır; “ürün sayfasında teslimat süresini CTA yakınında göstermek, satın alma öncesi belirsizliği azaltarak ziyaretçi başına tamamlanan siparişleri artırabilir” test edilebilir bir öngörüdür. Sonuçta bu tahminin doğrulanmaması da yararlı olabilir: varsayılan engelin davranışı açıklamadığını öğrenir ve sonraki çalışmayı yeniden yönlendirirsiniz.

Ana metrik, test edilen değişikliğin kullanıcıya sağladığı değere yakın olmalıdır. E-posta konu satırında açılma oranı erken bir sinyal olabilir; eğer amaç satışsa, tıklama veya gelir metriğini de izlemek gerekir. Tıklama artarken nitelikli kayıt azalabilir. Bu nedenle metrikleri huni boyunca düşünün: ilk tepki, sonraki davranış ve mümkünse iş sonucu. Ölçüm penceresini ve uygun payda tanımını önceden belirleyin.

Metrik seçerken bir kullanıcıyı birden fazla kez sayıp saymayacağınızı açıklayın. Dönüşüm oranı çoğu zaman dönüşüm yapan benzersiz kullanıcı sayısının uygun kullanıcı sayısına bölünmesiyle ifade edilir, ancak platformlar farklı paydalar kullanabilir. Oturum, kullanıcı ve gösterim bazlı oranlar birbirinin yerine geçmez. Ekip, araç raporuyla finans veya analitik raporundaki sayıların neden farklı olduğunu anlayacak bir tanıma sahip olmalıdır.

Gerekli örneklem tek bir evrensel sayı değildir. Başlangıç dönüşüm oranı, tespit etmek istediğiniz minimum etki, seçilen hata toleransı, istatistiksel güç ve varyant sayısı örneklem ihtiyacını etkiler. Daha küçük bir farkı yakalamak için genellikle daha fazla gözlem gerekir. Aracın size verdiği tahmini, bu girdilerin ve seçilen istatistiksel yaklaşımın sonucu olarak okuyun; “her test için 1.000 ziyaretçi yeterlidir” gibi genel kurallara dayanmayın.

Minimum tespit edilebilir etki (MDE), bir testte iş açısından anlamlı bulduğunuz en küçük farktır. MDE'yi çok küçük seçmek örneklem ihtiyacını ve süreyi artırabilir; çok büyük seçmek önemli ama daha sınırlı iyileşmeleri gözden kaçırabilir. MDE'yi yalnızca mevcut trafikte test daha çabuk bitsin diye seçmeyin. Geliştirme maliyeti, kullanıcı etkisi ve kararın değeri ile birlikte değerlendirin.

Örneklem hesabında başlangıç oranının hangi döneme ve kullanıcı grubuna ait olduğunu kontrol edin. Kampanya, fiyat değişimi, ürün karması veya mevsimsellik bu oranı değiştirebilir. Atama oranı 50/50 değilse her varyantın alacağı trafik farklı olur. Üç veya daha fazla varyant eklemek de her bir kolun daha yavaş veri toplamasına yol açabilir. Bu nedenle daha çok seçeneğin otomatik olarak daha iyi öğrenme getirdiğini varsaymayın.

Süreyi yalnızca takvim gününe göre belirlemeyin. Testin örneklem hedefini karşılaması ve iş döngünüzde önemli olan günleri içermesi gerekir. Talep hafta içi ve hafta sonu değişiyorsa, her iki örüntüyü de gözlemleyecek plan yapın. Sezonluk kampanya, ödeme günü veya stok durumu da sonuçları etkileyebilir. Önceden belirlenen süreye ulaştığınızda örneklem yetersizse, yalnızca sonuçları beğendiğiniz için testi kapatmayın; uzatma kararını planlanan kurala göre verin.

Önce veri kalitesini kontrol edin. Varyantların atama oranları beklenen dağılımdan anlamlı biçimde sapıyorsa örnek oranı uyumsuzluğu (sample ratio mismatch, SRM) olabilir. Bu durum yanlış tetiklenen olay, yönlendirme problemi, cihaz filtresi, bot trafiği veya kullanıcıların varyantlar arasında geçiş yapması gibi sorunlara işaret edebilir. Sorun çözülmeden sonuca güvenmeyin; Amplitude'ın SRM hata ayıklama rehberi bu kontrolün neden önemli olduğunu açıklar.

Daha sonra etki tahminini, belirsizlik aralığını ve önceden tanımladığınız karar eşiğini birlikte inceleyin. İstatistiksel anlamlılık, seçilen model ve varsayımlar altında gözlenen verinin ne kadar uyumlu olduğunu anlatır; değişikliğin kesin doğru olduğunu veya iş açısından önemli olduğunu kanıtlamaz. Yüzde fark küçükse ama istatistiksel olarak tutarlıysa uygulama maliyeti bu artışı karşılamayabilir. Büyük görünen farkın belirsizlik aralığı genişse daha fazla veri gerekebilir.

Sadece gösterge panelinde renkli “kazanan” etiketi çıkmasına göre karar vermeyin. Test sırasında sonuçlara tekrar tekrar bakmak ve iyi görünen anda durdurmak, kullandığınız yöntem böyle bir karar için tasarlanmadıysa yanlış pozitif olasılığını artırabilir. Sabit örneklemli bir plan yapıyorsanız planlanan örneklem ve durdurma kuralına uyun. Sıralı test kullanıyorsanız, bu yöntemi destekleyen ve tekrar bakışları doğru ele alan analiz altyapısını kullanın. Firebase'in çıkarım açıklaması kullandığı test yaklaşımının platforma özgü olduğunu gösterir; farklı araçların kurallarını birbirine taşımayın.

Aşağıdaki tablo, sonuçları en sık bozan uygulama kararlarını ve düzeltme yönünü bir araya getirir. Amaç bir ekibi kusursuz bir istatistik sürecine zorlamak değil; yanlış sonuç doğurabilecek sorunları test bitmeden görünür kılmaktır. Her ekip bunları test planına ve kendi ölçüm sistemine göre uyarlayabilir.

Hata | Sonuç üzerindeki etkisi | Daha güvenli yaklaşım

Sonuç iyi görünür görünmez testi bitirmek | Yanlış pozitif riskini artırır | Örneklem ve durdurma kuralını baştan belirleyin

Birden çok öğeyi aynı anda değiştirip A/B demek | Hangi değişikliğin etki ettiğini ayıramazsınız | Tek hipotezle başlayın veya etkileşimleri ölçen uygun tasarım kurun

Yalnızca tıklama oranına bakmak | Alt hunideki kalite kaybını kaçırabilirsiniz | Birincil metrik yanında iş ve koruyucu metrikleri izleyin

Atama veya olay ölçümünü test etmemek | Hatalı veri gerçek fark gibi görünebilir | Başlamadan önce varyant ve olay QA'sı yapın

Çok sayıda metrik ve alt grup taramak | Tesadüfi bulgu olasılığı yükselir | Birincil metriği önceden seçin, alt grup analizini sınırlayın

Bu hataların bazıları rapor ekranında hemen görünmez. Örneğin deney kodu yalnızca belirli tarayıcılarda çalışmıyorsa, genel sonuç doğru görünen bir dağılımın altında sistematik veri kaybı bulunabilir. Test öncesi cihaz, tarayıcı, dil ve oturum kontrolleri yapın; test başladıktan sonra alarm ve olay hacmini izleyin. Teknik kontrol listesini olay şeması ve gerçek kullanıcı akışlarıyla eşleştirin.

Bir test iki varyant arasında net fark göstermediğinde “hiçbir şey öğrenmedik” demek zorunda değilsiniz. Aralık, büyük bir olumlu veya olumsuz etkiyi dışlayacak kadar darsa, değişiklik önemli bir etki yaratmamış olabilir. Aralık genişse test kararsızdır; örneklem yetersiz veya ölçüm gürültülü olabilir. Bu iki durumu ayırmak, aynı testi tekrar çalıştırma, daha güçlü bir hipoteze dönme ya da değişikliği terk etme kararını destekler.

Düşük trafik her testi imkânsız yapmaz; hangi büyüklükteki farkı ne kadar sürede ölçebileceğinizi sınırlar. Küçük örneklemle çok küçük etkileri ayırt etmek gerçekçi olmayabilir. Bir testin aylarca sürmesi bekleniyorsa, daha yüksek trafikli bir akışa odaklanın, daha büyük bir tasarım değişikliğini inceleyin veya kullanıcı araştırması gibi başka yöntemlerden yararlanın. Alternatif yöntemler sorunu keşfedebilir; kontrollü deneyle aynı tür kanıtı sunmadıklarını karar notunda belirtin.

Daha yüksek hacimli sayfa veya olayları incelemek, tüm kullanıcı yolculuğunu anlamanın yerine geçmemelidir. Örneğin ürün sayfasındaki sepete ekleme testi daha hızlı sinyal verebilir, ancak satış sonrası iptal ve iade etkisini göstermeyebilir. Kullanıcı başına gelir gibi daha geç oluşan metrikler daha çok süre gerektirebilir. Erken sinyali ana sonuca bağlayan ölçüm planı kurun ve iş sonucuyla uyuşmadığında kısa vadeli artışı başarı diye sunmayın.

Araç seçerken yalnızca görsel editör veya fiyatı karşılaştırmayın. Rastgele atama, kalıcı kullanıcı kimliği, mobil ve web desteği, deney çakışmalarını yönetme, veri dışa aktarma, istatistik yaklaşımı, erişilebilirlik ve performans etkisi de önemlidir. Mevcut analitik yığınınızla hangi olayların paylaşılacağını ve kişisel veri politikalarınıza uyumu kontrol edin. Bir araç, kötü deney tasarımını otomatik olarak doğru hale getirmez.

Google Analytics, tek başına tüm platformlarda test ataması yapan bir A/B test aracı olarak görülmemelidir. Google Analytics yardım belgesi, GA4'te test çalıştırmak için üçüncü taraf deney aracıyla entegrasyon gerektiğini belirtir. Firebase A/B Testing ise Google Analytics olaylarını kullanarak mobil uygulama yapılandırması ve mesajlaşma gibi kullanım alanlarına odaklanır. Aracı seçmeden önce test edeceğiniz kanalı, karar ihtiyacını ve mevcut olay altyapısını eşleştirin.

Her deneyden sonra varyantı yayına almak tek başarı ölçütü değildir. Sonucu hangi kitlede, hangi zaman aralığında, hangi metrik ve varsayımla aldığınızı kaydedin. Test öncesi hipotez, uygulanan değişiklik, dış etkenler, veri kalitesi kontrolleri ve karar gerekçesi arşivde bulunmalıdır. Fark yoksa veya test kararsızsa bunu da kaydedin; başarısız testler sonraki hipotezlerin kalitesini artırabilir.

Sonucu uyguladıktan sonra gerçek iş metriklerini takip edin. Deney ortamındaki etki üretimde farklılaşabilir; trafik karması, performans, teknik uygulama veya kullanıcı davranışı değişebilir. Yayına alma kademeli yapılabiliyorsa hataları ve koruyucu metrikleri izleyin. İyileştirme sürecini dönüşüm ve pazarlama hesaplayıcıları ile temel oranları hesaplayarak destekleyebilir, GEO kontrol listesindeki ölçüm yaklaşımı gibi ilgili analiz içeriklerine geçebilirsiniz.

A/B testi, iş kararını rastgele kullanıcı grupları üzerindeki kontrollü karşılaştırmaya dayandırır. Değerli sonuç; yeterli örneklem, güvenilir ölçüm, önceden tanımlanmış metrik ve makul karar kuralı gerektirir. Testin cevabı yalnızca “B kazandı” olmamalıdır. Hangi değişikliğin hangi koşulda etkili göründüğünü, sonucun ne kadar belirsiz olduğunu ve bu öğrenimin sonraki kararı nasıl değiştireceğini açıklayabilmelisiniz.