A/B Testi Nasıl Yapılır? Bir Affiliate Landing Page Testini Baştan Sona Yürütmek

Bir landing page'in başlığını değiştirdiniz, ertesi hafta satışlar arttı. Başlık mı işe yaradı, yoksa o hafta maaş günü müydü? A/B testi nasıl yapılır sorusunun özü bu belirsizliği ortadan kaldırmaktır: aynı dönemde gelen ziyaretçileri rastgele iki gruba ayırır, birine mevcut sayfayı, diğerine değiştirilmiş sayfayı gösterir ve farkı önceden seçtiğiniz bir metrikle ölçersiniz.

Bu rehberde istatistik dersine girmeden, tek bir affiliate landing page testini hipotezden karara kadar uçtan uca yürütüyoruz. Örneğimizde varyantları ağ raporunda ayırmak için sub ID kullanacağız; çünkü affiliate dünyasında asıl sonuç, yani onaylanmış dönüşüm, sizin sayfanızda değil ağın kayıtlarında oluşur. Örneklem hesabı ve anlamlılık yorumu gibi derin konular için ilgili kardeş yazılara yönlendireceğiz.

A/B testi nedir ve affiliate kampanyalarında neden farklıdır?

A/B testi, trafiği eşzamanlı ve rastgele iki sürüme bölerek tek bir değişikliğin sonuca etkisini ölçen kontrollü bir deney yöntemidir. Mevcut sürüme "kontrol" ya da A, değiştirilmiş sürüme "varyant" ya da B denir. Eşzamanlılık ve rastgelelik, mevsim, kampanya dönemi veya trafik kaynağındaki değişimlerin iki grubu eşit etkilemesini sağlar.

Affiliate kampanyalarında testin üç farkı vardır. Birincisi, dönüşüm çoğu zaman sizin sayfanızda değil, reklamverenin sitesinde gerçekleşir. İkincisi, dönüşüm anında kesinleşmez; iptal, iade veya geçersiz lead gerekçesiyle sonradan reddedilebilir. Üçüncüsü, dönüşüm tıklamadan saatler hatta günler sonra gelebilir. Bu üç fark, testin hem nasıl işaretleneceğini hem de ne zaman değerlendirileceğini belirler.

Adım 1: Sorunu tespit edin ve hipotezi yazın

İyi bir A/B testi, "şunu deneyelim" fikriyle değil, veride görülen somut bir sorunla başlar. Örneğimizdeki yayıncı, bir ev aletleri kampanyası için ücretli sosyal medya trafiğini kendi hazırladığı bir ara sayfaya gönderiyor. Isı haritası ve oturum kayıtları, ziyaretçilerin büyük bölümünün sayfanın ilk ekranında kalıp aşağı kaydırmadan çıktığını gösteriyor.

Hipotez, bu gözlemi test edilebilir bir öngörüye çevirir. Kullanışlı bir kalıp şöyledir: "[Gözlem] nedeniyle [değişiklik] yaparsak [metrik] [yön] yönde değişir, çünkü [gerekçe]." Örneğimizde hipotez şu: "Ziyaretçiler ilk ekranda karar veremeden çıktığı için, ilk ekrana ürünün üç somut faydasını ve sınırlı süreli indirim vurgusunu eklersek, ziyaretçi başına onaylanmış komisyon artar; çünkü ziyaretçi teklife geçmek için gereken bilgiyi kaydırmadan görür."

Hipotezi yazmanın iki faydası var. Test bittiğinde neyi öğrendiğinizi net biçimde söyleyebilirsiniz ve test sırasında hedef kaydırma yapamazsınız. Hipotez yazımı ve test fikirlerini önceliklendirme konusunu CRO test hipotezi nasıl yazılır rehberinde ayrıntılı ele aldık.

Adım 2: Birincil metriği ve koruma metriğini seçin

Birincil metrik, testin kazananını belirleyecek tek ölçüttür ve test başlamadan seçilir. Affiliate testlerinde en sık yapılan hata, kolay ölçüldüğü için tıklama oranını birincil metrik yapmaktır. Oysa daha fazla kişiyi teklife göndermek, daha fazla para kazanmak anlamına gelmez; düşük niyetli ziyaretçiyi teklife iten bir sayfa, tıklamayı artırırken onaylanmış satışı düşürebilir.

