Kullanıcılar Uygulamayı Neden Siler? İlk 7 Günde Elde Tutma Rehberi

Kullanıcı bir uygulamayı indirirken bir sorunu çözmeyi umar. Ancak telefonunda yer açarken ya da ilk deneyimde hayal kırıklığı yaşadığında, silme kararı birkaç saniye sürer. Kullanıcı size neden gittiğini söylemez; geriye yalnız düşen bir grafik kalır. Yani silme, tek bir hatadan çok küçük sürtünmelerin birikmesinden doğar.

Talha Aslan ve ekibi olarak mobil projelerde gördüğümüz tablo şudur: silme nedenlerinin büyük kısmı tasarım ve yayın sürecinde önceden fark edilebilir. Aşağıdaki başlıklar en sık rastladığımız nedenleri sırayla ele alıyor:

• Uygulamayı denemeden önce hesap açmaya zorlamak.
• İlk açılışta bildirim, konum, kamera ve rehber izinlerini peş peşe istemek.
• Kullanıcıya ilk dakikalarda somut bir sonuç gösterememek.
• Çökme, donma ve uzun yükleme ekranları.
• Değer taşımayan, sık ve genel bildirimler.
• Telefonu yoran boyut, pil ve veri tüketimi.

Elde tutma (retention) nedir, 1., 7. ve 30. gün nasıl okunur?

Elde tutma (İngilizcede retention), belirli bir günde uygulamayı ilk kez açan kullanıcılardan kaçının sonraki günlerde geri döndüğünü gösteren orandır. Örneğin 1. gün elde tutma, kurulumdan bir gün sonra uygulamayı yeniden açan kullanıcıların oranını anlatır. 7. gün ve 30. gün değerleri de aynı mantıkla hesaplanır.

Bu üç nokta farklı soruları cevaplar. 1. gün, ilk izlenimin işe yarayıp yaramadığını söyler. 7. gün, uygulamanın bir alışkanlık başlatıp başlatmadığını gösterir. 30. gün ise ürünün kalıcı bir ihtiyaca cevap verip vermediğini ortaya koyar. Dolayısıyla tek bir rakama bakmak yerine eğrinin şekline bakmanız gerekir.

Örnek hesap: Pazartesi günü 1.000 kişi uygulamayı ilk kez açtı. Salı günü bu kişilerden 300'ü geri döndüyse 1. gün elde tutma yüzde 30 olur. Ertesi pazartesi 120 kişi döndüyse 7. gün değeri yüzde 12'dir. Bu rakamlar yalnız hesabın mantığını gösteren örnek değerlerdir; sektör ortalaması ya da hedef değildir.

Eğri hızlı düşüp sonra yataylaşıyorsa sağlıklı bir çekirdek kitleniz var demektir. Eğri hiç yataylaşmıyorsa sorun büyük olasılıkla ürünün temel değerindedir, yani yalnız arayüz düzeltmesi yetmez.

Neden ilk 7 gün belirleyicidir?

İlk 7 gün, kullanıcının uygulamayı hayatına yerleştirip yerleştirmeyeceğine karar verdiği dönemdir. Bu sürede kullanıcı uygulamayı birkaç kez açar, bir iki temel işlemi dener ve beklentisini karşılayıp karşılamadığını tartar. Bu yüzden sonraki haftalarda kalan kitlenin büyük kısmı, ilk haftayı atlatan kişilerden oluşur.

Ayrıca ilk hafta, edinme maliyetinin geri dönüp dönmeyeceğini de belirler. Reklamla getirdiğiniz kullanıcı ilk gün siliyorsa, o reklam harcaması fiilen boşa gider. Öte yandan ilk haftasını tamamlayan kullanıcı, satın alma, abonelik ya da randevu gibi asıl hedef işlemlere çok daha yakındır.

Bu haftada dikkat etmeniz gereken üç an vardır:

1. İlk açılış: kullanıcı ilk ekranda ne yapacağını anlıyor mu?
2. Değer anı: kullanıcı ilk somut sonucu ne kadar sürede görüyor?
3. İlk geri dönüş: kullanıcıyı ikinci kez uygulamaya getiren bir neden var mı?

