A/B Testi Nedir? Güvenilir Bir Deney Nasıl Tasarlanır?

Bir landing page’in conversion rate’i geçen ay %3,2 idi.

Başlığı değiştirdik.

Bu ay conversion rate %3,8 oldu.

Başlık işe yaradı mı?

Olabilir.

Ama yalnızca bu iki rakama bakarak bunu bilmiyoruz.

Aynı dönemde trafik kaynağı değişmiş olabilir. Kampanya başlamış olabilir. Kullanıcı profili değişmiş olabilir. Sezon etkisi oluşmuş olabilir. Fiyat değişmiş olabilir. Rakiplerden biri kampanyasını bitirmiş olabilir.

A/B testi veya A/B testing, bu tür çevresel değişkenlerin etkisini mümkün olduğunca dengeleyerek belirli bir değişikliğin kullanıcı davranışı üzerindeki etkisini ölçmeye çalışan randomize kontrollü deney yöntemidir.

Temel yapı şöyledir:

Uygun kullanıcılar
↓
Random Assignment
↙              ↘
CONTROL        TREATMENT
A              B
↘              ↙
Metric Comparison
↓
Treatment Effect

A grubu mevcut deneyimi görür.

B grubu test edilen değişikliği görür.

Kullanıcılar gruplara rastgele atanır ve iki deneyim aynı zaman diliminde çalıştırılır.

Böylece soru:

Değişiklikten sonra metrik yükseldi mi?

olmaktan çıkar.

Daha güçlü bir soruya dönüşür:

Aynı koşullarda rastgele ayrılmış benzer kullanıcı gruplarında yalnızca treatment değiştiğinde sonuç farklılaştı mı?

A/B testing’i değerli yapan şey iki tasarımı karşılaştırması değil, nedensel etkiyi daha güvenilir biçimde tahmin etmeye çalışmasıdır.

A/B testi nedir?

A/B testi, kullanıcıların rastgele farklı deneyimlere atanarak bu deneyimlerin belirlenen metrikler üzerindeki etkilerinin karşılaştırıldığı kontrollü deneydir.

En basit örnek:

CONTROL A
Mevcut ürün sayfası

vs.

TREATMENT B
Yeni ürün sayfası

Ancak A/B testi yalnız web tasarımı için kullanılmaz.

Test edilen treatment:

• headline,
• value proposition,
• CTA,
• checkout akışı,
• ürün sıralama algoritması,
• arama sistemi değişikliği,
• fiyatlandırma sunumu,
• feature,
• notification sistemi,
• backend veya altyapı değişikliği

olabilir.

Dolayısıyla A/B testing’i yalnız CRO tasarım taktiği olarak görmek alanı gereksiz biçimde daraltır.

A/B testi ile before-after analizi arasındaki fark nedir?

Bu ayrım experimentation’ın temelidir.

Şöyle bir değişiklik yaptığımızı düşünelim:

1–14 Ağustos
Eski checkout
Conversion: %4

15–31 Ağustos
Yeni checkout
Conversion: %5

Yeni checkout’un %25 relative lift ürettiğini söylemek caziptir.

Ancak iki dönem aynı koşullarda gerçekleşmemiştir.

İkinci dönemde:

• trafik kompozisyonu değişmiş,
• kampanya başlamış,
• maaş dönemi gelmiş,
• rakip fiyatları değişmiş,
• site performansı iyileşmiş

olabilir.

A/B testinde ise iki deneyim mümkün olduğunca aynı dönemde paralel çalışır:

                 USER
                  ↓
             RANDOMIZATION
             ↙           ↘
        CONTROL A      TREATMENT B
          %4,0            %5,0

Random assignment sayesinde çevresel etkilerin iki grup arasında sistematik biçimde farklılaşma ihtiyacı azaltılır.

Bu nedenle:

Before / After
= Correlation için yararlı olabilir

Randomized A/B Test
= Causal effect tahmini için daha güçlüdür

A/B testing neden randomization kullanır?

Randomization veya rastgele atama, experiment ile basit karşılaştırma arasındaki en kritik farklardan biridir.

Kullanıcıları kendimiz:

Yeni kullanıcı → A
Returning kullanıcı → B

şeklinde ayırırsak gruplar treatment uygulanmadan önce zaten farklıdır.

B grubunun daha yüksek conversion üretmesi treatment’tan değil, returning kullanıcıların doğası gereği daha yüksek conversion eğilimine sahip olmasından kaynaklanabilir.

