Düşük Trafikli Sitelerde CRO Nasıl Yapılır?

Bir site ayda 300 ziyaret alıyor.

Ayda 5 veya 10 form gönderimi gerçekleşiyor.

Landing page’deki CTA metnini değiştirip A/B test başlatıyoruz.

Trafiğin yarısı A’ya, yarısı B’ye gidiyor.

Bir ay geçiyor.

A varyasyonu 3 lead, B varyasyonu 5 lead üretiyor.

B kazandı mı?

Bilmiyoruz.

Bir sonraki ay tablo tamamen tersine dönebilir.

Buradaki problem CRO yapılamaması değildir.

Problem, elimizdeki trafik hacmine uygun olmayan bir doğrulama yöntemini kullanmaya çalışmamızdır.

Düşük trafikli sitelerde CRO yapılabilir.

Ancak optimizasyon programının merkezi çoğu zaman A/B testing değil:

• teknik analiz,
• heuristic analysis,
• analytics ve funnel analizi,
• session recording,
• customer interviews,
• sales feedback,
• usability testing,
• copy research,
• competitor research,
• before/after measurement

olmalıdır.

Bu nedenle düşük trafikli sitelerde CRO’nun en önemli prensibi şudur:

Experimentation ≠ CRO.

A/B testing, optimizasyon sürecinde kullanılabilecek güçlü bir doğrulama yöntemidir.

Ama CRO’nun kendisi değildir.

Düşük trafik CRO için neden problem yaratır?

Düşük trafik bütün CRO çalışmalarını değil, özellikle istatistiksel deney kapasitesini sınırlar.

A/B testin temel problemi şudur:

Control ve treatment arasında gördüğümüz fark gerçek treatment effect mi, yoksa random variation mı?

İki varyasyon arasındaki gerçek fark küçüldükçe bu farkı güvenilir biçimde tespit etmek için genellikle daha fazla veri gerekir.

Örneğin %50 gibi çok büyük bir etkiyi tespit etmek ile %5 gibi küçük bir etkiyi tespit etmek aynı sample size ihtiyacını oluşturmaz.

Optimizely de düşük trafikli siteler için hazırladığı rehberde küçük conversion uplift’lerini doğrulamanın uzun sürebileceğini, bu nedenle high-impact değişikliklere ve daha yakın micro-conversion’lara odaklanmanın daha uygulanabilir olabileceğini belirtiyor.

Bu yüzden:

Low Traffic
≠
No CRO

Low Traffic
=
Lower Experimentation Capacity

CRO için minimum trafik kaç olmalı?

“Aylık 10.000 ziyaretçinin altındaysan CRO yapamazsın” gibi tek bir evrensel sayı yoktur.

A/B testing kapasitesini yalnız trafik belirlemez.

En azından şu değişkenler birlikte önemlidir:

• baseline conversion rate,
• test edilen metrik,
• Minimum Detectable Effect (MDE),
• metric variance,
• statistical power,
• kabul edilen hata riski,
• varyasyon sayısı,
• test için kullanılabilecek trafik oranı.

Örneğin ayda 5.000 ziyaret alan fakat yalnız 10 satın alma üreten bir site ile aynı trafikte 1.000 signup üreten bir ürünün experimentation kapasitesi aynı değildir.

Bu nedenle doğru soru:

Kaç ziyaretçim var?

değil yalnızca.

Daha doğru soru:

İş açısından önem verdiğim büyüklükteki bir değişikliği mevcut trafik ve conversion hacmimle makul sürede tespit edebilir miyim?

100–500 ziyaret alan bir sitede A/B test yapılabilir mi?

Teknik olarak bir A/B test aracı kurulabilir.

Fakat bu, testin karar vermek için yeterli bilgi üreteceği anlamına gelmez.

Ayda 100–500 ziyaret alan tipik bir lead-generation sitesinde macro conversion sayısı da düşükse:

Traffic
↓
50 / 50 Split
↓
Çok az kullanıcı / varyasyon
↓
Çok az conversion
↓
Yüksek belirsizlik

oluşur.

Bu durumda küçük headline, renk veya CTA değişikliklerinin gerçek etkisini güvenilir biçimde ayırmak pratik olmayabilir.

Ancak bu:

