2 Haftada Kullanıcıların Beğendiği Bir Sağlık Uygulamasını Nasıl Geliştirdik?
İngilizce Medium yazıları arasında en beğendiğim ve okumaktan eğlendiğim yazılar kendi hikayelerini teknik anlamda anlatan yazılar olmuştur. Bu yazıda benzeri bir formatta, geliştirdiğimiz sağlık rehberi uygulamasını, piyasa kalitesinin daha üstü bir kalitede geliştirip yayınladığımızı ve ilk haftasında kaç kullanıcının indirdiğini ve kullanıcıların tepkilerini ve karşılaştığımız sorunların hikayesini anlatacağım. Bundan önce uygulamaya siz kendiniz göz atmak isterseniz buraya tıklayın.
Motivasyon
Ben ve İstanbul’dan Doktor müşterim/arkadaşım Dr. Can Çiftçi’nin 3 yıldan uzun süredir devam ettirdiği Fitekran isminde bir internet sitesi var. Bu internet sitesi aylık ortalama 1 milyon ziyaretçiye ev sahipliği yapıyor. İnternet sitesinin ana konsepti okuyuculara ve meraklılarına; beslenme rehberleri, egzersiz rehberleri, bilimsel incelemeler, hastalıklar, sağlıklı yaşam püf noktaları ile alakadar içerikler sunmak.
Bu içeriklerin tarafsız şekilde Türkçe içerik olarak görebileceğiniz en kaliteli içerikler olduğunu söyleyebilirim. Ayrıca Can’ın kendine has rehber yazma tarzı ile istatistiklere göre kullanıcıların rehberleri okumaya başladıktan sonra tamamlama oranı %80'in üzerinde. Fitekran’nın en büyük sorunu kullanıcı elde tutma ve internet sitesini tekrar ziyaret etmesini sağlamak (retention).
Her ne kadar Fitekran kâr amacı gütmeyen bir kuruluş olsa da, düşük retention’a sahip bir üründen conversion almak veya monetize etmek gerçekten zor bir iş. İçeriğiniz ne kadar kaliteli olursa olsun, internet sitesi aracılığı ile devamlı takipçi kazanmak çok zor. Yine istatistiklere göre Fitekran’ı Google’dan bulan okuyucuların %80'i yazıyı okumayı tamamlamasına rağmen, sadece %10'u site içeriğine tekrar dönüş yapıyor.
Bunun nedeni Fitekran internet sitesinin kötü bir arayüze sahip olması veya içeriğinin kötü olması değil, nedeni tamamen alışkanlık. Şöyle bir düşünürseniz, siz de içeriğini beğenmenize rağmen düzenli olarak ziyaret ettiğiniz 5 internet sitesi sıralayamazsınız. (Sosyal medya siteleri dışında)
Peki bunun çözümü nedir? Mobil uygulamalar. Mobil uygulamalar, mobil websitelerine oranla x3 daha fazla retention oranına sahip.
Bunun böyle olması aslına bakarsanız gayet doğal. Kullanıcı mobil uygulamanızı indiriyorsa markanıza bir tür bağlılığı vardır, mobil uygulamayı indirdiğinde cihazının ana ekranında uygulamanızın ikonu bulunacak ve kullanıcı eğer kabul ederse push notification gönderebileceksiniz. Ayrıca genellikle mobil uygulamalar, mobil sitelere göre genelde daha iyi bir kullanıcı deneyimine sahipler.
Her ne kadar Progresif web uygulamaları (PWA*) ile mobil internet sitelerinin offline performansını arttırmak, internet sitelerini ana uygulama ekranında ikonlarının çıkmasını sağlamak ve daha kolay push notification göndermelerini sağlamak çalışılsa da, özellikle iOS platformunda yeterince teknik destek bulunmuyor, ayrıca kullanıcıların alışkanlığını değiştirmek de çok büyük bir sıkıntı.
Peki her zaman mobil uygulama, mobil websitelerine karşı üstün mü? Bu çok dolu bir soru ve üzerine çok fazla konuşmak lazım. Fakat ikisinin de kendi başına faydaları var. İkisinin de olması, kullanıcıya aracıdan bağımsız bir şekilde içeriğinizi ulaştırmanız her zaman için daha iyi bir seçimdir, diyebiliriz.
Sağlık Rehberi Uygulaması da Nedir?
Bir sağlık rehberi uygulamasını (en azından biz aramızda) kullanıcıya sürekli bilgi vererek, kullanıcıdan minimum bilgi alan uygulamalar olarak tanımlıyoruz. Kullanıcılar genellikle üşengeç ve MyFitnessPal’in istatistiklerine göre kendi bilgilerini vermekten veya sürekli olarak girdi yapmaları gereken uygulama formatlarından bir süre sonra soğuyorlar.
Bu durum Fitekran’ın içeriğine olarak retention’ı arttırmak için önümüzde bir engel olabilirdi.
Tüm bunları göz önüne alarak bir “sağlık rehberi uygulaması” tasarladık. Uygulama, tasarladığımız rehberler sayfası ile, Fitekran’daki en iyi rehberlere ışık tutmamızı sağlıyor.
Tasarlarken asıl amacımız kullanıcıların sağlıklı yaşam konusunda kafasına takılan bir şey olduğunda uygulamayı açmasını sağlamaktı. Bu nedenle 3 ana sekme düşünerek bu sekmelerde rehberlere ek olarak sitemizin veritabanındaki besinler ve tarifler arasında arama yapıp bu bilgilerin görüntülenebileceği bir arayüz tasarladık.
Bunlara ek olarak uygulamamızın bir diğer Fitekran açısından önemli tarafı kullanıcılar ile sürekli olarak bağlantıda kalmamızı sağlayan push notification özelliği. Bu özelliğe ek olarak bir bildirim sayfası tasarladık. Bu sayfada kullanıcılara gönderdiğimiz bildirimler yeniden eskiye sıralanacak ve bu bildirimlerle bağlantılı rehber, video veya 3. parti linkleri kullanıcılar rahatça takip edebilecek.
Uygulamayı yayınlamadan hemen önce eklediğimiz bir diğer özellik de, çok basit şekilde tasarlanmış, kullancıların yüzlerce rehber arasında kendilerine en uygun rehberi listelemelerini sağlayan bir chat-botuydu. Bu sayede kullanıcılar arasında ilgi göreceğini tahmin ettiğimiz bir özellik eklenmiş oldu.
Çoğu zaman basit bir arama kutusu, kullanıcılara istediklerini vermiyor. Kullanıcı deneyimi olarak “ne istediğini bilmeyen kullanıcılar” için arama kutusu hiç bir işe yaramamakta. Lineer de olsa bu tür bir özellik, ne okumak istediğini bilmeyen kullanıcıları ayıra uygulamada tutacağını düşünüyoruz.
Teknik Arka Plan
Sanıyorum benim yazarken en çok zevk alacağım konuya geldik. Anlatacak çok şey var, ve her konuya değinmek istiyorum, fakat her konuya ayrıntılı olarak değinmek zor olduğundan bazı konuları yüzeysel olarak geçebilirim.
Backend
Fitekran internet sitesi Wordpress kullanan bir internet sitesi ve DigitalOcean’da host ediliyor. Fitekran’da ek olarak kapalı şekilde önceden tasarladığım bir besin ve yemek tarifi API’ı bulunuyordu. Buna ek geliştirmeler yapıp uygulamada işime yarayacan endpoint’ları geliştirdikten sonra (PHP ve wordpress’in sunduğı araçlarla) ayrıca Dr. Can chatbotu için de lineer bir programatik arayüz de oluşturdum.
Backend’de ek olarak yaptığım bir diğer şey de bildirimlerin store edileceği bir veritabanı oluşturmak, bildirim almak isteyen kullanıcıların call ettirdiği token’ları kaydettiğimiz bir tablo ve ayrıca hem benim hemde Can’ın rahatça bildirim gönderebileceği wordpress admin paneline entegre bir arayüz geliştirdim.
Bahsettiğim gibi bu bildirimler ve bilgileri kayıt ediliyor ve yine bir diğer API endpoint ile uygulamanın bildirim sekmesinde eski bildirimler olarak listeleniyor olacak.
Rehber Sayfaları
Rehber sayfalarının ve yazıların bir API aracılığı ile alınıp uygulamada render edilmesi başlangıçta mantıklı görünse de, uygulamanın çok fazla kullanıcı tarafından kullanıldığını düşündüğümüzde ve ortalama kullanıcının yazı API’ına 10 istek yaptığını düşünürsek (Wordpress yüzünden arkada PHP çalıştırdığımızı düşünürseniz) her ay sonu ağır bir sunucu ücreti ile karşılaşabiliriz ve ayrıca bu sistemin ne kadar hızlı olduğu konusunda yorumları sizlere bırakıyorum.
Fitekran internet sitesinde AMP kullanıyoruz. AMP, geliştirilmesi Google tarafından desteklenen ve mobil web sayfaların çok hızlı şekilde yüklenmesini sağlayan bir teknoloji. AMP sayfaları önbelleklenerek server-side’da daha az iş yapılmasını sağlıyor. AMP ile oluşturulmuş sayfalarınızda kendi sunucunuzda sunabilirken, ayrıca isterseniz çok daha hızlı bir CDN üzerinden de sunabilirsiniz, ki bu daha ucuz olacaktır.
AMP sayfalarının ek olarak görünmeyen bölgeyi render etmiyor olması durumu da uygulamada sonrasında işime yarayacak bir özellikti. Çok küçük bir çalışma sonunda AMP sayfalarımın uygulama içerisine embed edilecek halleri için birkaç çalışma yaptıktan sonra uygulamanın kodlamasına geçmeye hazırdım. (Örnek bir uygulamada görünen AMP sayfası)
Uygulamayı Geliştirmek
Uygulamayı geliştirirken React Native/ReactJS’i birlikte kullandım. Daha çok React kullandığımı söyleyebilirim. Bunun nedenini önceden yazdığım bir yazımda anlatmaya çalışmıştım.
Kısaca özetlemek gerekirse, React Native çoğu nedenden dolayı yorucu olabiliyor, tamamı React Native uygulamalar da geliştirmiş birisi olarak, Native uygulamaların kattığı söylendiği performans artısı bana çok küçük geliyor. Ayrıca ReactJS ile proje geliştirirken kendimi kısa sürede çıkartacağım ürün açısından daha rahat ve özgür hissediyorum.
Kurduğum sistemin çalışma akışından biraz bahsetmem gerekirse, asıl uygulama geliştirme yaptığım bir projem var ve bu projenin çıktısını wrap edip uygulama marketler için build edecek bir projem var.
İlk proje ReactJS projesi ve geliştirme gayet trivial, API’ları kullanarak bir single page uygulama geliştirdim ve ek olarak webpack’in inline loaderlarını kullanarak SVG ikonlarını, sayfada kullanılan küçük resimleri, (CDN’den çekilmeyen arayüz materyalleri), kullanılan fontları, CSS ve JavaScript dosyalarının tamamını tek bir index.html dosyası içerisine gömüyor.
Bu sayede sonrasında cihazın yerel depolamasına uygulamanın dosyasını yüklediğimde ve her seferinde ulaşmaya çalıştığımda telefonun depolama hızının limitlemelerinden ve uygulama kullanılırkenki storage latency sorununu da tek seferde ortadan kaldırmış olacağım. HTML dosyası tek başına önbelleğe alındıktan sonra, uygulamanın cihaz depolaması ile tekrar iletişim kurması gerekmeyecek.
Bu HTML dosyası geliştirme tamamlandığında webpack’in de sihirli araçlarıyla 561kB boyutundaydı. Yani bu demek oluyor ki, teorik olarak 561kB dosya ile tam bir uygulama rahatça çalıştırılabilir. (Yok ;))
İlk projenin ürettiği html dosyası otomatik olarak 2. projenin dizinine taşınıyor ve 2. proje (React Native projesi) bu html dosyasını bir webview olarak yüklüyor. Burada bu projenin neden React Native olduğunu merak edebilirsiniz, bunun yerine Phonegap gibi bir teknoloji kullanarak da HTML dosyamı bir native wrapper’a çok daha rahat şekilde gömebilirdim, ayrıca native özellikler arasında kullanmak istediğim bir özellik olursa da birsürü phonegap eklentisi var. Bunlar işimi görürdü.
Buna rağmen React Native tercih etmemin ilk sebebi, HTML dosyasının, yani asıl uygulamanın uygulama marketlerden bağımsız bir şekilde versiyonlanmasını istememdi. Normalde eğer uygulamada güncelleme yapmam gerekirse, HTML dosyasının buildini aldıktan sonra her iki uygulama marketi için native build almam gerekiyor, buna ek olarak uygulama marketlere bu yeni binary’leri yükleyip onay sürecinden uygulamanın geçmesini (iOS’de) beklemem gerekiyor.
React Native’de bir geliştirme aracı olan Expo’yu kullanarak bu durumu ortadan kaldırdım, Expo’nun asset CDN’inde HTML dosyam versiyonlanarak uygulamayı kullanıcı her açtığında eğer kullanıcının o anda internet bağlantısı varsa ve uygulamanın yeni bir versiyonu varsa HTML dosyasının en yeni hali kullanıcının cihazına indirilecek. Bu tür bir manevra kabiliyeti 10–20 MB ek uygulama boyutuna değer. Ek olarak Expo’nun sunduğu push notification sistemini uygulamada kullanıyorum.
Yine bir diğer Expo sunuşu olan Segment’in analitik aracı ile uygulamada toplanan veriyi rahat şekilde istediğim analitik aracına aktarabiliyorum. (Benim durumumda google analytics) Buna ek olarak mixpanel gibi veriyi anlamlandırma konusunda bana yardımcı olacak birçok araca bu datayı rahat şekilde istediğim zaman aktarabilirim. Expo’nun kendi başına sunduğu bir diğer güzel özellik de uygulamaların buildlerinin çok daha hızlı ve cloud’da alınabilir olması.
Hepsine ek olarak ilerleyen zamanlarda native üzerinde yapmam gereken komplike işlemler olabilir, bu açıdan RN kullanmak benim durumun için daha mantıklıydı.
Çevirimdışı Desteği
Fitekran uygulaması online olmadığınızda tasarlandığı gibi çalışmayacaktır. Çünkü API’lara ulaşamayacak ve içerik yükleyemeyeceksiniz. Bu yüzden offline kullanıcılara bu yüzden hiç bir içerik sunmamak iyi bir tercih değil.
Buna ek olarak arayüz ögeleri lokalde (html) dosyasında olduğundan, uygulama içinde fetch fonksiyonların çalışıp çalışmadığını kontrol eden bir state tutarak bu state’i kullanıp uygulama içinde küçük bir internet bağlantısının kontrol edilmesi gerektiği bildirisi ekledim.
Bu durum kullanıcının en azından bomboş bir ekranla karşılaşmasını engelleyecek ayrıca uygulama kullanılırken internet kesildiğinde kullanıcı uygulama içinde bunu fark edebilecek.
Kullanıcı Deneyimi ve Arayüz
Fitekran’ın ziyaretçi profili büyük oranda millennial kullanıcılar olsa da, önemli bir kısmı orta yaş üstü kullanıcılar. Bu kullanıcılara uygulamanızın daha verimli bir kullanım deneyimi sunmak çok önemli. Bu tür kullanıcılar genellikle uygulamanız ne kadar iyi ve işlerini görür olsa da, eğer kullanamazlarsa uygulamanızı terk etmektedir.
Kullanıcı deneyimi çalışmalarını, en azından Fitekran gibi küçük bir proje için sağlıklı şekilde yürütmek çok zordur. Bu yüzden bu durum için en çok kullanılan teknik popüler olan uygulamaları (özellikle aynı kategorideki) kullanıcı deneyimi olarak taklit etmek ve üzerine koymak.
Her ne kadar taklit kelimesi ucuz dursa da, insan/bilgisayar iletişimi tasarımının önemli bir prensibidir. Literatürde Baby Duck Syndrome* olarak geçen bu duruma göre;
- Kullanıcı sizin uygulamanızı kullandığı diğer uygulamalarla karşılaştırır ve bu uygulamalardaki çalışma akışını sizin uygulamanızda da bekler
- Kullanıcı önceden başka bir uygulamada görmediği çok farklı bir özelliği uygulamanızda verimli olarak kullanamazsa bunu sizin uygulamanız açısından negatif olarak görebilir.
Bu sendromun ilgi çekici bir çok açısı da var. Şurada hakkında güzel bir makale var.
Bunu göz önüne olarak, çok popüler bir “sağlık” uygulaması olan, ve benim de şahsen beğenerek kullandığım bir uygulama olan Nike+ Run Club arayüz elementlerinin düzenini ve yapısını rol model olarak almaya karar verdim.
NRC uygulaması’nın içinde Guided Runs bölümü tam olarak Fitekran uygulamasında istediğimiz şeye sahipti. Rehberleri kategorize etmek ve kullanıcıya yatay olarak kaydırılabilir olarak sunulacak bir arayüz tam olarak ihtiyacımız olan şeydi.
Bunun dışında NRC’nin diğer sekmeleri çok daha farklı bir yapıya sahip, bunun yerine bu yapıyı uygulamanın diğer sayfalarında da devam ettirmeyi daha uygun bulduk.
Hepsine ek olarak uygulama içerisine basit bir arama kutusu ile kullanıcılara rehberler içinde arama yapmalarını sağlamaktansa, biraz daha farklı bir yol izledik. Kendi sitemizde kullanıcıların arama kutularını istediğimiz kadar kullanmadıklarını istatistiklere göre fark ettik. Buna göre siteye uğrayan kullanıcıların sadece %2'si arama kutusunu kullanıyor. Fakat arama yapan kullanıcıların sitede durma süresi de yapmayanlara göre çok daha fazla.
Amacımızın önceden kullanıcıyı daha fazla rehber ile bir araya getirmek ve uygulamada kalma süresini arttırmak olduğundan bahsetmiştik. Bunun için çok basit bir chat botu arayüzü oluşturup kullanıcılardan soru-cevap şeklinde ne tür bir rehberin onlara uygun olacağını belirleyerek kullanıcının okumak isteyeceği rehberleri listeliyoruz.
Burada ek olarak kullanıcı ile konuşan persona’nın da Dr. Can olduğundan bahsetmek gerekiyor. Bunun da kullanıcıların bu özelliğe ilgisini arttırdığı bir gerçek.
Teknik Zorluklar
Android 5.x webview üzerinde kullandığım webpack JS kod sıkıştırıcısı için bir syntax hatası alıyordum, bunu çözdüm. Tabi bunu fark etmem biraz sıkıntılı bir süreçti. Herhangi bir android cihazına sahip olsam bile bu cihazı kullanarak hatayı görmem imkansızdı. Kısa bir araştırma sonrasında Android Studio’nun emulatörün’de 5.0.2 versiyonunu kullanan bir cihaz çalıştırdım ve bu cihazdaki tarayıcıyı Chrome’nun Developer Console’unda görebildiğimi öğrendim.
Buna göre usb ile bağladığınız bir cihazın (sanıyorum) webkit tabanlı tarayıcılarının konsol çıktılarını dinleyebiliyorsunuz. Benim durumumda bilgisayardaki emulatör’deki android tarayıcısının.
Şuan bu yazıyı yazarken aklıma gelen bir diğer çözüm ise, Chrome’un eski bir versiyonunu indirip bu tarayıcıda debug da yapabilirdim. Android 5.0.x için Chrome 39.0.0 kullanılmış.
Android 4.4.x üzerinde syntax hatası olmamasına rağmen bu tarayıcıda CSS’deki calc özelliği çalışmıyor. Bu yüzden sayfada calc özelliği kullandığım boyutlandırmalar için Javascript’te width veya height tabanında ögelere boyutları aritmatik yaparak verdim. Sorun çözüldü.
Android 4.0.x, çalışmıyor. Ne yaptıysam build aldığım halinin veya localhost’taki react projesini android 4.0.x’deki webview tarayıcısında çalıştıramadım. Zaten uğraşmadım da, çünkü kullandığım araç Expo Android 4.4.0 ve üzerini destekliyor. Her ne kadar React Native Android 4+ destekliyor olsa da.
Android ile ilgili teknik sorunlarımız devam ediyor, bildiğiniz gibi Android cihazlarında “geri butonu” gibi tutarsız bir özellik bulunuyor. Bazı kullanıcıların bildirdiği üzere bu butona tıklandığında uygulama kapanıyormuş. React native android’in geri butonuna özel olarak BackHandler isimli bir wrapper’a da sahip. Bunu kullanarak webview’a geçirdiğim bir event ile react projesinde geri tuşuna basılma durumunda navigasyonda olması gerekenleri hallettim.
Uygulamamızı hiç bir sorun olmadan Google Play’de yayınladık ve yaklaşık 2 saat sonra uygulama marketinde görünür haldeydi. Buna karşın AppStore’da uygulamayı yayınlama süreci hem uzun hem de stresliydi.
İlk kez submit ettiğimizde uygulamanın ne olduğunu ve nasıl çalıştığını anlatan çok detaylı bir İngilizce cover metni yazmış olmama rağmen, uygulama 2 gün sonra reddedildi. Nedeni, uygulama içerisinde ve market’te 3. parti bir kişinin kimliğinin kullanılması ve bu yolla marketing yapılmasıydı. Yani Dr. Can Çiftçi ile uygulamanın bağlantılı olduğunu, bu uygulamayı geliştiren kişilerin Can’ın iznine sahip olduğunu kanıtlamamızı istediler.
Ben de Can’dan kimliği ve yanında bir kağıda “Hello appstore review team” yazmasını istedim. Ek olarak fitekran.com domain ve sunucusuna erişimim olduğunu kanıtlamak için sunucuda review.txt isimli bir dosya oluşturup içerisine erişimim olduğunu belirten bir yazı yazdım. Tekrar incelemeye gönderdikten 2 gün sonra uygulama onaylandı.
İlk Hafta Sonu İndirme ve Retention Oranları
Açıkçası ilk hafta sonu çok daha büyük bir indirme sayısı bekliyordum. Buna rağmen Dr. Can ile aramızda olan bir iletişimsizlikten veya benim ilk hafta indirilme sayısının önemini yeterince kendisine iyi şekilde aktaramadığımdan dolayı kaliteli bir reklam yapamadık.
İndirme Sayıları
Buna rağmen internet sitesinde, kullanıcıların dönebileceği bölgelere bağlantılar oluşturduk, sosyal medyada Instagram, Facebook ve Twitter üzerinden paylaşımlar yaptık. En fazla dönütü beklediğim YouTube üzerinden ne yazıkki henüz paylaşım yapamadık. Buna rağmen sonuçlar iç açıcı duruyor.
İki platform toplamda yaklaşık 2bin kullanıcı indirmiş. Burada benim ilimi çeken en önemli nokta iOS’de Android’e göre daha fazla indirme olması. Neredeyse aynı fakat ortalama %70/%30 olmak üzere Android kullanıcısı bulunuyor.
Bu grafiklerde ilgi çekici bir diğer nokta Store Listing veya Product page sayfalarını görüntüleyen kullanıcıların %70'inin uygulamayı indiriyor olması. Bu değerin yüksek olması uygulama marketleri tarafından da arama sıralamasında ödüllendiriliyor olmalı.
Bu görseli incelerseniz AppStore’da kullanıcıların %59 ve %13'ü App Referrer ve Web Referrer yolu ile uygulamayı indirmiş. Bu demek oluyor ki %72lik kısım indirmesi Fitekran referansı ile gerçekleşmiş.
Buna ek olarak App Store Browse ve App Store Search (anahtar kelimeler) toplam indirmelerin %28'ini sağlamış. Bu demek oluyor ki, sadece iOS platformunda 434 yeni kişiyi Fitekran’a tanıştırmış olduk.
Aynı şekilde organik indirmeler Android için ilk hafta 170 kişi. Organik indirmesi bir kategori olan Health & Fitness kategorisinde bu bile büyük bir kazanım.
Yazıda segment.io kullanarak iki uygulamadaki analitik verilerini tek bir havuza toplayıp bu veriyi de Google Analytics’e bağladığımdan bahsetmiştim. Bu verileri kullanarak önce genel değerlere sonrasında kullanıcı tutma oranlarına göz atalım;
Bu veriler market verilerini neredeyse tutuyor. Toplam 1,979 indirmemiz var, buna rağmen uygulamayı başlatan kullanıcı sayısı toplamda 1,948. Yaklaşık 30 kullanıcı uygulamayı indirdiğinde kullanmadan silmiş veya uygulama başlangıçta hata verip açılmamış, veya Android kullanıyorsa özel bir ROM ile analitik sunucularına izin vermemiş olabilir. Bu üzücü bir durum, fakat bu kişilerin hangi cihazlara sahip olduğu veya sorunun ne olduğunu tespit edecek bir sistem düşünmedik.
Uygulamada Geçirilen Süre
Ayrıca segment’ten geçen daha ile ilgili bir sorundan dolayı session duration verisi yanlış geçiyor. Bunu segment’teki raw dataya bakarak fark ettim. Bunun yerine şuanda tek bir screen kullanıyor ve screen değişiklikleri için de event kayıtlarını kullanıyorum.
Efektif olarak uygulamada tek bir screen var ve o da “home” olarak geçiyor. Burada Ekrandaki Ortalama Süre 07dk 43sn olarak görünüyor ve bu süre kullanıcıların rehberleri de okuduğunu da düşünürsek tahmin ettiğimiz değerlerde. Şuan için kullanıcıyı uygulamada tutma süresi olarak başarılı bir sayı olduğunu düşünüyorum.
Retention
Şuan itibari ile kullanıcıyı uygulamaya tekrar getiren özelliklerin en başında nutrition değerleri ve tarifler geliyor. Bunun dışında açıkçası kullanıcının eğer yeni bir rehber eklenmiyorsa manuel olarak uygulamayı tekrar açmasının herhangi bir nedeni yok gibi duruyor.
Şimdiye kadar sadece 1 kez uygulama üzerinden push notification gönderdik. Bunu da 2. gün yapmıştık. Grafikte ilk gün indirenler için fark edilir bir retention 2. günde görünüyor.
Tüm buna ek olarak indiren kullanıcıların %20'sinin 2. gün de uygulamaya girmiş olması, kullanıcıya herhangi bir incentive vermemiş olmamıza rağmen güzel bir değer, tabi ben şahsen bu değerin yeni içerikleri bildirim olarak göndermeye düzenli şekilde başladığımızda çok daha artacağını düşünüyorum.
Gelin bu değerleri Fitekran internet sitesinin kullanıcı tutma oranı ile karşılaştıralım. Günlük ortalama %4, uygulamanın %20'sine karşın (bildirimsiz) gerçekten komik bir sayı. Bu verileri gördüğümde de başlangıçta bahsettiğim siteye kullanıcıları geri çekemiyor olma sorunumuzun büyüklüğünün farkına daha net şekilde varıyorum.
Kullanıcı Geri Bildirimleri
Hatırlarsanız uygulamayı indirenlerin %70'inin Fitekran’ın önceden takipçisi olduğunu istatistikleri yorumlayarak çıkartmıştık. Buna göre kullanıcıların uygulamayı beğenmesi açısından bir yanlılık olacak gibi duruyor. Fakat buna rağmen, ben şahsen bu kadar pozitif bir dönüş beklemiyordum.
AppStore’da 16 kişinin tamamının 5 puan vermesi, gelen güzel incelemeler ve Android’te yine büyük oranda kullanıcıların 5 puan vermesi. Buna ek olarak gelen teknik anlamda geribildirimler de gayet işlevseldi. Yayınladığımız ilk gün kullanıcıların karşılaştığı sorunları hemen çözüp yeni client versiyonunu kullanıcılar update yapmasına gerek kalmadan cloud’a pushladık. Bu durumdan yine pozitif etkilenenler de vardı.
Sonuç
Eğer ürünüzü (içeriğinizi) verimli şekilde monetize etmek istiyorsanız kullanıcılara içeriği veya ürünü her alanda ulaşılabilir hale getirin. Her kullanıcının yoğurt yeme tarzı birbirinden farklıdır, kimseye kaşıkla veya çatalla yemesi konusunda baskı yapmayın.
Eğer içeriğinizi şuanda sadece internet sitesinde kullanıcılarınız ile buluşturuyorsanız, mobil uygulama marketlerinde kitlenize ek, sitenizi hiç duymamış %30'luk bir kitle sizi bekliyor.
2 haftada bir uygulamanın back-end API, front-end, arayüz tasarımı, kullanıcı deneyimi tasarımı, marketing ve istatistik yorumlama tek bir kişi tarafından (ek olarak Dr. Can’ın uygulama kurgusu ile birlikte) yapılabilir, kendinizi tek bir alana sınırlamanız gerekmiyor!
Fitekran uygulamasına göz atmayı unutmayın!
—
Ayrıca konu ile çok yakından alakası olmamasına rağmen ilgisini çekebilecekler için front-end ile alakadar yazdığım kitaplara göz atmayı unutmayın. Özellikle başlangıç seviyesi için ilk kitap* incelenebilir.