Bu üç anı tasarlamadan yayına çıkan bir uygulama, reklam bütçesini sızdıran bir kova gibi davranır. Kısacası büyümeyi konuşmadan önce ilk haftayı sağlamlaştırmanız gerekir.

Zorunlu ve uzun kayıt akışı kullanıcıyı nasıl kaçırır?

Kayıt ekranı, kullanıcının uygulamayı tanımadan önce bir bedel ödemesi demektir. Kullanıcı daha hiçbir değer görmeden ad, e-posta, telefon, doğrulama kodu ve şifre girmek zorunda kalınca, birçoğu o noktada vazgeçer. Özellikle mağaza sayfasından merakla gelen kullanıcı için bu engel ağırdır.

Apple'ın App Store İnceleme Yönergeleri 5.1.1 maddesi bu konuda açık bir ilke koyar: uygulamanız önemli hesap tabanlı özellikler içermiyorsa, kullanıcıların giriş yapmadan kullanabilmesine izin vermelisiniz. Aynı madde, uygulama hesap oluşturmayı destekliyorsa hesap silmenin de uygulama içinden sunulmasını ister. Yani kayıt hem kullanıcı deneyimi hem de mağaza uyumu konusudur.

Pratikte şu düzeni öneriyoruz:

• Kullanıcıya önce göz atma, arama ya da deneme imkânı verin.
• Hesabı yalnız gerçekten gerektiren adımda isteyin: sepeti kaydetme, randevu alma, ilerlemeyi saklama gibi.
• Formu en kısa hale getirin; sonradan tamamlanabilecek bilgileri ilk ekranda istemeyin.
• Kayıt sonrasında kullanıcıyı boş bir ekrana değil, kaldığı işe geri götürün.

Akışın ayrıntılı tasarımı için uygulama onboarding ekranı tasarımı rehberimize göz atabilirsiniz.

İzin bombardımanı neden silmeye yol açar?

İlk açılışta bildirim, konum, kamera ve kişiler izinlerini art arda isteyen uygulama, kullanıcıya güvensizlik hissi verir. Kullanıcı neden bu kadar erişim istendiğini anlamaz ve en kolay çözümü seçer: uygulamayı siler. Üstelik verilmeyen izinler sonradan geri kazanılması zor kararlara dönüşür.

Android geliştirici belgelerindeki çalışma zamanı izinleri rehberi, izni bağlam içinde, yani kullanıcı ilgili özelliği kullanmaya başladığında istemenizi önerir. Aynı belgeye göre kullanıcı bir izni uygulamanın kurulu kaldığı süre içinde birden fazla kez reddederse, sistem izin penceresi tekrar gösterilmez ve bu karar kalıcı ret sayılır. Bu nedenle izni yanlış anda istemek, o özelliği fiilen kaybetmek anlamına gelebilir.

Apple tarafında da benzer bir ilke var. Yönergelerin 5.1.1 maddesi, uygulamaların kullanıcının izin ayarlarına saygı göstermesini ve kullanıcıyı gereksiz veri erişimine zorlamamasını ister. Ayrıca kullanıcı konum paylaşmazsa adresi elle girme gibi bir alternatif sunmanızı tavsiye eder.

Uygulanabilir kural basittir: her izni, ihtiyacın doğduğu ekranda, kısa bir açıklamayla isteyin. Kullanıcı reddederse uygulamanın geri kalanını açık tutun ve yalnız o özelliği devre dışı bırakın. Bildirim izninin zamanlaması için push bildirim izni ne zaman istenmeli yazımızda adım adım bir akış anlattık.

Uygulama ilk oturumda değerini gösteremezse ne olur?

Kullanıcı ilk oturumda "bu uygulama işime yarıyor" diyebileceği bir an yaşamazsa, ikinci kez açma nedeni bulamaz. Ürün ekiplerinde bu ana sıkça "aha anı" denir. Bu an bir yemek uygulamasında ilk siparişin kolayca verilmesi, bir randevu uygulamasında ilk boş saatin bulunması, bir not uygulamasında ilk notun kaydedilmesidir.