Randomization bu tür sistematik farkları azaltmayı amaçlar.

Yeterli ve doğru randomizasyon altında treatment ve control grupları başlangıçta karşılaştırılabilir hale gelir.

Böylece gözlenen metric farkını treatment ile ilişkilendirebilmek için daha güçlü bir temel oluşur.

Control ve treatment nedir?

Control, değişikliğin uygulanmadığı referans deneyimdir.

Treatment, etkisini ölçmek istediğimiz değişikliğin uygulandığı deneyimdir.

Örneğin:

CONTROL
"Teklif Al"

TREATMENT
"Ücretsiz Proje Analizi İste"

Burada treatment yalnız CTA copy değişikliğidir.

Ancak treatment birden fazla elementi aynı hipotez doğrultusunda da değiştirebilir.

Örneğin hipotez:

Kullanıcılar teklifin kendileri için ne yaptığını hero alanında anlayamıyor.

ise treatment:

• headline,
• supporting copy,
• hero visual

üçünü birlikte değiştirebilir.

Buradaki önemli nokta her deneyde yalnız tek HTML elementinin değişmesi değildir.

Test edilen treatment ile hipotez arasındaki ilişkinin yorumlanabilir olmasıdır.

A/B testi hipotezle başlamalıdır

Test edilebilecek bir şey bulmak ile test edilmesi gereken bir problem bulmak aynı şey değildir.

Zayıf test fikri:

Butonu yeşil yapalım, bakalım conversion artıyor mu?

Daha güçlü başlangıç:

Session recordings ve kullanıcı testlerinde kullanıcıların mevcut CTA’yı form açan bir aksiyon olarak anlamadığı görülüyor. CTA copy’sini aksiyonun sonucunu açık biçimde ifade edecek şekilde değiştirmek form başlangıç oranını artırabilir.

İkinci yaklaşımın arkasında:

Evidence
↓
Observed Problem
↓
Hypothesis
↓
Treatment
↓
Metric

zinciri vardır.

Microsoft’un experimentation yaklaşımında da deney tasarımının ilk adımı açık ve ölçülebilir bir hipotez oluşturmaktır. Hipotezin beklenen treatment effect’i tanımlaması ve seçilen metriklerle doğrulanabilir veya yanlışlanabilir olması gerekir.

İyi A/B test hipotezi nasıl yazılır?

Pratik bir yapı:

Evidence:
Ne gördük?

Problem:
Kullanıcının hangi davranışında problem var?

Treatment:
Neyi değiştireceğiz?

Expected Effect:
Hangi davranışın değişmesini bekliyoruz?

Metric:
Bunu neyle ölçeceğiz?

Örnek:

Mobil kullanıcılarda form_start oranı desktop’a yakın olmasına rağmen form_submit oranı belirgin biçimde düşük. Session recording incelemesinde validation error mesajlarının mobil ekranda görünmediği görülüyor. Error mesajlarını ilgili input’un yanında görünür hale getirmenin form completion rate’i artıracağını düşünüyoruz.

Buradaki hipotez:

Mobil validation visibility
↑
Form completion
↑

ilişkisini test eder.

“Yeni form daha güzel olacak” ise ölçülebilir hipotez değildir.

A/B testinde metric nasıl seçilir?

Experiment başlamadan önce başarı kriterinin belirlenmesi gerekir.

Aksi halde test bittikten sonra yüzlerce metriğe bakıp olumlu görünen herhangi bir sonucu “winner” ilan etmek mümkündür.

Bu, sonuçtan sonra hedef tahtasını okun düştüğü yere çizmek olur.

Metric’leri üç ana grupta düşünmek faydalıdır.

Primary metric

Testin ana başarı metriğidir.

Hipotezin test ettiği davranışı mümkün olduğunca doğrudan temsil etmelidir.

Örneğin product detail page’deki Add to Cart alanını test ediyorsak:

Primary Metric:
Add-to-Cart Rate

mantıklı olabilir.

Revenue işletme açısından daha önemli olsa bile treatment’ın doğrudan etkilediği davranış Add to Cart olabilir.

Çok uzaktaki ve düşük frekanslı bir metriği primary metric yapmak testin gerekli sample size’ını veya sonuç alma süresini ciddi biçimde artırabilir.

Secondary metrics

