Ayda Kaç A/B Testi Yapmalısınız?

Bu, test programınızın başarısı için dikkate alınması gereken önemli bir sorudur.

Çok fazla test yapın ve herhangi bir bireysel deneyden fazla değer elde etmeden kaynakları boşa harcayabilirsiniz.

Ancak çok az test yaparsanız, daha fazla dönüşüm sağlayabilecek önemli optimizasyon fırsatlarını kaçırabilirsiniz.

Öyleyse, bu muamma göz önüne alındığında, ideal test temposu nedir?

Bu soruyu yanıtlamaya yardımcı olmak için, dünyanın en başarılı ve ilerici deney ekiplerinden bazılarına bakmak için can atıyor.

Amazon akla gelen böyle bir isimdir.

E-ticaret devi aynı zamanda bir deney devidir. Aslında, Amazon'un yılda 12.000'den fazla deney yaptığı söyleniyor! Bu miktar, ayda yaklaşık bin deneye ayrılıyor.

Google ve Microsoft'un Bing'i gibi şirketlerin de benzer bir hızda ilerlediği söyleniyor.

Wikipedia'ya göre, arama motoru devlerinin her biri yılda 10.000'den fazla A/B testi veya ayda yaklaşık 800 test gerçekleştiriyor.

Ve bu hızda çalışan sadece arama motorları değil.

Booking.com, denemede dikkate değer başka bir isimdir. Seyahat rezervasyon sitesinin yılda 25.000'den fazla test yaptığı bildiriliyor, bu da ayda 2 binden fazla test veya günde 70 test anlamına geliyor!

Yine de araştırmalar, ortalama bir şirketin ayda yalnızca 2-3 test yaptığını gösteriyor.

Yani, çoğu şirket ayda sadece birkaç test yapıyorsa, ancak dünyanın en iyilerinden bazıları ayda binlerce deney yapıyorsa, ideal olarak kaç test yapıyor olmalısınız?

A/B Testlerini Çalıştırırken Dikkate Alınması Gereken 6 Faktör

Ayda kaç test yapılacağına karar verirken dikkate alınması gereken 6 temel faktör vardır. İçerirler

• Örnek boyutu gereksinimleri
• kurumsal olgunluk
• Mevcut kaynaklar
• Test fikirlerinin karmaşıklığı
• Test zaman çizelgeleri
• Etkileşim etkileri

Her birine derinlemesine dalalım.

Örnek Büyüklüğü Gereksinimleri

A/B testinde, örnek boyutu, güvenilir bir test yapmak için ihtiyaç duyduğunuz trafik miktarını tanımlar.

İstatistiksel olarak geçerli bir çalışma yürütmek için geniş, temsili bir kullanıcı örneğine ihtiyacınız vardır.

Teorik olarak sadece birkaç kullanıcı ile bir deney yapabilirsiniz ancak çok anlamlı sonuçlar elde edemezsiniz.

Düşük Örneklem Boyutları Hala İstatistiksel Olarak Anlamlı Sonuçlar Verebilir

Örneğin, yalnızca 10 kullanıcının A ve 2 sürümünün dönüştürüldüğünü gördüğü bir A/B testi hayal edin. Ve yalnızca 8 kullanıcı, dönüşüm gerçekleştiren 6 kullanıcıyla B sürümünü gördü.

Bu grafiğin gösterdiği gibi, sonuçlar istatistiksel olarak anlamlıdır:

Sürüm B, %275 oranında daha iyi performans gösteriyor gibi görünüyor. Ancak, bu bulgular çok güvenilir değildir. Örnek boyutu, anlamlı sonuçlar sağlamak için çok küçüktür.

Çalışma yetersiz. Büyük, temsili bir kullanıcı örneği içermez.

Test yetersiz olduğundan, sonuçlar hataya eğilimlidir. Ve sonucun sadece rastgele bir şansla mı meydana geldiği yoksa bir versiyonun gerçekten üstün mü olduğu açık değil.

Bu küçük örnekle yanlış sonuçlara varmak kolaydır.

Düzgün Güçlendirilmiş Testler

Bu tuzağın üstesinden gelmek için, A/B testlerinin geniş, temsili bir kullanıcı örneklemiyle yeterince güçlendirilmesi gerekir.

Yeterince büyük ne kadar büyük?

Bu soru, bazı basit örneklem büyüklüğü hesaplamaları yapılarak cevaplanabilir.

Örnek boyutu gereksinimlerinizi en kolay şekilde hesaplamak için, bir örnek boyutu hesaplayıcı kullanmanızı öneririm. Orada onlardan çok var.

