Dönüşüm Optimizasyonu

A/B Testine Başlarken: İlk Testini Nasıl Kurarsın, Ne Zaman 'Kazandı' Dersin?

DDijital Kafa11 Temmuz 20268 dk okuma

Dönüşüm oranı optimizasyonu (CRO) bir fikir yarışması değil, bir ölçüm disiplini. "Bence bu buton daha iyi çalışır" cümlesiyle başlayan her değişiklik, aslında test edilmemiş bir tahmin. A/B testi tam da bunu çözer: iki versiyonu aynı anda gerçek trafikte yarıştırıp kazananı veriyle belirlersin. Ama işin sırrı testi çalıştırmakta değil, doğru kurmakta. Çünkü ilk testini kuranların çoğu aynı üç hatayı yapar: iki günde "kazandı" ilan eder, aynı anda beş şeyi birden değiştirir ve dönüşümü zerre etkilemeyecek bir ayrıntıyı test eder.

Bu yazı, açılış sayfasındaki CRO hatalarının son maddesini — "test etmeden karar verme"yi — derinleştiriyor ve GA4'te bakman gereken ilk 10 metriği bir test döngüsüne nasıl çevireceğini gösteriyor.

İyi bir hipotezin anatomisi

Test, "şunu değiştirelim de bakalım" ile değil, bir hipotezle başlar. İyi bir hipotezin üç parçası vardır:

[Değişiklik] yaparsak, [çünkü şu sebep], [şu metrik]'in artmasını bekliyoruz.

Örnek:

Form alanlarını 7'den 3'e indirirsek, çünkü kullanıcı fazla alanda yorulup vazgeçiyor, form tamamlama oranının artmasını bekliyoruz.

