A / B testi sıklıkla tasarım kararlarını doğrulamak için bilimsel bir yöntem olarak faturalandırılır. Bazen bölünmüş test olarak adlandırılan A / B testi, yüzeyde somut sonuçlar vaat ettiği için basit bir süreçtir:
Bir tasarım öğesinde iki varyasyon oluşturun, bunları sitenizde rastgele değiştirin ve kullanıcılarınızın nasıl tepki verdiğini kaydedin, sonuçları karşılaştırın, hangisi en iyi gerçekleştirilmişse uygulayın. Mantıklı.
Klasik örnek: daha fazla tıklanacak olan yeşil düğmeye karşı kırmızı bir düğme mi? Ancak, daha ilginç olan soru: yeşil düğmeye, aynı yeşil düğmeye daha fazla dokunacak mı?
A / B iki özdeş varyasyonu test ettiğimizde ne olur? Eğer yapacaksan A / A testi.
Herhangi bir A / B testinin geçerliliğini test etmek için, 'doğru' cevabı olan bir sınava ihtiyacımız var. Doğru bir cevaba ihtiyacımız var çünkü bilmek istiyoruz, her şeyin eşit olması, A / B testinin sonucunu üretmesinin ne kadar muhtemel olduğu ve bunun için hangi sonucun beklendiğini bilmemiz gerekiyor.
Eğer A / B iki aynı düğmeyi test ederse, sonuç ölü bir ısı olmalıdır.
Öyleyse, yeşil düğmeye ve aynı yeşil düğmeye karşı test yaptığımızı ve düğmenin kullanıcıların% 100'ünün buna dokunacağını fark ettiğimizi varsayalım.
(Yüzde aslında önemli değil,% 14.872 olabilir. Önemli olan, düğmelerin aynı olması, musluk oranının da aynı olması gerektiğidir.)
Eğer A / B iki aynı düğmeyi test ederse, sonuç ölü bir ısı olmalıdır .
Bozuk para atmak. Hangi taraf gelecek, kafa mı, kuyruk mu gelecek? İki tarafın da olduğunu biliyoruz, ikisi de aynı, bu yüzden 50-50 şans.
Madalyonuzu iki kez atlarsak, üç olası sonuç olduğunu biliyoruz: 2 kafa, 2 kuyruk veya 1 kafa ve 1 kuyruk. Ve bunun gibi…
Madeni para atmanın A / A testimiz olduğunu varsayalım; kafalar tarafının ortaya çıkma ihtimali, kuyruklar tarafının yaklaşmasıyla aynıdır, tıpkı bizim yeşil düğmelerimizin herhangi birinin hızının eşit olması gibi.
Bu yüzden tarayıcıda hızlı bir komut dosyası yazalım (en çok A / B testi, tarayıcıda gerçekleştiği için), hangisinin sunulduğuna bağlı olarak, bir düğmeye veya diğerine dokunarak kullanıcıları simüle etmek için.
Unutmayın: Bir düğmenin iki aynı varyasyonunu test ediyoruz ve aynı olduklarını bildiğimiz yol, onların aynı olduğu gibi olma olasılığını ele almamızdır. Tek istediğimiz tutarlı (ve dolayısıyla doğru) bir sonuçtur.
İlk olarak, sonuçlarımızı kaydetmek için bir HTML tablosuna ihtiyacımız var, tablo şöyle görünecek:
# Heads Tails Difference Margin of Error
İlk sütunda testin sayısını kaydedeceğiz (tüm iyi A / B testleri, sonuçları doğrulamak için tekrarlanır, böylece testi birkaç kez tekrar ederiz). Ardından, Heads sonuçlarının sayısını, ardından Kuyrukların sonuçlarının sayısını kaydedeceğiz. Bundan sonraki sütun, iki sonuç arasındaki fark olacaktır (sıfır olmalıdır ). Ardından hata payını kaydederiz (yine,% 0 olmalıdır). Tablo altında bir özet, tüm sonuçların ortalamasını ve en kötü durum sonucunu yazdıracağız.
İşte senaryo:
var bestOf = 12, // the number of times we want to run the testtestRepeat = 12, // the number of times we’d like to repeat the testtestCount = 0, // the number of the current testtestInterval = setInterval(performCoinToss, 100), // call the coin toss functiontotalDifference = 0, // used for calculating the average differenceworstDifference = 0; // the worst casefunction performCoinToss(){testCount++; // increment the current testvar testCounter = bestOf, // the current iteration of the testheadsCounter = 0, // the total number of times the script came up with "heads"tailsCounter = 0; // the total number of times the script came up with "tails"while(testCounter--) // loop 'testCounter' times{Math.round(Math.random()) ? headsCounter++ : tailsCounter++; // finds 0 or 1 randomly, if 1 increments headsCounter, otherwise increments tailsCounter}var difference = Math.abs(headsCounter - tailsCounter), // the difference between the twoerror = (difference / bestOf) * 100; // the error percentagedocument.getElementById("results").innerHTML += "" + testCount + " " + headsCounter + " " + tailsCounter + " " + difference + " " + error + "% Average difference: " + averageDifference + "
Average margin of error: " + averageError + "%
Worst Case: " + worstDifference + "
"; // write summary to pageclearInterval(testInterval); // if the test has been repeated enough times, clear the interval}}Kod yorumlandı, yani burada sadece önemli noktalar var:
Öncelikle, parayı (bestOf) atmak istediğimiz zaman sayısını ve testi tekrarlamak istediğimiz zaman sayısını (testRepeat) içeren bazı değişkenler oluşturuyoruz.
Spoiler uyarısı: bazı oldukça yüksek döngülere gireceğiz, böylece herhangi birinin tarayıcısını kırmamak için testi her 100 ms'de bir aralıkta çalıştırıyoruz.
PerformCoinToss işlevinin içinde gereken sayıda döngü yaparız, her döngü yinelemede JavaScript'in rasgele işlevini kullanırız; ya 1 veya 0 üretir, ki bu da ya headCounter'ı veya tailsCounter'ı artırır .
Daha sonra, bu testin sonucunu tabloya yazıyoruz.
Son olarak, eğer test tekrar edersek kaç kez tekrar edersek, ortalamaları ve en kötü durumları buluruz, bunları özete yazarız ve aralıkları temizleriz.
İşte sonuç . Ortalama farkı görebildiğiniz gibi, bu sizin için farklı olacaktır, ancak yazarken ortalama fark 2.8333333333333335, ortalama hata bu nedenle 23.611111111111114% 'dir.
% 23'ten fazla hata, özellikle de farkın% 0 olması gerektiğini bildiğimiz için, güven duymaz. Daha da kötüsü, en kötü durumumun 8 olması, bu da 10–2'lik kafalar lehine olmasıdır.
Tamam, bu yüzden test adil değildi. Gerçek bir A / B testi, yalnızca 12 kullanıcıdan kesin bir sonuç bulmayı asla istemez.
A / B testi, “istatistiksel anlamlılık” olarak adlandırılan bir şeyi kullanır, bu da testin işlem yapılabilir bir sonuca ulaşmak için yeterli zamana sahip olması gerektiği anlamına gelir.
Yani, en iyiOf değişkenini ikiye katlayalım ve% 1'den daha az bir hata payı elde etmek için ne kadar yol katettiğimizi görelim -% 99 güvene eşdeğer.
En iyi 24'te (yazma anında) ortalama fark 3.1666666666666665, yani 13.194444444444445%. Doğru yönde bir adım! Kendin için dene (sonuçlarınız değişecektir).
Hadi tekrar iki katına çıkalım. Bu sefer, ortalama farkım 6.666666666666667, 13.88888888888889% hata payı ile. Daha da kötüsü, en kötü durum 16, bu 33.33333333333333% bir hata! Yapabilirsin bunu dene kendiniz için de.
Aslında, devam edebileceğimizi tahmin etmek için ödül yok: 96'nın en iyisi , 192’nin en iyisi , 384'ün en iyisi , 768'in en iyisi , 1536'nın en iyisi , 3072'nin en iyisi , 6144'ün en iyisi , 12288 en iyisi , 24576 en iyisi , 49152 en iyisi , 98304'ün en iyisi .
Son olarak, 98304'ün en iyisinde en kötü durum senaryosu% 1'in altına düşer. Başka bir deyişle, testin doğru olduğundan% 99 emin olabiliriz.
Dolayısıyla, önceden bildiğimiz bir A / A testinde, kabul edilebilir bir hata payına ulaşmak için 98.304'lük bir örnek büyüklüğüne sahip oldu.
A / B testi ele alındığında, biri A / B'nin kendi sitesinde tek bir düğmeyi test ettiği bir arkadaşın arkadaşını hatırlatır ve derhal bazı kârsızlıklara neden olur (her duyduğumda düğmenin gerçek dolar değeri artar. Öykü).
Bu masallarda düğmeler genellikle mikro-kopya, “E-kitabımı indir” ve “Ücretsiz e-kitabımı indir” için test edilir. İkincisinin kazandığı bir sürpriz olmamalı. İyi bir yazarın yapacağı bir gelişme. Daha uygun bir A / B testi “E-kitabımı indir” e karşı “E-kitabı indir” (benim paramın ikincisini) olacaktır.
Kendinizi seçeneklerden birine doğru ağır bir sonuçla bulursanız, varyasyonlarınızdan biriyle bir şeylerin yanlış olduğunu gösterir. Daha sık olarak, iyi bir sonuç% 5'in altında bir iyileşme olacaktır, bu da yaklaşık 1000 kullanıcı ile test ediyorsanız sorun yaratır (hata payı% 5 civarındadır).
Bir test ne kadar faydalı olursa, bir varyasyon ya da diğeri için zafer marjı o kadar sıkı olur. Bununla birlikte, zafer marjı ne kadar sıkı olursa, size örnek olarak kabul edilebilir küçük bir hata payı vermesi için gereken büyüklük artar.
Mark Twain, muhtemelen Disraeli'den alıntı yaparak, bir keresinde şu ifadeyi kullandı: yalanlar, lanet olası yalanlar ve istatistikler. Bu, istatistiklerle kanıtlanmış bir şey anlamına geldiği için, mutlaka doğru değildir. İstatistikler, istediklerini kanıtlamak için kullanılabilir.
A / B testi size bir sonuç verecektir, ancak bu sizin ve müşterilerinizden daha fazlasını bulmanız için beklentileriniz hakkında daha fazla şey söyleyecektir.
A / B testi ile ilgili en tehlikeli şey, istediğiniz herhangi bir şeyi kanıtlayabilmesidir; Yanlış pozitifler üretebilir ve doğru şekilde desteklenmeyen kalıpları ayırt etmemizi sağlar.
Ayrıca bir A / B testi, yeşil bir düğmenin kırmızı bir düğmeden daha iyi olduğunu gösterebilir, ancak mavi düğme hakkında ne düşünüyorsunuz? Başarılı A / B testleri bile, tasarım kararlarımızı yalnızca testin kendi bağlamında doğrulamamıza izin verir.
Bir A / B testinin amaçlandığı şekilde çalışması için, iki karşıt koşulun doğru olması gerekir:
Ne yazık ki çoğu sitenin yeterince küçük bir hata payına ulaşacak kadar büyük bir örnek boyutu yoktur. Ve örneklem büyüklüğümüzü artıramayacağımızdan (eğer yapabilirdik), tek tercihimiz, tercihlerimizle testi netleştirmek için net bir sonuç elde etmek için seçeneklerin çeşitliliğini arttırmaktır.
A / B testi size bir sonuç verecektir, ancak sizin ve müşterilerinizden daha fazlasını bulmanız için beklediğiniz şey hakkında daha fazla şey söyleyeceğiniz bir sonuçtur. Çok yüksek trafik hacmine sahip olanlardan başka herhangi bir sitede tasarım kararları vermek söz konusu olduğunda, A / B testi olarak bir bozuk para atmış olabiliriz.
Özellikli resim, sikke görüntü atmak Shutterstock üzerinden.