Huni optimizasyonu: adım adım teşhis ve kontrollü test

Huni optimizasyonu, satın alma ya da kayıt gibi bir hedefe giden adımlarda kaç kişinin kaldığını ölçüp en fazla tamamlama getirecek değişikliği bulmak ve bunu kontrol grubuyla test etmektir. Teşhiste nereden başlayacağını en yüksek kayıp oranı belirlemez: o adımda kaybedilen kişi sayısı, sonraki adımların bu kişileri sona taşıma oranı ve değişikliğin gerçekçi büyüklüğü belirler.

Türkçe kaynaklarda aynı iş çoğunlukla dönüşüm hunisi optimizasyonu diye geçer. Adım oranlarının hesabı huni analizi hesaplayıcısında duruyor. Dönüşüm oranı optimizasyonunun (CRO) tanımı, süreci ve araçları da kendi rehberinde anlatılıyor.

Huninin her adımı analitik aracında tek bir olaya ve açık bir koşula karşılık gelmeli. "Ödeme sayfası" gibi bir sayfa adı yerine kullanıcının ne yaptığında o adımda sayılacağını yaz ve bu tanımı huniyi okuyan herkesle paylaş. Google Analytics 4 (GA4) için Google'ın 14 Ekim 2026'da güncellenen e-ticaret olayları belgesi örneğin ödeme sürecinin ilk adımını begin_checkout olayıyla ölçmeyi tarif ediyor. Dört adımlı bir e-ticaret hunisi bu belgedeki olaylarla şöyle tanımlanabilir:

1. Ürün sayfası: kullanıcı bir ürünün ayrıntı sayfasını görür (view_item).
2. Sepete ekleme: kullanıcı sepete ürün ekler (add_to_cart).
3. Ödemeyi başlatma: kullanıcı ödeme sürecinin ilk adımına geçer (begin_checkout).
4. Satın alma: sipariş tamamlanır (purchase).

Her adımın yanına sayım birimini, dönemi ve adımlar arasındaki süre sınırını da yaz. Google'ın yardım sayfasına göre GA4 dönüşüm hunisi keşfi, Kasım 2026 itibarıyla, bir kullanıcıyı seçilen tarih aralığında huniye yalnızca bir kez alır. Adımları birden fazla kez tamamlayan kullanıcı için de yalnızca ilk adım dizisini raporlar. Ay içinde üç kez ödemeyi başlatan biri bu hunide tek kullanıcıdır, ödeme denemelerini saymak için olay düzeyinde ayrı bir sayım gerekir.

Adımlar arasındaki ilişkiyi de GA4'te sen seçersin. Bir adım öncekini dolaylı izliyorsa araya başka işlemler girebilir, doğrudan izliyorsa önceki adımın hemen ardından gelmelidir. İçinde ayarı ise bir adımın öncekinden sonra belirli bir süre içinde gerçekleşmesini şart koşar. Süre sınırı koyduğunda o süreden sonra gelen satın almalar o adımda sayılmaz, bu yüzden testin takip süresini de aynı sınırla kur.

Olayların doğru tetiklendiğini huniyi okumadan önce doğrula. Google'ın e-ticaret belgesi olayları gerçek zamanlı görmek ve sorunları gidermek için hata ayıklama modunu açmayı öneriyor. Açık ve kapalı huni farkı, boş adımlar ve çift sayım gibi veri kontrolleri ise hesaplayıcı sayfasında ayrıca anlatılıyor.

Kayıp oranı bir adımın ne kadar sızdırdığını, kişi sayısı ise kaybın nerede yoğunlaştığını gösterir. İkisi de bir değişikliğin kaç satın alma getireceğini söylemez. Ürün sayfasından ayrılanların bir kısmı zaten satın almaya niyetli olmayabilir, ödemeyi başlatıp ayrılan biri ise kararın son aşamasına gelmiştir.

Bir adımdan fazladan geçirdiğin kullanıcı, satın almaya ancak sonraki adımların oranıyla ulaşır. Huninin üstünde kurtarılan kişi bu yüzden sonda daha az satın alma demektir, altta kurtarılan kişi daha fazla. Adayları karşılaştırırken her değişikliği bu iki bilgiyle birlikte düşün: adımdan fazladan geçecek kişi sayısı ve o kişilerin sona ulaşma oranı.

