Uygulamanızı Karlı Hale Getirin, 2. Bölüm – Mobil Dönüşüm Hunisinden Yararlanma

Kârlı uygulamalarla ilgili önceki blog yazımda, çoğu mobil uygulamanın nasıl kârlı olmadığını ve uygulamanızın para kazanıp kazanmadığını ayırt etmede kilit faktörlerden birinin analizlerinizi ölçmek olduğunu tartıştım.

İlk örneğimde mobil oyun örneğini kullandım. Bu ilkeleri hemen hemen her tür mobil uygulamaya uygulayabilirsiniz, evet. Ancak, oluşturduğunuz uygulamanın türüne bağlı olarak kullanmak için daha iyi bir mobil analiz seti olabilir. Bu yazıda, kullanıcının abonelik satın aldığı bir fitness akış hizmetini ele alacağım.

Geleneksel Satış Hunisi

Bir şeyler satan insanlar olduğundan, onları yönlendirmeye yardımcı olacak bir satış/satın alma hunisi olmuştur. Satış hunisi örnekleri, işletmeniz hakkında bilgi almaktan ödeme yapan bir müşteri olmaya giden bir yolculuğa çıkan müşterilerinize bakmanın harika bir yoludur.

İyi bir satış hunisi stratejisi, potansiyel bir müşterinin sürecin neresinde olduğunu görselleştirmeye yardımcı olabilir, hunideki bir sonraki aşamaya geçmek için neler yapabileceğiniz konusunda önerilerde bulunabilir ve en büyük boşluğun nerede olduğunu, yani en çok nerede kaybettiğinizi görebilir. potansiyel müşterileriniz.

Dönüşüm Hunisini Mobil Uygulamaya Uygulama

Satış çağrılarına ve takiplere yol açmak yerine, kullanıcının biraz farklı yolumuzda ne kadar ilerlediğine ilişkin metrikleri kullanacağız. Bir örnek, İndir → Hesap Oluşturma → İlk Deneme → Kaydol olabilir. (Örneğimiz biraz daha kapsamlı olacak, ancak aynı fikir hemen hemen her uygulamaya uygulanabilir.)

Bu mobil uygulama dönüşüm hunisinin, indirmeleri nasıl alacağınızı da içerecek şekilde en üstte genişletilebileceğini (ve muhtemelen genişletilmesi gerektiğini) belirtmek de önemlidir. Facebook reklamı gibi bir şey için bu, gösterimler ve tıklamalar olabilir. App Store optimizasyonu (ASO) için bu, gösterimler ve App Store sayfa görüntülemeleri olabilir. Bu makale için, pazarlama ve reklam harcamalarına değil, ürüne odaklanacağız.

Hangi Mobil Dönüşüm Hunisi Adımlarının Kullanılacağını Belirleme

Örnek olarak şu anki nakliye mobil uygulamam Charge Running'i kullanacağım. Ayda 9,99 ABD Doları karşılığında telefonunuza canlı akışlı koşu dersleri sağlıyoruz. Her sınıf belirli bir zamanda gerçekleşir ve her koşunuzda size koçluk yapan gerçek bir kişi vardır.

Hemen hemen her şirketin kullanıcısını bir dönüşüm huni olarak görselleştirebilirsiniz. Örneğin, eBay'in satış hunisi modeli, uygulamaların büyük çoğunluğu tarafından kullanılan oldukça standart bir yaklaşımdır. Facebook ise bir kullanıcının belirli sayıda bir eylemi nerede yaptığını bildiğim en popüler örnek. Charge Running'in kullanıcı edinme modeli için Facebook rotasına daha yakın bir yol izledik:

Facebook'un ilk günlerinde, bir kullanıcının platformda 10 gün içinde yedi arkadaşıyla bağlantı kurmasını sağlayabilseydi, siteyi sonsuza kadar kullanacaklarını analiz yoluyla keşfettiler. Bu yüzden neredeyse tüm çabalarını ilk yedi arkadaşı elde etmeye odakladılar.

Tahminimiz (ki doğru çıktı!), bir kullanıcı bizimle 3-4 koşu yaparsa abone olur. Bunu göz önünde bulundurarak, odaklanmayı seçtiğimiz özel mobil dönüşüm hunimizdeki her adım:

İndir → Hesap Oluştur

Uygulamayı 100 kişi indirirse kaç kişi bizde hesap oluşturur?

Hesap Oluştur → Bir Koşu İçin Kaydolun

Bir hesapları varsa, belirli bir zamanda bizimle kaç taahhütte bulunacaklar?

Koşuya Kaydolun → Doğru Zamanda Geri Dönün