Benim favorim Evan Miller'ınki çünkü esnek ve eksiksiz. Ayrıca, nasıl kullanılacağını anlarsanız, hemen hemen her hesap makinesini kavrayabilirsiniz.

Evan Miller'ın hesap makinesi şöyle görünür:

Hesaplamaların kendileri oldukça basit olsa da, bunların arkasındaki terminolojiyi anlamak öyle değil. Bu yüzden kompleksi açıklığa kavuşturmaya çalıştım:

Temel Dönüşüm Oranı

Temel dönüştürme oranı, kontrolün veya orijinal sürümün mevcut dönüştürme oranıdır. Bir A/B testi ayarlarken genellikle "versiyon A" olarak etiketlenir.

Bu dönüşüm oranını analitik platformunuzda bulabilmeniz gerekir.

Hiç A/B testi yapmadıysanız veya temel dönüşüm oranını bilmiyorsanız, en iyi eğitimli tahmininizi yapın.

Çoğu site, sektör dikeyi ve cihaz türünde ortalama dönüşüm oranı %2 ile %5 arasındadır. Bu nedenle, temel dönüşüm oranınızdan gerçekten emin değilseniz, dikkatli olun ve %2'lik bir temel değerle başlayın.

Temel dönüşüm oranı ne kadar düşükse, ihtiyaç duyacağınız örnek boyutu o kadar büyük olur. Ve tam tersi.

Minimum Saptanabilir Etki (MDE)

Minimum Tespit Edilebilir Etki (MDE) kulağa karmaşık bir kavram gibi geliyor. Ancak terimi üç kısma ayırırsanız kavramak çok daha kolay hale gelir:

• Asgari = en küçük
• Algılanabilir = denemeyi çalıştırarak algılamaya veya bulmaya çalıştığınız istek
• Etki = kontrol ve tedavi arasındaki dönüştürme farkı

Bu nedenle, Minimum Saptanabilir Etki, testi çalıştırarak algılamayı umduğunuz en küçük dönüşüm artışıdır.

Bazı veri sadeliği uzmanları, bu tanımın aslında Asgari İlgi Etkisini (MEI) tanımladığını iddia edeceklerdir. Nasıl adlandırmak isterseniz isteyin, amaç, testi çalıştırarak ne kadar büyük bir dönüşüm artışı elde etmeyi beklediğinizi tahmin etmektir.

Bu alıştırma çok spekülatif görünse de, beklenen MDE'yi hesaplamak için bunun gibi bir örneklem büyüklüğü hesaplayıcısı veya Convert'in A/B testi istatistiksel hesaplayıcısını kullanabilirsiniz.

Çok genel bir kural olarak, %2-5 MDE makul kabul edilir. Gerçekten düzgün çalışan bir test çalıştırırken çok daha yüksek herhangi bir şey genellikle gerçekçi değildir.

MDE ne kadar küçük olursa, ihtiyaç duyulan örneklem büyüklüğü o kadar büyük olur. Ve tam tersi.

Bir MDE, mutlak veya göreli bir miktar olarak ifade edilebilir.

mutlak

Mutlak bir MDE, kontrolün ve varyantın dönüştürme oranı arasındaki ham sayı farkıdır.

Örneğin, temel dönüşüm oranı %2,77 ise ve varyantın +%3 mutlak MDE elde etmesini bekliyorsanız, mutlak fark %5,77'dir.

Akraba

Buna karşılık, göreceli bir etki, değişkenler arasındaki yüzde farkını ifade eder.

Örneğin, temel dönüşüm oranı %2,77 ise ve varyantın +%3 göreli MDE elde etmesini bekliyorsanız, göreli fark %2,89 olur.

Genel olarak, çoğu deneyci göreli bir yüzde artışı kullanır, bu nedenle genellikle sonuçları bu şekilde göstermek en iyisidir.

İstatistiksel güç 1−β

Güç, gerçekten var olduğu varsayılarak bir etki veya dönüşüm farkı bulma olasılığını ifade eder.

Testte amacınız, varsa bir farkı hatasız olarak anlamlı bir şekilde tespit etmek için yeterli güce sahip olduğunuzdan emin olmaktır. Bu nedenle, daha yüksek bir güç her zaman daha iyidir. Ancak değiş tokuş şu ki, daha büyük bir örneklem büyüklüğü gerektiriyor.

