30 saniyelik özet

Funnel analysis, kullanıcıların belirli bir sonuca ulaşırken geçtiği adımları ve bu adımlar arasındaki kayıpları inceleyen dönüşüm hunisi analizidir. Kayıt olmak, ilk raporu oluşturmak veya teklif talebini tamamlamak için kullanılabilir. Analiz, akışın hangi bölümünün araştırılması gerektiğini gösterir; ayrılmanın nedenini tek başına açıklamaz. Product Owner, yani ürünün değerini artırmaktan sorumlu rol, adımları iş sorusuna göre tanımlar, ölçümün güvenilirliğini değerlendirir ve bulguları kullanıcı araştırmasıyla birleştirir. Amaç her adımı zorla tamamlatmak değil, kullanıcıyı anlamlı sonuca ulaştıran deneyimi iyileştirmektir.

Neden önemli?

Bir ürünün ziyaretçi sayısı artarken tamamlanan başvurular aynı düzeyde kalabilir. Yalnızca sonuca bakıldığında ekip reklam kalitesini, form uzunluğunu veya fiyatı tartışmaya başlayabilir. Oysa kayıp belirli bir cihazdaki hata mesajından, işlem süresinden veya kullanıcıya açıklanmayan bir koşuldan kaynaklanıyor olabilir.

Huni analizi, genel tartışmayı daha belirgin sorulara dönüştürür. Kullanıcılar süreci başlatıyor mu? Bilgilerini kaydedebiliyor mu? Son onaya ulaşanlar işlemi tamamlıyor mu? Bu sorular, farklı ekiplerin sorumluluklarını da görünür kılar. Pazarlamanın getirdiği talep, ürün deneyimi ve operasyonun karşılayabildiği sonuç birlikte değerlendirilir.

Yönetim açısından önemli ayrım, hacim ile verim arasındadır. Daha fazla kullanıcı getirmek, mevcut akıştaki engeli çözmeden maliyeti artırabilir. Buna karşılık küçük görünen bir iyileştirme, önemli bir müşteri grubunun işini tamamlamasını sağlayabilir. Öncelik kararı yalnızca kayıp oranına bakılarak verilmemelidir; etkilenen kullanıcı sayısı, ihtiyaçlarının önemi ve beklenen iş sonucu da değerlendirilmelidir.

Bir başka fayda, sorumluluğu doğru yere taşımaktır. Tamamlanmayan başvuru her zaman kötü ekran tasarımı anlamına gelmez. Kullanıcı gerekli bilgiyi başka bir kişiden bekliyor veya ürünün kendisine uygun olmadığını öğrenmiş olabilir. Analiz, sürecin ürün dışındaki adımlarını konuşmak için de başlangıç oluşturur. Bu ayrım yapılmadan tasarım ekibine verilen iyileştirme işi, gerçek engeli ortadan kaldırmayabilir.

Terim nedir?

Huni, analiz için seçilen olayların dizisidir. Olay, kullanıcının bir eylemini veya sistemdeki durum değişikliğini temsil eden ölçüm kaydıdır. Başlangıç olayı sürece girişi, son olay ise tanımlanan dönüşümü gösterir. Conversion, yani dönüşüm, analizde belirlenen tamamlanma koşulunun karşılanmasıdır.

Adımların sırası açık olmalıdır. Bazı analizlerde kullanıcıların seçilen adımları belirli sırayla tamamlaması gerekir; başka durumlarda araya farklı eylemler girebilir. Analize hangi kullanıcı grubunun dahil edildiği de sonucu değiştirir. Amplitude’ın dokümantasyonu, başlangıç olayı, sonraki olaylar, sıralama ve kullanıcı grubu gibi ayarların tanımlanmasını anlatır.

