CRO denetimi nasıl yapılır: önce ölçüm, sonra kaybın yeri ve nedeni

CRO denetimi (CRO audit), bir sitenin ziyaretçiyi nerede ve neden kaybettiğini sabit bir sırayla inceler: önce ölçümün doğru olduğunu kanıtlarsın, sonra kaybın yerini adım verisinde bulur, nedenini sayfa incelemesi ve kullanıcı araştırmasıyla ararsın. Denetimin çıktısı, her biri kanıtına bağlı test hipotezlerinden ve düzeltmelerden oluşan sıralı bir listedir.

Sıra önemli, çünkü her adım bir öncekinin rakamını kullanır. Satın alma etiketi bir ödeme yolunda çalışmıyorsa huni o adımda olduğundan büyük bir kayıp gösterir, o kayba göre kurulan A/B testi de aynı bozuk etiketle ölçülür. Türkçe kaynaklarda bu iş CRO analizi diye de geçiyor.

CRO'nun tanımı, süreci ve araçları CRO rehberinde duruyor. Örnekler bir e-ticaret sitesinden, lead sitelerinde satın alma yerine form gönderimini müşteri ilişkileri yönetimi (CRM) sistemindeki kayıtla karşılaştırırsın.

CRO denetiminin beş adımı, bir önceki adımın çıktısını girdi olarak kullanır. Her adımın ayrı bir sorusu ve o soruyu cevaplayan ayrı bir kanıtı var:

1. Ölçüm: Rakamlar gerçek mi? Kanıt, sipariş kaydı ile GA4 arasındaki eşleşme ve bir test satın alması. Çıktı, düzeltilecek ölçüm hataları.
2. Adım verisi: Kayıp nerede? Kanıt, huni ve yol keşfi ile cihaz ve kaynak dökümü. Çıktı, incelenecek adım ve segment listesi.
3. Sayfa incelemesi: Sayfada ne engel olabilir? Kanıt, birden fazla kişinin bağımsız sezgisel değerlendirmesi. Çıktı, ciddiyet puanı verilmiş aday sorunlar.
4. Nitel araştırma: Kullanıcı neden duruyor? Kanıt, oturum kayıtları, kullanılabilirlik testi ve anket. Çıktı, gözleme dayanan neden adayları.
5. Hipotez ve öncelik: Önce ne yapılacak? Kanıt, önceki dört adımın toplamı. Çıktı, düzeltme, test ve ek araştırma listesi.

İlk iki adımın kanıtı davranışı sayar ama nedenini göstermez. Üçüncü ve dördüncü adım neden önerir ama ne kadar yaygın olduğunu söylemez. Bu yüzden bir bulguyu hipoteze çevirmeden önce iki türden de kanıt aramak işe yarar.

Ölçüm kontrolü, GA4'ün saydığı satın almaların sipariş sistemindeki siparişlerle örtüşüp örtüşmediğini sınar. Karşılaştırmayı doğru metrikle yap. Kasım 2026 itibarıyla Google'ın e-ticaret metrikleri sayfasına göre "E-ticaret satın alma işlemleri" yalnızca purchase etkinliğini sayar. "İşlem sayısı" ise iade (refund) gibi değer taşıyan başka etkinlikleri de içerir, siparişle karşılaştırılacak olan ilkidir.

En açık sonucu sipariş numaraları verir. Google, işlem kimliği için sipariş onay numarasını örnek veriyor ve aynı kimliği taşıyan iki satın almayı tek sayıyor. Sipariş numaralarını sipariş sisteminden, aynı dönemin işlem kimliklerini GA4'teki İşlem kimliği boyutundan al ve eşleştir.

Eşleşmeyen siparişleri cihaza ve ödeme yöntemine göre grupla. Kayıp tek bir yolda toplanıyorsa aday neden o yoldadır.

Aynı Google sayfası iki ters hatayı da anlatıyor. Etiket farklı siparişlere aynı kimliği gönderirse satın almalar olduğundan az sayılır. Kimliği boş gönderilen bütün satın almalar da birbirinin tekrarı sayılıp tekilleştirilir.

Önemli etkinlik listesini de bu adımda gözden geçir. Google önemli etkinliği işletmenin başarısı için özellikle önemli bir işlemi ölçen etkinlik olarak tanımlıyor. Sepete ekleme de önemli etkinlik olarak işaretliyse raporlardaki önemli etkinlik sayıları satın almayla birlikte o adımı da içerir.

Test satın alması ve DebugView