0,80'lik bir güç, standart en iyi uygulama olarak kabul edilir. Bu nedenle, bu hesap makinesinde varsayılan aralık olarak bırakabilirsiniz.

Bu miktar, bir etki varsa, bunu hatasız ve doğru bir şekilde tespit etme şansınızın %80 olduğu anlamına gelir. Bu nedenle, efekti doğru bir şekilde tespit edememe ihtimaliniz yalnızca %20'dir. Almaya değer bir risk.

Önem Düzeyi α

Çok basit bir tanım olarak, anlamlılık düzeyi alfa, yanlış pozitif oran veya gerçekte var olmasa bile bir dönüşüm farkının algılanacağı zaman yüzdesidir.

Bir A/B testi en iyi uygulaması olarak, önem seviyeniz %5 veya daha düşük olmalıdır. Yani bu hesap makinesinde varsayılan olarak bırakabilirsiniz.

%5 anlamlılık düzeyi α, kontrol ve varyant arasında bir fark bulma şansınızın %5 olduğu anlamına gelir; oysa gerçekte hiçbir fark yoktur.

Yine, almaya değer bir risk.

Örnek Büyüklüğü Gereksinimlerinizi Değerlendirme

Bu sayıları hesap makinenize taktığınızda, artık sitenizin standart 2 ila 6 haftalık bir test süresi boyunca düzgün bir şekilde güçlendirilmiş bir testi çalıştırmak için yeterli trafiğe sahip olmasını sağlayabilirsiniz.

Doğrulamak için, tercih ettiğiniz analiz platformuna gidin ve sitenin veya test etmek istediğiniz sayfanın sınırlı bir süre boyunca geçmişteki ortalama trafik oranına bakın.

Örneğin, bu Google Analytics 4 (GA4) hesabında, Yaşam döngüsü > Edinme > Edinmeye genel bakış sekmesine giderek, Ekim-Kasım 2022 arasındaki yakın geçmişte 365 bin kullanıcı olduğunu görebilirsiniz:

%80'lik bir standart güçte ve %5'lik bir standart anlamlılık düzeyinde %5 göreli MDE ile %3,5'lik mevcut temel dönüşüm oranına dayalı olarak, hesaplayıcı düzgün bir şekilde çalıştırmak için varyant başına 174.369 ziyaretçilik bir örnek boyutu gerektiğini gösteriyor- güçlü A/B testi:

Trafik eğilimlerinin önümüzdeki aylarda nispeten sabit kalacağını varsayarsak, sitenin makul bir test süresi içinde yaklaşık 365 bin kullanıcıya veya (365 bin/2 varyant) varyant başına 182 bin ziyaretçiye ulaşmasını beklemek mantıklıdır.

Numune boyutu gereklilikleri elde edilebilir, bu da devam etmek ve testi çalıştırmak için yeşil ışık verir.

Önemli bir not, bu örneklem büyüklüğü gerekliliği doğrulama alıştırması, düzgün bir şekilde güçlendirilmiş bir testi çalıştırmak için yeterli trafiğiniz olup olmadığını bilmeniz için her zaman herhangi bir çalışma yürütmeden ÖNCE yapılmalıdır.

Ek olarak, testi çalıştırırken, sonuçlar daha erken önemli görünse bile önceden hesaplanmış numune boyutu gereksinimlerinize ulaşmadan önce ASLA testinizi durdurmamalısınız.

Örnek boyutu gereksinimlerini karşılamadan erken bir kazanan veya kaybeden ilan etmek, "gözetleme" olarak bilinen şeydir ve sonuçlar tamamen çıkmadan önce yanlış kararlar vermenize neden olabilecek tehlikeli bir test uygulamasıdır.

Yeterli Trafiğiniz Varsa Kaç Test Yapabilirsiniz?

Test etmek istediğiniz site veya sayfaların örneklem büyüklüğü gereksinimlerini karşıladığını varsayarsak, kaç tane test çalıştırabilirsiniz?

Cevap, yine, duruma göre değişir.

Microsoft'un Bing Deneylerinden Sorumlu Eski Başkan Yardımcısı Ronny Kohavi tarafından paylaşılan bir sunuma göre, Microsoft genellikle günde 300'den fazla deney gerçekleştiriyor.

Ama bunu yapacak trafikleri var.

Her deneme 100 binin üzerinde kullanıcı görüyor:

Kullanılabilir trafiğiniz ne kadar büyükse, o kadar çok test çalıştırabilirsiniz.

Herhangi bir testte, düzgün bir şekilde desteklenen bir deneyi yürütmek için yeterince büyük bir örneklem boyutunuz olduğundan emin olmanız gerekir.

