Banka Örneğinde Kullanıcı Terkini Nasıl Analiz Edersiniz?

Banka Örneğinde Kullanıcı Terkini Nasıl Analiz Edersiniz?

Bir kredi başvuru ekranı düşünün. Müşteri formu açıyor, birkaç adım ilerliyor ve sonra ortadan kayboluyor. Çağrı merkezi bir şey duymadı, satış ekibine bir yansıma gelmedi, ama bir yerde bir şey oluyor ve insanlar süreci tamamlamadan gidiyor. Ürün ekibi olarak masanın başına oturduğunuzda ilk refleksiniz "acaba neyi yanlış yaptık?" olur; ama bu sorunun cevabı sezgiyle değil, izlerin takip edilmesiyle bulunur.

Kısaca söylemek gerekirse: Kullanıcı terkini analiz etmek, önce logları ve metrikleri monitör etmek, ardından bu verileri kullanıcıdan gelen niteliksel geri bildirimle birleştirmek ve son olarak tüm paydaşların aynı oranları aynı şekilde takip etmesini sağlamaktan geçer. Yani işin bir veri, bir de hizalama tarafı var.

Önce Loglara Bakmak, Sonra Yorumlamak

Ürünün sahibi sizseniz, müşterinin sesini en doğrudan duyan kişi siz değilsiniz. Çağrı merkezi müşteriyi anlık dinliyor, satış ekibi sahadan geri dönüş (feedback) topluyor. Ama Product ekibi olarak sizin işiniz, bu duyumların arkasındaki örüntüyü (pattern) görmek.

Bu yüzden ilk adım her zaman loglara gitmek olmalı. Çünkü müşteri bazen gerçekten teknik bir hatayla karşılaşıyordur; bazen form çok uzundur; bazen de hiçbir problem yaşamadığı halde çekip gidiyordur. Bu üçünü ayırt etmenin tek yolu, hangi adımda, kaç kişinin, nasıl davrandığını görmektir.

Logları monitör ederken yapmanız gereken ikinci şey, datayı karşılaştırmaktır. Geçen haftaya göre, geçen aya göre, farklı kullanıcı segmentlerine göre. Tek başına "yüzde 30 terk var" cümlesi bir şey söylemez; ama "belge yükleme adımında terk yüzde 15'ten yüzde 30'a çıktı" cümlesi size bir yol haritası verir.

Verinin Anlattığını Kullanıcıya Sormak

Loglar size "nerede" sorusunun cevabını verir, ama "neden" sorusunun cevabını her zaman vermez. Burada devreye niteliksel araçlar girer.

İlk akla gelen ısı haritalarıdır (heatmap). Kullanıcıların ekranın hangi bölgesinde takıldığını, hangi alanı atlamaya çalıştığını, hangi butonu fark etmediğini görmek size logların söyleyemediğini söyler. Eğer ekran kaydı (session recording) araçları kullanıyorsanız, bunları da devreye almak resmi netleştirir.

Bunun yanında kullanıcı görüşmeleri (user interview) ve kullanılabilirlik testleri (usability test) sorunu çok daha iyi anlamanıza yardımcı olur. İkisi arasında bir tercih yapmak gerekirse, kullanılabilirlik testi daha doğru bir adımdır; çünkü kullanıcıyı gerçek akışın içinde gözlemler, varsayımla değil davranışla konuşursunuz.

Herkesin Aynı Tabloya Bakması

İşin teknik kısmından önce gelen, ama çoğu zaman atlanan bir mesele var: Bütün paydaşların aynı metrikleri aynı şekilde takip etmesini sağlamak. Çünkü kredi başvuru gibi uçtan uca bir süreçte birden fazla ekip aynı kullanıcıya dokunuyor; herkesin kendi tablosu olduğunda, herkes farklı bir hikaye anlatmaya başlıyor.

Bu yüzden ortak izlenmesi gereken birkaç temel metriği masaya koymak gerekir:

• Başvuru tamamlama oranı: Kaç kullanıcı süreci baştan sona bitiriyor?
• Adım bazlı terk oranı: Hangi ekranda, hangi alanda dökülme yaşanıyor?
• Kimlik doğrulama başarısızlığı: Doğrulama adımı bir tıkanma noktası mı?
• Belge yükleme hatası: Teknik bir sorun mu, yoksa kullanıcı tarafında bir anlama problemi mi var?
• Kullandırım oranı: Başvuruyu bitirenlerin ne kadarı gerçekten ürünü kullanmaya başlıyor?

Bu beş başlık, ürün ekibinin, operasyonun, satışın ve teknolojinin aynı dili konuşmasını sağlar. Logları açıp bu oranları çıkardığınızda, artık "bence böyle" tartışması bitmiş, yerini "veri böyle diyor" konuşmasına bırakmış olur.