Bir test satın alması, eşleştirmenin gösterdiği adayı doğrular. Google'ın DebugView sayfasına göre kendi cihazın için hata ayıklama modunu Tag Assistant ya da önizleme moduyla açarsın. Testi kayıp görünen yolda yap: aynı cihaz türü, aynı ödeme yöntemi. Çerez bannerında Analytics çerezlerine izin ver, çünkü izin modu kullanılan bir sitede izin vermeyen kullanıcının etkinlikleri DebugView'da görünmez.

DebugView'da önce purchase etkinliğinin gelip gelmediğine, sonra parametrelerine bak. Google'ın eksik gelir verisi sayfası purchase etkinliğinde currency, transaction_id, value ve items parametrelerini zorunlu sayıyor ve value değerinde para simgesi olmamasını istiyor. Etkinlik hiç gelmiyorsa kullanıcının etiketin çalıştığı onay sayfasına ulaşıp ulaşmadığını kontrol et.

Ödeme sayfası, alan adları ve iç trafik

Ödeme başka bir alan adında tamamlanıyorsa iki ayarı kontrol etmen gerekir. Google'ın web alanları arası ölçüm sayfasına göre bu ölçüm yokken kullanıcının ziyaret ettiği her alan adı için yeni kimlikli çerezler oluşur ve aynı kişi iki kullanıcı gibi sayılabilir. Kurulumu, hedef alan adının adresinde _gl parametresinin göründüğünü kontrol ederek doğrularsın.

Kullanıcı üçüncü taraf bir ödeme sayfasından siteye dönüyorsa o alan adı trafik kaynağı olarak görünebilir. Google bu durumu istenmeyen yönlendirmeler sayfasında ilk örnek olarak veriyor. Bu hata satın almayı kaybettirmez, ama satın almanın geçtiği oturumu ödeme sağlayıcısından gelmiş gibi gösterebilir ve kanal dökümünü bozar.

Ekibin ve ajansın test trafiği de rakamlara karışır. Dahili trafik filtresi etkin hale geldiğinde etkisi kalıcı oluyor ve hariç tutulan veri bir daha işlenmiyor. Filtreyi önce Test durumunda çalıştır ve hangi etkinlikleri yakaladığına bak.

İzin modu, eşikler ve örnekleme

GA4'ün göremediği kullanıcılar, sipariş kaydıyla aradaki farkın bir kısmını açıklar. Google'ın izin modu için davranış modelleme sayfası, çerez bannerı kullanan bir sitede izin vermeyen kullanıcıların verisinin eksik kalacağını yazıyor. Modelleme bu boşluğu yalnızca mülk uygunluk şartlarını karşıladığında tahminle dolduruyor. Bu yüzden eşleşmenin tam çıkmasını bekleme, aradığın şey bütün yollarda benzer olan kayıptan sapan yoldur.

Küçük segmentlere inerken iki sınır daha var. Google'a göre veri eşikleri demografik veri içeren rapor ve keşiflerde uygulanabiliyor, sistem tarafından belirleniyor ve değiştirilemiyor. Kullanıcı ya da etkinlik sayısı düşük dar bir tarih aralığında da veri gizlenebiliyor.

Veri örnekleme ise bir keşifte kullanılan etkinlik sayısı mülkün kotasını aştığında devreye girebiliyor. Raporda ikisinden biri görünüyorsa segment rakamını kesin sayı gibi okuma.

Ölçüm hatası bulduysan denetimin geri kalanına geçmeden düzelt ya da hangi raporları etkilediğini yaz. GA4 ile Google Ads arasındaki dönüşüm farkı ayrı bir konu ve GA4 ile Google Ads rakamlarının farkını inceleyen yazıda anlatılıyor.

Adım verisi, ölçüme güvendikten sonra kaybın hangi adımda ve hangi kullanıcı grubunda toplandığını gösterir. GA4'te bunun aracı dönüşüm hunisi keşfi. Kapalı hunide kullanıcılar ilk adımdan girmek zorunda, açık hunide herhangi bir adımdan girebiliyor. Huni kullanıcıları sayar ve bir kullanıcı seçilen tarih aralığında huniye yalnızca bir kez girer, yani bu sayılar oturum ya da sipariş değildir.

Cihaz dökümünde bir ayrıntı yorumu değiştirir. Google'a göre döküm boyutu eklendiğinde kullanıcı, kendisi için geçerli değerin ilk örneğine yazılır. Mobilde ödemeye başlayıp masaüstünde bitiren kullanıcı bütün adımlarda mobil altında görünür. Cihaz değiştiren kullanıcı payı yüksek bir sitede mobil ile masaüstü farkını yorumlarken bunu hesaba kat.

