CRO danışmanlığı: sürtünmeyi ölçerek, deneyle kanıtlanan dönüşüm.

Bu rehberi, sitesine düzenli trafik gelen ama ziyaretçinin hangi adımda ve neden vazgeçtiğini net göremeyen pazarlama, ürün ve e-ticaret ekipleri için yazdık. Anlattığımız ölçüm ve test mekanizmaları Google Analytics, Microsoft Clarity, Firebase ve Optimizely’nin İngilizce resmî belgelerine, W3C’nin erişilebilirlik standardına, web.dev’de yayımlanmış bir vakaya ve ABD Federal Ticaret Komisyonu’nun (FTC) bir duyurusuna dayanıyor; kaynaklar sayfanın altında numaralı olarak listeleniyor. Ürün adlarını ve özellikleri Eylül 2026 itibarıyla kaynaktan doğruladık. Kendi saha gözlemlerimizi ise “Uzman notu” başlığıyla ayrı işaretledik.

CRO danışmanlığında işimiz üç katmanda ilerler: kaybın yerini ve nedenini bulan ölçüm, bulguyu sınanabilir bir hipoteze çeviren deney ve kazananı yayına alıp öğrenmeyi saklayan uygulama. Aşağıdaki on başlık bu katmanları, yaptığımız hesapları ve yapmadığımız işleri sırasıyla anlatır.

CRO nedir, neyi ölçer ve neyi değiştirir?

CRO, ziyaretçilerin sizin için değerli bir eylemi tamamlama oranını ölçer ve bu oranı düşüren sürtünmeyi, trafiği artırmadan sitenin kendisinde değişiklik yaparak azaltır. Ölçümün başlangıç noktası, hangi eylemin “dönüşüm” sayılacağıdır. Google Analytics 4’te işinizin başarısı için özellikle önemli bir eylemi ölçen olaya anahtar etkinlik (key event) denir ve toplanan her olay anahtar etkinlik olarak işaretlenebilir.¹ Google bu adlandırmayı, Analytics’te dönüşüm olarak işaretlenen olayların Google Ads dönüşümlerinden farklı ölçülmesi iki platform arasında tutarsızlık yarattığı için değiştirdi; “dönüşüm” artık reklam kampanyalarının performansını ölçen eylemi anlatıyor.¹ Reklam tarafındaki dönüşüm kurulumunu Google Ads danışmanlığı sayfamızda anlatıyoruz.

CRO çalışmasında dört tür sinyali birbirinden ayırıyoruz:

Ara adımlardan biri hedef yapılırsa ekip en kolay artan sayıyı kovalar: sepete ekleme artar, satış artmaz. Bu yüzden testlerimizde başarı ölçütü her zaman anahtar etkinliktir.

Huni analizi kaybın yerini nasıl gösterir?

Huni analizi, ziyaretçinin bir işi tamamlarken geçtiği adımları sıraya dizer ve her adımda ne kadarının ayrıldığını gösterir; GA4’te bu iş, adım adım başarıyı ve terki görselleştiren huni keşfiyle (funnel exploration) yapılır.² Bir huniye en çok 10 adım tanımlanabilir; adımlar olaylardan ya da boyut değerlerinden kurulur, metriklerden kurulamaz.² Huninin açık ya da kapalı olması, ziyaretçinin nasıl sayılacağını belirler:²

İki türde de ziyaretçi yalnız tanımlanan sırayla tamamladığı adımlarda sayılır; bir adımı atlayan kişi huniden düşer.² Aynı kişi seçilen tarih aralığında huniyi birkaç kez tamamlasa da yalnız ilk dizisi raporlanır.² “Sonraki eylem” ayarı her adımdan sonra en sık yapılan beş eylemi, geçen süre ayarı adımlar arasındaki ortalama süreyi gösterir; aynı huni en çok 4 segmentle karşılaştırılabilir.²

Huniyi önce cihaz kategorisi kırılımında okuyoruz: masaüstünde sorunsuz geçilen bir adımın telefonda belirgin kayıp vermesi, sorunun teklifte değil arayüzde olduğuna işaret eder.

Isı haritası ve oturum kaydı neyi gösterir?