Değişikliğin funnel’ın diğer bölümlerinde nasıl sonuç ürettiğini anlamamıza yardım eder.

Örneğin:

Primary:
Add to Cart Rate

Secondary:
Begin Checkout Rate
Purchase Rate
Revenue per Visitor

Primary metric yükselirken downstream sonuçların nasıl hareket ettiğini görmek önemlidir.

Guardrail metrics

Guardrail metric’ler testin kazanmasını beklediğimiz metrikler değildir.

Bozulmasını istemediğimiz sistem özelliklerini korur.

Örneğin:

• page load time,
• error rate,
• crash rate,
• unsubscribe rate,
• refund rate,
• checkout abandonment

guardrail olarak kullanılabilir.

Örneğin yeni ürün görselleri Add to Cart Rate’i artırırken sayfa performansını ciddi biçimde bozuyorsa test sonucu yalnız:

+8% Add to Cart, winner.

şeklinde yorumlanmamalıdır.

Daha doğru karar problemi:

Primary Metric ↑

ama

Guardrail ↓

Bu trade-off kabul edilebilir mi?

olur.

Primary metric neden doğrudan treatment’a yakın olmalıdır?

Şöyle bir test düşünelim:

Product page’deki CTA’nın konumunu değiştiriyoruz.

Şirket açısından en önemli metrik revenue olabilir.

Fakat kullanıcı CTA’yı gördükten sonra:

Add to Cart
↓
Cart
↓
Checkout
↓
Payment
↓
Purchase

gibi çok sayıda başka adımdan geçmektedir.

Revenue bu treatment’tan oldukça uzaktadır.

Aradaki her geçiş ek variance üretir ve treatment’ın sinyalini zayıflatabilir.

Bu nedenle doğrudan etkilenen davranış:

Add-to-Cart Rate

primary metric olarak daha yüksek signal üretebilir.

Revenue ise secondary veya guardrail bağlamında izlenebilir.

Ancak bu da mekanik bir kural değildir.

Örneğin bulk discount testinde yalnız conversion rate veya AOV tek başına yanıltıcı olabilir. Discount conversion’ı artırırken order value’yu düşürebilir.

Böyle bir durumda:

Revenue per Visitor

treatment’ın iş etkisini daha bütünlüklü temsil edebilir.

Metric seçimi treatment’ın gerçekten neyi değiştirdiğine göre yapılmalıdır.

A/B testinde sample size neden önemlidir?

İki varyant arasında fark gördüğümüzde temel problem şudur:

Bu fark treatment nedeniyle mi oluştu, yoksa random variation mı?

Sample size arttıkça belirsizlik genellikle azalır ve daha küçük gerçek etkileri tespit etmek mümkün hale gelir.

Ancak gerekli örneklem büyüklüğü:

"Her varyasyona 1.000 kullanıcı yeter."

gibi evrensel bir rakam değildir.

Gerekli sample size özellikle şu faktörlere bağlıdır:

• baseline conversion rate,
• Minimum Detectable Effect,
• significance level,
• statistical power,
• metric variance,
• varyasyon sayısı.

Minimum Detectable Effect (MDE) nedir?

Minimum Detectable Effect, deney tasarımında güvenilir biçimde tespit etmek istediğimiz en küçük treatment effect büyüklüğüdür.

Örneğin baseline:

Conversion Rate = %5

ise işletme:

%5’ten %5,05’e çıkan minicik fark bizim için önemli değil. En az %10 relative improvement tespit edebilmek istiyoruz.

diyebilir.

Bu durumda hedeflenen absolute conversion:

%5 → %5,5

olur.

Relative lift:

(5,5 - 5) / 5
= %10

Absolute lift ise:

5,5% - 5%
= 0,5 percentage point

Relative ve absolute farkı birbirine karıştırmamak özellikle test raporlarında önemlidir.

Statistical power nedir?

Statistical power, gerçekten belirli büyüklükte bir treatment effect varsa testin bu etkiyi tespit edebilme olasılığıdır.

Düşük power ile çalışan bir deney:

Fark bulamadık.

sonucunu verebilir.

Fakat bunun anlamı mutlaka:

Treatment’ın etkisi yok.

değildir.

Test gerçek etkiyi tespit edecek kadar hassas olmayabilir.

Bu nedenle “statistically significant değil” ile “iki deneyim kesinlikle aynıdır” aynı ifade değildir.

Statistical significance nedir?