Örneğimizdeki yayıncı üç katmanlı bir metrik seti belirliyor:

• Birincil metrik: Ziyaretçi başına onaylanmış komisyon (onaylanan komisyon toplamı ÷ sayfa ziyaretçisi).
• Destekleyici metrikler: Teklife çıkış tıklama oranı ve ziyaretçi başına dönüşüm oranı. Bunlar sonucun nedenini açıklamaya yardım eder.
• Koruma metriği: Onay oranı (onaylanan dönüşüm ÷ toplam dönüşüm). Bu oran belirgin düşerse, birincil metrik iyi görünse bile varyant reklamverenle ilişkiyi zedeleyebilir.

Koruma metriği, özellikle agresif mesajların test edildiği durumlarda hayat kurtarır. "Son 2 saat" gibi baskı unsurları, ürünü gerçekten istemeyen kişileri de satın almaya iter; bu siparişlerin bir kısmı iade veya iptal edilir. Metriklerin tanımları ve birbirleriyle ilişkisi için EPC, CR ve ROAS metrikleri rehberine göz atabilirsiniz.

Adım 3: Örneklemi ve test süresini önceden belirleyin

Test süresi, "yeterince veri gelince bakarız" diye değil, test başlamadan hesaplanan bir örneklem büyüklüğüne göre belirlenir. Hesap üç girdiye dayanır: mevcut dönüşüm oranı, yakalamak istediğiniz en küçük iyileşme ve günlük ziyaretçi sayısı. Bu yazıda hesabın matematiğine girmiyoruz; adım adım formül ve tablolar A/B testinde örneklem büyüklüğü hesaplama rehberinde yer alıyor.

Örneğimizdeki yayıncının sayfası günde yaklaşık 1.400 ziyaretçi alıyor. Yüzde 1,2 civarındaki mevcut dönüşüm oranıyla yaklaşık yüzde 35 göreli bir iyileşmeyi yakalamak için yapılan hesap, varyant başına yaklaşık 9.800 ziyaretçiye ihtiyaç olduğunu gösteriyor; bu da iki varyant için yaklaşık 14 gün demek. Yayıncı süreyi tam iki hafta olarak sabitliyor: pazartesi başlayıp iki hafta sonraki pazar gece yarısı bitecek.

İki hafta kuralının mantığı basit: satın alma davranışı haftanın günlerine göre değişir. Hafta sonu gelen ziyaretçi ile salı sabahı gelen ziyaretçi aynı niyette olmayabilir. Testi tam haftalarla sınırlamak, varyantların her gün tipinden eşit pay almasını sağlar. Buna ek olarak affiliate tarafında bir bekleme payı eklenir: trafik kesildikten sonra gecikmeli dönüşümlerin gelmesi ve onay kararlarının verilmesi için beklenen süre. Bu kampanyada reklamveren siparişleri ortalama 10 günde onaylıyor; dolayısıyla nihai değerlendirme trafik bittikten 10–14 gün sonra yapılacak.

Adım 4: Varyantları hazırlayın ve sub ID ile işaretleyin

Varyant hazırlığında kural tektir: B, A'dan yalnızca hipotezde yazan değişiklikle ayrılmalıdır. Örneğimizde B sürümü ilk ekrana üç maddelik fayda listesi ve indirim vurgusu ekliyor; sayfanın geri kalanı, görseller, yükleme hızı ve teklif linkinin hedefi birebir aynı kalıyor. B'nin daha ağır bir görsel yüzünden yavaş açılması, testi farkında olmadan bir hız testine çevirir.

Sub ID, yayıncının affiliate linkine eklediği ve tıklamayla birlikte ağa taşınan serbest metin bir etikettir. Varyantları ayırmak için her sürümdeki teklif linkine farklı bir sub değeri verilir. Yayıncının şeması şöyle:

Varyant A linki: ...?sub1=meta&sub2=lp-firin-v1&sub3=test07-a
Varyant B linki: ...?sub1=meta&sub2=lp-firin-v1&sub3=test07-b

