Kullanıcı hesabını açtı, hoş geldiniz turunu bitirdi ve kontrol paneline ulaştı. Buna rağmen ürünün kendisine nasıl yardım edeceğini hâlâ bilmiyor olabilir. Onboarding akışında ekranların tamamlanmasıyla ürünün değerinin anlaşılması aynı sonuç değildir.
SaaS onboarding, kullanıcıyı ürünün temel faydasını deneyimleyebileceği işe hazırlayan süreçtir. Bu fayda raporun oluşması, bir rezervasyonun alınması, takım arkadaşına görev atanması veya gerçek bir veri bağlantısının çalışması olabilir. Önce bu anı tanımlamak, sonra onu destekleyen adımları tasarlamak gerekir.
Bu yazıda kullanılan iş yönetimi ürünü ve sayısal hesaplar örnektir. Olay adları önerilen bir ölçüm sözlüğüdür; evrensel standart veya gerçekleşmiş müşteri sonucu değildir.
“İlk değer” için gözlenebilir bir davranış seçin
Bir iş yönetimi ürününde kullanıcı yalnızca boş bir proje oluşturmuşsa henüz ekip işini kolaylaştırmış sayılmayabilir. Örnek ilk değer tanımı şöyle olabilir: “Yeni çalışma alanında gerçek bir görev oluşturuldu ve daveti kabul etmiş başka bir ekip üyesine atandı.”
Bu tanım kusursuz olmak zorunda değildir; doğrulanabilir bir başlangıç hipotezidir. Kullanıcı görüşmeleriyle görev atamanın gerçekten faydayı temsil edip etmediğini kontrol edin. Daha sonra bu davranışı yapan hesapların ürüne geri dönüp dönmediğini inceleyin.
Kullanıcı birimi ile hesap birimini karıştırmayın
Ekip ürününde kayıt olan kişiyle değeri yaşayan organizasyon farklı birimlerdir. Yönetici hesabı kurabilir, çalışan görevi tamamlayabilir. Tek bir kullanıcının bütün adımları yapmasını bekleyen ölçüm, başarılı ekipleri yanlışlıkla başarısız sayabilir.
Başlangıç için hesap düzeyinde aktivasyon ve kullanıcı düzeyinde adım tamamlama raporlarını ayrı tutabilirsiniz. Hangi birimin neden kullanıldığını gösterge tanımına yazın.
Değere ulaşmadan önce gerekenleri azaltın
Akışı kurarken her alan için şu soruyu sorun: “Bu bilgi olmadan kullanıcı ilk temel işi yapabilir mi?” Yapabiliyorsa alanı sonraya bırakmayı değerlendirin. Şirket logosu, ayrıntılı fatura bilgisi veya bütün takım rollerinin yapılandırılması ilk görevden önce gerekmeyebilir.
Güvenlik ve erişim için gerçekten gerekli adımları koruyun. Ama her zorunluluğun gerekçesini anlaşılır biçimde açıklayın. Bir veri bağlantısı kurulacaksa hangi verinin alınacağı, işlemin ne kadar sürebileceği ve başarısızlıkta ne yapılacağı görülebilsin.
Örnek akış şu şekilde sadeleştirilebilir: çalışma alanını aç, ilk işi seç, gerekli kişiyi davet et, ilk görevi oluştur, sonucu gör. Bu sıra ürünün işine göre değişir; aynı rehberi bütün SaaS ürünlerine uygulamak yerine kendi değer anınızdan geriye doğru ilerleyin.
Örnek veri gerçek başarıdan ayrılmalı
Boş ekran yerine örnek proje göstermek ürünü anlaşılır kılabilir. Ancak örnek projedeki görevin tamamlanmasını gerçek müşteri aktivasyonu olarak saymayın. Kayıtların örnek veri olduğunu belirten bir alan bulundurun ve raporda ayrıştırın.
İlk kullanımda kullanıcıya örnek veriyi silme veya kendi verisiyle devam etme yolu verin. Deneme verisinin aylar sonra operasyonel raporlara karışması, ürün içinde başka bir güven sorunu yaratabilir.
Olay sözlüğünü ekran akışından bağımsız yazın
Bir olay için ad, tetikleme koşulu, kimlikler, gerekli özellikler ve kayıt zamanı tanımlanmalıdır. Segment'in Track yapısı davranışın olay adı ve özelliklerle kaydedilmesine örnek bir çerçeve sunar. Aşağıdaki sözlük, ürününüz için uyarlanabilecek özgün bir öneridir. Twilio Segment: Track.
- account_created: Çalışma alanı sunucuda başarıyla oluşturulduğunda, hesap başına bir kez.
- member_joined: Davetli kişi daveti kabul edip hesaba bağlandığında.
- task_created: Görev kalıcı olarak kaydedildiğinde; hesap ve görev kimliğiyle.
- task_assigned: Atama başarıyla tamamlandığında; atanan kullanıcının hesap üyeliği doğrulanmışken.
- first_value_reached: Tanımlanan ilk değer koşulları sağlandığında, hesap başına tek aktivasyon kaydı olarak.
Ekrandaki düğmeye tıklamayı kalıcı kayıt başarısıyla karıştırmayın. Başarısız isteklerde de tıklama oluşur. Özellikle aktivasyonun dayandığı iş olayını sunucunun doğruladığı sonuçtan üretmek daha güvenilir bir başlangıçtır.
Her olayda event_id, account_id, occurred_at ve schema_version gibi alanlar düşünülebilir. Yeniden gönderilen olayları event_id ile tekilleştirin. Saat dilimi ve gecikmeli ulaşan kayıtların rapora hangi tarih ile gireceği kararlaştırılmalıdır.
Aktivasyon oranını açık bir pencereyle hesaplayın
“Aktivasyonumuz arttı” demeden önce payda ve süreyi yazın. Örnek tanım: belirli haftada oluşturulan uygun hesaplardan ilk yedi gününde ilk değere ulaşanların oranı. Deneme hesapları ve iç ekip hesaplarının dışlanma kuralı baştan belirlenmelidir.
Tamamen varsayımsal bir hesapta 100 uygun hesabın 35'i bu koşulu sağlıyorsa aktivasyon yüzde 35'tir. Bu oran bir sektör hedefi veya WebWizz performansı değildir; tanımın nasıl hesaplandığını gösterir.
Yeni açılmış hesapların henüz yedi günü dolmadıysa onları tamamlanmış pencereye sahip hesaplarla aynı sonuç tablosunda karşılaştırmayın. Aksi hâlde son haftanın performansı sırf gözlem süresi kısa olduğu için düşük görünebilir.
İlk değere ulaşma süresini tek başına okumayın
İlk değere ulaşma süresi, başlangıç olayı ile ilk değer olayı arasındaki farktır. Ortanca süreyi ve daha yavaş kullanıcıları temsil eden üst yüzdelikleri birlikte izleyebilirsiniz.
Ancak yalnızca aktive olan hesapların süresi kısalırken aktive olmayanların sayısı artabilir. Bu nedenle süreyi aktivasyon oranıyla beraber değerlendirin. Hızlanan akışın daha fazla kullanıcıya yardım edip etmediği ancak birlikte görülebilir.
Ölçüm verisini ürün davranışıyla karşılaştırın
Analitik grafiği tek doğruluk kaynağı saymayın. Bir örnek hesapta olay akışını gerçek uygulama kayıtlarıyla eşleştirin. Hesap kimliği değişmiş, olay iki kez gönderilmiş veya deneme verisi gerçek veri sayılmış olabilir.
Google Analytics'in önerdiği sign_up olayı kayıt olmayı anlatır; sizin ürününüzdeki değer anını kendiliğinden tanımlamaz. İlgili iş olayını ayrıca tasarlamanız gerekir. Google Analytics: önerilen olaylar.
Analitik araçlarına serbest metin, müşteri adı veya e-posta adresi aktarmamaya özen gösterin. Özellikle Google Analytics'e gönderilmemesi gereken kişiyi tanımlayan bilgiler için ürünün resmî kurallarını kontrol edin. Google Analytics: kişiyi tanımlayan bilgiler.
Onboarding uygulama kontrol listesi
- İlk değer davranışını tek cümlede ve test edilebilir yazın.
- Ölçümün hesap mı kullanıcı mı düzeyinde olduğunu belirtin.
- İlk iş için gerekmeyen alanları sonraya bırakın.
- Örnek veri ve iç ekip kullanımını ayırt edin.
- Olaylara açık tetikleme koşulları ve sürüm verin.
- Tekrar olayları ve kimlik birleşmelerini sınayın.
- Aktivasyon penceresini ve paydasını sabitleyin.
- Süreyi, aktivasyonu ve sonraki kullanımı birlikte inceleyin.
WebWizz ile SaaS ürününüzün başlangıç akışını ele almak isterseniz ilk değer tanımınızı ve mevcut ekranlarınızı iletişim üzerinden paylaşabilirsiniz. Böylece tasarım kararları ölçülebilir ürün davranışlarına bağlanabilir.
Sık sorulan sorular
Onboarding turunu tamamlamak aktivasyon sayılır mı?
Ancak ürünün faydasını gerçekten temsil ediyorsa düşünülebilir. Çoğu durumda tur tamamlanması bir hazırlık göstergesidir. Kullanıcının temel işi yapabildiğini gösteren davranış ayrıca izlenmelidir.
Her SaaS için ilk değer aynı gün mü oluşmalı?
Hayır. Veri aktarımı, ekip onayı veya uzun süren iş akışları farklı pencereler gerektirebilir. Süreyi ürünün doğasına göre belirleyin ve neden o pencereyi seçtiğinizi belgeleyin.
Aktivasyon arttığında müşteri kaybı otomatik azalır mı?
Böyle bir garanti yoktur. İlk davranış ile devam eden kullanım ilişkisini sonraki kohortlarda inceleyin. Yanlış seçilmiş aktivasyon tanımı, yalnızca kolay tamamlanan bir işlemi ölçebilir.
Ölçüme çok sayıda olayla mı başlamalıyız?
Önce temel akışın güvenilir olaylarıyla başlayın. Her olayın karar karşılığı yoksa bakım yükü artabilir. Daha ayrıntılı ölçüm, somut bir kullanıcı sorusunu açıklamak için eklenebilir.