Örnek senaryo: Bir kuaför zinciri randevu uygulaması yayınlıyor. İlk ekranda kampanya slaytları, ardından üyelik formu, ardından şube seçimi geliyor. Kullanıcı boş saati görmek için dört ekran geçmek zorunda kalıyor. Oysa ilk ekranda en yakın şubenin bugünkü boş saatleri görünse, kullanıcı değeri ilk on saniyede yaşardı.

İlk değer anını kısaltmak için şunları yapabilirsiniz:

1. Kullanıcının uygulamayı indirme nedenini tek cümleyle yazın.
2. O nedene ulaşmak için gereken ekranları sayın.
3. Zorunlu olmayan her ekranı sonraya taşıyın ya da kaldırın.
4. Boş ekranlar yerine örnek içerik, hazır şablon ya da yakın sonuç gösterin.

Kısacası ilk oturumun amacı tanıtım yapmak değil, kullanıcıya küçük ama gerçek bir başarı yaşatmaktır.

Çökme ve donma silme kararını ne kadar hızlandırır?

Çökme, kullanıcının sabrını en hızlı tüketen sorundur. Kullanıcı bir işlemin ortasında uygulamadan atıldığında, ikinci denemede aynı şeyin olacağını varsayar. Özellikle ödeme, kayıt ya da form gönderimi sırasında yaşanan çökme, güveni doğrudan sarsar.

Google Play bu konuyu yalnız kullanıcı deneyimi olarak görmez. Android vitals belgesine göre kullanıcı tarafından algılanan çökme oranı ve uygulama yanıt vermiyor (ANR) oranı için hem genel hem cihaz modeli bazında kötü davranış eşikleri vardır. Uygulama bu eşikleri aşarsa Play, uygulamanın görünürlüğünü azaltabilir ve mağaza sayfasında kullanıcılara uyarı gösterebilir. Eşiklerin güncel değerini resmi sayfadan kontrol etmenizi öneririz.

Apple da yönergelerin 2.1 maddesinde çöken ya da bariz teknik sorun gösteren uygulamaları reddedeceğini belirtir. Dolayısıyla kararlılık, hem incelemeden geçmenin hem de mağazada görünür kalmanın şartıdır.

İlk haftada çökmeleri izlemek için bir hata raporlama aracı kurun, en çok kullanıcıyı etkileyen hata kümesinden başlayın ve düşük donanımlı cihazlarda test edin. Ölçüm ve eşik ayrıntılarını uygulama çökme oranı ve mağaza eşikleri yazımızda ayrıca ele aldık.

Bildirim aşırılığı kullanıcıyı nasıl yorar?

Bildirim, doğru kullanıldığında kullanıcıyı geri getiren en güçlü araçtır. Ancak her gün gelen genel kampanya mesajları, kullanıcıyı önce bildirimleri kapatmaya, ardından uygulamayı silmeye iter. Kullanıcı açısından değersiz bildirim, cebindeki gürültüdür.

Apple'ın yönergelerindeki 4.5.4 maddesi, push bildirimlerin uygulamanın çalışması için zorunlu tutulmamasını ister. Aynı madde, bildirimlerin tanıtım ya da doğrudan pazarlama için kullanılabilmesini, kullanıcının uygulama arayüzündeki onay metniyle açıkça izin vermesine ve uygulama içinde bundan çıkış yolu bulunmasına bağlar. Bu nedenle pazarlama bildirimini işlem bildiriminden ayırmanız gerekir.

İlk hafta için önerdiğimiz bildirim düzeni şöyledir:

• Yalnız kullanıcının başlattığı işlemle ilgili bildirim gönderin: sipariş durumu, randevu hatırlatması, yarım kalan işlem.
• Kampanya bildirimlerini ayrı bir tercih olarak sunun ve varsayılan olarak açık tutmayın.
• Gece saatlerinde bildirim göndermeyin.
• Her bildirimin açılma ve kapatma etkisini ayrı ayrı ölçün.