Burada sub1 trafik kaynağını, sub2 sayfayı, sub3 ise test numarasını ve varyantı taşıyor. Test kimliğini (test07) varyant harfiyle birlikte yazmak, aylar sonra raporlara baktığınızda hangi testin hangi satırı ürettiğini karıştırmamanızı sağlar. Tutarlı bir isimlendirme düzeni kurmak için sub ID adlandırma şeması rehberinden yararlanabilirsiniz.

Adfacten'de: Takip linklerinde sub1–sub10 alanları bulunur ve bu değerler tıklama, dönüşüm, onay ve red verisiyle birlikte gerçek zamanlı raporlarda geri döner. Bir testin varyantlarını sub3 gibi tek bir alanda işaretlediğinizde, raporu bu alana göre gruplayarak her varyantın onaylanan ve reddedilen dönüşümlerini sebep koduyla birlikte ayrı ayrı görebilirsiniz.

Adım 5: Trafiği rastgele ve eşit bölün

Trafik bölme, her ziyaretçinin hangi sürümü göreceğine rastgele ve kalıcı biçimde karar verme işlemidir. "Kalıcı" kısmı önemlidir: aynı kişi sayfaya ikinci kez geldiğinde aynı varyantı görmelidir; aksi halde bir ziyaretçi iki sürümden de etkilenir ve sonuç bulanıklaşır.

Affiliate yayıncıları için üç yaygın yöntem var:

1. Sunucu tarafında bölme: Ziyaretçi geldiğinde sunucu rastgele bir sayı üretir, sonucu bir çereze yazar ve ilgili sürümü gösterir. En temiz yöntemdir; sayfa titremesi olmaz.
2. Test aracıyla bölme: Bir A/B test aracı, aynı adres üzerinde sürümleri dönüşümlü gösterir. Kurulumu kolaydır ama yükleme sırasında kısa süreli içerik değişimi yaşanabilir.
3. Reklam platformunda bölme: Reklam platformunun deney özelliğiyle iki ayrı adrese eşit bütçe dağıtılır. Uygulaması basittir; ancak platformun teslimat algoritması iki kola farklı kitleler gösterebileceği için gerçek rastgelelik zayıflar.

Örneğimizdeki yayıncı birinci yöntemi seçiyor. Bölme oranı 50/50; çünkü eşit bölme, belirli bir toplam trafikle en hızlı sonuç veren düzendir. Riskli bir değişiklik test ediliyorsa trafiğin küçük bir kısmıyla başlamak mümkündür, ancak dengesiz bölmenin testi uzattığını bilmek gerekir.

Adım 6: Yayına almadan önce kalite kontrol yapın

Kalite kontrol, testin teknik olarak doğru veri ürettiğini trafik açılmadan doğrulama adımıdır. Yanlış kurulmuş bir test, iki haftalık trafiği ve bütçeyi boşa harcar; üstelik hata çoğu zaman sonuç gelene kadar fark edilmez.

Yayıncının kontrol listesi şöyle:

1. Her iki sürümü masaüstü ve mobilde açın; görsel bozulma, eksik buton veya kırık bağlantı olmadığını doğrulayın.
2. Gizli pencerede sayfayı birkaç kez açarak her iki varyantın da gerçekten gösterildiğini ve aynı tarayıcıda varyantın sabit kaldığını kontrol edin.
3. Her varyanttan birer test tıklaması yapın ve ağ raporunda tıklamanın doğru sub3 değeriyle düştüğünü görün.
4. İki sürümün yüklenme süresini ölçün; aradaki fark belirginse önce bunu giderin.
5. Analitik aracınızda sayfa ziyaretlerinin varyant etiketiyle ayrıştığını doğrulayın; ziyaretçi sayısı bu taraftan, dönüşüm verisi ağ tarafından gelecektir.
6. Test başlangıç tarihini, bitiş tarihini, hipotezi ve metrikleri bir test kaydına yazın.

Uçtan uca takibin doğrulanmasıyla ilgili daha kapsamlı bir prosedür için test siparişi ile uçtan uca takip doğrulama yazısına bakabilirsiniz.

Adım 7: Testi çalıştırın, ama sonuca dokunmayın

Test çalışırken yapılacak tek iş, teknik sağlığı izlemektir; sonuçlara bakıp karar vermek değil. Her gün kontrol edilmesi gerekenler şunlardır: iki varyantın ziyaretçi sayısı yaklaşık eşit mi, sub ID değerleri raporda düzgün akıyor mu, sayfa hata veriyor mu?