Karşılaştırmada üç miktarı ayrı tut: adımda kaybedilen kişi sayısı, mevcut rakamlarla görünen fark ve değişikliğin getireceği kazanç. İlk ikisini verinden okursun, üçüncüsü test edilene kadar bir varsayımdır. Bir adımın bütün kaybını geri almak gerçekçi olmadığı için kazancı, değişikliğin fazladan geçireceğini düşündüğün kişi sayısıyla tahmin et. Tahmini neye dayandırdığını da not et: bir segmentteki daha yüksek oran, kullanıcı araştırması ya da benzer bir test.

Varsayımsal bir mağazada 30 günde 40.000 kullanıcı bir ürün sayfası görüyor ve 1.800'ü satın alıyor. Kullanıcıların en büyük kısmı ilk adımda kayboluyor:

İlk adım 34.000 kullanıcıyla en büyük kaybı veriyor, ama o adımı geçen kullanıcının satın almaya ulaşma oranı da en düşük. Sepete ekleyenlerde bu oran %30, ödemeyi başlatanlarda %50.

Üç aday değişiklik

Mağazanın her adım için bir değişiklik fikri var. Her fikrin kendi adımını ne kadar iyileştireceği bir tahmin, aşağıdaki rakamlar ölçülmüş sonuç değil:

Bu varsayımlarla ödeme değişikliği 216 ek satın almayla önde, en büyük kaybın olduğu ürün sayfası ise 120 ile sonda. Ürün sayfasında fazladan geçen 400 kullanıcı, ödemede fazladan geçen 216 kullanıcıdan daha az satın alma getiriyor.

Sonuç hangi varsayıma bağlı

Ürün sayfası değişikliği bir yerine iki puan getirirse ek satın alma 240'a çıkar ve ödeme değişikliğini geçer. Sıralamayı belirleyen, her değişiklik için varsaydığın büyüklük.

Kurtarılan kullanıcılar sonraki adımlardan mevcut kullanıcıların yarısı oranında geçerse ürün sayfası 60, sepet 75 ek satın almaya iner. İki puanlık senaryo da bu durumda 120'de kalır. Ödeme değişikliği yerinde durur, çünkü ondan sonra başka adım yok. Huninin üstünde kazanılan kullanıcılar daha az niyetliyse sıralama ödemenin lehine açılır.

Huninin üstündeki bir iyileşmenin kendiliğinden katlanarak büyüdüğü de bu varsayımsal örnekte görülmez. Diğer adımların oranları sabit kaldığında her adımda %10'luk göreli bir iyileşme aynı 180 ek satın almayı getirir. Fark, oranın ne kadar değiştiğinden ve sonraki adımların bu değişimden etkilenip etkilenmediğinden gelir.

Adım oranı düşerken satın alma artabilir

Bir değişiklik bir adımın oranını düşürüp sonraki adımı yükseltebilir. Kargo ücretini ürün sayfasında göstermek bazı kullanıcıları sepete eklemeden vazgeçirebilir, ama ücreti ödemede ilk kez görüp ayrılanları azaltabilir. Örnekteki mağazada sepete ekleme oranı yarım puan düşüp ödeme tamamlama 5 puan artarsa satın alma 1.800'den 1.914'e çıkar.

Testin birincil metriği bu yüzden gruba atanan kullanıcılar içinde satın almadır. Adım oranı, neyin değiştiğini açıklayan ikincil metrik olarak kalır. Bu bölümdeki rakamlar varsayımsal: tekil kullanıcılar 30 günlük tek pencerede, kapalı huniyle sayıldı, kullanıcılar ve satın almalar tam sayıya yuvarlandı.

Segmentlere ayırmak, toplam oranın sakladığı farkı görünür kılar. Cihaz, yeni ya da geri gelen kullanıcı, trafik kanalı ve ödeme yöntemi sık kullanılan ayrımlardır. Her segmentte yine iki şeye bak: adım oranı ve o segmentte kaybedilen kişi sayısı. Oranı düşük ama küçük bir segment, oranı ortalama ama büyük bir segmentten daha az satın alma kaybettirebilir.