Huni kaybın yerini, ısı haritası ve oturum kaydı ise nedenini gösterir: ziyaretçi nereye tıkladı, nereye kadar kaydırdı, neyi bekleyip bulamadı. Microsoft Clarity’nin tıklama haritası masaüstünde tıklamaları, telefon ve tablette dokunmaları izler; bağlantı olmayan öğelere yapılan tıklamalar da buna dahildir.³ Aynı ekrandan kaydırma, alan, dikkat ve dönüşüm haritalarına geçilebilir. CRO için en çok işe yarayan tıklama türleri şunlardır:³

• Ölü tıklama (dead click): tıklamanın hiçbir etki ya da yanıt üretmediği yerler; tasarımda bağlantı sanılan öğeler bu yolla ortaya çıkar.
• Öfke tıklaması (rage click): kısa bir süre içinde aynı küçük alana art arda yapılan tıklamalar.
• Hata tıklaması: bir JavaScript hatasından hemen önce gelen tıklamalar; bozuk bir düğmenin izini sürerken ilk baktığımız yer.

Bir ısı haritası en çok 100.000 sayfa görüntülemesinden kurulur.³ Oturum kayıtlarında gizlilik kurulumda belirlenir: Clarity, giriş kutularının içeriğini bütün maskeleme modlarında maskeler ve bu davranış değiştirilemez; varsayılan “Balanced” modda sayılar ve e-posta adresleri de maskelenir.⁴ Maskelenen içerik Clarity’ye hiç yüklenmez.⁴

İyi bir test hipotezi nasıl kurulur, neyi hiç test etmeyiz?

İyi bir hipotez bir gözleme dayanır, tek bir değişikliği tanımlar ve beklenen etkiyi testten önce yazar; ziyaretçiyi yanıltan karanlık kalıplar ise hiçbir zaman hipotez listemize girmez. Hipotezleri sıralarken üç soruya bakıyoruz: kayıp ne kadar büyük, kanıt ne kadar güçlü, değişiklik ne kadar pahalı. Trafiği az olan sitelerde bu sıralama daha da önemlidir; çünkü her test haftalar sürer.

FTC, 2022’de yayımladığı raporda karanlık kalıpları (dark patterns) tüketiciyi bir ürün ya da hizmet satın almaya veya gizliliğinden vazgeçmeye kandırabilen ya da yönlendirebilen tasarım uygulamaları olarak ele aldı.⁵ Rapordaki taktikler arasında gerçekte süreli olmayan teklif için geri sayım sayacı, zorlaştırılmış abonelik iptali, gizlenen koşul ve ücretler ve kişiyi daha fazla veri paylaşmaya yönelten gizlilik seçenekleri var.⁵ Duyuruya göre şirketler bu kalıpları deneyip en etkili olanları kullanabilir hâle geldi.⁵ A/B testi tam da bu deneyi mümkün kılan araç olduğu için sınırı baştan koyuyoruz: dönüşümü kısa vadede artırsa bile ziyaretçiyi yanıltan, iptali zorlaştıran, fiyatı saklayan ya da izni önceden işaretleyen bir varyant kurmuyoruz.

Google Optimize kapandıktan sonra A/B testi nasıl kuruluyor?

Google Optimize kapandıktan sonra A/B testi üç yoldan kuruluyor: GA4 ile entegre üçüncü taraf test araçları, Firebase A/B Testing ve varyantın sunucuda seçildiği sunucu tarafı test. Optimize ve Optimize 360, 30 Eylül 2023’ten beri kullanılamıyor; o tarihte açık olan deneyler de sona erdi.⁶ Google, AB Tasty, Optimizely ve VWO ile entegrasyonlar üzerinde çalıştığını ve herkesin kendi test aracını Google Analytics’e bağlayabilmesi için API’lerini herkese açtığını yazıyor.⁶ Firebase A/B Testing ise sürüyor; 23 Ekim 2023 ve sonrasında başlatılan deneyler Optimize altyapısına dayanmadan frekansçı (frequentist) çıkarımla hesaplanıyor.⁶ Firebase sonuçları 0,05 anlamlılık düzeyinde değerlendirir: dönüşüm gibi ikili metriklerde oranlar için z-testi, gelir gibi sürekli metriklerde eşit olmayan varyanslı t-testi kullanır.⁷

Optimizely’nin belgelerine göre tarayıcı tarafı test aracı sayfaya eklenen tek satırlık bir kod parçacığıyla, sunucu tarafı deney ise yazılım geliştirme kitleri (SDK) ve kod dağıtımıyla çalışır; sunucu tarafı deney, yükleme süresini etkileyebilen ya da hafif bir titremeye (flicker) yol açabilen tarayıcı içi deneyden daha verimli olabilir.⁸

