Çoğu satıcı A/B testini bir buton rengi meselesi sanır. İki renk dener, birinde satış biraz yüksek çıkar, "bulduk" der ve aynı yanılgıyla aylarca devam eder. Oysa o farkın büyük kısmı istatistiksel gürültüdür ve o test hiçbir şey öğretmemiştir. Yanlış öğeyi test etmek, hiç test etmemekten daha pahalıdır çünkü seni doğru yaptığına inandırır.
Bu yazıda A/B testini e-pin ve dijital ürün satışı bağlamında nasıl kuracağını, hangi öğelerin gerçekten kazandırdığını ve hangi öğelerin trafiğin yetmediği için asla sonuç vermeyeceğini anlatacağım. Ayrıca kullandığın dijital ürün satış scriptinin üzerinde testi ölçülebilir biçimde kurmanın teknik iskeletini vereceğim. Süslü araç gerekmiyor; gereken şey doğru sıralama.
Çoğu A/B testi neden hiçbir şey öğretmeden bitiyor?
Çünkü test, karar verebilmek için gereken veriye ulaşmadan kapatılıyor. Örneklem hesabı yapmadan başlayan bir test, sonucu "okuyan kişinin beklentisine" göre yorumlanır. İlk gün A öndeyse A kazanır, üçüncü gün B öndeyse B kazanır. Bu, test değil kumar okumadır.
İkinci sebep, ölçülen olayın yanlış seçilmesidir. Butona tıklama arttı diye sevinen çok satıcı gördüm; ödeme tamamlama aynı kalmıştı. Tıklama bir ara metriktir ve yanıltıcıdır. Tek geçerli hedef olay, tamamlanmış ve teslim edilmiş sipariştir. Testin hedefini bu olaya bağlamazsan ne ölçtüğünü bilemezsin.
Trafiğin yetmiyorsa hangi öğeleri test etmelisin?
Ayda birkaç yüz sipariş alıyorsan mikro öğeleri test etmeye hakkın yok; matematik buna izin vermiyor. Küçük etkileri görmek için büyük örneklem gerekir. Senin yapman gereken, büyük etki potansiyeli olan az sayıda öğeye odaklanmaktır: ödeme akışının adım sayısı, fiyat sunum biçimi, teslimat vaadi metni, kayıt zorunluluğu.
Bu öğeler %10 üzerinde fark üretebildikleri için düşük trafikte de istatistiksel olarak ayırt edilebilirler. Buna karşılık başlık yazı tipi, ikon seti veya buton gölgesi gibi kalemler %1-2 seviyesinde oynar ve o farkı görebilmek için on binlerce işleme ihtiyacın olur. Kararı duyguna değil, tespit edilebilirlik eşiğine göre ver.
| Test edilecek öğe | Beklenen etki | Gereken sipariş/kol | Sıra |
|---|---|---|---|
| Ödeme adımı sayısı (3 → 1) | %12-20 | ~250 | 1 |
| Üyeliksiz satın alma | %8-15 | ~400 | 2 |
| Teslimat süresi vaadi metni | %6-12 | ~600 | 3 |
| Fiyat gösterim biçimi (TL/paket) | %5-10 | ~800 | 4 |
| Güven rozetleri konumu | %3-6 | ~2.000 | 5 |
| Ürün kartı düzeni | %2-5 | ~3.500 | 6 |
| Buton rengi / metni | %1-3 | ~10.000 | Son |
Test edilecek öğelerin gizli hiyerarşisi nasıl işler?
Hiyerarşi tek bir mantığa dayanır: kullanıcının vazgeçme anına ne kadar yakınsan etkin o kadar büyüktür. Ana sayfadaki görsel, kullanıcının vazgeçme anından çok uzaktadır; ödeme ekranındaki ek form alanı ise tam vazgeçme anındadır. Bu yüzden ödeme ekranındaki bir alanın kaldırılması, ana sayfadaki on değişiklikten daha fazla getirir.
Bu hiyerarşiyi panelinde uygulamak için akışı geriye doğru yürü: teslimat, ödeme onayı, ödeme yöntemi seçimi, sepet, ürün sayfası, liste, ana sayfa. Terk oranının en yüksek olduğu adımdan başla ve orada test et. Doğru kurulmuş bir e-pin satış yazılımı adım adım terk verisini sana verir; vermiyorsa ilk testin zaten ölçüm kurmak olmalı.
Aynı anda kaç şeyi değiştirebilirsin?
Klasik cevap "bir" ama bu her zaman doğru değil. Trafiğin düşükse tek bir mikro değişiklik test etmek aylarca sürer ve sonuçsuz kalır. Bu durumda tema testi yapmak daha akıllıdır: birbirini destekleyen değişiklikleri tek pakette uygula, paketi teste sok. Kazanırsa hangi parçanın katkı verdiğini bilemezsin ama en azından kazanırsın.
Buna karşılık trafiğin yüksekse ve öğrenmek istiyorsan tek değişkenli teste sadık kal. Paket testi kazanç odaklıdır, tek değişkenli test bilgi odaklıdır. Hangisine ihtiyacın olduğunu cironun büyüklüğü belirler, kitaplar belirlemez. Küçükken kazan, büyüdükçe öğren.
A/B testi başarısızlıklarının sebep dağılımı
- Yetersiz örneklem 42%
- Yanlış hedef olay 26%
- Etkisi çok küçük öğe seçimi 20%
- Teknik bölünme hatası 12%
Kazandı sandığın varyantın seni yanılttığı üç durum
Birincisi erken bakma. Teste her gün bakıp öne geçeni ilan etmek, yanlış pozitif oranını ciddi biçimde şişirir. Bitiş koşulunu testi başlatmadan yaz ve ona uy. İkincisi mevsimsel çakışma. Kampanya, oyun güncellemesi veya maaş günü etkisi bir kolu şişirebilir; bu yüzden test süresi tam hafta katlarında olmalı ve kampanya dönemlerine denk gelmemeli.
Üçüncüsü ve en sinsisi bölünme sızıntısı. Kullanıcı bir kolda görüp diğer kolda satın alıyorsa veri karışır. Bunun sebebi genelde önbellek, CDN veya oturum yönetimidir. Varyant atamasını kullanıcı kimliğine sabitle, önbelleği varyanta göre ayır. Bu üç tuzağı kapatmadan yapılan hiçbir test güvenilir değildir. Teknik yeteneklere /#ozellikler bölümünden bakabilirsin.
"Kol başına en az N tamamlanmış sipariş toplandığında ve en az iki tam hafta geçtiğinde bakacağım." Bu cümleyi yazmayan testlerin çoğu gürültüyü zafer sanarak biter.
Testi panelden nasıl kurarsın: teknik iskelet
Harici araç şart değil. Sunucu tarafında üç parça yeter: kullanıcıya sabit bir varyant atayan bir fonksiyon, varyantı sipariş kaydına yazan bir alan, ve kol bazında dönüşümü raporlayan bir sorgu. Varyant atamasında kullanıcı kimliğinin veya kalıcı bir çerez değerinin karmasını kullan; rastgele sayı kullanma çünkü her istekte değişir.
Sipariş tablosuna eklediğin tek bir ab_variant alanı, raporlamanın tamamını mümkün kılar. Böylece "A kolunda 6.318 oturum, 214 sipariş; B kolunda 6.402 oturum, 251 sipariş" cümlesini kurabilirsin ve karar verilebilir bir veriye sahip olursun. Modern bir epin yazılım altyapısında bu üç parçayı kurmak yarım gün sürer ve sonrasında her testin maliyeti neredeyse sıfıra iner. Maliyet tarafını /#fiyat bölümünde görebilirsin.
| Kurulum kontrolü | Neden gerekli | Kim yapar | Durum |
|---|---|---|---|
| Hipotez tek cümleyle yazıldı | Yorum kaymasını engeller | İşletme sahibi | Zorunlu |
| Hedef olay = tamamlanmış sipariş | Ara metrik yanıltır | İşletme sahibi | Zorunlu |
| Örneklem ve süre önceden belirlendi | Erken bakmayı bitirir | Analitik | Zorunlu |
| Varyant kimliğe sabitlendi | Sızıntıyı önler | Geliştirici | Zorunlu |
| Önbellek varyanta göre ayrıldı | CDN karışmasını önler | Geliştirici | Zorunlu |
| Varyant sipariş kaydına yazılıyor | Raporlamayı mümkün kılar | Geliştirici | Zorunlu |
| Kampanya takvimi kontrol edildi | Mevsimsel sapmayı keser | Pazarlama | Önerilir |
| Kaybeden varyant tamamen kaldırıldı | Teknik borcu engeller | Geliştirici | Önerilir |
Test altyapısını sıfırdan kurmakla uğraşmak ister misin?
Pinova, sipariş akışının her adımını ve varyant bazlı raporlamayı aynı panelde tutar. Hipotezini yaz, kolları aç, kararı veriyle ver.
Ayda 200 siparişle A/B testi yapabilir miyim?
Yapabilirsin ama sadece büyük etkili öğelerde. Ödeme adımı sayısı veya üyeliksiz satın alma gibi kalemleri test et; buton rengi gibi mikro öğeler bu hacimde asla anlamlı sonuç vermez.
Testi ne zaman kapatmalıyım?
Başlamadan önce yazdığın iki koşul birlikte sağlandığında: kol başına hedeflenen sipariş sayısı dolduğunda ve en az iki tam hafta geçtiğinde. Arada bakmak kararı bozar.
Aynı anda iki test çalıştırabilir miyim?
Farklı akış adımlarındaysa ve birbirini etkilemiyorsa evet. Aynı ekranda iki test çalıştırırsan etkileri ayrıştıramazsın; bu durumda ikisini tek paket testine çevir.
Kullandığım e-pin scripti A/B testini destekliyor mu?
Sipariş kaydına özel alan eklemene, şablonu koşullu üretmene ve adım bazlı terk verisi almana izin veriyorsa destekliyor demektir. Bu üçü varsa harici araca ihtiyacın kalmaz.
A/B testinin sırrı araçta değil, sırada. Vazgeçme anına en yakın ve etkisi en büyük öğeden başla, hedefi tamamlanmış siparişe bağla, bitiş koşulunu önceden yaz. Varyant bazlı raporlamanın ve adım adım sipariş akışının bir panelde nasıl göründüğünü merak ediyorsan canlı demo üzerinden ödeme adımlarını sırayla deneyip terk noktalarının nerede raporlandığına bakabilirsin.