A/B Testi Nedir, Nasıl Planlanır? Hipotez, Trafik ve Sonuç Yorumlama

A/B testi, bir sayfanın veya deneyimin mevcut sürümüyle alternatifini, aynı dönemde rastgele oluşturulmuş kullanıcı gruplarında karşılaştırma yöntemidir. Amaç; bir değişikliğin satın alma, nitelikli başvuru veya başka bir iş sonucunu gerçekten iyileştirip iyileştirmediğini ölçmektir.

Yeni bir tasarımın daha iyi görünmesi, daha fazla satış getireceği anlamına gelmez. Daha yüksek dönüşüm oranı görmek de tek başına yeterli değildir: farkın büyüklüğünü, belirsizliğini, veri kalitesini ve uygulama maliyetini birlikte değerlendirmek gerekir. Bu rehberde bir e-ticaret örneği üzerinden hipotezden yayın kararına kadar test planını kuracağız.

Yazıdaki mağaza, trafik ve sonuç örnekleri yöntemi açıklamak için hazırlanmıştır; gerçek bir müşteri çalışması veya performans vaadi değildir.

A/B testi nedir, nasıl çalışır?

A sürümü kontrol grubudur: bugün kullandığınız deneyimi temsil eder. B sürümü ise etkisini ölçmek istediğiniz değişikliği içerir. Teste uygun kullanıcılar iki gruba rastgele atanır. Her iki grup aynı tarih aralığında izlenir ve önceden seçilmiş başarı metriğiyle karşılaştırılır.

Örneğin bir ürün sayfasında teslimat bilgisi yalnızca açılır bir bölümde bulunuyor olsun. B sürümünde tahmini teslimat aralığını fiyatın altına taşıyabilirsiniz. A ve B kullanıcılarının satın alma oranlarını karşılaştırarak bu görünürlük değişikliğinin etkisini araştırırsınız.

Geçen ayın eski sayfasıyla bu ayın yeni sayfasını karşılaştırmak aynı deney tasarımı değildir. Kampanyalar, trafik kaynakları, fiyatlar ve sezon değişmiş olabilir. Rastgele atama ve eşzamanlı kontrol grubu, bu etkenlerin değişikliğin etkisiyle karışmasını azaltır.

A/B testi, dönüşüm oranı optimizasyonu çalışmalarının bir parçasıdır. Araştırma, ölçüm doğrulama, kullanılabilirlik incelemesi ve açık hataları giderme de bu çalışmanın kapsamındadır.

A/B, yönlendirme ve çok değişkenli test arasındaki fark

A/B testinde mevcut deneyimle bir alternatif karşılaştırılır. İlk çalışmada tek bir açıklanabilir hipoteze odaklanmak, sonucu yorumlamayı kolaylaştırır. Bir hipotez birkaç arayüz değişikliği gerektirebilir; bu durumda ölçtüğünüz etki değişiklik paketinin tamamına aittir.

Yönlendirme testinde kullanıcılar farklı URL’lerdeki sayfalara dağıtılır. Baştan tasarlanmış iki açılış sayfasını karşılaştırmak için kullanılabilir. Deney kimliğinin, varyant atamasının ve dönüşüm takibinin yönlendirme sırasında korunması gerekir.

Çok değişkenli testte başlık, görsel ve teklif gibi birden fazla öğenin kombinasyonları incelenir. Üç başlık ve iki görsel, altı kombinasyon oluşturur. Her kombinasyonun değerlendirilmesi trafik ihtiyacını artırabilir. Sınırlı trafikte çok sayıda seçenek açmak öğrenmeyi yavaşlatır.

A/A testi ise aynı deneyimin iki gruba gösterilmesidir. Atama ve ölçüm altyapısını kontrol etmeye yardımcı olur. Tek bir A/A testinin anlamlı sonuç vermemesi, sistemin bütünüyle hatasız olduğunu kanıtlamaz.

Test edilebilir bir hipotez nasıl kurulur?

İyi bir hipotez gözlenen bir soruna dayanır. “Butonu yeşil yapalım” bir değişiklik önerisidir; kullanıcı davranışını neden etkilemesini beklediğinizi açıklamaz. Analiz raporları, kullanıcı görüşmeleri, destek talepleri ve kullanılabilirlik incelemeleri hipotezin başlangıcı olabilir.