Bir test için kaç ziyaretçi gerekir?

Gereken ziyaretçi sayısı dört girdiden hesaplanır: bugünkü dönüşüm oranı, saptamak istediğiniz en küçük fark, kabul ettiğiniz yanlış pozitif riski ve gerçek bir farkı yakalama olasılığı (istatistiksel güç). Optimizely’nin sabit ufuklu (fixed horizon) test belgesi de örneklemi temel metrik değeri, saptanabilir en küçük etki (MDE), anlamlılık düzeyi, varyans ve varyant sayısından hesaplıyor.⁹ İki oranı karşılaştıran bir testte varyant başına örneklem, yaygın yaklaşık formülle şöyle yazılır:

1. p₁: bugünkü dönüşüm oranı (temel oran); huni ve anahtar etkinlik verisinden gelir.
2. p₂: varyantın ulaşması hâlinde fark etmek istediğiniz oran; göreli MDE ile p₁ × (1 + MDE).
3. α: anlamlılık düzeyi, yani gerçekte fark yokken fark bulma riski; iki yönlü testte α = 0,05 için z ≈ 1,96.
4. 1 − β: istatistiksel güç, yani gerçek bir fark varken onu yakalama olasılığı; güç yükseldikçe örneklem büyür.

Formülün paydası farkın karesidir: saptanacak farkı yarıya indirmek, gereken örneklemi yaklaşık dört katına çıkarır. Temel oran düştükçe de aynı göreli farkı görmek için daha çok ziyaretçi gerekir. Optimizely belgesindeki örnekte %5 temel oran, %10 göreli artış, %95 anlamlılık düzeyi ve iki varyantla varyant başına 34.363 ziyaretçi gerekiyor.⁹

Test ne kadar sürer, sonuç ne zaman okunur?

Test süresi, gereken toplam örneklemin teste giren günlük ziyaretçiye bölünmesiyle bulunur ve en az bir tam haftayı kapsayacak biçimde yukarı yuvarlanır. Optimizely, hafta içi ve hafta sonu ziyaretçileri arasındaki fark gibi davranış çeşitliliğini kapsamak için her testin en az bir iş döngüsü, yani yedi gün çalıştırılmasını öneriyor.⁹ Firebase de tipik bir Remote Config deneyi için en kısa süre olarak iki hafta öneriyor.⁷ Sonucun ne zaman okunabileceği ise istatistik yöntemine bağlıdır:¹⁰

Sabit ufuklu testte örneklem tamamlanmadan sonuca bakmak (peeking) yanlış pozitif olasılığını artırır; tesadüfi bir farkı kazanan sanıp testi erken durdurma riski doğar.⁹ Ardışık yöntemde sonuçlar sürekli izlenebilir; Optimizely bu yöntemde yanlış keşif oranını denetleyerek sonuçların geçerliliğini koruduğunu belirtiyor.¹⁰

Sonucu tek bir yüzdeyle değil, güven aralığıyla okuyoruz. Firebase fark için %95 güven aralığı raporlar; aralık sıfırı içeriyorsa varyant ile temel sürüm arasında anlamlı bir fark saptanmamış demektir.⁷ Aynı belge, öndeki varyantı yayına almadan önce ikincil metriklere ve güven aralığının alt ucundaki olası kayba da bakılmasını öneriyor.⁷

Form ve ödeme adımları nasıl sadeleştirilir?

Form ve ödeme adımlarını sadeleştirmek, gereksiz alanı kaldırmak ve kalan her alanı etiketi, hata mesajı ve otomatik doldurmasıyla tek seferde doğru doldurulabilir kılmak demektir. Ölçütümüz W3C’nin Web İçeriği Erişilebilirlik Yönergeleri’dir (WCAG 2.2); ölçütler engelli kullanıcılar için yazılmıştır, ama karşıladıkları sorunlar her ziyaretçi için sürtünmedir. Kontrol ettiğimiz başarı ölçütleri:¹¹