Siteye dokunmayalım, trafik 10.000 olunca CRO yaparız.

demek değildir.

Tam tersine, trafik azken her ziyaretçinin değerli olması nedeniyle:

• açık usability sorunlarını,
• ölçüm hatalarını,
• zayıf mesajları,
• teknik friction’ı,
• kullanıcı itirazlarını

daha erken düzeltmek anlamlı olabilir.

Düşük trafikli sitelerde CRO nasıl yapılır?

Düşük trafik CRO metodolojisini ortadan kaldırmaz.

Yalnızca kanıt hiyerarşisini değiştirir.

Ben süreci şöyle düşünürüm:

MEASUREMENT
↓
TECHNICAL QA
↓
HEURISTIC REVIEW
↓
BEHAVIOURAL DATA
↓
CUSTOMER / USER RESEARCH
↓
PROBLEM SYNTHESIS
↓
HIGH-CONFIDENCE CHANGE
↓
BEFORE / AFTER MEASUREMENT
↓
LEARNING

1. Önce conversion tanımını belirle

Düşük trafikli sitede en sık yapılan hatalardan biri yalnız final conversion’a bakmaktır.

Örneğin B2B hizmet sitesinde:

Lead Form Submit

ana conversion olabilir.

Ancak ayda yalnız 5 lead oluşuyorsa yalnız bu metriğe bakarak sayfanın nerede zorlandığını anlamak güçleşir.

Bu nedenle funnel boyunca anlamlı davranış sinyallerini ayrıca ölçmek faydalıdır:

Landing Page View
↓
Primary CTA Click
↓
Form Start
↓
Form Submit
↓
Qualified Lead

E-ticarette:

Product View
↓
Add to Cart
↓
Begin Checkout
↓
Purchase

gibi.

Ancak micro-conversion’ları gerçek iş sonucu sanmamak gerekir.

CTA click yükselirken qualified lead düşüyorsa business outcome iyileşmemiş olabilir.

Bu yüzden:

Micro Conversion
=
Diagnostic Signal

Macro Conversion
=
Business Outcome'a daha yakın sinyal

ayrımını korumak gerekir.

2. Measurement QA yapmadan CRO yapma

Düşük trafikte veri zaten azdır.

Bir de veri yanlışsa analiz neredeyse tamamen anlamsız hale gelir.

Örneğin:

• form_submit iki kez tetikleniyor,
• WhatsApp tıklaması ölçülmüyor,
• purchase yalnız bazı ödeme yöntemlerinde çalışıyor,
• thank-you page tekrar yenilendiğinde yeni conversion sayılıyor

olabilir.

Bu durumda conversion rate değişimini UX problemi gibi yorumlamak hatalıdır.

Ölçüm sistemi stratejinin sonunda eklenen raporlama katmanı değildir. SEO stratejisinde ölçümün uygulamanın sonuna bırakılmaması gerektiğini savunmamın nedeni de aynıdır: güvenmediğimiz veri sonraki bütün kararları bozar.

3. Heuristic analysis yap

Heuristic analysis, bir interface’i önceden tanımlanmış kullanılabilirlik veya conversion prensipleri üzerinden sistematik biçimde incelemektir.

Bu yöntem kullanıcı trafiğine ihtiyaç duymaz.

NN/g heuristic evaluation’ı design problemlerini belirlemek için evaluator’ların interface’i kullanılabilirlik prensiplerine göre incelemesi olarak tanımlar.

Özellikle sınırlı research budget’ında açık UX problemlerini bulmak için kullanılabilir.

Ancak önemli sınır şudur:

Heuristic evaluation kullanıcı araştırmasının yerine geçmez.

Expert review bize:

Burada problem olabilir.

der.

Kullanıcı araştırması ise bu problemin gerçek kullanıcı davranışındaki karşılığını anlamaya yardım eder.

CRO açısından sayfayı şu lenslerle inceleyebilirsin:

Lens	Soru
Relevance	Sayfa kullanıcının geldiği ihtiyaçla eşleşiyor mu?
Clarity	Teklif, değer ve sonraki adım açık mı?
Value	Kullanıcı neden bu teklifi önemsemeli?
Trust	İddiaları destekleyecek yeterli kanıt var mı?
Friction	Görevi gereksiz zorlaştıran ne var?
Distraction	Ana karardan uzaklaştıran ne var?
Usability	Kullanıcı görevi teknik olarak rahat tamamlayabiliyor mu?