Daha sınırlı trafiğe sahip daha küçük bir kuruluşsanız, daha az sayıda yüksek kaliteli test yapmayı düşünün.

Günün sonunda önemli olan kaç test yaptığınız değil, deneylerinizin sonucu.

Örnek Büyüklüğü Gereksinimlerini Karşılayamıyorsanız Seçenekler

Örnek boyutu gereksinimlerini karşılayamayacağınızı keşfederseniz, üzülmeyin. Deney sizin için masanın dışında değil. Birkaç potansiyel deneme seçeneğiniz var:

1. Trafik edinmeye odaklanın

Büyük sitelerde bile belirli sayfalarda düşük trafik olabilir.

Site trafiğinin veya belirli sayfalardaki trafiğin örnek boyutu gereksinimlerini karşılamadığını fark ederseniz, çabalarınızı daha fazla trafik elde etmeye odaklamayı düşünün.

Bunu yapmak için, arama motorlarında daha üst sıralarda yer almak ve daha fazla tıklama toplamak için agresif Arama Motoru Optimizasyonu (SEO) taktikleri uygulayabilirsiniz.

Ayrıca Google Ads, LinkedIn reklamları ve hatta banner reklamlar gibi kanallardan ücretli trafik elde edebilirsiniz.

Bu satın alma etkinliklerinin her ikisi de web trafiğini artırmaya yardımcı olabilir ve size, kullanıcılar üzerinde en iyi dönüşüm sağlayan şeyin ne olduğunu test etme konusunda daha güçlü bir yetenek verebilir.

Ancak, örnek boyutu gereksinimlerini karşılamak için ücretli trafik kullanıyorsanız, ziyaretçi davranışı trafik kaynağına göre değişebileceğinden, test sonuçlarını trafik türüne göre bölümlere ayırmayı düşünün.

2. A/B testinin sizin için en iyi deneme yöntemi olup olmadığını değerlendirin

A/B testi, denemenin altın standardı olarak görülse de, sonuçlar yalnızca arkasındaki veriler kadar iyidir.

Düzgün bir şekilde desteklenen bir testi çalıştırmak için yeterli trafiğiniz olmadığını fark ederseniz, A/B testinin sizin için gerçekten en iyi deneme seçeneği olup olmadığını düşünmek isteyebilirsiniz.

Çok daha küçük örnekler gerektiren ve yine de inanılmaz derecede değerli optimizasyon içgörüleri sağlayabilen başka araştırmaya dayalı yaklaşımlar vardır.

Kullanıcı Deneyimi (UX) testi, tüketici anketleri, çıkış anketleri veya müşteri görüşmeleri, A/B testine alternatif olarak deneyebileceğiniz diğer birkaç deneme yöntemidir.

3. Realize sonuçları yalnızca yönlü veriler sağlayabilir

Ancak A/B testine devam ederseniz, yine de testler yapabilirsiniz.

Sonuçların tam olarak doğru olmayabileceğini ve yalnızca - tamamen güvenilir olmaktan ziyade olası - sonucu gösteren "yön verileri" sağlayacağını anlayın.

Sonuçlar tamamen doğru olmayabileceğinden, zaman içindeki dönüşüm etkisini yakından izlemek isteyeceksiniz.

Bununla birlikte, genellikle doğru dönüşüm rakamlarından daha önemli olan şey, banka hesabındaki rakamlardır. Yükseliyorlarsa, yaptığınız optimizasyon çalışmasının işe yaradığını bilirsiniz.

Olgunluğun Test Edilmesi

Numune büyüklüğü gerekliliklerine ek olarak, test etme kadansını etkileyen diğer bir faktör, test eden kuruluşun olgunluk düzeyidir.

Test olgunluğu, deneylerin bir organizasyon kültürü içinde ne kadar yerleşik olduğunu ve deney uygulamalarının ne kadar gelişmiş olduğunu açıklamak için kullanılan bir terimdir.

Ayda binlerce test gerçekleştiren Amazon, Google, Bing ve Booking gibi kuruluşların ilerici, olgun test ekipleri var.

Bu tesadüf değil.

Test temposu, bir kuruluşun olgunluk düzeyine yakından bağlı olma eğilimindedir.

Eğer deney organizasyon içinde yerleşmişse, yönetim buna kendini adamıştır. Ayrıca, kuruluş genelindeki çalışanlar genellikle deneyleri desteklemeye ve önceliklendirmeye teşvik edilir ve hatta test fikirleri sağlamaya yardımcı olabilir.