Ziyaretçi dağılımı beklenen orandan belirgin saparsa, örneğin 50/50 planlanan bir testte bir varyant sürekli yüzde 55 trafik alıyorsa, bölme mekanizmasında bir sorun vardır ve sonuçlara güvenilmez. Buna örneklem oranı uyumsuzluğu denir ve test durdurulup hata düzeltilmelidir.

Buna karşılık "B üçüncü günde yüzde 20 öndeymiş, kazandı sayalım" türünden kararlar testin en yaygın bozulma nedenidir. Erken dönemde küçük sayılar büyük dalgalanmalar üretir ve sürekli bakıp ilk uygun anda durdurmak, yanlış kazanan ilan etme olasılığını katlar. Bu tuzağın ve benzerlerinin ayrıntılı açıklaması A/B testi hataları ve çözümleri rehberinde.

Test süresince değişmemesi gerekenleri de not edin: reklam hedeflemesi, teklif linki, komisyon oranı ve sayfadaki diğer öğeler. Reklamveren test ortasında kampanya koşullarını değiştirirse, bu tarih test kaydına yazılmalıdır.

Adım 8: Sonuçları birleştirin ve okuyun

Değerlendirme, sayfa analitiğindeki ziyaretçi verisini ağ raporundaki dönüşüm ve onay verisiyle sub ID üzerinden birleştirerek yapılır. Örneğimizde iki haftalık trafik ve ardından 14 günlük bekleme payı sonunda tablo şöyle oluşuyor (rakamlar varsayımsaldır, komisyon onaylanan dönüşüm başına 60 TL kabul edilmiştir):

İlk bakışta B'nin başarılı olduğu düşünülebilir: teklife çıkış oranı dört puan yükselmiş ve bu fark, bu hacimde tesadüfle açıklanamayacak kadar büyük. Ancak birincil metrik farklı bir hikâye anlatıyor. Toplam dönüşüm neredeyse aynı kalmış, onay oranı ise sekiz puan düşmüş. Reklamverenin red sebep kodlarına bakıldığında B tarafındaki fazlalığın büyük bölümünün "order_returned" ve "order_cancelled" olduğu görülüyor.

Yorum: İndirim vurgusu, teklife daha fazla kişi göndermiş ama bu kişilerin bir kısmı ürünü gerçekten istemeyen, fiyat cazibesiyle tıklayan ziyaretçilermiş. Ziyaretçi başına onaylı komisyondaki fark istatistiksel olarak anlamlı değil; yani B'nin daha kötü olduğunu kesin söyleyemiyoruz, ama daha iyi olduğuna dair hiçbir kanıt yok ve koruma metriği bozulmuş. Anlamlılık testinin nasıl okunacağını istatistiksel anlamlılık nedir rehberinde varsayımsal örneklerle anlattık.

İpucu: Reddedilen dönüşümleri sebep koduna göre varyant bazında ayırmak, "neden" sorusunun cevabını çoğu zaman tek tabloda verir. Bu analizin genel yöntemi için onay oranı analizi rehberine bakabilirsiniz.

Adım 9: Kararı verin ve öğrenimi kayda geçirin

Karar, birincil metriğe, koruma metriğine ve uygulama maliyetine birlikte bakılarak verilir. Olası üç karar vardır: varyantı kalıcı hale getirmek, kontrolde kalmak veya hipotezi revize edip yeni bir test kurmak.

Örneğimizdeki yayıncı kontrolde kalmaya ve hipotezi ikiye bölmeye karar veriyor. Veriler, fayda listesinin ilk ekranda çıkışı azalttığını, indirim vurgusunun ise kaliteyi düşürdüğünü düşündürüyor. Bir sonraki test (test08) yalnızca fayda listesini, indirim vurgusu olmadan deneyecek. Bu, büyük ve karma bir değişikliği test ettikten sonra bileşenlerine ayırmanın tipik bir örneği.

Test kaydı şu alanları içermeli:

• Test kimliği, tarih aralığı, sayfa ve trafik kaynağı
• Hipotez ve gerekçe
• Birincil, destekleyici ve koruma metrikleri
• Planlanan ve gerçekleşen örneklem
• Varyant bazında sonuç tablosu ve anlamlılık değerlendirmesi
• Karar, gerekçesi ve bir sonraki adım

Kaybeden testler de kazananlar kadar değerlidir. Altı ay sonra bir ekip arkadaşı "indirim vurgusunu deneyelim mi?" dediğinde, test07 kaydı iki haftalık trafiği ve bütçeyi korur. Sistemli bir test programının nasıl kurulacağını CRO nedir rehberinde süreç ve roller açısından ele aldık.

Reklamverenler ve ajanslar için aynı akış

Bu yazıdaki akış yalnızca yayıncılar için geçerli değildir; reklamverenler ve ajanslar da kendi landing page'lerinde aynı adımları uygular. Fark, varyant bilgisinin taşınma biçimindedir. Reklamveren kendi sitesinde dönüşümü doğrudan gördüğü için varyantı analitik aracında işaretler; ancak affiliate trafiğinin ayrı değerlendirilmesi gerekiyorsa, hangi yayıncı ve hangi sub ID'den gelen ziyaretçinin hangi sürümü gördüğünü de kaydetmek gerekir.

Reklamveren tarafında koruma metriği genellikle iade oranı veya lead kalitesidir. Örneğin CPL kampanyasında daha kısa bir form daha fazla lead getirebilir ama satış ekibinin ulaşamadığı geçersiz lead oranını da artırabilir. Lead formlarına özgü test fikirleri için lead formu optimizasyonu rehberine bakabilirsiniz.

Ajanslar için ek bir disiplin vardır: birden fazla müşteri için yürütülen testleri ortak bir kayıt formatında tutmak. Böylece bir müşteride öğrenilen ders, başka bir müşterinin benzer sayfasında hipotez kaynağı olur. Adfacten'in ajans paneli, birden fazla müşterinin kampanyasını tek yerden yönetmeye imkân verdiği için, test etiketlerini müşteriler arasında aynı şemayla uygulamak kolaylaşır. Ajanslara yönelik özellikleri ajanslar sayfasında inceleyebilirsiniz.

Test sonuçlarını otomatik izlemek

Test sayısı arttıkça varyant verisini elle dışa aktarıp birleştirmek zaman alır ve hata riskini artırır. Bu noktada raporlama otomasyonu devreye girer: ağın rapor API'sinden sub ID'ye göre gruplanmış tıklama, dönüşüm ve onay verisini düzenli olarak çekip kendi analitik verinizle eşleştiren küçük bir betik, her testin durumunu günlük olarak gösterebilir.

Adfacten'in REST API'si ve rapor API'si sub alanlarına göre gruplanmış veriyi programatik olarak sunar; dokümantasyonu developers.adfacten.com adresindedir. Yapay zekâ asistanı kullanan ekipler için MCP sunucusundaki get_report aracı, "test07'nin varyant bazında onaylı dönüşümlerini getir" gibi bir isteği doğrudan rapor sorgusuna çevirebilir. Otomatik raporlamanın kurulumu için rapor API ile otomatik raporlama rehberine göz atın.

Otomasyon, testi erken durdurma dürtüsünü de körüklememelidir. Günlük panel, örneklem oranı uyumsuzluğu ve takip hataları için bir alarm sistemi olarak kullanılmalı; kazanan seçimi yine planlanan süre ve bekleme payı dolduğunda yapılmalıdır.

Adfacten ile başlayın

A/B testi, sezgiyi veriye çeviren en güvenilir yöntemdir; ama affiliate dünyasında ancak dönüşüm ve onay verisini varyant bazında görebildiğinizde gerçekten işe yarar. Sub ID ile işaretlenmiş linkler, gerçek zamanlı raporlar ve sebep kodlu red kayıtları, yukarıdaki dokuz adımı uygulanabilir kılan temel altyapıdır.

Kendi trafiğiniz üzerinde test yürütmek istiyorsanız yayıncı olarak kaydolun; kampanyanızın landing page'lerini affiliate trafiğiyle test etmek istiyorsanız reklamveren hesabı açın. Birden fazla müşteri adına test programı yöneten ekipler ajans hesabıyla başlayabilir.