4. Teknik friction analizi yap

Düşük trafik, açık teknik hataları görmezden gelmek için gerekçe değildir.

Örneğin:

• mobilde CTA ekran dışında kalıyor,
• form validation mesajı görünmüyor,
• telefon alanı belirli format dışında giriş kabul etmiyor,
• checkout button bazı browser’larda çalışmıyor,
• sayfa etkileşime geç cevap veriyor,
• popup formu kapatıyor,
• stok bilgisi yanlış görünüyor

olabilir.

Bunların bir bölümünü A/B test etmeye gerek yoktur.

Çalışmayan bir buton:

Control:
Broken

Treatment:
Works

diye test edilmez.

Bug düzeltilir.

5. Funnel analysis kullan ama sayıların sınırını bil

Az trafik funnel analysis’i tamamen anlamsız hale getirmez.

Ancak küçük sample üzerinde yüzdeleri fazla kesin yorumlamak gerekir.

Örneğin:

100 Landing View
↓
20 CTA Click
↓
8 Form Start
↓
4 Form Submit

gibi bir funnel bize en azından davranış zincirini görme imkânı verir.

Fakat:

CTA → Form Start drop-off tam olarak %60’tır ve problem kesin burada.

gibi aşırı güvenli sonuçlar çıkarmak doğru değildir.

Düşük trafikte funnel’ın amacı çoğu zaman:

Hangi alanı daha yakından araştırmalıyız?

sorusuna cevap vermektir.

Yani:

Funnel
→ Problem Localization

Research
→ Problem Explanation

6. Session recordings kullan ama Netflix gibi izleme

Session recording düşük trafikli sitelerde özellikle faydalıdır çünkü tek tek gerçek kullanıcı davranışlarını görebilirsin.

Ancak araç açıp rastgele 150 video izlemek research yöntemi değildir.

Önce araştırma sorusu belirle.

Örneğin:

Mobil kullanıcılar formu başlatıyor fakat neden tamamlamıyor olabilir?

Ardından özellikle:

• mobile sessions,
• form_start yapan kullanıcılar,
• submit gerçekleştirmeyen sessions

incelenebilir.

Aradığımız şey:

• rage click,
• dead click,
• validation problemi,
• geri dönüş,
• tekrar tekrar aynı alanı doldurma,
• beklenmeyen scroll davranışı

gibi belirli sürtünme sinyalleridir.

Session recordings:

Kullanıcıların %42’si bunu yapıyor.

demek için değil;

Bu davranış gerçek kullanıcı oturumlarında oluşuyor mu?

sorusunu araştırmak için daha kullanışlıdır.

7. Customer interviews yap

Trafik az olduğunda tek bir müşteri konuşmasının bilgi yoğunluğu analytics dashboard’daki yüzlerce zayıf sinyalden daha yüksek olabilir.

Özellikle şunları öğrenmek için interview kullanılabilir:

• Neden çözüm aramaya başladınız?
• Başka hangi alternatifleri değerlendirdiniz?
• Satın almadan önce en büyük soru işaretiniz neydi?
• Neredeyse vazgeçmenize ne sebep olacaktı?
• Neden bizi seçtiniz?
• Web sitesinde hangi bilgi eksikti?
• Karar verirken başka kimler etkiliydi?

Ancak interview’de de:

Butonu kırmızı yapsak daha çok tıklar mıydınız?

gibi gelecekteki davranışı tahmin ettirmeye çalışmak zayıf yöntemdir.

Kullanıcıların geçmiş deneyimleri, karar süreçleri, beklentileri ve problemleri üzerine konuşmak daha değerlidir.

8. Sales feedback topla

Özellikle lead-generation ve B2B projelerinde satış ekibi gerçek customer research kaynağıdır.

Sales görüşmelerinde sürekli şu sorular geliyorsa:

• Fiyat ne kadar?
• Süreç nasıl ilerliyor?
• Ne kadar sürüyor?
• Sözleşme var mı?
• Benim sektörümde çalıştınız mı?
• Sonuç garantisi var mı?
• Teslimatta tam olarak ne var?

bunlar landing page’de cevaplanmayan objection veya information gap sinyalleri olabilir.