GA4 huni keşfinde döküm boyutu her adımı örneğin cihaz kategorisine göre böler, segment karşılaştırması ise en çok 4 segmente izin verir. Döküm kullanıldığında kullanıcı, kendisi için geçerli değerin ilk örneğine bağlanır.

Google'ın örneğinde mobilde huniye girip sonraki adımları masaüstünde tamamlayan kullanıcı bütün adımlarda yalnızca mobil altında görünür. Cihazlar arası geçişin yaygın olduğu bir mağazada mobil satırı, masaüstünde tamamlanan satın almaları da taşır. Bu yüzden cihaz dökümünü huniye girilen cihazın dökümü olarak oku.

Varsayımsal örnek: segment oranları aynı, toplam oran düşük

Varsayımsal mağazanın ödeme adımında satın alma oranı mobilde %45, masaüstünde %60. İkinci ay ödemeyi başlatan kullanıcı sayısı aynı kalıyor ama mobilin payı büyüyor:

Toplam oran 2,5 puan düştü ve satın alma 1.800'den 1.710'a indi, ama iki cihazın oranı da yerinde. Düşüşün nedeni ödeme sayfası değil, trafik karışımı. Bu ayrımı yapmadan ödeme sayfasında arıza arayan bir hipotez, var olmayan bir sorunu düzeltmeye çalışır.

Örnek gerçek bir adayı da gösteriyor. İlk ayda bile mobil, ödeme adımında 1.320 kullanıcı kaybediyor, masaüstü 480. Mobil ödeme hem daha düşük oranlı hem daha büyük, hipotezin adresi orası. Segment karışımının bir test sonucunu nasıl tersine çevirebileceği, yani Simpson paradoksu, A/B testlerinde segmentasyon yazısında ayrıca anlatılıyor.

İyi kurulmuş bir huni hipotezinin dört parçası var: hangi adımda ve hangi segmentte kaç kişinin kaybolduğu, kaybın olası nedeni, bu nedeni hedefleyen değişiklik ve değişikliğin satın almayı ne kadar artırmasını beklediğin.

Örnekteki mağazada şüphelenilen neden mobildeki zorunlu üyelik formu. Hipotez şöyle kurulabilir: kayıp bu formdan geliyorsa üyeliksiz ödeme, ödemeyi başlatanlar içinde satın alma oranını artırır. Beklenen artışı sayıyla yaz, çünkü testin süresini o belirler.

Olası nedeni testten önce verinle sına. GA4 huni keşfindeki sonraki işlem kartı, seçtiğin boyuta göre, bir adımı tamamlayan kullanıcıların ardından en sık ne yaptığını gösterir. Geçen süre ayarı da adımlar arasındaki ortalama süreyi verir. Google, sayfa ya da ekran boyutlarında "(sonraki işlem yok)" girişinin her zaman bir düşüş anlamına gelmediğini belirtiyor: kullanıcı, sayfa başlığı değişmeden bir sonraki adıma geçmiş olabilir.

Olay verisi kullanıcının neden durduğunu göstermez. Oturum kaydı, kullanıcı testi ve anket nedeni daraltır, bu yöntemlerin ne zaman işe yaradığı CRO rehberinde anlatılıyor.

Huniden çıkan kullanıcıya sonradan ulaşmak ise ayrı bir kaldıraç: ödemeyi başlatıp tamamlamayanlara giden hatırlatmaların kurgusu ödeme adımını tamamlama journey'sinde duruyor. Kayıp adımın kendisinden geliyorsa hatırlatma kullanıcıyı aynı engele geri getirir, bu yüzden önce adımı düzelt.

Önce ve sonra karşılaştırması, aradaki dönemde değişen sezonu, kampanyaları ve trafik karışımını da farkın içine katar. Etkiyi ayırmak için kullanıcıları değişikliğin yapıldığı adıma ilk geldiklerinde rastgele iki gruba ata. Kontrol grubu mevcut sürümü, deney grubu yeni sürümü görür. Grupların boyutu, atama birimi ve örneklem oranı uyuşmazlığı kontrol grubu rehberinde anlatılıyor.

