Daha iyi kullanıcı deneyimleri sunabilmek için mobil ekiplerin mobil uygulamalarında izlemesi gereken temel performans ölçümleri hakkında bilgi edinin. En iyi deneyimleri oluşturmak için mühendislerin mevcut en iyi verilere ihtiyacı vardır. Mobil cihazlar, cihaz türlerini, farklı işletim sistemlerini ve bağlantıları içeren değişkenlerden sadece birkaçı ile bu zorluğu daha da karmaşık hale getiriyor. Mobil uygulamanızın sağlığına, performansına ve kararlılığına ilişkin farklı düzeylerde görünürlük sunan araçların sayısının artmasıyla, tam olarak hangi ölçümleri izlemeniz gerektiğini bilmek zor olabilir. Bu gönderide, izlemeniz gereken en önemli performans ölçümlerini ve bunların, daha iyi mobil deneyimler oluşturabilmeniz için sorunların temel nedenine daha hızlı ulaşmanıza nasıl yardımcı olacağını ana hatlarıyla açıklayacağız. 1. Başlatma zamanı Mobil kullanıcılar genellikle uygulamalarını hareket halindeyken kontrol ederler ve anlık sonuçlara alışkındırlar. Bu nedenle oturup uygulamanın yüklenmesini beklemeyecekler. Örneğin, Uber uygulamasının yüklenmesi çok uzun sürerse kullanıcı muhtemelen bunun yerine Lyft uygulamasına geçecektir. Ayrıca, Uber uygulamasında kötü, Lyft uygulamasında ise iyi bir deneyime sahip olan kullanıcıların sadık bir Lyft kullanıcısı olma olasılıkları çok daha yüksektir. Artık yalnızca o kullanıcının oturumundan gelir kaybetmekle kalmadınız, aynı zamanda edinme ve kayıp başına maliyetiniz de arttı; söz konusu müşterinin şirkete getirebileceği LTV'den bahsetmeye bile gerek yok. Bu nedenle, başarısı için çok önemlidir. uygulamanızın başlatma süresinin kullanıcı beklentilerini karşılamasını sağlamak, Bununla birlikte, mobil ekibin yalnızca erişimi varsa, muhtemelen önemli değişiklikleri kaçırır ve proaktif olmak yerine tepkisel olarak yanıt verir. ortalama başlatma süresine Örneğin, bir şirketin uygulamasını yeni bir pazara sunduğunu ve genel geri bildirimin olumsuz olduğunu varsayalım. Ortalama başlatma süresi, uygulamanın lansman öncesine göre birkaç milisaniye daha uzun olduğunu gösteriyor ancak lansman sırasında önemli ölçüde yavaşladığını göstermiyor. Yani başka bir sorun olmalı değil mi? Ne yazık ki, yeni pazardaki kullanıcıların yüzdesi genel kullanıcı tabanının yalnızca bir kısmı olduğundan, yeni pazardaki çok düşük bir başlangıç süresinin bile toplam kullanıcı tabanının başlangıç süresini yalnızca minimum düzeyde etkileyeceği mantıklıdır. Bunun yerine ekibin, başlangıç süresinin işi nasıl etkilediğini daha iyi anlamak için verileri bölümlere ayırabilmesi gerekiyor. Örneğin, yüksek değere sahip kullanıcılar yavaş başlangıçlardan nasıl etkileniyor? Yeni bir pazardaki kullanıcılar daha kötü performans mı yaşıyor? Bazı cihazlarda başlatma işlemi daha yavaş mı oluyor? Bu veriler, şirketinizin durumun kontrolünü tekrar eline almasını sağlar ve gelirinizi etkileyen zamana duyarlı senaryolarda tahminleri ortadan kaldırır. Daha fazla bilgi edinmek için anlatan e-Kitabımıza göz atın. mobil uygulama başlatma süresinin nasıl iyileştirilebileceğini 2. Kilitlenme oranı müşterileri kızdırmanın kesin bir yoludur ve bunun iyi bir nedeni vardır! Bu aslında bir müşterinin fiziksel bir mağazaya girmesine ve personelin onu alışverişin yarısında kapıdan dışarı atmasına eşdeğerdir. Çökmeler Bu, iki nedenden dolayı şirketin markası açısından önemli bir sorundur: Müşterilerin zamanlarına saygısızlık edildiğini düşünmesi . markanızın itibarına zarar verir Müşteriler işlemlerini anında tamamlayamadıkları için bu durum gelirinize zarar verir ve bir rakibe geçmeye karar verirse o müşterinin yaşam boyu değerini kaybedersiniz. İşte bir çöküşün doğrudan gelir kaybına yol açtığı çeşitli sektörlerden sadece birkaç örnek: Bir e-ticaret uygulaması ödeme sırasında çökerse müşteri satın alma işlemini gerçekleştiremeyecek ve muhtemelen geri dönmeyecektir. E-ticaret Uygulamaları: : Canlı bir etkinlik sırasında bir POS sistemi çökerse, bu canlı müşterilerden hiçbiri alışveriş yapamayacak veya mekana giremeyecektir. POS Sistemleri : Diş fırçası gibi akıllı bir cihaz kurulum işlemi sırasında bozulursa müşterinin ürünü iade etme olasılığı çok yüksektir. Akıllı Cihaz Uygulamaları Ancak ortalama kilitlenme oranını takip etmek iyi bir başlangıç olsa da, . kilitlenmelerin işletmenizi nasıl etkilediğini anlamak yeterli değildir Örneğin, mevcut kilitlenme oranı yalnızca %0,5 ise daha derinlemesine incelemeye gerek kalmayabilir. Ancak, meydana gelen tüm çökmeler ödeme ekranında meydana gelirse ne olur? Bu küçük yüzde, işletmeyi önemli miktarda gelirden mahrum bırakıyor olabilir. Bu nedenle, temel metrik rakamlara bakmanın yanı sıra, kaza oranındaki modelleri gösteren verilere sahip olmak da önemlidir. Özellikle uygulamanızdaki çeşitli yüksek değerli alanların performansı nasıl? Hangi cihazlar en çok çökme yaşama eğilimindedir? Uygulamanın yüksek değere sahip kullanıcılar açısından performansı nasıl? Kaza oranlarının özellikle düşük olduğu bölgeler var mı? Eğer öyleyse, uygulamanın bu bölgelerden düzeltilmesi mi yoksa kaldırılması mı gerekiyor? Ekibiniz kilitlenme ayrıntılarını bölümlere ayırarak sorunları düzeltmeye daha iyi öncelik verebilir. 3. ANR oranı genellikle donma veya aksaklık olarak tanımlanır. Yanıt Vermeyen Uygulama (ANR) hataları Temel olarak, ana iş parçacığı engellenirse uygulamalar etkili bir şekilde çalışamaz. Bu nedenle kullanıcı devam edemez ve bu durum işiniz üzerinde büyük bir etkiye sahip olabilir. Örneğin, birlikte çalıştığımız bir perakendecinin ANR'lerle ilgili bir sorunu vardı. Bu sorun, başlangıç sürelerinin neredeyse %60 artmasına neden oluyordu ve bu da yılda 6,5 milyon dolarlık tahmini gelir kaybına yol açıyordu. Mühendislik ekibi, sorunu hızlı bir şekilde çözebildi ve kaybedilen geliri geri kazanabildi. doğru verilerle ANR'ler, gelirin ötesinde ve uygulamanın yeni müşteriler için daha az görünür olmasına neden olabilir. bir uygulamanın Google Play Store'daki sıralamasını da olumsuz yönde etkileyebilir ANR'leri etkili bir şekilde izlemek için yığın izlemesine bakabilir ve kullanıcıların soruna nasıl yanıt verdiğini görebilirsiniz. Mobil ekip buradan, çeşitli eşiklerde kaç kişinin ayrıldığına, yüksek değere sahip kullanıcıların en çok nerede etkilendiğine ve ANR'lerden en çok hangi cihaz türlerinin ve ekranların etkilendiğine bağlı olarak ilk olarak neyin düzeltileceğine öncelik verebilir. Daha fazla bilgi edinmek için göz atın. ANR'ler gibi Android kilitlenmelerini araştırmaya ilişkin bu yayına 4. Bölge metrikleri Farklı bölgelerdeki kullanıcıların farklı cihazlara ve farklı bağlantılara sahip olması nedeniyle bölge metriklerinin takibi de oldukça önemlidir. Bu, çeşitli nedenlerden dolayı iş üzerinde büyük bir etkiye sahip olabilir. Birincisi, bölgelerin bir işletmenin kârlılığı açısından önemleri farklılık gösterir. Örneğin, kullanıcılarınızın yalnızca bir kısmı Singapur'da olabilir ancak toplam yıllık gelirinizin büyük bir bölümünü oluşturabilirler. Bu nedenle, bölge metriklerinin ayrıntılı düzeyde kontrol edilmesi, özellikle yüksek değere sahip kullanıcılar için uygulamayı iyileştirme fırsatlarını ön plana çıkaracaktır. Yeni bir bölgeyi başlatırken segmentlere ayrılmış bölge metriklerini izlemek de önemlidir. Örneğin, Avustralya'ya genişlediğinizi ancak bu coğrafi bölgenin lansman sırasında tüm kullanıcıların yalnızca %5'ini oluşturduğunu varsayalım. Bu durumda, medyan/ortalama metrikleri, ekibin performansı etkili bir şekilde takip etmesine yetecek kadar etkilemeyecektir. Kültürel farklılıkları hesaba katmak da önemlidir ve bölgeye özgü ölçümler sağlayan bir araçla ekip, uygulamanın belirli yönlerini yalnızca o bölge için test edebilir. Örneğin, Amerika Birleşik Devletleri'nde iyi dönüşüm sağlayan bir e-ticaret ödeme ekranı Dubai'de iyi dönüşüm sağlamayabilir. Ayrıca ayrıntılı bölge ölçümleri, yeni özelliklerin yavaş yavaş kullanıma sunulmasını kolaylaştırır. Örneğin ekip yeni bir özelliği daha küçük bir bölgede kullanıma sunabilir ve nasıl performans gösterdiğini görebilir. İyi performans gösteriyorsa, daha yüksek değere sahip kullanıcıların bulunduğu daha fazla bölgeye sunun. Bu veriler ekibinize aşağıdaki gibi kritik soruları yanıtlama konusunda rehberlik edebilir: Bu bölge için yeni bir uygulama geliştirmemiz gerekiyor mu? Bu yeni lansmanın performansı diğer bölgelerdeki lansmanlarla karşılaştırıldığında nasıl? En sorunlu bölgeler hangileri? Peki onlara hizmet etmeyi tamamen bırakmalı mıyız? Uygulamanın çeşitli kritik alanları bir bölgede diğerine göre nasıl performans gösteriyor? 5. Oturum süresi Dikkat edilmesi gereken bir diğer önemli ölçüm, kullanıcıların uygulamanızı ne kadar süreyle kullandığını gösterdiği için oturum süresidir. Ortalama oturum süresi bir hafta içinde önemli ölçüde değişiyorsa bu, uygulamada bir sorun olduğuna dair oldukça iyi bir ipucudur. Örneğin, bir oyun uygulamanız varsa ve ortalama oturum süresinin 15 dakikadan 5 dakikaya düştüğünü fark ederseniz, kullanıcıların kötü bir deneyim yaşaması ihtimali yüksektir. Bu ipucuyla aşağıdaki gibi sorular sorabilirsiniz: Kötü bir sürüm mü gönderdik? Kullanıcılar uygulamayla daha mı az ilgileniyor? Oturum süresindeki değişikliği açıklamaya yardımcı olabilecek başka bir ölçümde buna karşılık gelen bir değişiklik var mı? Oturum süresinin takip edilmesi ayrıca ekibin etkilenen bireysel oturumlar arasındaki kalıpları araştırmasına ve sorunların temel nedenini keşfetmesine olanak tanır. Mobil mühendisler, oturum süresini diğer ölçümlerle paralel olarak analiz ederek, hangi sorunların kullanıcılar için en rahatsız edici olduğuna dair daha net bir resim çizebilir. Örneğin, bir e-ticaret mağazasında, ürünlerin ana kaydırma akışında, daha kısa bir oturum süresiyle güçlü bir şekilde ilişkili olan bir OOM sorunu olabilirken, başka bir ekrandaki yavaş ağ çağrılarının, oturum süresiyle çok az veya hiç ilişkisi yoktur. Bu nedenle, oturum süresinin takip edilmesi, kullanıcı katılımının azaldığını doğrudan ortaya çıkaracağından, ilk önce hangi sorunların çözülmesi gerektiğine öncelik vermenin harika bir yoludur. 6. Bırakma/elde tutma oranı Yeni bir müşteri edinmenin maliyeti, mevcut müşteriyi mutlu etmekten çok daha fazladır ve mobil uygulama kullanıcılarındaki kaybın başlıca nedeni, kötü kullanıcı deneyimidir. Yeni bir uygulamanın indirilmesi yalnızca birkaç saniye sürer; bu nedenle, bir uygulamanın deneyimi kullanıcıyı birkaç saniyeden fazla zaman alacak şekilde rahatsız ediyorsa, onların orada kalmasını beklemeyin. Bu nedenle, yalnızca genel kullanıcıyı kaybetme ve elde tutma oranını değil, aynı zamanda kullanıcı tabanı segmentlerinin (cihazlara, bağlantılara, bölgelere vb. göre) kaybetme ve elde tutma oranlarını da izleyin. Bu, elde tutmayı iyileştirmek ve önceliklendirmek için çeşitli fırsatları aydınlatacaktır. Örneğin, belirli bir bölgede aboneyi kaybetme oranının çok yüksek olmasına rağmen, o bölgede az sayıda yüksek değere sahip kullanıcıya sahip olduğunu görebilirsiniz. Bu nedenle, mühendislik kaynaklarını daha büyük iş sonuçlarına dönüşecekleri başka bir yere yatırmaya karar verebilirsiniz. Kaybı ve elde tutma oranını izlemek, kullanıcıların yeni sürümlere ve çeşitli denemelere nasıl tepki verdiğini anlamanın da harika bir yoludur. Yüksek kayıp ile yeni bir özellik güncellemesi arasında bir korelasyon varsa bu, ekibin bu özellik güncellemesini geri alması gerektiğine dair güçlü bir göstergedir. Ayrıntılı veriler, ekibin güncellemenin sunulduğu çeşitli segmentlerdeki (belirli bölgeler veya cihazlar gibi) dalgalanmayı izlemesine olanak tanıyacak. Bölümlere ayrılmış veriler olmadan çeşitli özellik güncellemelerinin küçük test grupları üzerindeki etkisini görmek zor olacaktır. Bu nedenle, özellik yalnızca büyük bir kullanıcı grubuna sunulduğunda (ve muhtemelen pek çok aylık aktif kullanıcının ayrılmasına neden olduğunda), özelliğin kullanıma sunulmasının erken olduğu anlaşılacaktır. 7. Kullanıcı sonlandırma oranı Bazı kullanıcı sonlandırma işlemleri, kullanıcının telefonunu dağıtmasından başka bir şey olmasa da, çoğu sonlandırma, uygulamanın donması nedeniyle gerçekleşir ve kullanıcının yukarı kaydırıp oturumu sonlandırmak dışında seçeneği yoktur. Elbette, oturumunu sonlandırmak zorunda kalan bir kullanıcı muhtemelen hoşnutsuz olacak ve bunun yerine bir rakibin uygulamasını seçecektir. Bunu önlemek için, ortalama kullanıcı sonlandırma oranının izlenmesi, aşağıdakiler de dahil olmak üzere, aboneliği kaybetmeye yol açabilecek potansiyel sorunların mükemmel bir göstergesidir: Başarısız reklam yüklemeleri donmalara neden oluyor Yavaş veya bozuk kullanıcı akışları Başarısız satın alma işlemleri Oturum açma hatalarına neden olan sunucu kesintileri Yavaşlamalara neden olan aşırı medya yükleme Ortalama kullanıcı sonlandırma oranlarına ilişkin genel bir bakış sunmanın yanı sıra, mobil ekiplerin her kötü kullanıcı deneyiminin kaynağını bilmesi gerekir. Bu nedenle, Embrace'e yerleştirdiğimiz temel özelliklerden biri görebilme yeteneğidir. , hangi ekranların hayal kırıklığına uğramış kullanıcıların uygulamanızı terk etmesine neden olduğunu Bu nedenle, mühendisler sonlandırmaların nerede gerçekleştiğini tahmin ederken değerli zamanınızı boşa harcamak ve satışları kaybetmek yerine, mobil ekip, sorunu olabildiğince verimli bir şekilde çözebilmeleri için derhal soruna yönlendirilir. 8. Anahtar kullanıcı eylemlerinin zamanlaması Uygulamanızda muhtemelen her zaman %100 çalışması gereken birkaç kullanıcı işlemi vardır. Örneğin, bir ofis anahtarsız giriş olanağı sunuyorsa bu özelliğin her zaman çalışması gerekir. Aksi takdirde kişiler ek destek çağırmadan ofise giremeyebilirler. Bu nedenle, birkaç önemli kullanıcı eylemini seçin ve bunları mobil ekibin izlediği performans ölçümleri listesine ekleyin. Çoğu durumda müşteri incelemeleri, uygulamada sorunla nerede karşılaştıklarını söylemez; dolayısıyla belirli kullanıcı işlemlerini takip etmek, normalde hemen fark edilmeyen sorunları yakalamanın harika bir yoludur. Bu aynı zamanda aşağıdaki gibi soruları yanıtlamanıza da yardımcı olur: Uygulamanın bu kritik alanlarında kaç kullanıcı sorun yaşıyor? Uygulamanın belirli alanlarındaki sorunlar ile uygulamayı kullanmayı bırakma arasında doğrudan bir ilişki var mı? Kullanıcılar uygulamadan vazgeçip vazgeçmeden önce ne kadar süre deneyecek? Örneğin, müşterilerimizden biri, tüm satın alma denemelerinin yaklaşık %1'inin satın alma başarısızlığıyla sonuçlandığını fark etti. Bununla birlikte, ilişkili ağ çağrılarının her ikisi de başarıyla çözümleniyordu, dolayısıyla incelenecek belirgin bir hata yoktu. Bu nedenle, bir müşterinin satın alma işlemi yapacağı anı tam olarak izlemeye başladılar ve satın alma girişimlerinin %1'inde iki ağ çağrısının hatalı gerçekleştiğini ve bunun da satın alma işleminin başarısız olmasına neden olduğunu buldular. Müşteriler bu sorundan şikayetçi olsa da mobil ekip, etkilenen oturumlardaki tüm olayların zamanlamasını, sonucunu ve sırasını bilmeden asıl nedeni tam olarak belirleyemedi. Yüksek kaliteli kullanıcı deneyimi verileri, toplam satışlarının %1'ini geri kazanmalarına yardımcı olmak açısından hayati önem taşıyordu. Yıllık satışları 10 milyon dolar olan bir şirket için bu, aksi takdirde her yıl kaybedilecek olan 100.000 dolardır! 9. Bellek kullanımı Olası bellek sızıntılarını belirlemek için uygulamanızın bellek tüketimini izlemek önemlidir. Uygulamanızın bellek kullanımının verimliliği, kullanıcı deneyiminizin ne kadar duyarlı olduğuyla doğrudan ilgilidir. Bu nedenle bellek kullanımını izlemek ve optimize etmek, kusursuz bir kullanıcı deneyimi sunmada çok önemli bir rol oynar. Uygulamanızın bellek kullanımıyla ilgili sorunları şu şekilde önleyebilirsiniz: Kod tabanınızı optimize etmek ve belleğin istenmeden tutulduğu alanları belirlemek, bellek kullanımının artmasına neden olur. Uygulamanızın bellek tüketimini düzenli olarak takip ederek yeni sürümlerden sonra değişiklikleri not edin. Büyük görüntülerin yüklenmesi veya büyük dosyaların işlenmesi gibi yoğun bellek kullanan işlemleri dikkatli bir şekilde izleyin ve anormal ani artışlar veya sürekli yüksek bellek kullanımı için oluşturun. uyarılar Uygulamanızın bellek tüketimine ilişkin ince ayarlı bir strateji, kullanıcılarınızın seveceği hızlı yanıt veren, kararlı ve etkili uygulamalar oluşturur. 10. Bağlantı Mobil uygulamalar, 3G, 4G, 5G, Wi-Fi ve bazen sınırlı veya dengesiz bağlantı dahil olmak üzere değişen sahip çeşitli ortamlarda çalışır. ağ koşullarına Mükemmel kullanıcı deneyimleri yaratmak için bu değişken koşulların ortaya çıkardığı zorlukların farkına varılmasının önemli olmasının nedeni budur. Zayıf ağ performansının göstergeleri şunları içerir: Gecikme ve yavaş yanıt süreleri. Bant Genişliği Kullanımı. Verimsiz API çağrıları. Cihaza özel çevrimdışı yetenekler. Örneğin , çiftçilerin ve ziraat uzmanlarının meslektaşları ve meslektaşlarıyla birlikte sahadayken bulgularını belgelemelerine olanak tanıyan bir tarım uygulamasıdır. Farm Dog Ağ yanıt süreleri son derece yavaş olduğunda ve cihazlar bağlı olup olmadıklarını belirleyemediğinde uygulama sıklıkla çöküyordu. Google Haritalar'ın yanıt sürelerinin yalnızca birkaç saniye olması gerekirken 18-22 saniye arasında olduğunu fark ettiler. Uygun araçlar olmadan, kötü bir ağ bağlantısını simüle etmek için bir proxy kullanarak sorunları çözmek için karmaşık geçici çözümler kullanmaları gerekir. Bununla birlikte, daha yüksek doğruluktaki verilerle, kullanıcıların sahada sahip olduğu tam koşulları görebilirler: Cihaz türleri, uygulama sürümleri, Wi-Fi ve hücresel ağ üzerinden ağ aramaları. Sorunlu yolları belirlemek için ortak alanlardaki 4xx ve 5xx hata eğilimlerine ilişkin içgörü. Kullanıcılarınızın uygulamayı başlatmasını, önemli içeriği yüklemesini veya önemli işlemleri tamamlamasını engelleyen bozuk uç noktalar. İstemci tarafından yapılan her ağ çağrısının süresi, gizli gecikme noktalarını ortaya çıkarır. Bu bilgilerle donanmış olan Farm Dog ekibi, kullanıcılarının karşılaştığı sorunları simüle etti, sorunlu koşulları kolayca tespit etti ve düzeltti. Başarı için mobil ekibinizi kurun Mobil deneyimlere önem veriyorsanız ekibinizin yukarıda bahsedilen tüm metrikleri görmesini sağlayacak verilere ihtiyacınız var. Embrace, size tam olarak bu verileri sağlayarak daha iyi mobil deneyimler oluşturmanıza yardımcı olur, mühendislerinizin daha verimli olmasını ve sıkıcı işlerle daha az batağa saplanmasını sağlar. Kullanıcılara göre uygulamadaki önemli sorunlar hakkında bilgi edinmek için hakkında daha fazla bilgi edinin ve raporunu indirin. Embrace Mobil Deneyimin Durumu Yazar: Colin Contreary da yayınlandı. Burada