Aynı huniyi trafik kaynağına, yeni ve geri dönen kullanıcıya ve giriş sayfası türüne göre de böl. Kayıpları oranla değil, kaybedilen kullanıcı sayısıyla sırala. Küçük bir segmentteki yüksek kayıp oranı, büyük bir segmentteki orta orandan daha az kullanıcıyı etkileyebilir. Her adımdaki geçişi ve kaybı huni analizi hesaplayıcısıyla hesaplayabilirsin.

Huninin göstermediği döngüleri dönüşüm yolu keşfi bulur. Google bu tekniğin kullanım örnekleri arasında, kullanıcıların takıldığını gösterebilecek döngüleri bulmayı sayıyor. Sepet ile ürün sayfası arasında gidip gelen kullanıcılar böyle bir döngü olabilir. Bu adımın çıktısı bir yer listesi: hangi adım, hangi segment, kaç kullanıcı.

Sezgisel değerlendirme (heuristic evaluation), adım verisinin işaret ettiği sayfaları kullanılabilirlik ilkelerine göre inceler. Nielsen Norman Group'un sezgisel değerlendirme rehberi bu işi tek kişiye bırakmamayı öneriyor: ideal olarak üç ila beş kişi aynı arayüzü bağımsız değerlendirmeli. Değerlendiriciler kendi incelemelerini bitirmeden birbirlerinin notlarını görmemeli.

Kapsamı adım verisi belirler. NN/g kapsamı tek görev, tek bölüm, tek kullanıcı grubu ya da tek cihaz türüyle daraltmayı öneriyor. Adım verisi mobil ödeme adımını gösteriyorsa inceleme o görevle sınırlı kalır. Ürünü tanımayan değerlendirici görevi önce yalnız sistemi öğrenmek için yapar, ikinci geçişte ilkelere aykırı noktaları not eder.

Bir ilkeye aykırılık kendiliğinden düzeltilecek bir sorun değildir. NN/g, bir tasarım kararının bir ilkeyi ihlal etmesinin her zaman düzeltilmesi gereken bir sorun anlamına gelmediğini yazıyor. Aynı rehbere göre sezgisel değerlendirme kullanıcı araştırmasının yerini tutmaz, bu yüzden bu adımın her notu aday sorun olarak kalır.

Notları birleştirdikten sonra her sorunu puanla. Jakob Nielsen'in 1994 tarihli ciddiyet puanı yazısı ciddiyeti üç etkene bağlıyor: sorunun ne sıklıkta yaşandığı, yaşandığında aşılmasının ne kadar zor olduğu ve kullanıcıyı tekrar tekrar etkileyip etkilemediği. Puan 0 ile 4 arasında.

Nielsen tek değerlendiricinin puanına güvenmiyor ve üç değerlendiricinin ortalamasını pek çok pratik iş için yeterli buluyor. Puanları inceleme bittikten sonra, bulunan bütün sorunların listesi her değerlendiricinin önündeyken topla.

E-ticaret sitelerinde genel ilkelerin yanına alana özgü yönergeler eklenebilir. Baymard Institute'un dönüşüm denetimi yazısı incelemenin masaüstü ve mobil sürümleri birlikte kapsamasını ve siteyi belirli kullanılabilirlik ve dönüşüm yönergelerine göre değerlendirmeyi öneriyor. Sayfa hızı da bu incelemeye girer ama kendi ölçümü olan bir konu, açılış sayfası hızı yazısında ayrıca anlatılıyor.

Nitel araştırma, sayfa incelemesinin önerdiği adayları gerçek kullanıcı davranışıyla sınar. NN/g araştırma yöntemlerini insanların ne söylediği ile ne yaptığı arasındaki ayrıma göre sınıflıyor ve ikisinin çoğu zaman oldukça farklı olduğunu belirtiyor. Anket söyleneni, oturum kaydı ve kullanılabilirlik testi yapılanı gösterir. Bir anket cevabını, kayıtlarda karşılığı olan bir davranış bulana kadar yarım kanıt say.

Oturum kayıtlarını rastgele izlemek yerine adım verisinin gösterdiği segmenti filtrele. Microsoft Clarity'nin semantik metrikler sayfası ölü tıklamayı (dead click), kullanıcı bir öğeye tıklayıp makul sürede geri bildirim alamadığında işaretliyor. Öfke tıklaması (rage click) ise aynı küçük alana art arda hızlı tıklandığında işaretleniyor.