Hipotez şablonu: [Hedef kullanıcı grubunda] [gözlemlediğimiz sorun] nedeniyle, [değişikliği] yaparsak [birincil metrikte] iyileşme bekliyoruz. Çünkü [davranışsal gerekçe]. Bu sırada [koruyucu metriklerin] kabul ettiğimiz sınırları aşmaması gerekiyor.

Temsili mağazamız için: “Ürün sayfasına gelen mobil kullanıcılar teslimat tarihini bulmakta zorlandığı için teslimat aralığını fiyatın altına taşırsak 7 günlük satın alma oranının artmasını bekliyoruz. Çünkü kullanıcı ödeme adımına geçmeden önce teslimat belirsizliğini giderebilecek. Bu sırada sayfa performansının ve iade oranının kabul ettiğimiz sınırlar içinde kalması gerekiyor.”

Burada ölçülebilir bir sonuç, tanımlı bir kitle ve sınanabilir bir gerekçe var. Sonuç olumsuz çıkarsa yalnızca B tasarımını elemiş olmayız; teslimat bilgisinin yeriyle ilgili varsayımımızı da yeniden değerlendiririz.

Hipotezi test başlamadan yazın. Sonuçları gördükten sonra başarı tanımını değiştirmek, tesadüfi hareketleri başarı gibi sunmanıza yol açabilir. Microsoft’un deney öncesi planlama yaklaşımı da açık hipotez, uygun metrik ve doğru kullanıcı seçiminin önemini vurgular.

Birincil metrik ve koruyucu metrikler nasıl seçilir?

Birincil metrik, deneyin ana karar ölçütüdür. Satış odaklı bir ürün sayfası testinde sepete ekleme, davranışı açıklamaya yardımcı olabilir; ana hedef satın almaysa yalnızca sepete ekleme artışıyla kazanan ilan etmeyin.

Payı, paydayı ve ölçüm penceresini birlikte tanımlayın. Örneğimizde oran, “atamadan sonraki 7 gün içinde en az bir satın alma yapan benzersiz kullanıcı / teste atanmış uygun benzersiz kullanıcı” olarak hesaplanır. Aynı kişinin üç siparişi bu ikili metrikte üç dönüşen kullanıcı sayılmaz.

Bir form testinde ana metrik başarılı başvuru olabilir. Ancak gereksiz başvurular satış ekibinin iş yükünü artırıyorsa CRM’de nitelikli başvuru oranını ve başvuru başına maliyeti de izleyin. Satışa dönüşmesi haftalar süren başvurular için gözlem süresini buna göre planlayın. Bu ayrımı lead generation rehberindeki huni yaklaşımıyla birlikte değerlendirebilirsiniz.

Koruyucu metriklere testten önce kabul edilebilir bozulma sınırı koyun. “İstatistiksel olarak anlamlı düşüş yok” demek, zararın dışlandığı anlamına gelmez; belirsizlik aralığı hâlâ işletmeniz için önemli bir kayba izin veriyor olabilir.

Kitle, rastgele atama ve varyant dağılımı

Önce kimlerin teste uygun olduğunu belirleyin: yalnızca mobil ziyaretçiler mi, belirli ürünleri görüntüleyenler mi, yoksa bütün kullanıcılar mı? Kapsam ne kadar darsa test sonucunun uygulanabileceği kitle de o kadar dar olur. Mobilde yapılan bir deneyin masaüstünde aynı etkiyi yaratacağını varsaymayın.

Atama birimini de seçin. Web deneylerinde çoğunlukla kullanıcıyı temsil eden tutarlı bir kimlik kullanılır. Aynı kişinin her ziyarette başka varyanta düşmesi karşılaştırmayı kirletebilir. Çerez silinmesi ve cihaz değişimi nedeniyle tekil kullanıcı tanımının kusursuz olmadığını hesaba katın.

Kullanıcı bazlı atamada aynı kişinin çok sayıdaki oturumunu bağımsız kullanıcılar gibi analiz etmeyin. B2B yazılımlarda şirket düzeyinde atama gerekebilir; o zaman örneklem hesabı ve analiz birimi de şirket düzeyine uygun olmalıdır.

Benzer maliyet ve varyansa sahip iki grup için %50/%50 dağılım genellikle verimli bir başlangıçtır. “Site trafiğinin %20’sini deneye alıp bunun yarısını B’ye göndermek” ile “tüm trafiğin %50’sini B’ye göndermek” aynı örneklemi üretmez. Trafik hesabında iki oranı da kullanın.