Statistical significance veya istatistiksel anlamlılık, gözlediğimiz farkın control ve treatment gerçekte aynı performansı üretseydi ne kadar beklenmedik olduğuyla ilgilidir.

Ancak burada iki büyük yanlış anlaşılmayı temizlemek gerekir.

Birincisi:

95% significance = B’nin A’dan daha iyi olma ihtimali %95.

ifadesi klasik frequentist yorumda doğru değildir.

İkincisi:

95% bütün A/B testlerinde kullanılması gereken evrensel eşiktir.

ifadesi de doğru değildir.

Kabul edilecek hata riski test bağlamına ve kullanılan experimentation sistemine göre değişebilir.

Örneğin bazı platformlar frequentist, bazıları sequential, bazıları Bayesian veya hibrit istatistik motorları kullanabilir.

Dolayısıyla experiment tool’un ekranda gösterdiği confidence veya significance değerinin ne anlama geldiğini kullanılan metodolojiyi bilmeden yorumlamak hatalıdır.

Statistical significance ile business significance aynı şey değildir

Çok yüksek trafikli bir sitede:

Control:   %10,00
Treatment: %10,05

arasındaki çok küçük fark istatistiksel olarak güvenilir hale gelebilir.

Ancak treatment’ın:

• development maliyeti,
• design maliyeti,
• maintenance maliyeti,
• operasyonel karmaşıklığı

bu farktan daha büyük olabilir.

Bu nedenle:

Statistically Detectable
≠
Economically Important

İyi experimentation yalnız:

Fark gerçek mi?

sorusunu değil:

Fark uygulamaya değer mi?

sorusunu da sorar.

Confidence interval neden tek bir lift rakamından daha değerlidir?

Test sonuçlarında yalnız:

+7% lift

göstermek etkinin büyüklüğü hakkındaki belirsizliği gizleyebilir.

Örneğin tahmin edilen effect:

+7%

olabilir.

Ancak confidence interval:

-2% ile +16%

arasında ise sonuç hâlâ oldukça belirsizdir.

Başka bir test:

+4% lift

Confidence Interval:
+3% ile +5%

üretebilir.

İkinci testin point estimate’i daha küçük olsa bile treatment effect hakkında çok daha hassas bilgi veriyor olabilir.

Bu nedenle yalnız “winner/loser” etiketi değil, effect estimate ve belirsizlik aralığı da değerlendirilmelidir.

A/B testi ne kadar süre çalıştırılmalı?

Burada da evrensel:

Testi 14 gün çalıştır.

kuralı yoktur.

Test süresini:

• gerekli sample size,
• trafik hacmi,
• baseline metric,
• beklenen MDE,
• conversion gecikmesi,
• haftalık kullanıcı davranışı,
• kullanılan statistical engine

etkileyebilir.

Örneğin ihtiyaç duyulan sample size:

20.000 kullanıcı / varyasyon

ve uygun günlük trafik:

2.000 kullanıcı

ise testin gerekli örneklemi birkaç günde değil daha uzun sürede toplaması beklenebilir.

Ancak yalnız sample size tamamlandı diye başka kalite kontrollerini görmezden gelmek de doğru değildir.

Test sonucuna sürekli bakıp winner görünce durdurabilir miyiz?

Kullanılan istatistik metoduna bağlıdır.

Klasik fixed-horizon frequentist testlerde sonuçlara tekrar tekrar bakıp:

Significant oldu, kapat.

davranışı false positive riskini artırabilir.

Çünkü her yeni kontrol aslında yeni bir “şimdi anlamlı oldu mu?” fırsatı yaratır.

Sequential testing yöntemleri ise deney boyunca tekrarlanan değerlendirmeyi hesaba katacak şekilde tasarlanabilir.

Bazı modern experimentation platformları bu nedenle continuous monitoring veya sequential statistics kullanır.

Buradaki pratik kural:

Kullandığın istatistik motorunun stopping rule’unu anlamadan testi ekrandaki yeşil işarete göre kapatma.

Birden fazla metric test etmek neden problem yaratabilir?

Bir deneyde yalnız bir metriğe değil:

Metric 1
Metric 2
Metric 3
...
Metric 50

gibi onlarca metriğe bakıldığını düşünelim.

Yeterince fazla karşılaştırma yaptığımızda bazı metriklerin yalnız şans nedeniyle istatistiksel olarak anlamlı görünme ihtimali artar.