Basit bir sistem kurulabilir:

Sales Call
↓
Repeated Question
↓
Objection Tag
↓
Frequency
↓
Landing Page Review
↓
Opportunity

Düşük trafik CRO’nun avantajlarından biri de budur.

Ayda 20 müşteri konuşması varsa bu konuşmaların her biri yüksek bilgi yoğunluğu taşıyabilir.

9. Support kayıtlarını kullan

Customer journey conversion ile bitmez.

Kullanıcı satın aldıktan sonra sürekli:

Bu ürüne hangi uç uyuyor?

diye destek ekibine yazıyorsa problem support’ta ortaya çıkmış olabilir ama kökü product page’dedir.

Aynı şekilde:

Kargom ne zaman gelecek?

sorusu sürekli tekrarlanıyorsa satın alma öncesi delivery expectation yeterince açık olmayabilir.

Bu nedenle support kayıtları:

Post-Purchase Problem
↓
Potential Pre-Purchase Information Gap

ilişkisini açabilir.

10. Usability testing yap

Usability testing düşük trafikli siteler için en güçlü araçlardan biridir çünkü canlı site trafiğine bağımlı değildir.

Gerçek hedef kullanıcıya görev verirsin:

Evinizde beton duvara raf monte edeceksiniz. Bu siteden size uygun ürünü bulun ve satın almaya hazır olduğunuz noktaya kadar ilerleyin.

Sonra kullanıcının:

• hangi bilgiyi aradığına,
• nerede durduğuna,
• hangi etiketi anlamadığına,
• hangi seçeneği yanlış yorumladığına,
• hangi noktada güvensiz hissettiğine

bakarsın.

NN/g qualitative usability testing için küçük katılımcı gruplarıyla iteratif çalışmanın etkili olabileceğini ve tipik kullanıcıların seçilmesinin kritik olduğunu vurgular.

Buradaki amaç istatistiksel population estimate üretmek değildir.

Amaç usability problem bulmaktır.

11. Copy research yap

Düşük trafikli sitelerde copy’yi yalnız “daha yaratıcı yazalım” diye değiştirmek yerine müşterinin kendi dilini araştırabilirsin.

Kaynaklar:

• customer interviews,
• sales calls,
• support tickets,
• review’lar,
• on-site surveys,
• chat kayıtları,
• search queries

olabilir.

Örneğin şirket hizmetini:

360 derece dijital büyüme çözümleri.

diye tanımlıyor olabilir.

Müşteri ise:

Google’dan trafik geliyor ama teklif gelmiyor.

diyebilir.

İkinci ifade gerçek customer language açısından çok daha güçlü bir problem sinyalidir.

12. Competitor research yap ama kopyalama

Rakip analizi:

Rakipte testimonial var, biz de ekleyelim.

değildir.

Daha faydalı sorular:

• Rakip hangi value proposition’ı kullanıyor?
• Hangi objections cevaplanıyor?
• Fiyat nasıl çerçeveleniyor?
• Hangi proof kullanılıyor?
• Hangi use case’ler vurgulanıyor?
• Hangi bilgiler bütün rakiplerde var?
• Hangi bilgiler hiçbirinde yok?

Competitor research çözümü değil, category expectations’ı anlamaya yardımcı olabilir.

13. Search data’yı CRO research’e bağla

Düşük trafikli sitelerde organik query verisi kullanıcının sayfaya hangi beklentiyle geldiğini anlamada özellikle değerlidir.

Örneğin hizmet sayfası:

"kurumsal klima servisi"
"vrf bakım fiyatları"
"vrf klima bakım sözleşmesi"

gibi sorgulardan trafik alıyorsa bu üç query aynı geniş hizmet alanında olsa bile farklı information need ve decision stage taşıyabilir.

SEO’da kullanıcı ihtiyacını doğru page role ile eşleştirmek nasıl önemliyse CRO’da da landing page’in bu beklentiyi devam ettirmesi gerekir.

Bu nedenle search demand’i kullanıcı ihtiyacı ve page role üzerinden değerlendiren SEO yaklaşımı, düşük trafikli sitelerde CRO research için de başlangıç verisi sağlayabilir.

14. E-ticarette ürün ve kategori davranışını incele