Bu yapı üç işi birden yapar: neyi değiştirdiğini, neden değiştirdiğini ve hangi metrikten sonuç beklediğini net bağlar. "Sebep" kısmı en önemlisi — çünkü seni bir gözleme (GA4'te form terkinin yüksek olması, ısı haritasında kullanıcıların takıldığı yer) dayanmaya zorlar. Sebebi olmayan test, kumar oynamaktır.

Kural 1: Aynı anda tek büyük değişken

En sık hata: başlığı, görseli, CTA'yı ve formu aynı anda değiştirip test etmek. Diyelim ki B versiyonu kazandı — peki hangi değişiklik kazandırdı? Bilemezsin. Belki başlık işe yaradı, görsel ise zarar verdi ama başlığın etkisi onu bastırdı. Öğrenemediğin bir zafer, bir sonraki teste taşınamaz.

  • Bir test = bir hipotez = bir büyük değişken. Kazananın neden kazandığını bilmek istiyorsan başka yolu yok.

  • İstisna: birden çok öğeyi birlikte değiştirmenin bilinçli olduğu "radikal yeniden tasarım" testleri vardır — ama bunlar öğrenme değil, sonuç odaklıdır ve ileri seviyedir. İlk testin için tek değişkende kal.

Kural 2: Neyi test etmeli — yüksek trafik × yüksek etki

Buton rengini test etmek popülerdir ama nadiren kazandırır. Sınırlı trafiğini ve süreni, sonucu gerçekten değiştirebilecek öğelere ayır:

  • Yüksek etki potansiyeli: ana başlık (değer önerisi), CTA metni, teklifin kendisi, form uzunluğu, fiyat sunumu, sayfa yapısı.

  • Düşük etki (sonraya bırak): buton rengi, ikon, minik metin rötuşları.

  • Yüksek trafikli sayfa seç: en çok ziyaret alan açılış sayfaları hem daha hızlı sonuç verir hem de kazanç mutlak olarak daha büyüktür. Ayda 200 kişi gören sayfada test yapmak haftalar sürer ve çoğu zaman sonuçsuz kalır.

Kural 3: Örneklem ve süre — neden iki gün yetmez?

İlk testini kuranların en pahalı hatası: iki gün sonra B öndedir, testi durdurur, "kazandı" der. Oysa o fark büyük olasılıkla gürültüdür. İki neden:

  1. Yeterli dönüşüm gerekir. 5'e 8 dönüşüm arasındaki fark rastlantı olabilir; 150'ye 210 arasındaki fark bir sinyaldir. Testin, versiyon başına anlamlı sayıda dönüşüm biriktirmesi gerekir — ziyaretçi değil, dönüşüm.

  2. En az 1-2 tam hafta çalıştır. Haftanın günleri farklı davranır: hafta içi alışveriş edeni, hafta sonu göz gezdireni aynı değildir. Testi tam haftalar boyunca çalıştırmak bu dalgalanmayı dengeler. Ödeme döngüleri, kampanya günleri gibi etkenler de tam haftalarla yumuşar.

"Peeking" tuzağı: Teste her gün bakıp "şu an öndeyken durdurayım" demek, istatistiği bozar. Ne kadar çok kez erken bakarsan, rastlantısal bir farkı "kazanç" sanma ihtimalin o kadar artar. Baştan bir bitiş kriteri belirle (hedef dönüşüm sayısı + minimum süre) ve ona kadar sonuca dokunma.

İstatistiksel anlamlılık — sade dille

Test araçları sana bir "güven düzeyi" gösterir; yaygın eşik %95. Bu şu demek: gözlemlediğin fark, gerçekte hiç fark yokken bile rastlantıyla ortaya çıkmış olabilir — ve %95 güven, bu rastlantı ihtimalinin %5'in altına indiği noktadır. Kısaca anlamlılık, gürültüyü gerçek farktan ayırma işidir.

Pratik sonuç: düşük trafikte test uzun sürer. Bu bir kusur değil, matematiğin gereği. Trafiğin azsa iki seçeneğin var — ya testi daha uzun çalıştırırsın ya da daha büyük bir değişiklik test edersin (küçük farkları yakalamak çok daha fazla veri ister). Gerçekçi ol: her sayfa A/B testine uygun değildir; çok düşük trafikte nitel yöntemler (kullanıcı görüşmesi, oturum kaydı) daha hızlı öğretir.

Birincil metrik + guardrail (koruma) metriği

Her testin tek bir birincil metriği olmalı. Hipotezinde belirttiğin metrik. Ama sadece ona bakmak yanıltıcı. Yanına bir de guardrail (koruma) metriği koy:

  • Ödeme adımını hızlandırdın, dönüşüm arttı - ama iade oranı da fırladıysa gerçek kazanç yok.

  • Formu kısalttın, gönderim arttı - ama gelen leadlerin kalitesi düştüyse satış tarafı zarar eder.

  • Daha agresif bir başlıkla tıklama arttı - ama sayfada kalma / etkileşim çöktüyse mesaj uyumsuzluğu yaratmışsındır.

Birincil metrik "kazandık mı?" sorusuna, guardrail "kazanırken başka bir yeri bozduk mu?" sorusuna cevap verir. İkisi birlikte okunur.

İyi bir A/B testi hipotezinin anatomisi: değişiklik + sebep + beklenen metrik; ve kaçınılacak üç hata

Sağlam hipotez üç parçadan oluşur; sağdaki üç hata ise ilk testlerin en sık öldüğü yerlerdir.

Araç notu: A/B testini bugün neyle çalıştırırsın?

Bir zamanlar ücretsiz standart olan Google Optimize, Eylül 2023'te kapandı. Bugün A/B testleri için:

  • Üçüncü parti test araçları: VWO, Optimizely, AB Tasty ve benzerleri — görsel editör + istatistik motoru sunar.

  • Sunucu tarafı / feature-flag testleri: geliştirici desteğiyle, özellikle uygulama ve dinamik sitelerde daha sağlam ölçüm.

  • GA4'ün rolü: GA4 tek başına A/B testi çalıştırmaz. Ama testin sonucunu ölçmek, segmentlere kırmak ve guardrail metriklerini izlemek için asıl referansın odur. Testi araç kurar, doğrulamayı GA4 yapar.

Araç seçimi, testin doğru kurulmasından daha az önemlidir; pahalı bir araç kötü hipotezi kurtarmaz.

En sık yapılan hatalar

  • İki günde, birkaç dönüşümle "kazandı" ilan etmek.

  • Aynı anda birçok öğeyi değiştirip kazananın nedenini kaybetmek.

  • Dönüşüme etkisi düşük ayrıntıları (buton rengi) test etmek.

  • Teste her gün bakıp erken durdurmak (peeking).

  • Guardrail metriği olmadan sadece birincil metriğe sevinmek.

  • Çok düşük trafikte A/B testinde ısrar etmek.

  • Hipotezsiz, "bir bakalım" diye test açmak.

  • Hızlı kontrol listesi

    • Testin bir gözleme dayanan net bir hipotezi var mı? (değişiklik + sebep + metrik)

    • Sadece tek büyük değişkeni mi değiştiriyorsun?

    • Yüksek trafikli, yüksek etkili bir öğeyi mi test ediyorsun?

    • Bitiş kriterini (hedef dönüşüm + min. 1-2 tam hafta) baştan belirledin mi?

    • Erken bakıp durdurmayacağına karar verdin mi?

    • Bir birincil metrik + bir guardrail metriğin var mı?

    • Sonucu GA4'te segmentlere kırarak doğrulayacak mısın?

    Dijital Kafa yorumu

    İyi bir test kültürünün sırrı hız değil, disiplindir: bir gözlem, bir hipotez, tek değişken, sabırlı bir süre ve dürüst bir okuma. Gördüğümüz en yaygın kayıp, "istatistiksel olarak kazandı" denen ama guardrail metriği hiç bakılmamış testlerdir — dönüşüm artmış, ama lead kalitesi ya da iade tarafından sessizce bedeli ödenmiştir.

    Dönüşüm optimizasyonu çalışmalarımızda testleri tek tek "deneme" olarak değil, önceliklendirilmiş bir öğrenme programı olarak kuruyoruz; veri ölçümleme tarafıyla birlikte ele alınca her test bir sonrakini besleyen bir bilgi bırakıyor. İlk test döngünü doğru kurmak istersen, bizimle iletişime geçebilirsin.

    İlgili Yazılar