Bu multiple comparisons problemidir.

Aynı problem çok sayıda variation test edildiğinde de oluşabilir.

Modern experimentation platformları false discovery rate veya başka multiple-testing correction yöntemleri kullanabilir.

Bu nedenle experiment bittikten sonra:

Primary metric olmadı ama şu 37 secondary metric’ten biri +12% çıktı, bunu ship edelim.

şeklindeki sonuç avcılığı güvenilir experimentation değildir.

Sample Ratio Mismatch (SRM) nedir?

Bir test:

50% Control
50% Treatment

olarak ayarlanmış olsun.

Fakat analizde:

Control:   60.000 kullanıcı
Treatment: 40.000 kullanıcı

görüyorsak bunun nedenini araştırmak gerekir.

Sample Ratio Mismatch, gözlenen varyasyon dağılımının beklenen randomization oranından istatistiksel olarak anlamlı biçimde sapmasıdır.

SRM şu tür problemlere işaret edebilir:

• yanlış bucketing,
• eksik telemetry,
• redirect problemi,
• user identifier hatası,
• data join problemi,
• bazı kullanıcıların analizden sistematik olarak kaybolması.

Bu küçük bir dashboard kusuru değildir.

Control ve treatment gruplarının karşılaştırılabilirliği bozulmuş olabilir.

Bu nedenle güvenilir experimentation platformları sonuç yorumlanmadan önce SRM kontrolü yapar.

A/B testinde tracking QA neden experiment sonucundan önce gelir?

Bir experiment istatistiksel açıdan kusursuz olabilir.

Ama measurement bozuksa sonuç yine işe yaramaz.

Örneğin treatment varyasyonunda:

purchase event

bazı kullanıcılar için tetiklenmiyorsa treatment gerçekte iyi performans gösterse bile dashboard kayıp gösterebilir.

Bu nedenle test başlamadan önce en azından:

• variant assignment,
• experiment exposure,
• primary metric tracking,
• secondary metrics,
• guardrail metrics,
• analytics integration

QA edilmelidir.

Test başladıktan sonra da metric volume’un beklenen aralıklarda olup olmadığı kontrol edilmelidir.

Experiment data quality, experiment sonucunun ön koşuludur.

A/A testi nedir?

A/A testinde kullanıcılar rastgele iki gruba ayrılır fakat iki grup da aynı deneyimi görür:

USER
↓
Randomization
↙       ↘
A        A
Same     Same

Gerçek treatment olmadığı için sistematik bir treatment effect beklenmez.

A/A testleri özellikle:

• randomization sistemini,
• metric hesaplamalarını,
• false-positive davranışını,
• experiment infrastructure’ını

doğrulamak için kullanılabilir.

A/A testing her web sitesinin her experiment öncesinde yapması gereken zorunlu ritüel değildir.

Daha çok experimentation sisteminin güvenilirliğini test etmek için kullanılan araçlardan biridir.

A/B testinin sonucu hangi biçimlerde çıkabilir?

Experiment sonucunu yalnız:

Winner
Loser

ikiliğine sıkıştırmak öğrenme değerini azaltır.

Pratikte en az dört sonuç olabilir.

1. Positive

Treatment primary metric üzerinde yeterli kanıtla olumlu etki üretir ve guardrail’larda kabul edilemez bozulma yoktur.

2. Negative

Treatment beklenen metriği kötüleştirir veya önemli guardrail’lardan birini bozar.

3. Inconclusive

Veri mevcut test tasarımıyla treatment effect hakkında yeterince hassas sonuç üretmez.

Bu:

A ve B kesinlikle aynı.

demek değildir.

4. Invalid

Tracking problemi, SRM, implementation bug veya başka data-quality sorunu nedeniyle deney sonucu güvenilir biçimde yorumlanamaz.

Bu dört sonucu ayırmak özellikle CRO programlarında önemlidir.

Çünkü:

Inconclusive ≠ Failed Experiment

Invalid ≠ Negative Experiment

A/B testi ne zaman yapılmamalıdır?

Her değişiklik experiment gerektirmez.

Açık bug varsa

Form submit butonu mobilde çalışmıyorsa kullanıcıların yarısına bozuk form göstermeye devam edip:

Bug fix conversion artırıyor mu test edelim.

demek anlamsızdır.

Bug düzeltilir.

Yeterli trafik veya event hacmi yoksa