Clarity'ye göre ölü tıklama bozuk bir öğeye, yavaş yanıt veren bir isteğe ya da yanıltıcı bir tasarıma işaret edebiliyor. Aynı sayfa tıklamadan sonra oluşan JavaScript hatalarını da ayrıca etiketliyor. Böyle bir hata her seferinde tekrarlanabiliyorsa test değil düzeltme konusudur.

Kayıt aracını açmadan önce maskeleme ayarına bak. Clarity'nin maskeleme sayfasına göre giriş kutularının içeriği her modda maskeleniyor ve Kasım 2026 itibarıyla varsayılan mod Balanced. Kayıtlarda görünmemesi gereken başka bir bilgi varsa o öğeleri ayrıca maskele.

Kullanılabilirlik testi, kayıtta görülen davranışın nedenini sorma fırsatı verir. NN/g'nin kullanılabilirlik testi rehberine göre katılımcılardan çoğu zaman görevi yaparken düşündüklerini yüksek sesle söylemeleri istenir. Görevi adım verisindeki yerden seç, "telefonundan bir ürün seçip ödemeyi tamamla" gibi.

NN/g nitel ve nicel testi karşılaştırırken nitel verinin kullanılabilirliği doğrudan, nicel verinin dolaylı değerlendirdiğini yazıyor. Pratikte bu, birkaç kayıtta ya da test oturumunda görülen bir takılmanın ne kadar yaygın olduğunu adım verisine dönerek ölçmen gerektiği anlamına gelir.

Hipotez, denetimin bulgusunu test edilebilir bir cümleye çevirir ve kanıtını yanında taşır. Dört parçası var: adım verisinde ve nitel araştırmada görülen şey, yapılacak tek değişiklik, beklenen etki ve kararı verecek metrik. "Mobilde ödemeye başlayanların bir kısmı üyelik ekranında duruyor ve kayıtlarda bu ekrandan geri dönüşler var" gözlemi, "üyeliksiz ödeme seçeneği ödemeye başlayan mobil kullanıcıların sipariş tamamlamasını artırabilir" hipotezine dönüşür.

A/B test kütüphanesindeki üyeliksiz ödeme senaryosu bu tür bir hipotezin hangi kanıtla değerlendirmeye alınacağını, sabit tutulacak öğeleri ve birlikte izlenecek metrikleri sıralıyor. Kendi bulgunu senaryonun "Ne zaman değerlendirilmeli?" başlığındaki koşullarla karşılaştır.

Testi, değişikliğin etkisini ölçebilecek biçimde kur. Kullanıcıları uygun hale geldikleri anda, burada ödeme adımına geldiklerinde rastgele ata ve sonuçları atandıkları gruba göre karşılaştır. İki grubu aynı süre boyunca izle. Kontrol grubu mevcut ödeme akışını görmeye devam eder.

Test başlamadan neyin kazanç sayılacağını yaz. İptal ve iade oranı gibi bir koruma metriği de seç ve testi hangi sınırda durduracağını önceden belirle.

Gereken kullanıcı sayısını örneklem büyüklüğü hesaplayıcısı verir. Bulgu yalnızca mobildeyse testin yalnız mobilde çalışacağına test başlamadan karar ver. Sonuçları sonradan segmentlere bölmenin riskini A/B testlerinde segmentasyon yazısı anlatıyor. Belirsiz kalan bir sonucu da "etkisi yok" diye değil, belirsiz diye kaydet.

Önceliklendirme, hangi bulgunun düzeltileceğine, hangisinin test edileceğine ve hangisinin ek araştırma gerektirdiğine karar verir. Ölçüm hataları sıranın başında yer alır, çünkü düzeltilene kadar diğer bulguların rakamı güvenilmez. Bulgu türü kararın büyük kısmını belirler:

Tablodaki ilk iki satır test gerektirmez, çünkü ne olduğu ve nasıl düzeltileceği bellidir. Düzeltmeden sonra ilgili adımın verisini önceki dönemle karşılaştırırken mevsim ve kampanya gibi başka değişiklikleri de not et. Üçüncü satır testin konusu, dördüncü satır ise henüz hipotez değil.

