CRO Hipotezi Nasıl Yazılır? Gözlemden Test Edilebilir Fikre

CRO hipotezi, bir sayfada yapılabilecek rastgele değişikliğin daha akademik görünen hali değildir. Araştırmayla desteklenen bir problemin, belirli bir değişikliğin kullanıcı davranışını neden ve nasıl etkileyebileceğine dair test edilebilir tahmine dönüştürülmesidir.

Örneğin:

“CTA’yı daha görünür yaparsak conversion artar.”

bir fikir olabilir. Fakat tek başına güçlü bir CRO hipotezi değildir.

Çünkü şu soruların cevabı yoktur:

• Kullanıcıların mevcut CTA’yı görmediğini nereden biliyoruz?
• Asıl problem görünürlük mü, teklifin anlaşılmaması mı?
• Hangi davranışın değişmesini bekliyoruz?
• Başarıyı hangi metric ile değerlendireceğiz?
• Değişikliğin işe yaramasını neden bekliyoruz?

Güçlü CRO hipotezi bu boşlukları kapatır.

RESEARCH
↓
OBSERVATION
↓
EVIDENCE
↓
PROBLEM
↓
RATIONALE
↓
PROPOSED CHANGE
↓
EXPECTED BEHAVIOR
↓
METRIC
↓
EXPERIMENT / DECISION

Optimizely güçlü bir hypothesis’in problem, proposed solution ve expected result olmak üzere üç temel parçadan oluştuğunu; problemin de yalnız varsayımla değil nitel ve nicel veriyle doğrulanmasını önerir.^[1]

CXL’in conversion research yaklaşımında ise araştırmadan elde edilen verinin insight’a, insight’ın da uygulanabilir bir test hypothesis’ine dönüşmesi CRO sürecinin temel bağlantılarından biridir.^[2]

CRO hipotezinin görevi “ne değiştirebiliriz?” sorusuna cevap vermek değil; “hangi problemi, neden bu değişiklikle çözmeyi bekliyoruz ve sonucu nasıl değerlendireceğiz?” sorusunu açık hale getirmektir.

CRO hipotezi nedir?

CRO hipotezi, mevcut kullanıcı deneyimi hakkında sahip olduğumuz evidence’a dayanarak belirli bir değişikliğin belirli bir kullanıcı davranışını etkileyeceğini öngören test edilebilir iddiadır.

Optimizely bunu basit biçimde şöyle formüle eder:^[1]

If [CAUSE],
then [EFFECT],
because [RATIONALE].

Statsig’in experiment oluşturma akışındaki hypothesis template’i ise kullanıcı segmentini, beklenen sonucu, nedeni, primary metric’i ve guardrail’leri aynı yapıya dahil eder.^[3]

Pratik CRO çalışması için ben daha açıklayıcı bir yapı kullanmayı tercih ederim:

GÖZLEM
+
KANIT
+
PROBLEM
+
DEĞİŞİKLİK
+
NEDEN / MEKANİZMA
+
BEKLENEN DAVRANIŞ
+
BAŞARI METRİĞİ

Bu yapı tek cümle olmak zorunda değildir.

Asıl amaç hypothesis kartını olabildiğince kısa göstermek değil, experiment başladığında ekibin:

• hangi problemi çözmeye çalıştığını,
• neden bu çözümü seçtiğini,
• hangi davranışın değişmesini beklediğini,
• hangi evidence’a dayandığını,
• sonuca nasıl karar vereceğini

anlayabilmesidir.

Fikir, gözlem, problem ve hipotez aynı şey değildir

CRO çalışmalarında bu kavramlar sık sık birbirine karışır.

Kavram	Ne anlatır?	Örnek
Observation	Veride veya kullanıcı davranışında gördüğümüz durum.	Kullanıcılar teslimat alanına tekrar tekrar dönüyor.
Evidence	Gözlemi destekleyen veri kaynakları.	Recording’ler, support soruları ve survey cevapları.
Problem	Kullanıcının hedefe ulaşmasını zorlaştırabilecek durum.	Teslimat zamanının karar anında yeterince açık olmaması.
Idea	Problemi çözmek için düşünülen müdahale.	Teslimat tarihini CTA yanına eklemek.
Hypothesis	Değişikliğin belirli bir davranışı neden etkileyeceğine dair test edilebilir tahmin.	Teslimat bilgisini CTA yanında gösterirsek belirsizlik azalacağı için add-to-cart oranının artmasını bekliyoruz.