Böylece bildirim, kullanıcıyı uzaklaştıran değil, geri getiren bir kanala dönüşür.

Yavaş açılış, boyut ve pil tüketimi silmeye yol açar mı?

Evet, özellikle depolama alanı sınırlı telefonlarda bu faktörler doğrudan silme nedenidir. Kullanıcı yer açmak istediğinde önce az kullandığı ve çok yer kaplayan uygulamalara bakar. İlk haftasında yeterince değer üretmemiş bir uygulama, bu temizlikte ilk gidenler arasında olur.

Açılış süresi de aynı etkiyi yaratır. Kullanıcı her açılışta uzun bir yükleme ekranı görürse, uygulamayı kullanma isteği azalır. Ayrıca arka planda gereksiz çalışan işlemler pili ve mobil veriyi tüketir; kullanıcı bunu telefon ayarlarında fark ettiğinde güven kaybı yaşar.

Bu alanda ilk adımlar şunlardır: görselleri sıkıştırın, kullanılmayan kütüphaneleri temizleyin, açılışta yalnız ilk ekran için gereken veriyi yükleyin, ağır içerikleri arka planda ve gerektiğinde indirin. Teknik seçim de burada önemlidir; örneğin tek kod tabanıyla iki platforma çıkmayı düşünüyorsanız React Native rehberimizde performans dengesini tartıştık.

Unutmayın: kullanıcı teknik ayrıntıyı görmez, yalnız yavaşlığı hisseder. Bu yüzden performansı yayın sonrası değil, geliştirme sürecinin her aşamasında ölçmelisiniz.

Kullanışsız arayüz ve küçük dokunma alanları neden kullanıcıyı bezdirir?

Arayüz hataları tek başına küçük görünür ama birikince yorgunluk yaratır. Tek elle ulaşılamayan butonlar, birbirine çok yakın dokunma alanları, okunmayan küçük yazılar ve tutarsız menüler kullanıcıyı her işlemde biraz daha zorlar. Kullanıcı sonunda aynı işi yapan daha rahat bir uygulamaya geçer.

Örneğin ana işlem butonunu ekranın üst köşesine koymak, büyük ekranlı telefonlarda başparmakla ulaşmayı zorlaştırır. Bu konuyu thumb zone (başparmak bölgesi) yazımızda örneklerle açıkladık.

Arayüz kaynaklı silmeleri azaltmak için şu kontrolleri yapabilirsiniz:

• Ana işlem her ekranda tek ve belirgin mi?
• Geri dönüş yolu her zaman aynı yerde mi?
• Hata mesajları kullanıcıya ne yapacağını söylüyor mu?
• Yazı boyutu sistem ayarına göre büyüyor mu?

Mevcut bir uygulamada bu sorunları sistemli bulmak istiyorsanız, UX audit (kullanıcı deneyimi denetimi) rehberimizdeki adımları mobil ekranlara uyarlayabilirsiniz.

Uygulama silme nedenleri ve ilk müdahaleler: karşılaştırma tablosu

Aşağıdaki tablo, uygulama silme nedenlerini belirti, ölçüm yolu ve ilk müdahale açısından yan yana koyar. Tabloyu ilk hafta toplantılarınızda kontrol listesi gibi kullanabilirsiniz.

Tablodaki her satır ayrı bir hipotezdir. Bu nedenle hepsini aynı anda değiştirmek yerine en büyük kaybın olduğu adımdan başlamanızı öneririz.

İlk 7 gün için gün gün kontrol listesi

Aşağıdaki liste, yeni bir kullanıcının ilk haftasını sizin açınızdan planlamanıza yardım eder. Gün numaraları kesin kural değil, ürününüzün kullanım sıklığına göre uyarlamanız gereken bir çerçevedir.