Artık belirli bir zamanda çalışmayı taahhüt ettiklerine göre, uygulamayı gerçekten olması gerektiği zaman mı açıyorlar?

Geri dön → Koşmaya Başla

Doğru zamanda uygulamadalarsa, gerçekten hareket etmeye mi başlıyorlar yoksa sadece dinliyorlar mı?

Koşmayı Başlat → Bir Koşuyu Bitir

Bizimle koşmaya başladılarsa, tüm antrenmanı tamamlayacak kadar keyif alıyorlar mı?

1 Koşu → 2 Koşu → 3 Koşu → 4 Koşu tamamlayın

Bir koşuyu tamamladıktan sonra, kaç tanesi başka bir koşu yapmak için geri dönüyor?

X Koşusunu Tamamla → Şarj Etmeye Abone Ol

Bu kadar çok koşu yapıyorlarsa, yüzde kaçı Charge'a abone olur?

Veri Toplama

Tüm bu soruları yanıtlayan harika bir araç olmasını dilerdim, ancak henüz bir tane bulamadım. Bulduğum en iyi yöntem, bu verileri almanın bir yolunu bulmak ve bunu izlemek için manuel olarak bir şeyler oluşturmak.

Uygulama veritabanımızın çalışması için tüm bunları zaten bilmesi gerektiğinden, üretim veritabanının bir kopyasını oluşturduk ve bir kullanıcının dönüşüm hunisinin her noktasında nerede olduğunu almak için kod yazdık. Bu önemli ölçüde daha fazla iş olsa da, bize daha hassas kontrol imkanı verdi.

Bu verileri görselleştirmeye yardımcı olmak için Metabase adlı ücretsiz açık kaynaklı aracı kullanmayı seçtik. Metabase, verilerinizi görselleştirmenize ve halihazırda kullanmakta olduğunuz bir veritabanından istatistikler ve huniler oluşturmanıza olanak tanır. Uygulamanız için SQL tipi bir veritabanı kullanıyorsanız, ihtiyacınız olan her şey bu araç olabilir.

Metabase, herhangi bir kod yazmadan uygulamanız hakkında bir şeyler aramanıza izin verir, ayrıca SQL sorguları yazarak daha fazla özelleştirme elde etmenize olanak tanır. Ayrıca, her gün başvurabileceğiniz panolar oluşturmanıza ve şirketinizde farklı roller için farklı panolar oluşturmanıza olanak tanır: Koşu uygulamamızda koçların panosu, huni panomuzdan çok farklı görünür. Bu, sizin için en önemli olan istatistikleri ön planda tutmanıza ve kolayca erişmenize olanak tanır.

Bu metriklere bakarken, dönüşüm hunisindeki her adıma iki farklı şekilde baktığınızdan emin olun:

1. Önceki adımdan mevcut adıma (örn. Adım 3 → Adım 4)
2. İlk adımdan mevcut adıma (örn. Adım 1 → Adım 4)

İlki, iyileştirmeleri görmek için daha kolay izlemenizi ve ince ayar yapmanızı sağlar. İkincisi, dönüşüm hunisinde bir sonraki adıma odaklanacağınız adımı seçmek için kullanıcılarınızın çoğunu nerede kaybettiğinizi görmenize olanak tanır.

Mobil Uygulama Metriklerini İyileştirme