Düşük trafikli bir e-ticaret sitesinde yalnız purchase metriğine bakmak oldukça yavaş öğrenme üretir.

Bunun yerine:

• kategori → ürün geçişi,
• filter usage,
• product comparison,
• add-to-cart,
• cart → checkout,
• site search

davranışları araştırılabilir.

E-ticaret SEO sisteminde de görünürlük ile gelir arasındaki ayrımı özellikle koruyorum: search impression veya organic session tek başına ticari değer kanıtı değildir. Aynı mantık CRO tarafında da geçerlidir; micro-conversion hareketi nihai satış etkisini tek başına kanıtlamaz.

15. Büyük ve yüksek güvenli değişikliklere öncelik ver

Düşük trafik:

Daha rastgele değişiklik yap.

demek değildir.

Tam tersine, değişiklik başına araştırma kalitesinin artması gerekir.

Şu test fikirleri:

• button rengini değiştir,
• border-radius değiştir,
• CTA’yı 20 piksel yukarı taşı

düşük trafikte özellikle kötü adaylardır.

Beklenen effect küçük olabilir ve bunu kanıtlamak çok fazla veri gerektirebilir.

Daha anlamlı change package:

Kullanıcıların hizmeti anlamadığına dair interview + sales + heuristic evidence var. Hero’daki genel mesajı spesifik problem, outcome, proof ve CTA yapısına dönüştürelim.

olabilir.

Burada değişiklik daha büyüktür.

Ama daha önemlisi, arkasındaki evidence daha güçlüdür.

16. High-confidence fix ile hypothesis’i ayır

Düşük trafikte her değişikliği aynı şekilde değerlendirmemek gerekir.

Üç sınıf kullanabiliriz:

Durum	Yaklaşım
Açık bug / accessibility / usability problemi	Düzelt
Birden fazla research kaynağıyla desteklenen yüksek güvenli problem	Uygula + dikkatli before/after ölç
Belirsiz veya birbirine yakın alternatifler	Trafik uygunsa experiment

Örneğin:

Mobil form submit butonu klavyenin arkasında kalıyor.

yüksek güvenli usability problemidir.

Bunu A/B test etmen gerekmez.

Ama:

Headline A mı, headline B mi daha ikna edici?

sorusu gerçek experimentation adayına daha yakındır.

17. Before/after measurement kullanılabilir mi?

Evet.

Ama doğru isimle.

Before/after measurement bize değişiklik öncesi ve sonrası performansın nasıl hareket ettiğini gösterebilir.

Örneğin:

Önce:
50 form_start
10 form_submit
%20 completion

Değişiklik

Sonra:
55 form_start
18 form_submit
%32,7 completion

Bu güçlü bir iyileşme sinyali olabilir.

Ancak:

Değişiklik kesin olarak %63,5 uplift üretti.

demek doğru değildir.

Çünkü before ve after dönemleri randomize değildir.

Arada:

• traffic mix,
• campaign,
• seasonality,
• pricing,
• competition,
• site değişiklikleri

farklılaşmış olabilir.

Bu nedenle:

Before / After
=
Directional Evidence

Randomized Experiment
=
Causal Evidence için daha güçlü tasarım

ayrımını korumak gerekir.

11 bin ürünlü e-ticaret vaka analizinde de benzer nedenle performans artışını gösterirken her SEO müdahalesinin nedensel katkısını ayrı ayrı kanıtladığımı iddia etmiyorum. Ölçümün sınırlarını açık yazmak, zayıflık değil metodoloji disiplinidir.

Düşük trafikte before/after analizi nasıl daha iyi yapılır?

A/B testin yerine geçtiğini iddia etmeden before/after analizi daha düzenli hale getirilebilir.

Örneğin:

• değişiklik tarihini analytics üzerinde annotation olarak kaydet,
• aynı trafik kaynaklarını ayrı incele,
• mobile ve desktop’ı karıştırma,
• kampanya dönemlerini not et,
• macro ve micro metric’leri birlikte takip et,
• haftalık tekil değişim yerine daha geniş trend penceresi kullan,
• aynı anda onlarca büyük değişiklik yapıldıysa attribution iddiasını azalt.

Buradaki amaç:

Bilimsel A/B test yapamadık, o zaman hiçbir şey bilemeyiz.