1. 0. gün (kurulum): giriş zorunluluğu olmadan ilk değer anına ulaştırın; yalnız gereken izni, gerektiği anda isteyin.
2. 1. gün: kullanıcının yarım bıraktığı işi hatırlatan tek ve kişisel bir mesaj gönderin; genel kampanya göndermeyin.
3. 2. gün: ikinci temel özelliği, kullanıcının ilk işlemiyle ilişkili bir bağlamda gösterin.
4. 3. gün: profil tamamlama ya da tercih seçimi gibi kişiselleştirme adımını şimdi önerin.
5. 4. ve 5. gün: kullanıcının alışkanlık kurmasına yardım edecek bir hatırlatma ya da içerik sunun.
6. 6. gün: memnuniyet sinyali gelen kullanıcıdan uygun anda geri bildirim isteyin.
7. 7. gün: kohort verisine bakın, en büyük kaybın olduğu adımı seçin ve bir sonraki sürümde onu düzeltin.

Örnek senaryo: Bir spor salonu uygulaması 0. günde ders programını giriş istemeden gösteriyor, ders rezervasyonu sırasında hesap istiyor, 1. günde rezervasyon hatırlatması gönderiyor. Böylece kayıt ve bildirim, kullanıcının kendi isteğine bağlanıyor.

Silmeyi anlamak için hangi olayları ölçmelisiniz?

Silmeyi azaltmak için önce silmenin nerede başladığını görmeniz gerekir. Google Analytics'in yardım belgelerinde kohort keşfinin nasıl çalıştığı anlatılır; uygulama tarafında ise otomatik toplanan olaylar size iyi bir başlangıç verir. Örneğin first_open olayı, kullanıcının uygulamayı kurduktan ya da yeniden kurduktan sonra ilk kez açmasını kaydeder.

Google'ın otomatik olay listesine göre app_remove olayı, uygulama paketi bir Android cihazdan kaldırıldığında tetiklenir ve yalnız Android'de çalışır. Yani iOS tarafında silmeyi doğrudan değil, geri dönmeyen kullanıcılar üzerinden okursunuz. user_engagement olayı da uygulama ön plandayken etkileşim süresini ölçer.

Otomatik olayların yanına kendi olaylarınızı eklemelisiniz:

• Kayıt başlangıcı ve kayıt tamamlanması.
• Her izin isteği ve kullanıcının verdiği cevap.
• İlk değer anı (ilk sipariş, ilk randevu, ilk kayıt gibi).
• Bildirim açılması ve bildirim tercihinin kapatılması.

Hangi olayların nasıl adlandırılacağını mobil uygulamada hangi olaylar ölçülmeli rehberimizde ayrıntılı anlattık; burada yalnız silme ile ilgili olanlara odaklandık.

Kohort analizi ile elde tutmayı nasıl okursunuz?

Kohort, aynı dönemde uygulamayı ilk kez açan kullanıcı grubudur. Google Analytics yardım belgesine göre kohort keşfinde bir dahil olma ölçütü (örneğin ilk ziyaret), bir geri dönüş ölçütü ve günlük, haftalık ya da aylık ayrıntı düzeyi seçersiniz. Haftalık ayrıntı, kayan 7 gün değil, pazardan cumartesiye takvim haftası olarak çalışır.

Belge üç hesaplama türü tanımlar. Standart hesapta her hücre, yalnız o dönemde geri dönen kullanıcıları sayar. Kayan hesapta kullanıcı, o dönemde ve önceki tüm dönemlerde geri dönmüş olmalıdır. Kümülatif hesapta ise değer dönemler boyunca birikir. Dolayısıyla iki raporu karşılaştırırken aynı hesaplama türünü seçtiğinizden emin olun.

Kohort tablosunu okurken şu sorulara cevap arayın:

1. Yeni sürümden sonra gelen kohortlar, öncekilere göre daha mı iyi tutuluyor?
2. Reklam kaynaklı kohortlar ile organik kohortlar arasında fark var mı?
3. Düşüş hangi günde en sert yaşanıyor?

Örneğin 1. günde sert düşüş görüyorsanız sorun büyük olasılıkla ilk açılıştadır. 3. ile 7. gün arasındaki düşüş ise genellikle alışkanlık kuramamaya işaret eder.

Uygulamayı silen kullanıcıyı geri kazanmak mümkün mü?