Atamayı değişikliğin dokunduğu adıma bağla. Ödeme sayfasındaki bir değişiklikte grup, ödemeyi başlatan kullanıcılardan oluşur. Ürün sayfasındaki bir değişiklikte ürün sayfası gören herkes atanır, çünkü sepete eklemeden çıkanlar da değişikliği görmüştür. Sonuçları kullanıcının atandığı gruba göre, iki grupta aynı uzunlukta takip süresiyle karşılaştır.

Koruma metrikleri, birincil metrik olan satın almanın yanında değişikliğin başka bir yere zarar verip vermediğini izler. Üyeliksiz ödeme için bunlar iptal ve iade oranı, sipariş tutarı ya da ödeme hataları olabilir. A/B test kütüphanesindeki üyeliksiz ödeme test fikri bu metrikleri ve iki grupta sabit tutulacak öğeleri tek sayfada topluyor.

Karar kuralı, sonucu görmeden önce neyin kazanç sayılacağını, hangi koruma metriğinin değişikliği hangi sınırda durduracağını ve belirsiz bir sonucun nasıl kaydedileceğini sabitler. Kuralı sonradan yazmak, sonucu gördükten sonra en olumlu görünen metriği seçmeye kapı açar.

Varsayımsal örnek: testin süresi ve kuralı

Testin süresini beklenen etki ile değişikliğin yapıldığı adıma gelen trafik belirler. Varsayımsal mağazada ödeme değişikliği için grup başına yaklaşık 1.086 kullanıcı gerekiyor. Ayda 3.600 kullanıcı ödemeyi başlattığı için test yaklaşık 19 gün sürüyor.

Ürün sayfası değişikliğinin beklenen etkisi, ürün sayfası gören kullanıcılar içinde satın alma oranını %4,5'ten %4,8'e taşıyor. Bu küçük farkı aynı güçle görmek için test yaklaşık 116 gün sürer. Ödeme değişikliği bu varsayımlarla hem daha fazla ek satın alma vaat ediyor hem de daha kısa sürede ölçülüyor.

Süreler iki oranın karşılaştırması için standart örneklem hesabından, %80 güç ve %5 anlamlılık düzeyiyle geliyor. Her 30 günde ilgili adıma ilk tablodaki kadar yeni kullanıcının geldiği varsayıldı. Haftalık döngüleri kapsaması için süreyi tam haftaya tamamla, kendi rakamlarınla gereken kullanıcı sayısını örneklem büyüklüğü hesaplayıcısıyla bulabilirsin. Ödeme testi için önceden yazılmış bir kural şöyle olabilir:

• Birincil metrik: ödemeyi başlatıp gruba atanan kullanıcılar içinde, atamadan sonraki 7 gün içinde satın alanların payı.
• Kazanç: deney grubunun oranı kontrolden yüksek ve farkın %95 güven aralığı sıfırın üstünde.
• Koruma: iptal ve iade oranı, iki grupta 30 günlük takip dolduğunda kontrolden 1 puandan fazla yüksekse değişiklik yayına alınmaz.
• Süre: grup başına 1.086 kullanıcıya ve 3 tam haftaya ulaşılmadan sonuç okunmaz, sonuç görüldükten sonra da test uzatılmaz.
• Belirsiz sonuç: güven aralığı sıfırı kapsıyorsa sonuç "belirsiz" diye kaydedilir, "etkisi yok" diye değil.

Beklenen 6 puanlık artış testin süresini planlamak içindir, kazanç eşiği değildir. Test aracının bir varyantı "kazanan" diye işaretlemesi de karar yerine geçmez, kararı yukarıdaki kural verir.

İlk turu tek bir sayfada yapabilirsin. Dört ya da beş adımı olay adlarıyla yaz, son 30 günün tekil kullanıcı sayılarını gir ve her adımın kaybını kişi olarak not et. Sonra her adım için bir değişiklik fikri, bu fikrin fazladan geçireceğini düşündüğün kullanıcı sayısı ve bu tahminin dayanağını yan yana yaz.

Bu kullanıcıları sonraki adımların oranıyla satın almaya taşıdığında adaylar aynı ölçüyle karşılaştırılır. En fazla ek satın alma getiren ve trafiğinin makul bir sürede ölçebildiği adayı seç, karar kuralını yaz ve testi ancak ondan sonra başlat.