Çoğu işletme sahibi dönüşüm oranını tek bir sayı sanır. "Bizde yüzde 1,8" der, sonra bu sayıyı yükseltmek için rastgele iyileştirmelere girişir: renk değiştirir, kampanya ekler, sayfa hızıyla oynar. Oysa dönüşüm oranı bir sayı değil, arka arkaya dizilmiş kapılar serisidir. Ziyaretçi her kapıda bir karar verir ve her kapının kendine ait bir kayıp oranı vardır. Tek ortalamaya bakmak, altı odalı bir evde sadece elektrik faturasının toplamına bakıp hangi odanın ışığının açık kaldığını aramaya benzer.
Dijital ürün satışında bu daha da kritik, çünkü huni kısa ama kırılgan. Ziyaretçi gelir, ürünü bulur, fiyatı görür, ödemeye geçer, doğrulama yapar, kodu teslim alır. Altı adım. Her adımda yüzde 20 kayıp verirsen sonuçta elinde başlangıçtaki trafiğin yüzde 26'sı kalır; ama kayıplar eşit dağılmaz. Genelde tek bir adım kaybın yarısını üretir ve onu bulduğun gün ciron zıplar. Bu yazıda hunini adım adım nasıl kuracağını, hangi olayları nasıl isimlendireceğini ve kullandığın e-pin scriptinden hangi veriyi çıkaracağını anlatıyorum.
Huni neden tek oran değil, altı ayrı kapı?
Hunini kurmanın ilk kuralı adımları gözlemlenebilir olaylar olarak tanımlamaktır. "İlgilendi", "karar aşamasında" gibi duygusal etiketler ölçülemez. Ölçülebilir olan şudur: oturum başladı, kategori görüntülendi, ürün görüntülendi, sepete eklendi veya doğrudan al tıklandı, ödeme yöntemi seçildi, ödeme başlatıldı, sipariş tamamlandı, teslim edildi. Bunların her biri sistemde bir kayıt bırakır.
İkinci kural: her adımın hem oran hem mutlak sayı olarak yazılması. Yüzde 12'lik bir düşüş, günde 40 kişi demekse önemlidir; günde 2 kişi demekse gürültüdür. Satıcıların en sık yaptığı hata, yüzdesi en kötü adımı öncelik sanmaktır. Öncelik, kayıp adet × müşteri değeri çarpımının en büyük olduğu adımdır. Bu çarpımı hesaplayabilmek için siparişlerin ortalama tutarını adım bazında ilişkilendirebilmen gerekir; bunu sağlamayan bir dijital ürün satış scripti seni ortalama körlüğüne mahkûm eder.
| Adım | Olay adı | Sağlıklı geçiş | Alarm eşiği |
|---|---|---|---|
| 1. Giriş | oturum_basladi | — | Hemen çıkma %70 üstü |
| 2. Ürün bulma | urun_goruntulendi | %55-70 | %45 altı |
| 3. Niyet | satin_al_tiklandi | %18-28 | %12 altı |
| 4. Ödeme seçimi | odeme_yontemi_secildi | %75-88 | %65 altı |
| 5. Ödeme | odeme_baslatildi | %70-85 | %60 altı |
| 6. Tamamlama | siparis_tamamlandi | %85-95 | %78 altı |
Olayları yanlış isimlendirmek hunini nasıl çöpe çevirir?
Ölçülemeyen olay, olmamış olaydır. Ama daha sinsi bir tuzak var: tutarsız isimlendirilmiş olay, olmamış olaydan daha zararlıdır, çünkü seni yanlış karara ikna eder. Aynı eylemin bir yerde "sepete_ekle", başka yerde "add_cart", mobil temada "cart_add" olarak yayınlandığı bir kurulumda huni raporu yüzde 40 daha düşük bir niyet oranı gösterir ve sen var olmayan bir sorunu kovalamaya başlarsın.
Bu yüzden kuruluma başlarken tek sayfalık bir olay sözlüğü yaz: olay adı, ne zaman tetiklenir, hangi parametreleri taşır. Parametreler en az şunları içersin: ürün kimliği, kategori, tutar, para birimi, ödeme yöntemi, kullanıcı türü (misafir mi bakiyeli mi). Sonra kurulumu bir kez doğrula: canlı sitede bir sipariş verip her adımın kayda düştüğünü gözle. Bu yarım günlük iş, sonraki altı ayın kararlarını kurtarır. İyi bir e-pin satış yazılımı bu olayları kutu dışı, tutarlı isimlerle yayınlar; senin işin sadece doğrulamak olmalıdır.
Bakiye hunisi ile ürün hunisini aynı grafikte ölçmek neden yanıltıyor?
Bakiye ile çalışan satış modellerinde iki ayrı huni vardır ve bunları birleştirmek raporunu anlamsızlaştırır. Birincisi bakiye yükleme hunisi: kullanıcı parayı sisteme koyar. İkincisi harcama hunisi: bakiyesiyle ürün alır. İkinci hunide dönüşüm oranı doğal olarak çok yüksektir, çünkü para zaten içeride ve ödeme sürtünmesi yok. Bu iki huniyi toplarsan, ortalaman şişer ve gerçek darboğaz olan bakiye yükleme adımındaki kaybı fark etmezsin.
Doğru kurgu: bakiye yükleme hunisini müşteri kazanma metriği, harcama hunisini elde tutma metriği olarak izle. Yeni ziyaretçi için hedef ilk yüklemenin tamamlanması; mevcut müşteri için hedef harcama sıklığı. Panel raporlarında bu ayrımı yapamıyorsan, büyüme mi yoksa sadakat mi sorunun olduğunu asla bilemezsin. Özellik listesini incelerken bakiye hareketlerinin ayrı raporlanıp raporlanmadığına özellikle bak.
Huni kaybının adımlara dağılımı (ortalama e-pin satış sitesi)
- Ürün bulma ve arama 40%
- Ödeme yöntemi ve güven 30%
- Kayıt ve doğrulama 20%
- Teslimat ve teknik hata 10%
Kohort olmadan huni neden dünü açıklar, bugünü açıklamaz?
Klasik huni raporu tarih aralığına bakar: "Bu hafta yüzde 2,1." Ama trafik bileşimi değiştiğinde bu sayı hiçbir şey anlatmaz. Reklamı artırdığın hafta yeni ziyaretçi oranı yükselir, dönüşüm düşer; reklamı kestiğin hafta geri dönen müşteri ağırlığı artar, dönüşüm yükselir. İkisinde de arayüzünde hiçbir şey değişmemiştir. Yani ortalaman, trafik karışımının gölgesidir.
Çözüm kohort: kullanıcıları ilk temas ettikleri haftaya ve kaynağa göre grupla, her grubun hunisini ayrı izle. Bu yaklaşımla "arama trafiğinden gelen kullanıcı ödeme adımında yüzde 12 daha az takılıyor" gibi kullanılabilir cümleler üretirsin. Kohort ayrıca reklamın gerçek etkisini gösterir: bir kampanya hemen satmıyor ama ikinci hafta bakiye yüklemesi getiriyorsa, o kampanyayı zarar diye kapatmak yerine bütçesini artırırsın. Kohort raporu olmayan bir epin yazılım kurulumunda bu farkı görmek imkânsızdır.
Ödeme adımındaki kaybın teknik mi psikolojik mi olduğunu anlamak için iki veriye bak: sağlayıcı hata kodları ve aynı kullanıcının tekrar deneme sayısı. Tekrar deneme yüksek ve hata kodu varsa sorun tekniktir; tek deneme sonrası sessiz çıkış varsa sorun güven ve fiyattır. Bu ayrımı yapmadan yapılan her iyileştirme kumar sayılır.
Terk noktasını teşhis etmek: hangi soruyu hangi sırayla sorarsın?
Darboğazı bulduktan sonra iş teşhise döner ve teşhisin sırası önemlidir. Önce teknik: sayfa yükleniyor mu, ödeme sağlayıcısı hata veriyor mu, mobilde bir alan taşıyor mu, doğrulama kodu geç mi geliyor. Bunlar ucuz ve kesin cevaplıdır. Sonra bilgi eksikliği: teslim süresi belirsiz mi, iade koşulu görünmüyor mu, hangi platform için geçerli olduğu anlaşılmıyor mu. Son olarak fiyat ve güven: rakip daha ucuz mu, site yeni mi, sosyal kanıt yok mu.
Bu sırayı ters çevirip işe fiyat indirerek başlamak, e-pin satıcılarının en pahalı hatasıdır; çünkü marj küçülür ama terk oranı aynı kalır. Gerçek sebep genelde daha sıkıcıdır: doğrulama SMS'i 90 saniyede geliyordur, ya da mobilde ödeme butonu klavye açılınca ekranın altında kalıyordur. Bunları ölçmek için siparişin her durum değişimini zaman damgasıyla saklayan bir altyapı gerekir. E-pin satış scripti seçerken sipariş durum geçmişinin tutulup tutulduğunu sorman şart.
| Kontrol | Neye bakarsın | Geçti ölçütü | Sıklık |
|---|---|---|---|
| Olay sözlüğü var mı | Tek sayfalık olay listesi | Tüm adımlar tanımlı | Kurulumda |
| Olaylar canlıda tetikleniyor mu | Gerçek test siparişi | 6/6 adım kayıtlı | Ayda bir |
| Bakiye ve ürün hunisi ayrı mı | Rapor ekranı | İki ayrı huni | Kurulumda |
| Kohort kırılımı mümkün mü | Kaynak ve hafta filtresi | Her ikisi çalışıyor | Kurulumda |
| Sipariş durum geçmişi | Zaman damgalı durum kaydı | Tüm geçişler saklı | Sürekli |
| Ödeme hata kodları | Sağlayıcı hata raporu | Kod bazında listelenebiliyor | Haftalık |
Huniyi dışarıdan tahmin etmek yerine yazılımın içinden ölçmek
Dış analitik araçları huninin ilk yarısını iyi ölçer, ikinci yarısını kötü. Çünkü ödeme, doğrulama, stok ve teslimat adımları tarayıcıda değil sunucuda yaşanır. Reklam engelleyiciler, çerez izinleri ve yönlendirmeli ödeme akışları yüzünden dış araçta gördüğün "tamamlanan sipariş" sayısı gerçeğin altında kalır; bazı kurulumlarda fark yüzde 20'yi aşar. Bu fark kapandığında bazı satıcılar kârlı sandığı kampanyanın zararlı, zararlı sandığının kârlı olduğunu görür.
Doğru yaklaşım, huninin sunucu tarafını satış yazılımının kendi kayıtlarından okumaktır. Pinova bu mantıkla kurulmuş bir yazılımdır: e-pin ve dijital ürün satan işletmenin siparişini, bakiye hareketini, stok durumunu ve teslimat sonucunu tek veri modelinde tutar; her adımı zaman damgasıyla saklar; huninin dış araçla göremediğin yarısını sana kayıp olmadan verir. Kullandığın dijital ürün satış yazılımı sana bu ikinci yarıyı vermiyorsa, hunini yarım ölçüyorsun ve yarım ölçüm yanlış karardan daha tehlikelidir, çünkü kendinden emin olmanı sağlar.
Hunini yarım değil tam ölç
Sipariş, bakiye, stok ve teslimat verisini tek modelde tutan bir altyapı ile hem tarayıcı hem sunucu tarafını gör. Pinova lisanslı sürümünü ve paket seçeneklerini incele.
Huni kaç adımdan oluşmalı?
Beş ile yedi arası ideal. Daha az adım darboğazı gizler, daha fazlası gürültü üretir ve her adımda örneklem küçüldüğü için istatistiksel güveni düşürür. E-pin satışında altı adım çoğu iş modeli için yeterlidir.
Dış analitik ile panel sayılarım neden farklı?
Çerez izinleri, reklam engelleyiciler ve yönlendirmeli ödeme dönüşleri tarayıcı tarafında kayıp yaratır. Sunucu tarafındaki sipariş kaydı kanonik doğrudur; dış aracı trafik kaynağı analizi için, paneli ciro gerçeği için kullan.
Ne kadar sürede bir huniye bakmalıyım?
Haftalık bakış eğilim için, aylık bakış karar için uygundur. Günlük bakmak neredeyse her zaman gürültüye tepki vermeye yol açar ve gereksiz değişiklik yapmana neden olur.
Trafiğim azsa huni ölçümü işe yarar mı?
Yarar, ama oranlar yerine mutlak sayılara ve kalitatif veriye ağırlık ver. Günde 30 siparişte yüzdeler oynar; buna karşın on müşteriyle konuşmak tek başına en büyük darboğazı bulmaya yeter.
Dönüşüm hunisini adım adım ölçmek, tahmin etmeyi bırakıp teşhis koymaya başlamaktır. Bir kez doğru kurduğunda her hafta hangi kapıyı yağlayacağını bilir, bütçeni kumar gibi değil cerrah gibi harcarsın. Altı adımın tamamını tek panelde gören bir kurulum nasıl görünüyor diye merak ediyorsan canlı demo üzerinden sipariş, bakiye ve teslimat raporlarını kendi elinle gez, kendi huni senaryonu test et.