Botlar, çalışanlar ve test siparişleri için filtreleri önceden tanımlayın ve iki gruba aynı şekilde uygulayın. Aynı sayfada eşzamanlı çalışan başka deneyler varsa olası etkileşimleri kaydedin. Deney sırasında hedef kitleyi veya varyant içeriğini değiştirmek yeni bir deney olarak ele alınmalıdır.

A/B testi için ne kadar trafik gerekir?

Herkes için geçerli bir ziyaretçi sayısı yoktur. Örneklem ihtiyacı; başlangıç dönüşüm oranına, tespit etmek istediğiniz etkiye, seçilen hata düzeyine, istatistiksel güce ve deney tasarımına bağlıdır.

• Başlangıç oranı: Teste girecek kitledeki mevcut performans. Site genelindeki oranı, yalnızca mobil ürün sayfasını kapsayan deneye doğrudan taşımayın.
• MDE: Seçtiğiniz güçle tespit etmek üzere planladığınız en küçük etki. Ticari açıdan değerli en küçük etkiyle ilişkili seçilir, fakat iki kavram aynı değildir.
• Anlamlılık düzeyi: Örneğin α = 0,05; yöntem varsayımları altında, gerçekte fark yokken yanlış pozitif karar verme sıklığını kontrol eder.
• Güç: Örneğin %80; gerçek etki planladığınız büyüklükteyse testin bunu istatistiksel olarak tespit etme olasılığıdır. B varyantının kazanma olasılığı değildir.

Mutlak fark ile göreli artışı ayırın

Dönüşüm oranı %2’den %2,4’e çıkarsa mutlak fark 0,4 yüzde puan, göreli artış %20 olur. Hesaplayıcıya “0,4” mü, “20” mi yazmanız gerektiği, aracın mutlak fark mı göreli etki mi istediğine bağlıdır.

Göreli artış formülü: (B oranı − A oranı) / A oranı × 100. Başlangıç oranı sıfır olduğunda bu formül kullanılamaz; farklı bir planlama yaklaşımı gerekir.

Hesap varsayımları: bağımsız kullanıcılar, ikili dönüşüm metriği, eşit grup büyüklüğü, iki taraflı test, α = 0,05 ve %80 güç. İki bağımsız oranın normal yaklaşımına dayalı planlama hesabı kullanıldı; sonuçlar yukarı doğru yüzlüğe yuvarlandı. Bu değerler her araçta geçerli sabit eşikler değildir. Gelir, tekrarlı olaylar, kümelenmiş atama ve sıralı analiz farklı hesaplar gerektirir.

Tablodaki sayılar bu rehber için hesaplandı. Yaklaşımın teknik açıklaması statsmodels örneklem hesabında bulunabilir. Kullanacağınız deney platformunun hesaplayıcısında aynı varsayımları seçerek planı doğrulayın.

Küçük iyileştirmeleri ölçmek daha çok trafik ister. Gerçekçi beklentiniz %5’lik artışken sırf test kısa sürsün diye MDE’yi %50 seçmek sorunu çözmez; testi küçük etkilere karşı yetersiz bırakır.

A/B testi ne kadar sürmeli, ne zaman durdurulmalı?

İlk süre tahmini, toplam gerekli kullanıcı / günlük deneye katılan yeni uygun kullanıcı hesabıyla yapılabilir. Toplam site oturumunu kullanmayın; aynı kişiyi tekrar tekrar yeni katılımcı saymak süreyi olduğundan kısa gösterir.

42.400 kullanıcılık örneklem için günde 2.000 yeni uygun katılımcı yaklaşık 22 gün, günde 200 katılımcı yaklaşık 212 gün gerektirir. Gerekli kitlenin yalnızca yarısını teste alırsanız süre de kabaca ikiye katlanır. Bu hesaplar yalnızca katılımcı toplama süresidir.

Hafta içi ve hafta sonu davranışları, maaş günleri, kampanya takvimi ve dönüşüm gecikmesini de düşünün. Örneklemin dört günde tamamlanması, dört günlük testin iş döngünüzü temsil ettiği anlamına gelmez. “Her test 14 gün sürer” gibi bir kural da yeterli değildir.