Kalan bulguları aynı ölçütlerle karşılaştır: bulgunun olduğu adıma ulaşan kullanıcı sayısı, kanıtın türü ve iş yükü. Her bulgu için üç rakamı ayrı yaz: etkilediği kullanıcı ya da sipariş sayısı, bugünkü rakamlarla görünen fark ve düzeltmenin getireceği kazanç. Kazanç test edilmeden bilinmez, bir bulgunun iyimser tahminini ötekinin kötümser tahminiyle de karşılaştırma. Bu sıralamayı tek bir puana indiren önceliklendirme çerçeveleri CRO rehberinde karşılaştırılıyor.

Varsayımsal bir mağaza dört haftalık veriyle denetime başlıyor. GA4'ün kapalı hunisinde mobilde ödemeye başlayan kullanıcıların %38,5'i, masaüstünde %58,8'i satın almış görünüyor ve mobil ödeme adımı listenin başına yerleşiyor. Örnekte her kullanıcının dönemde en fazla bir sipariş verdiği ve siparişi ödemeye başladığı cihazda tamamladığı varsayılıyor.

Ölçüm adımındaki eşleştirme, kaybın bir ödeme yolunda toplandığını gösteriyor. Masaüstü siparişlerin ve mobilde sitede kartla ödenen siparişlerin %98'i GA4'te var, harici ödeme sayfasından geçen mobil siparişlerin ise yalnızca %21'i:

Rakamlar varsayımsal, eşleşme payı bir ondalığa yuvarlandı. Harici ödeme sayfasından geçen 400 siparişin 316'sı GA4'te yok. Aday neden, ödeme sonrasında onay sayfasına dönmeyen kullanıcılar ya da o sayfada tetiklenmeyen etiket. Bu bir çıkarım ve o yolda yapılacak bir test satın almasıyla doğrulanır.

Varsayımsal örnekte varsayım değişince

Harici yol düzeltildikten sonra GA4'ün o yolda kaç siparişi göreceği bilinmiyor, kararı da bu varsayım belirliyor. Diğer yollar gibi %98 eşleşirse GA4 mobilde 1.078 satın alan kullanıcı gösterir. Varsayım aşağı çekildikçe mobil ödeme farkı yeniden açılıyor:

Ödemeye başlayan kullanıcı sayısı her satırda aynı: mobilde 2.000, masaüstünde 1.500. Masaüstünde tamamlama payı %58,8.

Üç varsayımın hepsinde GA4'ün gösterdiği farkın yarıdan fazlası ölçümden geliyor ve geriye 4,9 ile 8,5 puan arasında bir fark kalıyor. Mobil ödeme hâlâ masaüstünün gerisinde, ama önceliği düzeltilmiş rakamla diğer bulgularla yeniden karşılaştırılmalı.

Varsayımsal örnekteki üç ayrı rakam

Etkilenen miktar, harici ödeme yolundaki 400 sipariş, yani bütün siparişlerin %20'si. Görünen fark ise GA4'te 20,3 puan ve düzeltmeden sonra varsayıma göre birkaç puana iniyor.

Düzeltmenin kazancı üçüncü rakam ve henüz bilinmiyor. Etiketi düzeltmek tek bir ek sipariş getirmez, raporu düzeltir. Kalan farkı kapatmanın kazancı ancak bir testle ölçülür.

Ölçüm adımı atlansaydı ilk akla gelen test, harici ödeme seçeneğini mobilde geri plana almak olabilirdi. Bu test bozuk etiketle ölçülürse yanıltıcı bir kazanan üretir. Harici yoldaki 400 alıcının hepsi kartla öderse GA4 onları kart yolunun eşleşme payıyla görür, 84 yerine 392 kişi.

Bu durumda tek bir ek sipariş olmadan GA4'te 308 satın alma artışı görünür. Testin "kazanan" etiketi, ölçüm hatasının yer değiştirmesinden başka bir şey göstermez.

Denetimin ilk günü, sipariş kaydı ile GA4 arasındaki eşleşmeyi çıkarmaya ayrılır. Bu kontrol diğer bütün adımların rakamını belirlediği için kısa bir liste yeterli:

1. Sipariş sisteminden son 28 günün sipariş numaralarını cihaz ve ödeme yöntemiyle birlikte dışa aktar.
2. GA4'ten aynı dönemin işlem kimliklerini al ve iki listeyi sipariş numarasıyla eşleştir.
3. Eşleşmeyen siparişleri ödeme yoluna göre grupla ve diğerlerinden sapan yolda bir test satın alması yap.
4. Sapma varsa önce etiketi düzelt, yoksa adım verisine geç.

Sapan bir yol bulduysan düzeltmeden sonraki dönemin eşleşmesini aynı yöntemle tekrar çıkar. Denetimin geri kalanını bu yeni rakamlarla yürüt.