Toplam dönüşüm oranı, tanımlanan süre ve sıra koşullarını karşılayarak son adıma ulaşan birimlerin başlangıçtaki uygun birimlere oranıdır. Adım dönüşüm oranı ise bir aşamadan sonraki aşamaya geçişi inceler. Paydanın kullanıcı, müşteri hesabı veya işlem olması aynı soruya cevap vermez; analiz birimi baştan belirtilmelidir.

Kavramsal kaynak: Amplitude Docs, Build a funnel analysis.

Gerçek vaka: Gett’in kullanıcı bilgisi toplama akışını yeniden tasarlaması

Mixpanel’ın Gett müşteri hikâyesi, uygulamanın ilk kullanım akışındaki ad ve e-posta adımını ele alır. Kullanıcılar bu adımı atlayıp araç talep edebiliyordu. Ekip, kullanıcıların ilk alanı doldurmaya başlayıp ardından bölümü geçtiğini gözlemledi.

Daha fazla bilgi toplamak isteyen ekip, alanları zorunlu hale getirmeyi test etti. Bu değişiklik, süreci tamamlayıp araç talep edebilen kullanıcıları azalttı. Ekip daha sonra ad ve e-posta alanlarını ayrı ekranlara taşıyan yaklaşımı denedi. A/B testi, farklı deneyimlerin etkisini karşılaştırmak için kullanılan deney yöntemidir; vakada bu karşılaştırma yeni akışı değerlendirmek için kullanıldı.

Kaynağın aktardığı sonuca göre, huniden geçerek adını ve e-postasını veren kullanıcıların oranı iki katından fazla arttı; huni dönüşümü azalmadı. Bu ifade, dönüşüm oranına yüz puan eklendiği anlamına gelmez. Sonuç sağlayıcının yayımladığı müşteri anlatısına dayanır.

Bu vakadan çıkarılabilecek ders, ara hedefi iyileştirirken asıl kullanıcı sonucunu korumaktır. Daha fazla profil bilgisi toplamak, kullanıcıların araç talep etmesini zorlaştırıyorsa ürün açısından bir bedel doğurur. Huni bu bedeli görünür kılar; alternatif çözüm ise deneyle değerlendirilir.

Kaynak: Mixpanel, How Gett used targeted experiments on Mixpanel to double its onboarding rates.

Varsayımsal örnek: Teknik servis talebinin tamamlanması

İşletmelerin ekipmanları için teknik servis talebi oluşturduğu bir platformda ürün ekibi, başlatılan taleplerin neden tamamlanmadığını araştırır. Huni; talebin başlatılması, ekipmanın seçilmesi, arıza bilgilerinin kaydedilmesi ve talebin başarıyla gönderilmesi adımlarından oluşur. Gönder düğmesine basılması ile talebin sistem tarafından kabul edilmesi ayrı tutulur.

Ekip, aynı talebin tekrar düzenlenmesini yeni bir kullanıcı kaybı gibi saymamak için talep kimliği üzerinden ilerler. İnceleme süresi, işletmenin bilgi toplama ve şirket içi onay alma biçimi dikkate alınarak belirlenir. Süre içinde tamamlanmayan talep analizde kayıp sayılabilir; bu tanım kullanıcının kesin olarak vazgeçtiğini göstermez.

Toplam hunide arıza bilgileri aşaması dikkat çeker. Cihaz türüne göre ayrıştırıldığında mobil kullanıcıların bu adımda daha fazla zorlandığı görülür. Ekip önce olayların mobil uygulamada doğru kaydedildiğini doğrular. Ardından kullanıcı görüşmeleri ve hata kayıtlarıyla fotoğraf yükleme sürecini inceler.

İlk hipotez, fotoğraf yüklenirken ilerleme durumunun anlaşılmamasının tekrar denemeye veya ayrılmaya yol açtığıdır. Ekip, yükleme durumunu açıklayan ve başarısız yüklemeyi tekrar başlatmayı kolaylaştıran bir çözümü sınar. Başarı yalnızca arıza ekranından çıkışla ölçülmez; geçerli servis taleplerinin gönderilmesi ve destek ekibinin yeterli bilgiye ulaşması da izlenir.