Ayda 40 conversion üreten bir landing page’de %3’lük relative lift’i güvenilir biçimde tespit etmek pratik olmayabilir.

Böyle durumda:

• qualitative research,
• usability testing,
• larger changes,
• pre/post analysis with explicit limitations

daha kullanışlı olabilir.

Treatment’ın uygulanması etik veya yasal açıdan sorunluysa

“Experiment yapıyoruz” kullanıcılara zarar verebilecek veya yasal gereklilikleri ihlal edebilecek treatment’ları meşru hale getirmez.

Öğrenecek bir şey yoksa

Experiment’ın amacı yalnız dashboard’da test sayısını yükseltmek değildir.

Sonucu hangi kararın değişeceği belli değilse testin maliyeti gereksiz olabilir.

Düşük trafikli sitelerde A/B testing yapılabilir mi?

Teknik olarak evet.

Pratikte soru:

İlgilendiğimiz büyüklükteki effect’i makul sürede tespit edebilecek miyiz?

olmalıdır.

Düşük trafik:

• daha büyük MDE,
• daha yüksek baseline metric,
• daha hassas metric

varsa bazı deneyleri mümkün kılabilir.

Fakat çok küçük effect’lerin peşinden gidiliyorsa gerekli sample size hızla büyüyebilir.

Bu yüzden experiment backlog’unu yalnız:

Hangi fikir güzel?

üzerinden değil:

Expected Impact
×
Evidence
×
Traffic
×
Detectability
×
Implementation Cost

üzerinden de değerlendirmek gerekir.

Google Optimize hâlâ kullanılabilir mi?

Hayır.

Google Optimize ve Optimize 360, 30 Eylül 2023 tarihinde kullanımdan kaldırıldı.

Google Analytics 4 bugün A/B testing kavramını ve experiment sonuçlarının Analytics içinde değerlendirilmesini destekliyor; ancak experiment’ın kendisinin üçüncü taraf bir A/B testing platformunda çalıştırılması gerekiyor.

Google mevcut dokümantasyonunda AB Tasty, Optimizely ve VWO gibi üçüncü taraf experimentation sağlayıcılarıyla entegrasyon yaklaşımını kullanıyor.

Dolayısıyla 2026 yılında:

Google Optimize açın ve test oluşturun.

diyen rehber operasyonel olarak güncel değildir.

A/B testi ile multivariate testing arasındaki fark nedir?

A/B testing genellikle iki veya daha fazla bütün experience variation’ını karşılaştırır.

A
Control

B
Variation

Multivariate testing ise birden fazla elementin farklı kombinasyonlarının etkisini birlikte değerlendirmeye çalışır.

Örneğin:

Headline:
A1 / A2

CTA:
B1 / B2

Image:
C1 / C2

kombinasyonları test edilebilir.

Kombinasyon sayısı arttıkça trafik ihtiyacı da ciddi biçimde büyüyebilir.

Bu nedenle multivariate testing “A/B testing’in daha gelişmiş ve dolayısıyla her zaman daha iyi versiyonu” değildir.

A/B testing ile multi-armed bandit aynı şey midir?

Hayır.

Klasik A/B experiment’ın temel amacı treatment effect hakkında öğrenme üretmek olabilir.

Multi-armed bandit yaklaşımı ise trafik dağılımını zaman içinde daha iyi performans gösteren seçeneklere kaydırarak experiment sırasında oluşabilecek opportunity cost’u azaltmaya odaklanabilir.

Bu nedenle:

A/B Experiment
→ inference / learning ağırlıklı

Bandit
→ allocation / optimization ağırlıklı

şeklinde basitleştirilebilir.

İki yaklaşımın istatistiksel yöntemleri ve kullanım senaryoları farklı olabilir.

Bir A/B testi nasıl yapılır?

Pratik experimentation akışını dokuz adıma indirgerdim:

1. RESEARCH
Gerçek problem veya fırsat nedir?

2. HYPOTHESIS
Hangi treatment hangi davranışı neden değiştirmeli?

3. METRICS
Primary, secondary ve guardrail metric'ler ne?

4. DESIGN
Randomization unit, audience ve traffic split nasıl olacak?

5. POWER
MDE ve gerekli sample size gerçekçi mi?

6. QA
Variation ve tracking doğru çalışıyor mu?

7. RUN
Experiment kullanılan statistical engine'in kurallarına göre çalışıyor mu?

8. ANALYZE
Effect size, uncertainty, guardrails ve data quality ne söylüyor?