demek değildir.

Ama:

Rakam yükseldi, kesin bizim değişiklik yaptı.

demek de değildir.

İki uç arasında kanıt seviyesini doğru isimlendirmek gerekir.

Düşük trafikli sitelerde hangi CRO yöntemleri daha değerlidir?

Yöntem	Trafik ihtiyacı	Ana soru
Technical QA	Yok	Site gerçekten çalışıyor mu?
Heuristic Analysis	Yok	Olası usability / clarity problemleri neler?
Usability Testing	Canlı trafik gerekmez	Kullanıcı görevi tamamlayabiliyor mu?
Customer Interview	Site trafiğine bağlı değil	Kullanıcı neden karar verdi?
Sales Feedback	Site trafiğine bağlı değil	Hangi itirazlar tekrar ediyor?
Support Research	Site trafiğine bağlı değil	Hangi bilgi eksiklikleri tekrarlanıyor?
Session Recording	Düşük hacimde bile kullanılabilir	Gerçek oturumlarda friction nasıl görünüyor?
Funnel Analysis	Hacim arttıkça güven artar	Hangi geçiş araştırılmalı?
Before/After	Düşük hacimde mümkün	Değişiklik sonrası yön ne oldu?
A/B Testing	Metric ve effect’e göre yeterli sample gerekir	Değişiklik nedensel etki üretti mi?

Low-traffic CRO’da evidence stacking nedir?

Az trafik olduğunda tek bir veri kaynağının karar vermesini beklemek yerine farklı kanıtları üst üste koymak daha kullanışlıdır.

Örneğin:

Analytics:
Form completion düşük

+

Session Recordings:
Kullanıcılar fiyat alanında geri dönüyor

+

Sales:
"Fiyat nasıl hesaplanıyor?" sorusu sürekli geliyor

+

Interviews:
Kullanıcı toplam maliyeti anlayamadığını söylüyor

+

Heuristic Review:
Fiyatlandırma mekanizması açıklanmıyor

Burada elimizde randomize experiment yoktur.

Ama beş farklı sinyal aynı problemi göstermektedir.

Bu:

Kesin causal proof.

değildir.

Ama:

Yüksek güvenli optimization opportunity.

olabilir.

Düşük trafikli sitelerde CRO’nun merkezi bence tam olarak budur:

Tek bir zayıf metriğe aşırı güvenmek yerine farklı kanıt kaynaklarını aynı problem etrafında birleştirmek.

Düşük trafikte CRO önceliklendirmesi nasıl yapılmalı?

Klasik test backlog’u yerine problem backlog’u kullanmak daha faydalı olabilir.

Örneğin:

Problem	Evidence	Impact	Confidence
Mobil form error görünmüyor	QA + recordings	Yüksek	Yüksek
Value proposition belirsiz	Interviews + sales + heuristic	Yüksek	Yüksek
CTA rengi zayıf olabilir	Designer opinion	Bilinmiyor	Düşük

Bu tabloda yapılacak ilk iş oldukça açıktır.

İnsanlar buna rağmen CTA rengini seçebilir; çünkü renk değiştirmek form sistemini düzeltmekten daha eğlencelidir. İş sonuçları ise eğlence takvimine göre çalışmıyor.

Düşük trafikli sitelerde CRO için pratik framework

Ben düşük trafik CRO sürecini sekiz aşamaya indirgerdim:

1. MEASURE
Gerçek conversion ve davranışlar doğru ölçülüyor mu?

↓

2. FIX
Açık teknik ve usability problemleri var mı?

↓

3. LOCATE
Analytics ve funnel nereleri şüpheli gösteriyor?

↓

4. LISTEN
Customer, sales ve support ne söylüyor?

↓

5. OBSERVE
Kullanıcı gerçekten nasıl davranıyor?

↓

6. SYNTHESIZE
Hangi problem birden fazla kanıtla destekleniyor?

↓

7. IMPROVE
En yüksek güvenli değişiklik ne?

↓

8. MEASURE AGAIN
Sonuç hangi yönde değişti ve ne öğrendik?

Trafik büyüdüğünde sürece yeni bir katman eklenir:

9. EXPERIMENT
Belirsiz alternatifleri randomize kontrollü deneyle test et.