Mümkün, ama zor ve pahalıdır. Kullanıcı uygulamayı sildiğinde push bildirim kanalı kapanır. Geriye yalnız kullanıcının daha önce izin verdiği e-posta gibi kanallar ve yeniden hedefleme reklamları kalır. Bu nedenle geri kazanma planı, silmeyi önleme planının yerini tutmaz.

Geri kazanma için şu yaklaşımı öneriyoruz. Önce silmeden önceki son davranışı inceleyin: kullanıcı nerede takıldı? Ardından o sorunu düzelttiğiniz sürümü, yalnız izin veren kullanıcılara ve somut bir yenilik mesajıyla duyurun. Genel bir "sizi özledik" mesajı çoğu zaman işe yaramaz; "randevu artık iki adımda" gibi net bir değişiklik daha anlamlıdır.

Öte yandan kullanıcıyı geri getiren bağlantının doğrudan ilgili ekranı açması gerekir. Kullanıcı reklamdan uygulamaya döndüğünde ana sayfaya düşerse, aynı hayal kırıklığını yeniden yaşar. Ayrıca eski bir sürümde kalan kullanıcıların kritik düzeltmeleri alabilmesi için zorunlu güncelleme kurgusunu önceden planlamanız işe yarar.

Puan ve yorum istemenin zamanı silmeyi etkiler mi?

Doğrudan silme nedeni olmasa da yanlış zamanda gelen puan isteği ilk hafta deneyimini bozar. Kullanıcı daha uygulamayı tanımadan "bizi değerlendirin" penceresiyle karşılaşırsa, bunu bir dayatma gibi algılar. Üstelik memnun olmayan kullanıcıdan puan istemek, mağaza sayfanızdaki ortalamayı da düşürebilir.

Daha sağlıklı yaklaşım, puan isteğini kullanıcının başarılı bir işlem tamamladığı ana bağlamaktır. Örneğin sipariş teslim edildikten ya da randevu sorunsuz tamamlandıktan sonra gelen istek, hem daha doğal hem de daha adil bir değerlendirme getirir.

İki mağazanın da puan isteme konusunda kendi kuralları ve sistem pencereleri vardır. Bu kuralları ve uygun zamanlamayı uygulamada puan ve yorum nasıl istenir yazımızda ayrıntılı ele aldık. Bu yazı açısından önemli olan nokta şudur: puan isteği, ilk değer anından önce gelmemeli.

Kısacası, ilk hafta boyunca kullanıcıdan bir şey istemeden önce ona bir şey vermiş olmanız gerekir. Bu sıra, hem elde tutmayı hem de mağaza puanını korur.

Uygulama geliştirme sürecinde silmeyi baştan nasıl önlersiniz?

Silme nedenlerinin çoğu yayından sonra değil, planlama ve geliştirme aşamasında doğar. Hangi ekranın ilk açılacağı, hangi iznin ne zaman isteneceği, hangi olayın ölçüleceği gibi kararlar, kod yazılmadan önce verilmelidir. Bu kararlar sonradan değiştirildiğinde hem zaman hem bütçe kaybı yaşanır.

Talha Aslan ve ekibi olarak mobil uygulama geliştirme hizmetimizde uygulamanızı biz geliştirir, mağazaya biz çıkarırız. Bu süreçte ilk hafta akışını, izin zamanlamasını ve ölçüm planını en baştan projenin parçası olarak ele alırız. Böylece yayın günü yalnız çalışan bir uygulama değil, ölçülebilen bir ilk hafta deneyimi elde edersiniz.

Geliştirme sürecinde şu kontrolleri öneriyoruz:

• Tasarım aşamasında ilk değer anına kadar geçen ekran sayısını yazılı hale getirin.
• Her izin için hangi ekranda ve hangi açıklamayla isteneceğini belirleyin.
• Yayın öncesi testi farklı ekran boyutlarında ve düşük donanımlı cihazlarda yapın.
• Ölçüm planını yayından önce test ortamında doğrulayın.

Bütçe tarafını merak ediyorsanız mobil uygulama geliştirme maliyetini neler belirler yazımız kararlarınızı netleştirmenize yardım eder.