Daha fazla talep gönderilirken eksik bilgi nedeniyle servis planlaması zorlaşıyorsa iyileştirme tamamlanmış kabul edilmez. Ekip, kullanıcı açısından kolaylık ile operasyon açısından kullanılabilirliği birlikte değerlendirir. Geliştirme kararı bu sonuçlara göre güncellenir; ilk grafikte görülen kayıp, tek başına çözümün gerekçesi olarak bırakılmaz.

Yaygın üç hata

  1. En büyük kaybı doğrudan en önemli problem saymak

Bazı adımlarda ayrılma beklenen ve sağlıklı bir sonuç olabilir. Ürünün uygun olmadığını öğrenen kullanıcının devam etmemesi buna örnektir. Kaybın büyüklüğüyle birlikte hangi kullanıcıların etkilendiği ve o aşamada neyi başarmak istedikleri araştırılmalıdır. Her kaybı ortadan kaldırmak doğru hedef değildir.

  1. Farklı grupları tek ortalamada toplamak

Yeni ve mevcut müşteriler aynı akışı farklı amaçlarla kullanabilir. Cihaz, edinim kanalı veya ürün sürümü de sonucu etkileyebilir. Segment, ortak bir özelliğe göre ayrılan kullanıcı grubudur. Anlamlı segmentler incelenirken grup büyüklüğü de dikkate alınmalıdır; az sayıdaki gözlemi bütün kullanıcıların davranışı gibi yorumlamak yanıltıcı olur.

  1. Kayıp görülen adımdan neden çıkarmak

Bir aşamada ayrılma görülmesi, ekranın kötü tasarlandığını kanıtlamaz. Teknik hata, fiyat koşulu, eksik bilgi veya ölçüm sorunu etkili olabilir. Önce veri güvenilirliği değerlendirilir, ardından alternatif açıklamalar araştırılır. Yapılan değişikliğin etkisini görmek için mümkün olduğunda uygun bir karşılaştırma tasarlanır.

Mini uygulama / şablon

Cevaplanacak iş sorusu
—
Hedeflenen kullanıcı sonucu
—
Analiz birimi
Kullanıcı, hesap veya işlem:
Başlangıç ve tamamlanma olayları
—
Ara adımlar ve sıralama kuralı
—
Tamamlanma için tanınan süre
—
Kapsama alınacak ve dışarıda tutulacak gruplar
—
İncelenecek segmentler
—
Tekrarların ve yeniden denemelerin ele alınışı
—
Ölçüm güvenilirliğiyle ilgili bilinen sorunlar
—
Dikkat çeken kayıp veya gecikme
—
Alternatif açıklamalar
—
Sınanacak hipotez ve araştırma yöntemi
—
İyileşmesi beklenen sonuç
—
Bozulmaması gereken kalite göstergeleri
—
Karar ve sonraki değerlendirme
—

Şablonu mevcut bir akış için doldurun. Önce olay kayıtlarının gerçek tamamlanmayı temsil ettiğini değerlendirin. Sonra kaybın yanında adımlar arasındaki süreyi ve farklı kullanıcı gruplarını inceleyin. Bir araştırma sorusu seçip kullanıcı anlatılarıyla nedenleri daraltın. Değişiklikten sonra aynı tanımlarla karşılaştırma yapın; analiz süresi dolmamış kullanıcıları erken başarısız saymayın. Sonuçları paylaşırken hem oranları hem kapsanan birim sayılarını belirtin. Böylece grafik, geliştirme talebinin yerine geçen bir hüküm olmaktan çıkar ve araştırılabilir bir ürün kararını destekler.

İlgili terimler

Conversion Rate, Product Analytics, Tracking Plan, Event Taxonomy, Segmentation, Cohort Analysis, A/B Testing, Activation, Customer Journey, Guardrail Metrics