Yani experimentation CRO’ya sonradan eklenen yabancı bir yöntem değildir.

CRO sisteminin veri hacmi yeterli olduğunda daha güçlü hale gelen doğrulama katmanlarından biridir.

Düşük trafik CRO’nun dezavantajı nedir?

Dürüst cevap:

Daha az certainty.

Düşük trafikte birçok karar:

Bu değişiklik kesin %12 uplift üretti.

seviyesinde doğrulanamaz.

Daha çok:

Bu problemi destekleyen birkaç bağımsız kanıt var, değişikliği yaptık ve sonraki dönemde ilgili davranış iyileşti.

seviyesinde konuşuruz.

Bu bilimsel disiplinden vazgeçmek değildir.

Tam tersine elimizdeki kanıtın sınırını dürüstçe tanımlamaktır.

Düşük trafik CRO’nun avantajı var mı?

Var.

Küçük işletmelerde customer proximity genellikle daha yüksektir.

Yani:

• satış ekibine ulaşmak daha kolaydır,
• müşteriyle birebir konuşmak mümkündür,
• support kayıtları daha yakından incelenebilir,
• sayfalar daha hızlı değiştirilebilir,
• bürokrasi daha düşüktür.

Büyük şirketin milyonlarca event’i olabilir.

Küçük işletmenin ise müşteriyle doğrudan konuşma avantajı vardır.

İkisi farklı türde veri üretir.

SEO’dan gelen ilk trafik neden CRO için değerlidir?

Yeni bir site ilk aylarda henüz büyük trafik üretmeyebilir.

Ama gelen ilk kullanıcılar bile bize önemli sorular açabilir.

Örneğin:

Search Demand
↓
Organic Click
↓
Landing Page
↓
Behaviour
↓
Sales Conversation
↓
Customer Question
↓
Site Improvement

Bu yüzden SEO ve CRO’yu:

Önce SEO bitsin, sonra CRO’ya başlarız.

şeklinde tamamen ardışık düşünmek doğru değildir.

SEO görünürlük oluştururken CRO research de gelen kullanıcıların ne istediğini öğrenmeye başlayabilir.

E-ticaret SEO’da search visibility ile revenue’nun aynı metrik olmadığını özellikle ayırmamın nedeni de budur.

Trafik acquisition sisteminin çıktısıdır.

İşletmenin asıl sorusu bu trafiğin devamında ne olduğudur.

Düşük trafikli sitelerde yapılmaması gerekenler

Her şeyi A/B test etmeye çalışma

Yeterli sample yoksa dashboard’ın yeşil/kırmızı göstermesi sonucu güvenilir hale getirmez.

Küçük UI değişikliklerinin peşine düşme

Küçük expected effect genellikle daha yüksek sample ihtiyacı yaratır.

Tek bir session recording üzerinden karar verme

Bir kullanıcının davranışı bütün kullanıcı kitlesi değildir.

Best practice’i kanıt sanma

“Form kısa olmalı”, “CTA above the fold olmalı” veya “navigasyon kaldırılmalı” gibi kurallar bağlama göre değişir.

Before/after sonucu causal proof gibi sunma

İyileşme vardır demek başka, iyileşmenin tek nedenini kanıtlamak başkadır.

Analytics yok diye araştırmayı bırakma

Customer interviews, sales, support ve usability testing canlı trafik hacmine bağımlı değildir.

Analytics var diye müşteriyle konuşmayı bırakma

Event bize davranışı söyler.

Kullanıcının neden o kararı verdiğini her zaman açıklamaz.

Düşük trafikte CRO yapılır mı?

Evet.

Ama yöntem değişir.

Yüksek trafikli experimentation programı şöyle görünebilir:

Research
↓
Hypothesis
↓
A/B Test
↓
Statistical Result
↓
Ship / Reject

Düşük trafikli CRO ise daha çok:

Research
↓
Evidence Stacking
↓
High-Confidence Problem
↓
Implementation
↓
Before / After
↓
Continued Observation
↓
Learning

şeklinde ilerleyebilir.

Trafik büyüdükçe iki sistem birbirine yaklaşır.

Sonuç: CRO yapmak için milyonlarca ziyaretçiye ihtiyacın yok

Düşük trafikli bir sitede küçük A/B testleri çalıştırmak çoğu zaman kötü kaynak kullanımıdır.