Uygulama silme nedenleri sektöre göre değişir mi?

Temel uygulama silme nedenleri her sektörde benzerdir, ama ağırlıkları değişir. Bir alışveriş uygulamasında kullanıcı en çok ödeme ve teslimat adımlarındaki sürtünmeden rahatsız olur. Bir randevu uygulamasında ise boş saati bulamamak ya da onay mesajı alamamak en büyük kayıptır.

Örnek senaryo: Bir restoran zinciri sipariş uygulaması yayınlıyor. Menü hızlı açılıyor, ama adres girişi her siparişte baştan isteniyor. Kullanıcı iki siparişten sonra web sitesine dönüyor ve uygulamayı siliyor. Burada sorun tasarımda değil, tekrar eden küçük bir adımdadır.

Bu yüzden kendi sektörünüz için şu soruları sorun:

• Kullanıcı uygulamayı haftada kaç kez açmalı?
• Her kullanımda tekrar eden zahmetli adım hangisi?
• Web sitesi ya da mesajlaşma uygulaması aynı işi daha kolay mı yapıyor?

Son soru özellikle önemlidir. Uygulama, alternatiflerinden daha hızlı ya da daha kişisel bir deneyim sunmuyorsa, kullanıcı için telefonda yer kaplamaya değmez. Kısacası elde tutma, rakip uygulamalarla olduğu kadar tarayıcıyla da yarışır. Bu nedenle uygulamaya özel bir avantaj, örneğin kayıtlı adres, tek dokunuşla tekrar sipariş ya da kişisel hatırlatma, ilk haftada mutlaka görünür olmalıdır.

Hangi hatalar ilk hafta elde tutmayı en çok düşürür?

Sahada en sık gördüğümüz hatalar, iyi niyetli ama kullanıcıyı yoran kararlardır. Ekipler çoğu zaman her özelliği ilk gün göstermek ister; oysa kullanıcı ilk gün yalnız bir işi çözmek ister. Bu fark, ilk hafta grafiğinde açıkça görünür.

En sık rastladığımız hatalar şunlardır:

• Beş altı ekranlık tanıtım slaytlarını atlanamaz yapmak.
• Kayıt sonrası kullanıcıyı boş bir ana sayfaya bırakmak.
• İlk gün birden fazla pazarlama bildirimi göndermek.
• Yalnız toplam indirme sayısına bakıp kohort verisini izlememek.
• Çökme raporlarını yalnız yayın haftasında kontrol edip sonra bırakmak.

Bu hataların ortak noktası, kararların kullanıcı verisi yerine varsayıma dayanmasıdır. Bu yüzden her sürümde bir hipotez seçin, onu ölçün ve sonucu bir sonraki sürüme taşıyın. Ayrıca mağaza kurallarındaki değişiklikleri takip etmek için resmi yönerge sayfalarını düzenli kontrol edin; kurallar zamanla güncellenebilir.

Özet: uygulama silme nedenlerini azaltmak için nereden başlamalı?

Uygulama silme nedenlerini azaltmak için önce ölçümü kurun, sonra en büyük kaybın olduğu adımı düzeltin. Çoğu uygulamada ilk müdahale noktası kayıt akışı, izin zamanlaması ya da ilk değer anıdır. Çökme ve bildirim sorunları ise bunlarla paralel izlenmelidir.

Kısa bir başlangıç sırası şöyle olabilir:

1. first_open, kayıt, izin ve ilk değer anı olaylarını kurun.
2. Haftalık kohort tablosunda 1. ve 7. gün değerlerini izleyin.
3. En sert düşüşün yaşandığı adımı seçin ve tek bir değişiklikle test edin.
4. Değişikliğin etkisini yeni kohortlarda doğrulayın.

Yeni bir uygulama planlıyor ya da mevcut uygulamanızın ilk hafta deneyimini baştan kurmak istiyorsanız, mobil uygulama geliştirme sayfamızdan projeniz için teklif alabilirsiniz. Ekibimiz kapsamı, platformları ve yayın sürecini birlikte netleştirir.