Önceden örneklem büyüklüğü belirlenen bir testte analiz koşulunu başlamadan yazın: hedef örneklem, minimum süre, azami süre ve dönüşümlerin olgunlaşma penceresi. Örneğin son katılımcının satın alma davranışını 7 gün izleyecekseniz, katılımcı alımı bittikten sonra bu sürenin tamamlanmasını bekleyin.

Her sabah klasik p-değerine bakıp ilk olumlu günde testi bitirmek yanlış pozitif riskini artırır. Güvenli ara kararlar için buna uygun sıralı yöntem ve önceden tanımlı durdurma kuralları gerekir. Sabit örneklem, sıralı ve Bayesçi yöntemler aynı karar mantığını kullanmaz; platformdaki yüzdeleri birbirinin yerine okumayın.

Sabit örneklem yaklaşımında ana analiz zamanı önceden belirlenir. Sıralı yöntemlerde veri geldikçe karar verilebilmesi için hata kontrolü yönteme dahil edilir. Bayesçi yaklaşımda ise önsel varsayımlar ve gözlenen veriler birlikte kullanılarak etki olasılıkları hesaplanır; karar eşiği ve durdurma politikası yine baştan seçilmelidir. Bayesçi bir rapordaki “B’nin daha iyi olma olasılığı” ile klasik p-değeri farklı niceliklerdir.

Teknik hata veya önceden belirlenmiş ciddi zarar sınırı nedeniyle testi durdurmak ayrı bir operasyondur. Böyle bir durumda “B kazandı” ya da “A kazandı” demek yerine durdurma nedenini ve değerlendirilebilen verinin sınırını kaydedin.

Ölçüm kurulumu ve yayın öncesi kontrol

Test başlamadan önce atama, deneyin gerçekten uygulanması ve dönüşüm arasındaki ilişkiyi doğrulayın. Hangi kullanıcı hangi varyanta ne zaman atandı? Deneyimi gerçekten gördü mü? Sonraki satın alma doğru kullanıcı ve zaman penceresiyle eşleşiyor mu?

• Her iki varyantı mobil ve masaüstünde; özellikle form, sepet ve ödeme adımlarında kontrol edin.
• Deney kimliği ve varyant bilgisinin tutarlı kaydedildiğini doğrulayın.
• Başarılı işlemleri ölçün; butona tıklamayı otomatik olarak başarılı form veya sipariş saymayın.
• Tekrarlanan olayları ve siparişleri ayıklama kuralını tanımlayın.
• İzin tercihleri, reklam engelleyiciler ve kimlik kayıplarının iki grubu farklı etkileyip etkilemediğini inceleyin.
• Varyant geçişinde titreme, gecikme veya yönlendirme nedeniyle oluşan veri kaybını kontrol edin.

GA4, deney verilerini incelemek için kullanılabilir. Google’ın deney entegrasyonu dokümanı, deney ve varyant bilgilerini olaylarla kaydetme yollarını açıklar. Ancak yalnızca bir olay göndermek kullanıcıyı rastgele atamaz ve kendi başına istatistiksel deney analizi oluşturmaz. Varyant bilgisi sonraki dönüşümlerle ilişkilendirilmeli; gösterim olayına ait bir boyutun bütün satış olaylarında kendiliğinden bulunacağı varsayılmamalıdır.

Atama, maruz kalma ve dönüşüm için aynı kapsamı koruyun. B’de yalnızca yeni öğeye tıklayanları seçip A’da tüm ziyaretçileri analiz etmek grupları karşılaştırılamaz hâle getirir. Kurulumun temelini GA4 rehberiyle kontrol edebilirsiniz.

Grup dağılımı bozuksa sonucu yorumlamayın

%50/%50 planlanan bir deneyin kullanıcı sayıları tam eşit olmak zorunda değildir. Fakat gözlenen fark, rastgele dalgalanmayla açıklanamayacak kadar büyükse Sample Ratio Mismatch — SRM araştırılmalıdır. Örneğin 10.000 kullanıcıda 5.500/4.500 dağılımı ciddi bir inceleme nedenidir.

Hatalı atama, bir varyantta kaybolan olaylar veya farklı çalışan filtreler buna yol açabilir. Sayıları elle eşitlemek yerine nedenini bulun. Microsoft’un SRM incelemesi, bu sorunun deney sonucuna güvenmeden önce çözülmesi gerektiğini gösterir.

A/B testi sonuçları nasıl yorumlanır?