Bu faktörler bir araya geldiğinde, amaca uygun bir test programı yürütmek çok daha kolaydır.

Testi hızlandırmayı umuyorsanız, önce kuruluşunuzun olgunluk düzeyine bakmak yararlı olabilir.

gibi soruları değerlendirerek başlayın.

• C-Suite için deney yapmak ne kadar önemli?
• Deneyi teşvik etmek için hangi kaynaklar sağlanıyor?
• Test güncellemelerini iletmek için hangi iletişim kanalları mevcuttur?

Yanıt "yok" veya ona yakınsa, önce bir test kültürü oluşturmaya çalışın.

Kuruluşunuz daha ilerici bir deney kültürü benimserken, test temposunu artırmak doğal olarak daha kolay olacaktır.

Deney kültürünün nasıl oluşturulacağına dair öneriler için bu makale ve bunun gibi kaynaklara göz atın.

Kaynak Kısıtlamaları

Halihazırda bir dereceye kadar kurumsal katılımınız olduğunu varsayarsak, mücadele edilecek bir sonraki konu kaynak kısıtlamalarıdır.

Zaman, para ve insan gücü, test etme yeteneğinizi sınırlayabilecek sınırlamalardır. Ve hızlıca test edin.

Kaynak kısıtlamalarının üstesinden gelmek için test karmaşıklığını değerlendirerek işe başlamak yararlı olabilir.

Basit ve Karmaşık Testleri Dengeleyin

Bir deneyci olarak, süper basitten çılgın karmaşıklığa kadar değişen testler yapmayı seçebilirsiniz.

Basit testler, kopyalama veya renklendirme gibi öğeleri optimize etmeyi, görüntüleri güncellemeyi veya bir sayfadaki tek tek öğeleri taşımayı içerebilir.

Karmaşık testler birkaç öğeyi değiştirmeyi, sayfa yapısını değiştirmeyi veya dönüşüm hunisini güncellemeyi içerebilir. Bu tür testler genellikle derin kodlama çalışması gerektirir.

Binlerce A/B testi çalıştırarak, her zaman aynı anda çalışan yaklaşık ⅗ daha basit ve ⅖ daha karmaşık testlerin bir karışımına sahip olmayı yararlı buldum.

Daha basit testler size hızlı ve kolay kazançlar sağlayabilir.

Ancak daha büyük değişiklikler içeren daha büyük testler genellikle daha büyük etkiler sağlar. Aslında, bazı optimizasyon araştırmalarına göre, ne kadar çok ve karmaşık testler çalıştırırsanız, başarı olasılığınız o kadar artar. Bu nedenle, sık sık büyük salınım testleri yapmaktan korkmayın.

Sadece unutmayın, takas, testi tasarlamak ve oluşturmak için daha fazla kaynak harcayacağınızdır. Ve kazanacağının garantisi yok.

Mevcut İnsan Kaynaklarına Dayalı Test

Yalnız bir CRO stratejistiyseniz veya küçük bir ekiple çalışıyorsanız, kapasiteniz sınırlıdır. İster basit ister karmaşık olsun, ayda 2-5 testin size dokunduğunu görebilirsiniz.

Buna karşılık, özel bir araştırmacı, stratejist, tasarımcı, geliştirici ve QA uzmanı ekibine sahip bir kuruluştaysanız, muhtemelen ayda düzinelerce ila yüzlerce test yapma kapasiteniz vardır.

Kaç tane test çalıştırmanız gerektiğini belirlemek için insan kaynağı müsaitliğinizi değerlendirin.

Ortalama olarak, basit bir testin fikir oluşturması, tel kafes oluşturması, tasarlaması, geliştirmesi, uygulaması, KG'si ve sonuçları izlemesi 3-6 saat sürebilir.

Öte yandan, oldukça karmaşık bir test 15-20 saate kadar sürebilir.

Bir ayda yaklaşık 730 saat var, bu yüzden testler ve test sayısı hakkında çok hesaplı olmak isteyeceksiniz, bu değerli zamanda çalıştırıyorsunuz.

Test Fikirlerinizi Planlayın ve Önceliklendirin

En uygun test yapınızı belirlemenize yardımcı olması için PIE, ICE veya PXL gibi bir test önceliklendirme çerçevesi kullanmayı düşünün.

Bu çerçeveler, en iyi test fikirlerinizi sıralamak, uygulama kolaylığını değerlendirmek ve hangi testlerin dönüşümleri artırma olasılığının en yüksek olduğunu değerlendirmek için nicel bir teknik sağlar.