9. DECIDE & LEARN
Ship, iterate, reject veya yeniden test kararımız ne?

Bu zincirin herhangi bir adımını atlamak deneyin yalnız istatistiksel değil operasyonel güvenilirliğini de azaltabilir.

A/B testing CRO sürecinde nereye oturur?

A/B testing CRO ile güçlü biçimde ilişkilidir.

Fakat:

CRO
≠
A/B Testing

CRO daha geniş bir problem çözme sürecidir.

Örneğin:

Measurement
↓
Funnel Analysis
↓
Conversion Research
↓
Diagnosis
↓
Hypothesis
↓
A/B Test
↓
Learning
↓
Iteration

A/B testing burada hipotezin davranış üzerindeki etkisini doğrulamaya çalışan yöntemlerden biridir.

Problem bulunmadan sürekli A/B test yapmak CRO değildir.

Aynı şekilde yeterli trafik olmadığı için A/B testing kullanamamak da CRO yapılamayacağı anlamına gelmez.

Funnel analysis ile A/B testing arasındaki ilişki nedir?

Funnel analysis:

Kullanıcıların hangi geçişte kaybolduğunu

gösterebilir.

Örneğin:

view_item
↓
add_to_cart     ← büyük drop-off
↓
begin_checkout
↓
purchase

Sonraki research bu drop-off’un neden oluşabileceğine dair kanıt üretir.

Ardından A/B test şu soruyu cevaplamaya çalışabilir:

Bu problemi çözmek için tasarladığımız treatment gerçekten kullanıcı davranışını değiştiriyor mu?

Bu nedenle:

Funnel
→ WHERE

Research
→ WHY

Hypothesis
→ WHAT SHOULD CHANGE

Experiment
→ DID THE CHANGE CAUSE AN EFFECT?

ayrımı oldukça kullanışlıdır.

A/B testing’de en sık yapılan hatalar

Research yapmadan test fikri üretmek

Test backlog’u renk, button copy ve tasarım fikirleriyle dolar; gerçek kullanıcı problemleri arka planda kalır.

Test başladıktan sonra primary metric değiştirmek

Sonuca göre başarı kriteri seçmek interpretation bias yaratabilir.

Çok sayıda metriğin içinden winner aramak

Multiple-comparison problemi false positive üretme riskini artırır.

Significance görünce testi hemen durdurmak

Kullanılan statistical methodology continuous peeking’i desteklemiyorsa hata oranı yükseltebilir.

Statistically significant sonucu büyük başarı sanmak

Effect gerçek ama ekonomik olarak anlamsız olabilir.

Inconclusive sonucu “A ile B aynı” diye yorumlamak

Test yeterince hassas olmayabilir.

Tracking QA yapmamak

Garbage data üzerine mükemmel istatistik çalıştırmak yalnız daha bilimsel görünen garbage üretir.

Guardrail kullanmamak

Bir metriği optimize ederken başka kritik iş metriğini veya kullanıcı deneyimini bozabilirsiniz.

SRM’yi görmezden gelmek

Beklenen experiment split’i ile gerçek split arasında sistematik fark varsa sonuçların güvenilirliği sorgulanmalıdır.

Her değişikliği A/B test etmek

Bug fix, yasal gereklilik veya açık usability problemi için test her zaman gerekli değildir.

A/B test raporunda neler bulunmalı?

İyi bir experiment raporu yalnız:

Variation B +12%, winner.

değildir.

En azından şu bilgileri taşıması faydalıdır:

Alan	Ne yazılmalı?
Problem	Hangi kullanıcı veya iş problemi araştırıldı?
Evidence	Hipotez hangi veriye dayanıyordu?
Hypothesis	Beklenen treatment effect neydi?
Control	Mevcut deneyim neydi?
Treatment	Ne değiştirildi?
Audience	Kimler teste dahil edildi?
Primary Metric	Başarı hangi metrikle değerlendirildi?
Guardrails	Nelerin bozulmaması gerekiyordu?
Sample	Kaç randomization unit değerlendirildi?
Effect	Absolute ve relative fark neydi?
Uncertainty	Confidence / credible interval ne söylüyor?
Data Quality	SRM veya tracking problemi var mıydı?
Decision	Ship, iterate, reject veya retest?
Learning	Bu deneyden ne öğrendik?

Son alan özellikle önemlidir.