Önce veri kalitesini ve önceden belirlenen bitiş koşullarını kontrol edin. Sonra etki büyüklüğüne ve belirsizlik aralığına bakın. Aşağıdaki temsili sonuçta her grupta 22.000 kullanıcı vardır ve bütün kullanıcıların 7 günlük dönüşüm penceresi tamamlanmıştır.

Bağımsız kullanıcı varsayımıyla, iki taraflı iki oran z-testinde p-değeri yaklaşık 0,0042 çıkar. B−A mutlak farkının büyük örneklem normal yaklaşımıyla %95 güven aralığı yaklaşık +0,13 ile +0,67 yüzde puan arasındadır. Bunlar klasik sabit örneklem hesabıdır; sıralı bir platformun çıktısıyla birebir eşleşmek zorunda değildir.

P-değeri ne söyler?

Gruplar arasında gerçekte fark olmadığı ve test varsayımlarının geçerli olduğu durumda, gözlenen kadar veya daha uç bir sonuç elde etmenin olasılığını ifade eder. p = 0,0042, “B’nin daha iyi olma olasılığı %99,58” demek değildir. Hipotezin doğru olma olasılığını doğrudan vermez.

Güven aralığı ne söyler?

Etki tahmininin belirsizliğini gösterir. Örnekte aralık sıfırın üzerindedir, ancak her yeni dönemde tam %20 artış beklemek doğru olmaz. Aynı güven aralığı yöntemi geçerli varsayımlar altında tekrar tekrar uygulandığında, oluşturulan aralıkların yaklaşık %95’i gerçek farkı kapsar.

Bu örneğin hesaplama yaklaşımı için NIST’in iki oran karşılaştırması açıklamasına bakabilirsiniz. Küçük örneklemde veya az dönüşümde bu normal yaklaşım uygun olmayabilir; kullanılan yöntemin varsayımları ayrıca kontrol edilmelidir.

İstatistiksel anlamlılık ticari değerle aynı mı?

Hayır. Çok büyük trafikte, uygulama maliyetini karşılamayan küçük bir fark anlamlı çıkabilir. Örneğimizde tahmin edilen +0,4 yüzde puan fark, aynı koşullarda 50.000 uygun kullanıcı başına yaklaşık 200 ek satın alan kullanıcıya karşılık gelir. Bu yalnızca ölçekleme senaryosudur; gerçekleşmiş ek satış veya gelir değildir.

Karara geçmeden indirim maliyetini, kâr marjını, iptalleri, iadeleri ve geliştirme yükünü değerlendirin. Sepet ortalaması veya müşteri niteliği kötüleşiyorsa daha yüksek dönüşüm oranı işletmeye daha az değer sağlayabilir.

Kazanan, kaybeden ve belirsiz sonuçlarla ne yapılır?

“Anlamlı fark bulamadık” ile “iki sürüm eşittir” farklı sonuçlardır. Geniş bir güven aralığı, daha fazla bilgi gerektiğini gösterebilir. Testi her defasında “bir hafta daha” uzatmak yerine, azami süreye geldiğinizde ne yapacağınızı baştan belirleyin.

Toplam sonuç olumsuzken onlarca cihaz, şehir ve kanal kırılımından yalnızca olumlu olanı seçmek de güvenilir bir kazanım yaratmaz. Önceden planlanmamış segment bulgularını sonraki hipotez için kullanın. Çoklu karşılaştırmalar ayrıca hata kontrolü gerektirir; Optimizely’nin açıklaması, metrik ve varyant sayısının neden dikkate alınması gerektiğini anlatır.

Trafik azsa nasıl ilerlenir?

Örneklem hesabı aylar gösteriyorsa önce test fikrini yeniden değerlendirin. Bu süre içinde ürün, fiyat ve kampanya düzeni değişecekse aynı deneyi sağlıklı sürdürmek zorlaşabilir.

• Açık sorunları düzeltin: Çalışmayan buton, görünmeyen hata mesajı veya bozuk mobil düzen için pozitif A/B sonucu beklemek gerekmez.
• Kullanıcı araştırması yapın: Görüşmeler ve kullanılabilirlik testleri, davranışın nedenini anlamaya yardımcı olur.
• Daha güçlü bir hipotez seçin: Küçük kozmetik değişiklikler yerine önemli bir karar engelini çözmeyi araştırın.
• Varyant sayısını azaltın: Trafiği birçok alternatif arasında bölmek yerine bir kontrol ve bir alternatifle başlayın.
• Daha sık gerçekleşen metrikleri dikkatle kullanın: Form başlatma gibi göstergeler erken öğrenme sağlayabilir; satış artışını kanıtlamaz.