1. Etiket ve talimat (3.3.2, A): giriş isteyen içerikte etiket ya da talimat bulunur; biz etiketi yer tutucu metne bırakmıyoruz.
2. Hatanın tanımlanması (3.3.1, A): otomatik saptanan bir giriş hatasında hatalı öğe belirtilir ve hata metinle açıklanır.
3. Düzeltme önerisi (3.3.3, AA): düzeltme biliniyorsa, güvenliği ya da içeriğin amacını bozmadıkça kullanıcıya önerilir.
4. Alan amacı (1.3.5, AA): kullanıcıya ait bilgi toplayan alanların amacı programatik olarak belirlenebilir; pratikte ad, e-posta, telefon ve adres alanlarında otomatik doldurmayı açan autocomplete niteliğini kullanıyoruz.
5. Tekrarlanan giriş (3.3.7, A): aynı süreçte daha önce girilen bilgi yeniden gerekiyorsa otomatik doldurulur ya da seçilebilir sunulur; fatura adresinin teslimat adresinden seçilebilmesi gibi.
6. Hedef boyutu (2.5.8, AA): işaretçiyle seçilen hedefler, tanımlı istisnalar dışında en az 24 × 24 CSS pikseldir.

3.3.7 ve 2.5.8, WCAG 2.2 ile eklenen ölçütler arasındadır.¹¹

Sayfa hızı ve test aracı dönüşümü nasıl etkiler?

Hem sayfa hızı hem de test aracının kendisi dönüşümü etkileyebilir; hızın etkisi kontrollü bir A/B testiyle ölçülebilir ve web.dev’de yayımlanan Vodafone vakası bunun belgelenmiş bir örneğidir.¹² Ücretli medya trafiğinin yarısı Web Vitals (Google’ın kullanıcı deneyimi ölçütleri) için optimize edilmiş sayfaya, yarısı temel sayfaya gönderildi; iki sürüm görsel ve işlevsel olarak aynıydı.¹² Optimize edilen sürümde bir bileşenin çizimi sunucuya taşındı, kritik HTML sunucuda üretildi, ana görsel yeniden boyutlandırıldı ve henüz görünmeyen görsellerin yüklenmesi önlendi.¹² LCP’deki (Largest Contentful Paint, en büyük içerikli öğenin çizilme süresi) %31’lik iyileşme, %8 daha fazla satış, potansiyel müşteri/ziyaret oranında %15 ve sepet/ziyaret oranında %11 iyileşme getirdi.¹²

Bu vakayı vaat olarak değil yöntem örneği olarak aktarıyoruz: hız iyileştirmesinin sizin sitenizdeki etkisi de kontrollü bir testle ölçülmelidir. Ayrıntılı hız çalışmasını web sitesi hızlandırma sayfamızda anlatıyoruz. Test aracının kendisi de hızı etkileyebilir; tarayıcı içi deneyler yükleme süresini uzatabilir ya da titremeye yol açabilir.⁸ Bu yüzden kazanan varyantı test aracında bırakmıyor, sitenin koduna işleyip test betiğini kaldırıyoruz.

İlk 30 gün ve doğru ortağı seçmek

İlk 30 günün işi test açmak değil; ölçümü doğrulamak, kaybın yerini ve nedenini bulmak ve ilk hipotez sırasını örneklem hesabıyla çıkarmaktır. Şu sırayla ilerliyoruz.

1. 1. hafta · Ölçüm denetimi: GA4 anahtar etkinlikleri, huni adımları, Clarity kurulumu ve maskeleme ayarı denetlenir; eksik ölçüm düzeltilir.
2. 2. hafta · Teşhis: huni kaybı cihaz ve kanal kırılımında okunur; kaybın yaşandığı adımın ısı haritaları ve oturum kayıtları incelenir.
3. 3. hafta · Hipotez ve hesap: bulgular hipoteze çevrilir, her biri için örneklem ve süre hesaplanır; açık hatalar doğrudan düzeltmeye ayrılır.
4. 4. hafta · İlk test ve plan: trafiğin yettiği ilk test yayına alınır; sonraki ayın test sırası ve raporlama düzeni birlikte belirlenir.

Bir CRO ortağıyla görüşürken şu soruların somut yanıtını almak işe yarar: dönüşümü hangi anahtar etkinlikle tanımlıyorsunuz, örneklemi ve süreyi testten önce nasıl hesaplıyorsunuz, kaybeden testleri nasıl raporluyorsunuz, oturum kayıtlarında kişisel veriyi nasıl maskeliyorsunuz, karanlık kalıp kullanıyor musunuz.

Sitenizin hangi adımda ziyaretçi kaybettiğini birlikte okumak isterseniz aşağıdan size uygun bir görüşme günü seçebilirsiniz; ilk görüşmede ölçüm durumunu, trafik hacmini ve öncelikleri birlikte netleştiriyoruz.