Bu değerlendirmeyi yaptıktan sonra, öncelikli test fikirleri listeniz şuna benzer:

En iyi test fikirleriniz sıralandığında, test zaman çizelgenizi ve sonraki adımları görsel olarak planlamak için bir test yol haritası oluşturmanız da önerilir.

Yol haritanız şöyle görünebilir:

Şunları içermelidir:

• Test etmeyi planladığınız fikirlerin sayfa bazında listesi.
• Her bir test aşamasının (tasarım, geliştirme, KG vb.) ne kadar süreceğini tahmin ediyorsunuz.
• Önceden hesaplanmış numune boyutu gereksinimlerine göre her bir testi ne kadar süreyle çalıştırmayı planladığınız. Bunun gibi bir test süresi hesaplayıcı kullanarak test süresi gereksinimlerini hesaplayabilirsiniz.

Test fikirlerinizi planlayarak, test temposunu ve kapasitesini daha doğru bir şekilde belirleyebilirsiniz.

Test yol haritanızı doldururken, çalıştırabileceğiniz test sayısının elinizdeki kaynaklara bağlı olduğu çok açık hale gelebilir.

Aynı Anda Birden Çok Test Çalıştırmalı Mısınız?

Ama bir şeyi yapabiliyor olman her zaman yapman gerektiği anlamına gelmez.

Aynı anda birden çok test çalıştırma söz konusu olduğunda, en iyi yaklaşım hakkında büyük tartışmalar vardır.

Deney Ulusu lideri Rommil Santiago tarafından yazılan buna benzer makaleler tartışmalı bir soruyu gündeme getiriyor: Aynı anda birden fazla A/B testi yapmak uygun mu?

Bazı deneyciler kesinlikle hayır diyecektir!

Her seferinde bir sayfa olmak üzere yalnızca bir test yapmanız gerektiğini savunacaklar. Aksi takdirde, herhangi bir efekti uygun şekilde izole edemezsiniz.

Eskiden bu kamptaydım çünkü yaklaşık on yıl önce bana bu şekilde öğretildi.

Bir seferde tek bir sayfada tek bir değişiklikle yalnızca bir test yapmanız gerektiği bana kesinlikle öğretildi. Uzun yıllar bu zihniyetle çalıştım - daha hızlı daha fazla sonuç isteyen endişeli müşterileri dehşete düşürdü.

Ancak, Facebook'ta eski bir veri bilimcisi ve şimdi Statsig'de baş veri bilimcisi olan Timothy Chan'ın bu makalesi fikrimi tamamen değiştirdi.

Chan, yazısında etkileşim etkilerinin çok abartıldığını savunuyor.

Aslında, birden çok testi aynı anda çalıştırmak sorun olmaktan çıkmakla kalmaz; gerçekten test etmenin tek yolu bu!

Bu duruş, Chan'ın sosyal medya devinin birçoğu aynı sayfada olmak üzere aynı anda yüzlerce deneyi başarıyla yürüttüğünü gördüğü Facebook'ta geçirdiği zamana ait verilerle destekleniyor.

Ronny Kohavi ve Hazjier Pourkhalkhali gibi veri uzmanları aynı fikirde: etkileşim etkileri pek olası değil. Ve aslında, başarıyı test etmenin en iyi yolu, sürekli olarak birden çok kez birden çok test yapmaktır.

Bu nedenle, test temposunu düşünürken, çakışan testlerin etkileşim etkisi konusunda endişelenmeyin. Serbestçe test edin.

Özet

A/B testinde, çalıştırmanız gereken optimum sayıda A/B testi yoktur.

İdeal sayı, benzersiz durumunuz için doğru olan sayıdır.

Bu sayı, sitenizin örnek boyutu kısıtlamaları, fikirleri test etmenin karmaşıklığı ve mevcut destek ve kaynaklar dahil olmak üzere çeşitli faktörlere bağlıdır.

Sonuçta önemli olan yaptığınız testlerin sayısı değil, testlerin kalitesi ve elde ettiğiniz sonuçlardır. Büyük bir artış sağlayan tek bir test, iğneyi hareket ettirmeyen birkaç sonuçsuz testten çok daha değerlidir.

Test gerçekten nicelikten çok nitelikle ilgilidir!

A/B testi programınızdan en yüksek değeri nasıl alacağınız hakkında daha fazla bilgi için bu Dönüştürme makalesine göz atın.