Araştırmaya dayanarak değişiklik yapmak mümkündür. Böyle bir uygulamanın sonrasında iyileşme görülse bile, kontrollü deney yoksa değişikliğin tek başına buna neden olduğunu söylemeyin. Öncesi–sonrası izlemesini bu sınırla değerlendirin.

Google Optimize kapandıktan sonra hangi araç kullanılabilir?

Google Optimize ve Optimize 360, 30 Eylül 2023’te kapatıldı. Eski Optimize kurulum adımları güncel bir deney başlatmak için kullanılamaz. Google, resmî kapanış açıklamasında AB Tasty, Optimizely ve VWO ile deney entegrasyonlarından söz eder.

Araç seçimini şu ihtiyaçlara göre yapın: görsel düzenleyici mi kodla uygulama mı gerekiyor, kullanıcı kimliği nasıl korunacak, hangi istatistiksel yöntem kullanılacak, GA4 veya veri ambarına nasıl aktarılacak ve sonuçlar dışa alınabilecek mi?

Bir araç seçerken SRM kontrollerini, trafik hedefleme seçeneklerini, sayfa performansına etkisini ve ekipte uygulamayı kimin yöneteceğini de değerlendirin. Güncel plan kapsamı ve fiyatlar ürünlerin kendi kaynaklarından kontrol edilmelidir.

Shopify’da ürün sayfası, sepet ve ödeme adımları aynı uygulama imkânlarına sahip olmayabilir. Deney tasarımından önce temanın, uygulamanın ve mağaza planının hedeflediğiniz değişikliğe izin verdiğini doğrulayın.

Kullanabileceğiniz A/B testi planı

Aşağıdaki planı ilk toplantıda doldurun. Örnek değerler bir başlangıç gösterir; gerçek başlangıç oranı ve trafik hesabınızla değiştirilmelidir.

Sonuç raporuna test tarihlerini, gerçek grup büyüklüklerini, ana metriği, etkiyi, güven aralığını, veri kalitesi bulgularını ve alınan kararı ekleyin. Ekran görüntüleriyle A ve B’yi arşivlemek, sonraki deneylerde aynı fikrin tekrar denenmesini önler.

A/B testi hakkında sık sorulan sorular

Her testte tek bir öğe mi değiştirilmelidir?

Zorunlu değildir. Birden fazla öğeyi değiştirerek bütün bir tasarım yaklaşımını test edebilirsiniz. Ancak sonuç, paketin etkisini gösterir; hangi öğenin ne kadar katkı verdiğini tek başına açıklamaz.

100 dönüşüm aldıktan sonra testi bitirebilir miyim?

Evrensel bir “100 dönüşüm” kuralı yoktur. Yeterlilik; başlangıç oranı, hedeflenen etki, kullanıcı sayısı, yöntem ve güç hesabına bağlıdır. Dönüşüm sayısını tek başına bitiş koşulu yapmayın.

İki reklamın dönüşüm oranını karşılaştırmak A/B testi sayılır mı?

Reklamlar farklı kitlelere, zamanlara veya dağıtım algoritmalarına maruz kalıyorsa basit oran karşılaştırması kontrollü deney değildir. İlgili platformun deney tasarımını ve rastgele dağıtım imkânlarını kullanın.

Test bittikten sonra kazananın performansı neden değişebilir?

Trafik bileşimi, sezon, fiyat, stok veya kullanıcıların yeni tasarıma alışması sonucu etkileyebilir. Yayın sonrası izleme yapın; testte ölçülen etkiyi süresiz ve bütün kullanıcılar için geçerli kabul etmeyin.

GA4 veya GTM tek başına A/B testi yapar mı?

Ölçüm olayları ve etiket yönetimi, deneyin yalnızca bir bölümüdür. Rastgele atama, varyantın uygulanması, tutarlı kimlik ve uygun analiz için deney altyapısı gerekir. Araçları görevlerine göre birlikte planlayın.

İlk testinizi seçerken önce kullanıcının hangi adımda zorlandığını, sonra bunu hangi veriyle sınayabileceğinizi netleştirin. Ölçüm, hipotez ve uygulama planını birlikte oluşturmak için CRO danışmanlığı kapsamımızı inceleyebilirsiniz.