Fakat buradan:

CRO için trafik yok.

sonucu çıkmaz.

Doğru çıkarım:

Bu aşamada randomize experimentation kapasitemiz sınırlı.

olmalıdır.

Aradaki fark büyüktür.

CRO hâlâ:

• ölçüm kurabilir,
• teknik friction bulabilir,
• funnel inceleyebilir,
• kullanıcı davranışını gözlemleyebilir,
• müşteriyle konuşabilir,
• sales ve support verisini analiz edebilir,
• copy araştırabilir,
• usability test yapabilir,
• yüksek güvenli problemleri düzeltebilir,
• değişiklik sonrası sonucu ölçebilir.

Bu nedenle düşük traffic CRO’nun temel modeli:

Measure
↓
Observe
↓
Listen
↓
Diagnose
↓
Improve
↓
Measure Again

olmalıdır.

Trafik arttığında:

Experiment

katmanı daha güçlü biçimde sisteme girer.

Experimentation, CRO’nun kanıt üretme yöntemlerinden biridir. CRO’nun tamamı değildir.

Sık Sorulan Sorular

Düşük trafikli sitelerde CRO yapılabilir mi?

Evet. Trafik düşüklüğü özellikle A/B testing kapasitesini sınırlar; heuristic analysis, customer interviews, usability testing, technical analysis, sales feedback, session recording ve benzeri CRO araştırma yöntemlerini ortadan kaldırmaz.

CRO için minimum kaç ziyaretçi gerekir?

Evrensel bir minimum ziyaretçi sayısı yoktur. Experiment kapasitesi baseline conversion rate, test edilen metric, Minimum Detectable Effect, statistical power ve trafik hacmi gibi faktörlere bağlıdır.

Ayda 500 ziyaret alan bir sitede A/B test yapılabilir mi?

Teknik olarak yapılabilir ancak macro conversion sayısı düşükse küçük değişikliklerin etkisini güvenilir biçimde tespit etmek pratik olmayabilir. Böyle durumlarda qualitative research ve yüksek güvenli iyileştirmeler çoğu zaman daha verimlidir.

A/B testing olmadan CRO yapılabilir mi?

Evet. A/B testing CRO’da kullanılan doğrulama yöntemlerinden yalnız biridir. CRO ayrıca research, measurement, funnel analysis, usability, copy, user research ve friction reduction çalışmalarını kapsar.

Düşük trafikli sitelerde hangi CRO yöntemi en değerlidir?

Tek bir yöntem yoktur. Teknik QA, heuristic analysis, customer interviews, sales feedback ve usability testing canlı trafik hacmine daha az bağımlı oldukları için özellikle değerlidir. En güçlü sonuç genellikle birden fazla veri kaynağını birlikte değerlendirmekten gelir.

Before/after analizi A/B test yerine kullanılabilir mi?

Değişiklik öncesi ve sonrası performans karşılaştırılabilir ancak bu yöntem randomize experiment ile aynı nedensel güveni sağlamaz. Traffic mix, seasonality, kampanyalar ve başka değişiklikler sonucu etkileyebilir.

Session recordings düşük trafikte işe yarar mı?

Evet. Özellikle belirli bir problem veya funnel adımı hedeflenerek incelendiğinde gerçek kullanıcıların yaşadığı usability ve friction sorunlarını anlamaya yardımcı olabilir. Ancak birkaç session üzerinden genel kullanıcı kitlesi hakkında kesin oranlar çıkarılmamalıdır.

Trafik arttığında CRO yaklaşımı değişir mi?

Evet. Araştırma ve problem teşhisi devam eder; ancak yeterli sample oluştuğunda A/B testing gibi randomize experimentation yöntemleri hipotezlerin nedensel etkisini daha güvenilir biçimde doğrulamak için daha sık kullanılabilir.

Kaynaklar ve teknik referanslar

1. Optimizely — Test Tips for Low-Traffic Sites
2. Optimizely — Sample Size Calculations for Experiments
3. CXL — Conversion Research
4. CXL — How to Run A/B Tests
5. Nielsen Norman Group — How to Conduct a Heuristic Evaluation
6. Nielsen Norman Group — Qualitative Usability Testing
7. Baymard Institute — Cart & Checkout Usability Research