Experimentation’ın uzun vadeli değeri yalnız tek tek winner’lar değildir.

Zaman içinde:

Hypothesis
→ Test
→ Result
→ Learning
→ Next Hypothesis

şeklinde kurumsal bilgi üretmesidir.

Sonuç: A/B testing winner bulma makinesi değildir

A/B testing’in amacı sürekli B varyasyonunun A’yı yenmesini sağlamak değildir.

Amaç belirsizliği azaltmaktır.

Bazen yeni fikir kazanır.

Bazen kaybeder.

Bazen veri yetersiz kalır.

Bazen experiment sisteminde hata buluruz.

Dört durumda da doğru kurulmuş deney bilgi üretir.

Sağlıklı experimentation sistemi şu döngüyü kurar:

Observe
↓
Research
↓
Hypothesize
↓
Design
↓
Randomize
↓
Measure
↓
Estimate Effect
↓
Decide
↓
Learn
↓
Repeat

Bu nedenle A/B testing’i:

Hangi buton daha çok tıklanıyor?

seviyesine indirgemek alanın en değerli kısmını kaçırır.

Asıl soru:

Yaptığımız değişiklik gerçekten kullanıcı davranışını değiştirdi mi ve bu etki işletme açısından uygulamaya değer mi?

Güvenilir experimentation’ın işi bu soruya mümkün olduğunca az tahminle cevap verebilmektir.

Sık Sorulan Sorular

A/B testi nedir?

A/B testi, kullanıcıların rastgele control ve treatment gruplarına atanarak iki veya daha fazla deneyimin belirlenen metrikler üzerindeki etkisinin karşılaştırıldığı kontrollü deney yöntemidir.

A/B testi neden yapılır?

Bir değişiklik ile gözlenen kullanıcı davranışı arasındaki nedensel ilişkiyi before-after karşılaştırmasına göre daha güvenilir biçimde ölçmek için kullanılır.

A/B testinde A ve B neyi ifade eder?

A genellikle mevcut deneyimi yani control’u, B ise test edilen değişikliğin bulunduğu treatment variation’ını temsil eder.

A/B testi kaç gün yapılmalıdır?

Evrensel bir gün sayısı yoktur. Gerekli sample size, trafik hacmi, baseline metric, Minimum Detectable Effect, conversion gecikmesi ve kullanılan statistical methodology test süresini etkiler.

A/B testi için kaç kullanıcı gerekir?

Sabit bir sayı yoktur. Gerekli örneklem baseline conversion rate, tespit edilmek istenen minimum effect, statistical power, significance level ve metric variance gibi değişkenlere bağlıdır.

Statistical significance kaç olmalıdır?

Evrensel bir significance seviyesi yoktur. Kabul edilebilir hata riski ve kullanılan statistical engine’e göre karar değişebilir. Platformun kullandığı frequentist, sequential veya Bayesian metodoloji anlaşılmadan tek bir yüzde mekanik kural olarak kullanılmamalıdır.

A/B testinde primary metric nedir?

Primary metric, hipotezin başarılı olup olmadığını değerlendirmek için kullanılan ana metriktir. Mümkün olduğunca treatment’ın doğrudan etkilemesini beklediğimiz davranışı temsil etmelidir.

Guardrail metric nedir?

Guardrail metric, test ile artırmaya çalıştığımız metric değildir; treatment uygulanırken bozulmasını istemediğimiz performans, güvenilirlik veya iş sonuçlarını izlemek için kullanılır.

A/B testinde sonuç anlamlı çıkmazsa ne olur?

Inconclusive sonuç iki variation’ın kesinlikle aynı olduğunu göstermez. Experiment’ın ilgili büyüklükteki treatment effect’i tespit edecek kadar hassas olup olmadığı da değerlendirilmelidir.

Google Optimize hâlâ kullanılabilir mi?

Hayır. Google Optimize ve Optimize 360, 30 Eylül 2023 tarihinde kapatıldı. Google Analytics 4 ile A/B testing yapılmak istendiğinde testin üçüncü taraf bir experimentation platformunda çalıştırılması gerekir.

CRO ile A/B testing aynı şey midir?

Hayır. A/B testing CRO’da kullanılan doğrulama yöntemlerinden biridir. CRO ayrıca ölçüm, funnel analysis, kullanıcı araştırması, heuristic analysis, hipotez geliştirme ve başka optimizasyon yöntemlerini de kapsar.