Tabloyu Çıkardıktan Sonra Ne Yapmalı?

Diyelim ki monitörü kurdunuz, oranları çıkardınız, heatmap'leri yerleştirdiniz. Şimdi ne olacak?

İlk olarak terkin en yoğun olduğu adımı belirleyip, oradaki dökülmenin kaynağına dair hipotezler kurmanız gerekir. Form mu uzun, sistem mi yavaş, mesaj mı anlaşılmıyor? Her hipotez ayrı bir araştırma sorusudur ve her birini ayrı bir yöntemle test etmeniz gerekir.

İkinci olarak, niceliksel veriyle niteliksel veriyi yan yana koymalısınız. Loglar size "belge yükleme adımında yüzde 40 terk var" diyorsa, kullanılabilirlik testleri size bunun nedeninin "hangi belgenin yükleneceğinin anlaşılmaması" olduğunu söyleyebilir. İkisi birleştiğinde tek başına ne sayılar ne de görüşmeler verebilecekken, çözüm netleşir.

Son olarak, çözümü uyguladıktan sonra aynı metrikleri tekrar ölçmeniz gerekir. Çünkü analiz bir kerelik bir iş değil, sürekli bir döngüdür. Bir adımı iyileştirdiğinizde, terk başka bir adıma kayabilir; bu sefer ışığı oraya tutmanız gerekir.

Sahadan Bir Bakış

Kredi başvuru akışını düşünelim. Loglara baktığınızda kullanıcıların büyük bir kısmının kimlik doğrulama adımında düştüğünü görüyorsunuz. Bu noktada iki ihtimal var: Ya gerçekten teknik bir problem var, ya da kullanıcı süreci anlamlandıramıyor.

Ekran kayıtlarını izlediğinizde fark ediyorsunuz ki insanlar doğrulama ekranında uzun süre bekliyor, bir şeyler deniyor ve sonunda vazgeçiyorlar. Heatmap üzerinde, "yardım" linkinin neredeyse hiç tıklanmadığını görüyorsunuz. Birkaç kullanılabilirlik testi yaptığınızda da kullanıcıların "hangi bilgiyi nereye gireceğini" tam çözemediğini fark ediyorsunuz.

Bu üç katmandan elde ettiğiniz bilgileri çağrı merkeziyle ve satış ekibiyle paylaştığınızda, onların da benzer şikayetleri duyduğunu öğreniyorsunuz. İşte bu nokta, paydaşların aynı metrik dilini konuşmasının ne kadar kritik olduğunu gösteren andır. Çünkü herkes farklı bir parçayı görüyordu; metrikler ortaklaşınca resim tamamlandı.

Merak Edilenler

Sadece logları izlemek yeterli mi?

Loglar terkin nerede yaşandığını söyler ama nedenini her zaman söylemez. Bu yüzden niceliksel veriyi heatmap, ekran kaydı ve kullanılabilirlik testi gibi niteliksel yöntemlerle desteklemek gerekir.

Kullanıcı görüşmesi mi, kullanılabilirlik testi mi?

İkisi de değerlidir ama terk gibi davranışsal bir problemde kullanılabilirlik testi genellikle daha doğru sonuçlar verir. Çünkü kullanıcının ne dediğini değil, ne yaptığını gözlemlersiniz.

Hangi metrikler ortak izlenmeli?

Başvuru tamamlama oranı, adım bazlı terk oranı, kimlik doğrulama başarısızlığı, belge yükleme hatası ve kullandırım oranı temel beş başlık olarak öne çıkar. Ekibinizin ihtiyacına göre genişletilebilir, ama bu beşi ortak bir taban oluşturur.

Çağrı merkezi ve satışın geri bildirimi yeterli olmaz mı?

Değerlidir ama tek başına yetmez. Onlar yalnızca sizi arayan ya da sizinle konuşan kullanıcıları duyar. Loglar ise hiçbir şey söylemeden ayrılan kullanıcıları da görmenizi sağlar.

Terkin Arkasındaki Hikayeyi Görmek

Kullanıcı terki, aslında bir başarısızlık göstergesi olmaktan çok bir hikaye anlatıcısıdır. Logların içinden, heatmap'lerin üzerinden ve kullanıcı testlerinin kayıtlarından size birinin neyi anlamadığını, nerede yorulduğunu, neden vazgeçtiğini fısıldar.

Ürün ekibinin işi bu fısıltıyı duyulur hale getirmek; sonra da o sesi tüm paydaşların aynı dilden okuyabileceği metriklere çevirmektir. Banka örneğinde olduğu gibi, terk oranını düşürmenin yolu daha çok varsayımdan değil, daha net bir ortak görüş alanından geçer. Verinin ne dediğini birlikte gördüğünüz an, çözüm de zaten ortaya çıkmaya başlar.