Böyle bir huni oluşturduktan sonra, neredeyse her zaman beklemediğiniz bir alanda müşteri kaybettiğinizi göreceksiniz. (Bu, ürüne çok özel bir şeydir, ancak dönüşüm huninizdeki herhangi bir noktayı iyileştirmenize yardımcı olabilecek bazı genel yönergeler vardır. Bununla ilgili daha fazla bilgi için bu makalenin "Metriklerinizi Nasıl İyileştirirsiniz?" Bölüm 3'ü izlemeye devam edin. ”)

İşte hızlı bir örnek: 1.0 ürünümüzde, bizimle bir sınıfa kaydolan çok sayıda kullanıcı elde ettik, ancak çok azı zamanında geri döndü. Neden bu kadar çok insan bizimle kaçmayı taahhüt ediyor da zamanı geldiğinde geri gelmiyordu?

Sorunu keşfetmek ilk adımdı. Dışarı çıktık ve elimizden geldiğince çok insanla konuştuk ve birkaç şeyin eksik olduğunu gördük. İlk ve en önemlisi kullanıcı eğitimiydi. Kullanıcılar ürünün ne olduğunu ve geri sayım sayacının ne anlama geldiğini tam olarak bilmiyorlardı. Daha sonra ne olacağı ve ne yapmaları gerektiği hakkında daha fazla bilgi eklemek için bekleme ekranını güncelledik.

Ayrıca, kullanıcıların koşularına zamanında katılabilmeleri için sürekli olarak hatırlatılmaları gerekiyordu. O zamandan beri, koşularının yakında gerçekleşeceğini bilmelerini sağlamak için anında iletme bildirimleri ekledik. Ayrıca takvimlerine eklemelerine ve arkadaşlarının koşuyu hatırlatabilmesi için bir arkadaşlarını davet etmelerine izin verdik. Bunların her biri oldukça küçük değişikliklerdi ve bazıları büyük sonuçlar verdi.

Yazma sırasında, App Store'a her biri dönüşüm hunisinin bir bölümünü iyileştirmeye odaklanan 30'dan fazla güncelleme gönderdik ve sonuçları izledik. Hiç kimse ilk çekimde geliştirme yapamaz, bu nedenle test etmeye, analiz etmeye ve geliştirmeye hazır olduğunuzdan emin olun.

Her sürümde mevcut hunimizi yenisiyle karşılaştırabiliriz. Kullanıcılarınız ve geliştirme süreniz varsa, A/B testi ile birden çok şeyi aynı anda test edebilirsiniz. Bu, ikinci bir huni oluşturarak ve her kullanıcıyı bir gruba veya diğerine koyarak yapılabilir. Tüm bu testlerin amacı, size çevirmeniz için bir dizi kadran vermek ve bu kadranları çevirmenin uygulamanızın genel karlılığını nasıl etkilediğini görmektir.

Ömür Boyu Değeri (LTV) Hesaplama

Bir önceki makalede, en önemli mobil uygulama başarı metriklerinden biri olan LTV'yi araştırdık. Ama burada bu sayıyı elde etmek için farklı bir yaklaşıma ihtiyacımız var.

İlk olarak, dönüşüm hunisindeki ilk adımdan son adıma giden kişilerin yüzdesi, dönüşüm yüzdenizdir . Bu şu şekilde hesaplanır:

Abone veya alıcı sayısı / Dönüşüm hunisinin en üstündeki kullanıcı sayısı

Bir örnek 4 abone / 100 indirme = yüzde 4 olabilir.

Tek bir satın alma işlemi yapıyorsanız (pro sürümün kilidini açmak, bir öğe satın almak vb.) o zaman formülünüz basittir. Önce kullanıcı başına net karı bulun: satın alma fiyatından Apple'ın veya Google'ın %30'luk kesintisi, sunucu barındırma vb. maliyetler çıkarıldıktan sonra bunu dönüşüm yüzdenizle çarpın. Örneğin, %4'lük bir dönüşümle 29,99$'lık bir satın alma işlemim varsa, şunun gibi bir şey yapardım:

29,99 ABD doları * %70 = 20,99 ABD doları (Apple'ın veya Google'ın kesintisi kaldırıldı, yani kullanıcı başına net kâr) 20,99 ABD doları * %4 = 0,83 ABD doları (LTV)

Abonelik dünyasında, bir abonenin bizimle ne kadar kaldığını öğrenene kadar bir LTV'ye ulaşamayız.

Abone Tutma

Yani abone olacak bir kullanıcınız var, bu harika! Düşünülecek sonraki şeyler, elde tutma ve çalkalamadır.

Elde tutma , belirli bir süre kalan kullanıcıların yüzdesidir. Churn biraz tersidir: her ay kaç kişiyi kaybedersiniz.

Kullanıcı kaybını etkilemek için yapabileceğiniz bir sürü şey var. Şu anda, kayıplarımızı ölçmek ve bunu önemli bir sayı bulmak için kullanmak istiyoruz: Ortalama bir kullanıcının işletmenizde ne kadar kaldığı.

Bir süredir buralardaysanız, bu numaraya veya onu almak için ihtiyacınız olan verilere zaten sahip olabilirsiniz. Peçetenin arkası sayıları için, ilk ay için - tipik olarak en kötü ay - kayıp yüzdenizi alabilir ve gelecek aylar için varsayabilirsiniz. Ortalama bir kullanıcının ne kadar kalacağını bulmak için bu sayının tersini alın. Örneğin, her ay müşterilerimin %20'sini kaybedersem, ortalama kullanıcı 1 / 0,20 = 5 ay sürer .

Kayıp oranı bir aydan diğerine önemli ölçüde değişebilir. Örneğin, 1. ay yenilemelerindeki kayıp oranınız, neredeyse her zaman 6. aylık yenilemelerdeki kayıp oranınızdan daha yüksek olacaktır. Önümüzdeki 12 aydaki kayıp oranınızı biliyorsanız, ortalama bir kayıp oranı elde etmek için bu sayıları kullanabilirsiniz. Burada aylık yenilemeleri tartışıyoruz, ancak bu aynı zamanda haftalık ve yıllık abonelik süreleri için de geçerli olacaktır.

Bir kullanıcının abone olarak kaldığı ortalama ay miktarını hesaplamanın birçok farklı yolu vardır. Başvurunuza bağlı olarak, ne kadar süredir abone olduklarına, bir şeyi nerede tamamlama sürecinde olduklarına (tamamlanacak bir kursu olan bir eğitim uygulaması gibi) veya bir fitness uygulaması için, belki de yılın sezonu. İnternette dolaşmaktan ve size uygun bir sistem bulmaktan çekinmeyin. Ortalama bir kullanıcının ne sıklıkla abone olduğunu öğrendikten sonra bir sonraki adıma geçebilirsiniz.

Elde Tutma Metriği ile YBD'ye Geri Dön

Bir kullanıcının ortalama olarak ne kadar kaldığını öğrendiğimizde, LTV hesaplaması çok basittir:

Abonelik maliyeti × Abone olunan ödeme dönemi sayısı

Örneğin, kullanıcı başına ayda 20,99 ABD doları kazanırsak ve ortalama kullanıcı 10 ay boyunca abone kalırsa, LTV'miz 209,90 ABD dolarıdır.

Birden fazla ödeme seçeneğiniz varsa (örneğin, yıllık abonelik ve aylık abonelik), her ödeme seçeneği için yukarıdakiyle aynı yolu oluşturabilir ve ardından bunu, genel bir sayı oluşturmak için belirli bir yolu seçen kullanıcıların yüzdesiyle çarpabilirsiniz. .

Örneğin, kullanıcılarımın yüzde 66'sı aylık rotayı ve yüzde 34'ü yıllık rotayı seçiyorsa, şunları yapabilirsiniz:

Aylık YBD × %66 + Yıllık YBD × %34 = Ortalama YBD

Burada ayrıca bir abonelik seçeneğinin diğerinden önemli ölçüde daha karlı olduğunu da öğrenebilirsiniz. Bu durumda, diğerini daha karlı hale getirmek için bazı fiyat testleri yapmak veya hepsini ortadan kaldırmak isteyebilirsiniz. Yaşam boyu değerinizi bilmek, cephaneliğinizde sahip olabileceğiniz en değerli mobil uygulama metriklerinden biridir. Bir kullanıcı edinmek için tam olarak ne kadar harcamak istediğinizi belirlemenize ve şirketinizin temel pazarlama yönleri hakkında daha iyi kararlar vermenize olanak tanır.

Huni ve ARPDAU Ne Zaman Kullanılmalı?

Peki ilk blog yazısında anlatıldığı gibi günlük aktif kullanıcı başına ortalama gelir (ARPDAU) yerine yukarıda açıklanan modeli ne zaman kullanmalısınız? Her iki taktiği de kesinlikle kullanabilirsiniz, ancak işinize en uygun olanla başlamanızı tavsiye ederim ve her zaman genişletebilirsiniz!

Bir kullanıcının yaşam boyu değerini ARPDAU ile belirlemek birçok durumda harikadır. Aşağıdaki durumlarda ARPDAU ile başlamak muhtemelen daha iyidir:

1. Uygulamanızın birincil gelir kaynağı mikro işlemler veya reklamlardır.
2. Bir kullanıcının uygulamanızda harcadığı süre ile geliriniz arasında doğrudan bir ilişki vardır. (Örneğin bir alışveriş uygulaması.)
3. Birincil geliriniz, bir sosyal ağ gibi kullanıcı hakkında veri toplamaktır.

Aşağıdaki durumlarda huni kullanmak muhtemelen daha iyi bir seçenek olacaktır:

1. Kullanıcının, uygulamanızın veya oyununuzun tam sürümünün kilidini açmak gibi tek bir satın alma işlemi yapmasını sağlamak istiyorsunuz.
2. Belirli bir kullanıcı o gün uygulamayı açsa da açmasa da gelir elde ettiğiniz abonelikler yapıyorsunuz.
3. Bir kullanıcının bir satın alma işlemini tamamlamak için uygulamanızı başlattıktan sonra birkaç farklı adımı tamamlaması gerekir ve bunları nerede kaybettiğinizden emin değilsiniz.

Buradan Nereye Gitmeliyim?

Artık mobil huni süper güçleri ile donanmış olduğunuza göre, bundan sonra ne yapmalısınız? Buradaki cevap basit: Bu sayıları olabildiğince geliştirin! Ekibinizle beyin fırtınası yapın, bir şeyleri olabildiğince çabuk oluşturun ve test edin ve dönüşümünüze yardımcı olmayan özellikleri ortadan kaldırın.