Özellikle şu ayrım önemlidir:

IDEA
≠
HYPOTHESIS

“Hero’yu değiştirelim” bir fikirdir.

“Fiyat kartlarını yatay yapalım” bir fikirdir.

“Form alanlarını azaltalım” bir fikirdir.

Bunların herhangi biri iyi sonuç verebilir. Fakat hangi probleme neden müdahale ettiğimiz belli değilse experiment sonucunda öğrenebileceğimiz şey de sınırlı olur.

Hipotez neden research’ten çıkmalıdır?

Bir siteye bakıp birkaç dakika içinde onlarca değişiklik fikri üretmek zor değildir.

Zor olan doğru problemi seçmektir.

CXL conversion research’ü kullanıcı davranışı hakkında yeni ve kullanışlı bilgi arayan sistematik bir süreç olarak tanımlar ve araştırma verilerinin test edilebilir hipotezler oluşturmak için kullanılmasını önerir.^[2]

Optimizely de güçlü hypothesis oluştururken problemi nitel ve nicel kaynaklarla doğrulamayı ve intuition üzerinden hypothesis üretmekten kaçınmayı önerir.^[1]

Bu ayrım şu iki çalışma şeklinde açıkça görülebilir:

Solution-first CRO

"Rakip böyle yapmış."

↓
"Biz de yapalım."

↓
A/B TEST

Research-led CRO

BUSINESS PROBLEM
↓
RESEARCH QUESTION
↓
EVIDENCE
↓
USER PROBLEM
↓
SOLUTION HYPOTHESIS
↓
METRIC
↓
EXPERIMENT

Rakip analizi, heuristic evaluation veya deneyim solution idea üretebilir.

Ancak yalnız “başka sitelerde böyle” demek kullanıcılarımızın gerçekten aynı problemi yaşadığını göstermez.

Research finding doğrudan hipotez midir?

Hayır.

Research finding yalnız gördüğümüz şeyi söyler.

Örneğin:

“Mobil kullanıcıların form completion rate’i desktop kullanıcılardan daha düşük.”

Bu bir bulgudur.

Henüz nedenini bilmiyoruz.

Session recordings incelendiğinde mobil kullanıcıların telefon numarası formatında sık sık validation hatası aldığı görülürse problem daha netleşebilir.

FINDING
Mobil form completion düşük.

↓

BEHAVIORAL EVIDENCE
Telefon alanında tekrar eden validation hataları var.

↓

PROBLEM
Mobil kullanıcıların geçerli telefon formatını anlaması zor.

↓

SOLUTION IDEA
Format beklentisini input içinde açık göster.

↓

HYPOTHESIS
Telefon formatını alanın yanında açıkça gösterirsek
validation kaynaklı friction azalacağı için
form completion rate'in artmasını bekliyoruz.

Hipotez research bulgusunun kendisi değil, bulgudan çıkarılan test edilebilir açıklamadır.

İyi bir CRO hipotezinin temel parçaları nelerdir?

1. Observation

Önce ne gördüğümüzü tanımlamalıyız.

Observation mümkün olduğunca yorumdan ayrılmalıdır.

Örneğin:

“Pricing sayfasındaki kullanıcıların büyük bölümü paket karşılaştırma alanına geri dönüyor.”

observation olabilir.

Şu ise yorumdur:

“Kullanıcılar fiyatlarımızı çok karmaşık buluyor.”

İkinci cümle doğru olabilir fakat davranışın nedeni henüz kanıtlanmamıştır.

2. Evidence

Hipotezin dayandığı evidence mümkün olduğunca açık yazılmalıdır.

Örneğin:

• Analytics
• Funnel data
• Session recordings
• Usability testing
• Survey
• Customer interviews
• Sales feedback
• Customer support
• Technical analysis

Birden fazla kaynak aynı problemi destekliyorsa hypothesis’in temeli genellikle güçlenir.

Fakat evidence sayısının fazla olması otomatik olarak nedenselliği kanıtlamaz.

3. Problem

Problem kullanıcının deneyiminden tanımlanmalıdır.

Zayıf:

“Hero kötü.”

Daha iyi:

“Hero alanında hizmetin kimler için olduğu ve teklifin hangi problemi çözdüğü açık olmadığı için kullanıcıların teklifin kendileriyle ilgili olup olmadığını anlaması zor olabilir.”

Optimizely de hypothesis oluştururken meaningful customer-experience problem ile başlanmasını ve problem tanımının ziyaretçinin bakış açısından ele alınmasını önerir.^[1]

4. Proposed change

Sonra problemi çözebileceğine inandığımız müdahaleyi tanımlarız.

Değişiklik ekip tarafından uygulanabilecek kadar somut olmalıdır.

Örneğin:

“Sayfayı daha güvenilir yap.”

ölçülebilir bir treatment değildir.

Şu daha nettir:

“CTA’nın hemen altında mevcut müşteri logolarını ve doğrulanabilir müşteri sayısını göster.”

Ne değiştiği açıktır.

5. Rationale

Rationale, değişikliğin neden problemi çözmesini beklediğimizi açıklar.

Hipotezin en çok atlanan parçalarından biridir.

Örneğin:

CHANGE:
Teslimat tarihini CTA yanında göster.

RATIONALE:
Kullanıcının satın alma öncesinde aradığı
kritik lojistik bilgiyi karar anında sunarak
belirsizliği azaltmak.

“Because” kısmı yoksa hypothesis çoğu zaman yalnız değişiklik + beklenen uplift cümlesine dönüşür.

6. Expected behavior

Ne olmasını beklediğimizi kullanıcı davranışıyla ifade etmeliyiz.

Örneğin:

• daha fazla kullanıcının ürün detayına ilerlemesi,
• formu tamamlaması,
• checkout’a başlaması,
• plan seçmesi,
• sepete ürün eklemesi

gibi.

“Sayfa daha iyi olacak” expected behavior değildir.

7. Metric

Son olarak beklenen davranışın hangi metric ile değerlendirileceği belirlenmelidir.

Statsig experiment scorecard’ında hypothesis ile primary metric’ler aynı setup içinde tanımlanır ve primary metric’ler experiment’in doğrudan etkilemesini beklediğimiz ölçümler olarak ele alınır.^[3]

Optimizely de primary metric’in değişikliğin doğrudan etkilediği davranışı ölçmesini önerir.^[4]

Örneğin:

HYPOTHESIS:
Ürün sayfasında teslimat tarihini CTA yanında
gösterirsek satın alma öncesindeki belirsizlik
azalacağı için daha fazla kullanıcının
sepete ürün eklemesini bekliyoruz.

PRIMARY METRIC:
Add-to-cart rate

Pratik CRO hypothesis template’i

Tek cümlelik template kullanılacaksa şu yapı yeterince esnek ve açıklayıcıdır:

[USER / SEGMENT] için

[RESEARCH İLE BULUNAN PROBLEM] nedeniyle
[HEDEFLENEN DAVRANIŞ] zorlaşıyor.

[CHANGE] yaparsak,

[RATIONALE] nedeniyle

[EXPECTED BEHAVIOR]'ın gerçekleşmesini bekliyoruz.

PRIMARY METRIC:
[METRIC]

GUARDRAIL:
[VARSA KRİTİK METRIC]

Daha kısa versiyonu:

Because [EVIDENCE / INSIGHT],

we believe [CHANGE]

will cause [EXPECTED BEHAVIOR]

because [RATIONALE].

We will evaluate this using [PRIMARY METRIC].

Buradaki İngilizce kelimelerin özel bir büyüsü yok. Türkçe veya İngilizce yazılabilir.

Template’in amacı düşünme işini ortadan kaldırmak değil, gerekli parçaların unutulmasını engellemektir.

E-ticaret için CRO hipotezi örneği

Bir ürün sayfasında analytics ve research sonucunda şu bulguların ortaya çıktığını düşünelim:

• Mobil add-to-cart oranı desktop’tan daha düşük.
• Session recordings’de kullanıcılar teslimat bilgisi arıyor.
• Customer support’a sık sık “kaç günde gelir?” sorusu geliyor.
• Survey cevaplarında teslimat zamanı satın alma kararında önemli kriter olarak geçiyor.

Zayıf hypothesis:

“Teslimat bilgisini yukarı taşırsak conversion artar.”

Daha güçlü model:

Observation: Mobil PDP kullanıcılarının önemli bölümü teslimat bilgisini bulmak için sayfanın farklı alanlarına dönüyor.

Evidence: Session recordings, support soruları ve survey verileri teslimat zamanının satın alma öncesinde tekrar eden bir bilgi ihtiyacı olduğunu gösteriyor.

Problem: Teslimat zamanı CTA yakınında görünür olmadığı için kullanıcı karar anında lojistik belirsizlik yaşayabilir.

Change: Tahmini teslimat tarihini Add to Cart CTA’sının hemen yanında göstermek.

Rationale: Kritik teslimat bilgisini karar anına yaklaştırmak belirsizliği azaltabilir.

Expected Behavior: Daha fazla kullanıcının ürünü sepete eklemesi.

Primary Metric: Add-to-cart rate.

Secondary: Checkout start ve purchase rate.

Guardrail: Gerekliyse cancellation veya başka downstream kalite metriği.

Lead generation için CRO hipotezi örneği

Bir B2B landing page’de şu bulgular olduğunu düşünelim:

• Form start yüksek fakat completion düşük.
• Kullanıcılar formun ikinci bölümünde yoğun biçimde çıkıyor.
• Sales ekibi düşük kaliteli lead’lerden şikâyet etmiyor.
• Usability test’te kullanıcılar bazı zorunlu alanların neden istendiğini anlamıyor.

Buradan doğrudan:

“Formu kısaltalım.”

sonucuna atlamak gerekmez.

Problem belki alan sayısı değil, alanların neden istendiğinin açıklanmamasıdır.

Örnek hypothesis:

Formun ikinci aşamasındaki şirket bilgisi alanlarının neden gerekli olduğunu açıklarsak, kullanıcılar veri talebinin amacını daha iyi anlayacağı için form abandonment’ın azalmasını ve form completion rate’in artmasını bekliyoruz.

Burada:

PRIMARY:
Form completion rate

GUARDRAIL:
Qualified lead rate

kullanılabilir.

Form completion artarken qualified lead rate düşüyorsa local improvement business outcome’a aynı biçimde taşınmamış olabilir.

Copywriting hipotezi nasıl yazılır?

Copy değişikliklerinde de “daha iyi headline yazacağız” hipotez değildir.

Örneğin research sonucunda kullanıcıların hizmetin kimler için olduğunu anlamadığı görülüyorsa:

Zayıf:

“Headline’ı daha güçlü yaparsak lead artar.”

Daha iyi:

Hero headline’ında hizmetin hedef kitlesini ve ana sonucu açıkça belirtirsek, kullanıcılar teklifin kendileriyle ilgili olup olmadığını daha hızlı değerlendireceği için daha fazla uygun kullanıcının hizmet detayına veya form başlangıcına ilerlemesini bekliyoruz.

Burada copywriting treatment’tır.

Hipotezin asıl konusu ise kullanıcının:

• relevance,
• clarity,
• motivation,
• risk,
• objection

problemlerinden hangisini çözmeye çalıştığımızdır.

Bir hipotezde tek değişken mi olmalıdır?

Her CRO experiment’ının yalnız tek bir kelime veya tek bir UI öğesi değiştirmesi gerektiği gibi katı bir kural yoktur.

Bazen problem bütün bir experience treatment gerektirebilir.

Örneğin pricing modelinin anlaşılmaması problemini çözmek için:

• başlık,
• paket isimleri,
• feature hierarchy,
• comparison table

birlikte yeniden tasarlanabilir.

Fakat treatment ne kadar çok bağımsız değişiklik içerirse hangi parçanın sonucu ürettiğini anlamak o kadar zorlaşır.

Bu nedenle önemli soru:

Değişiklikler aynı problem ve aynı rationale etrafında tek bir anlamlı treatment oluşturuyor mu?

olmalıdır.

Birbiriyle ilgisiz beş fikri aynı variant’a doldurup sonuç aldığımızda “hangisi çalıştı?” sorusu cevapsız kalır.

Hipotezde user segment belirtilmeli mi?

Değişiklik belirli bir kullanıcı grubunun problemine dayanıyorsa segment hypothesis içinde açıkça yazılmalıdır.

Statsig’in kendi hypothesis template’i de değişiklik ile user segment’i birlikte tanımlamaya izin verir.^[3]

Örneğin:

“Kullanıcılar için checkout’ı sadeleştirirsek…”

yerine:

“Mobil checkout’a giren yeni kullanıcılar için adres formundaki gereksiz alanları kaldırırsak…”

daha net olabilir.

Fakat sırf template doldurmak için anlamsız segment yaratmaya gerek yoktur.

Research problemi gerçekten belirli bir kullanıcı grubunda yoğunlaşıyorsa segment eklenir.

Hipotez metric ile nasıl bağlanır?

Hipotezin expected behavior bölümü metric seçiminin temelini oluşturur.

Örneğin hypothesis:

“Kategori filtrelerini daha görünür yaparsak kullanıcıların ilgili ürünleri daha kolay bulacağını düşünüyoruz.”

ise yalnız:

FILTER CLICK RATE

ölçmek yeterli olmayabilir.

Çünkü filtre kullanımındaki artış kullanıcının ürün bulma başarısının arttığını tek başına göstermez.

Metric hierarchy şöyle olabilir:

PRIMARY
Product detail progression

SECONDARY
Filter usage
Add-to-cart

GUARDRAIL
Purchase / revenue metric

Optimizely de hypothesis sonucunu business metric’lerle bağlamayı ve experiment başlamadan başarı/failure kriterlerinin belirlenmesini önerir.^[1]

CRO hipotezi ile istatistiksel hipotez aynı şey midir?

Hayır. Bu ayrım özellikle experimentation terminolojisinde önemlidir.

Bu yazıda anlattığımız CRO veya product hypothesis:

“Bu değişiklik kullanıcı davranışını şu nedenle şu yönde değiştirecek.”

şeklindeki ürün veya davranış tahminidir.

İstatistiksel hypothesis testing’de ise ayrıca null hypothesis gibi kavramlar bulunur.

Örneğin bir A/B testinin istatistiksel analizinde null hypothesis treatment’ın ölçülen metric üzerinde etkisi olmadığı varsayımı olabilir.

Statsig p-value’yu, treatment’ın metric üzerinde etkisi olmadığı varsayımı altında gözlenen kadar veya daha uç bir metric delta görülme olasılığıyla ilişkilendirir.^[5]

Dolayısıyla:

CRO / PRODUCT HYPOTHESIS
"Değişikliğin neden davranışı etkilemesini bekliyoruz?"

≠

STATISTICAL NULL HYPOTHESIS
"Ölçülen farkın gerçek bir treatment etkisi olmadığı varsayımı"

İkisini aynı şey gibi kullanmak gereksiz kavram çorbası üretir.

Experiment sonucu hipotezi kanıtlar mı?

Burada dilimizi dikkatli kullanmak gerekir.

Experiment sonucunda beklenen metric yönünde yeterli evidence bulabiliriz.

Ancak bu her zaman hypothesis içindeki bütün nedensel açıklamanın kesin olarak doğru olduğunu kanıtlamaz.

Örneğin:

“Teslimat bilgisini görünür yaparsak belirsizlik azalacağı için add-to-cart artar.”

hypothesis’inde variant gerçekten add-to-cart’ı artırabilir.

Bu treatment’ın davranış üzerinde etkisi olduğuna dair evidence sağlayabilir.

Fakat kullanıcıların gerçekten “belirsizlik azaldığı için” davrandığını yalnız metric sonucu üzerinden doğrudan gözlemlemiş olmayız.

Başka mekanizmalar da etkili olabilir.

Statsig de experiment sonuçlarının istatistiksel yorumlar olduğunu, kesin gerçekler olmadığını ve statistically significant sonuçlarda dahi false positive, multiple comparison ve başka açıklamaların dikkate alınması gerektiğini vurgular.^[6]

Daha doğru dil:

• Hypothesis ile uyumlu evidence bulundu.
• Treatment hedeflenen metric’i olumlu etkiledi.
• Beklenen etki gözlenmedi.
• Mevcut veri hypothesis için yeterli evidence üretmedi.

gibi ifadelerdir.

“Hipotezi bilimsel olarak kanıtladık, kullanıcı psikolojisini çözdük” kısmını insanlığın geri kalanına bırakabiliriz.

Hipotez başarısız olursa research yanlıştı mı?

Hayır.

Bir experiment beklenen sonucu üretmediğinde birkaç olasılık vardır:

• Problem gerçektir fakat solution yanlış olabilir.
• Rationale yanlış olabilir.
• Treatment problemi yeterince güçlü çözmemiş olabilir.
• Metric yanlış seçilmiş olabilir.
• Effect beklenenden küçük olabilir.
• Experiment yeterli evidence üretmemiş olabilir.
• Problem yalnız belirli bir segmentte bulunabilir.

Optimizely de solution beklenen sonucu üretmezse problem statement’a geri dönüp farklı çözümler araştırmayı önerir.^[1]

Bu yüzden optimization cycle:

PROBLEM
↓
HYPOTHESIS
↓
EXPERIMENT
↓
RESULT
↓
LEARNING
↓
NEXT QUESTION

şeklinde ilerlemelidir.

Experiment yalnız winner bulma makinesi değildir.

Null result değersiz midir?

Hayır.

Beklenen etkiyi gözlemleyememek de bilgi üretebilir.

Örneğin delivery information hypothesis’i add-to-cart üzerinde anlamlı bir hareket üretmediyse:

• teslimat bilgisi gerçek objection olmayabilir,
• bilgi zaten yeterince görünür olabilir,
• başka friction daha güçlü olabilir,
• treatment kullanıcı algısını değiştirmek için yetersiz olabilir.

Statsig, statistically insignificant sonuçların hypothesis’in yanlış olduğunu otomatik olarak kanıtlamadığını; underpowered experiment gibi nedenlerle gerçek effect olsa bile neutral sonuç görülebileceğini belirtir.^[6]

Bu nedenle:

NO SIGNIFICANT EFFECT
≠
"PROBLEM YOK"

Sonuç yeni research sorusu üretebilir.

Hipotez backlog’u nasıl tutulmalı?

Bir CRO programında hypothesis yalnız experiment tool’un description alanında kaybolmamalıdır.

Pratik hypothesis card şu alanları içerebilir:

Alan	İçerik
Problem	Hangi kullanıcı problemi çözülüyor?
Evidence	Problemi hangi research kaynakları destekliyor?
Segment	Problem kimlerde görülüyor?
Hypothesis	Değişiklik ve beklenen davranış nedir?
Rationale	Değişikliğin neden işe yaraması bekleniyor?
Treatment	Ne değiştirilecek?
Primary Metric	Ana karar hangi ölçümle verilecek?
Secondary / Guardrail	Downstream ve olası olumsuz etkiler nasıl izlenecek?
Priority	Evidence, impact ve effort açısından öncelik nedir?
Result	Experiment ne gösterdi?
Learning	Kullanıcı veya ürün hakkında ne öğrendik?
Next Action	Ship, iterate, investigate veya abandon?

Böyle bir yapı experiment geçmişini yalnız:

TEST 27
CONTROL: %4.2
VARIANT: %4.6

seviyesinde saklamaz.

Neden bu testi yaptığımızı ve ne öğrendiğimizi de korur.

Kötü CRO hipotezi örnekleri

“CTA’yı kırmızı yaparsak conversion artar.”

Problem bilinmiyor. Evidence yok. Rationale yok.

“Homepage’i yeniden tasarlarsak kullanıcı deneyimi iyileşir.”

Treatment aşırı geniş, outcome belirsiz ve metric tanımlanmamış.

“Rakibimiz social proof kullanıyor, biz de ekleyelim.”

Rakibin uygulaması research evidence değildir.

“Formu kısaltırsak daha fazla lead alırız.”

Form length’in gerçekten friction olduğu doğrulanmamış olabilir. Ayrıca lead quality guardrail’i eksik.

“Daha iyi copy conversion’ı artıracaktır.”

“Daha iyi” tanımlanmamış. Hangi message problemine müdahale edildiği belli değil.

“Yeni tasarım satışları %20 artıracak.”

%20 tahmini nereden geliyor belli değilse sahte precision üretir.

İyi ve kötü hypothesis arasındaki fark

Zayıf	Güçlü
Solution ile başlar.	Problem ile başlar.
Intuition’a dayanır.	Research evidence’a dayanır.
“Conversion artar” der.	Hangi kullanıcı davranışının değişeceğini tanımlar.
Rationale içermez.	Değişikliğin neden etkili olabileceğini açıklar.
Metric belirsizdir.	Primary metric önceden tanımlıdır.
Her şeyi aynı anda değiştirir.	Treatment aynı problem etrafında tutarlıdır.
Winner bulmayı amaçlar.	Problem hakkında öğrenme üretmeyi amaçlar.

CRO hipotezi yazarken sık yapılan hatalar

Research yapmadan hypothesis üretmek

Bu durumda hypothesis çoğu zaman yalnız ekip içindeki en ikna edici kişinin fikridir.

Problem yerine solution yazmak

“Formu kısaltmalıyız” problem değildir.

Davranışı motivation sanmak

Kullanıcının bir alana tekrar bakması neden baktığını doğrudan göstermez.

Rationale yazmamak

Change ile expected outcome arasında neden-sonuç mantığı kurulmaz.

Metric’i hypothesis bittikten sonra düşünmek

Test sonucu görüldükten sonra en iyi metric’i başarı kriteri seçmek cherry-picking riskini artırır. Statsig de hypothesis öncesinde az sayıda, hypothesis ile doğrudan ilişkili key metric belirlenmesini önerir.^[6]

Çok fazla metric’i success kriteri yapmak

Her metric primary olduğunda aslında hiçbir metric primary değildir.

Winner’ı kullanıcı gerçeği ilan etmek

Variant’ın daha yüksek metric üretmesi rationale’ın bütün psikolojik açıklamasını otomatik olarak doğrulamaz.

Null sonucu başarısızlık saymak

Experiment beklenen etkiyi göstermese bile problem veya solution hakkında bilgi üretebilir.

CRO hipotezi için son kontrol listesi

Bir hypothesis experiment backlog’una girmeden önce şu soruların cevaplanabilmesi gerekir:

1. Hangi kullanıcı problemini çözmeye çalışıyoruz?
2. Bu problemin var olduğunu hangi evidence destekliyor?
3. Observation ile yorum birbirinden ayrıldı mı?
4. Problem kullanıcı perspektifinden açık mı?
5. Önerilen change somut mu?
6. Bu change’in neden işe yaramasını bekliyoruz?
7. Hangi kullanıcı davranışının değişmesini bekliyoruz?
8. Primary metric bu davranışı gerçekten ölçüyor mu?
9. Downstream veya guardrail metric gerekiyor mu?
10. Treatment aynı problem etrafında yorumlanabilir mi?
11. Sonuç olumlu, nötr veya olumsuz olduğunda ne öğreneceğimiz belli mi?

Bu soruların çoğuna cevap verilemiyorsa henüz experiment problemi değil, research problemi olabilir.

Research’ten experiment’a doğru geçiş nasıl görünür?

CRO hypothesis’in sistem içindeki yeri tam olarak iki disiplin arasındadır:

CONVERSION RESEARCH
↓
EVIDENCE
↓
PROBLEM DEFINITION
↓
CRO HYPOTHESIS
↓
METRIC DEFINITION
↓
EXPERIMENT DESIGN
↓
RESULT
↓
LEARNING

Research neyin yanlış olabileceğini araştırır.

Hypothesis problemi test edilebilir bir tahmine dönüştürür.

Measurement hangi davranışın değerlendirileceğini belirler.

Experiment ise treatment’ın gerçekten beklenen etkiyi üretip üretmediği hakkında evidence sağlar.

Bu yüzden güçlü CRO hypothesis:

"BENCE BUNU DEĞİŞTİRELİM"

ile:

"RESEARCH BİZE ŞU PROBLEMİ GÖSTERİYOR,
BU NEDENLE ŞU DEĞİŞİKLİĞİN
ŞU DAVRANIŞI ETKİLEMESİNİ BEKLİYORUZ
VE BUNU ŞU METRİKLE DEĞERLENDİRECEĞİZ."

arasındaki farktır.

CRO hipotezi test fikrini süsleyen bir cümle değildir. Research bulgusunu ölçülebilir bir öğrenme sorusuna dönüştüren köprüdür.

Kaynaklar ve teknik referanslar

1. Optimizely — Design an Effective Hypothesis
2. CXL — Conversion Research to Identify Better A/B Tests
3. Statsig — Create an Experiment
4. Optimizely — Primary Metrics, Secondary Metrics, and Monitoring Goals
5. Statsig — Introduction to Experiment Statistical Methods
6. Statsig — Best Practices and Avoiding False Positives