Caliency.
Mobil Uygulama

Silinmeden Push Bildirimi Göndermek

İki platform da size tek bir izin penceresi veriyor ve ikisinde de varsayılan artık kapalı. Asıl karar, o tek isteği neye harcadığınız.

C

Caliency

12 dk okuma
Gece karanlık bir koltuğun üzerinde duran telefon; kilit ekranında saat 8:47 ve bir sıra bildirim simgesi.

Tek bir izin pencereniz var. İki platformda da izin isteği bir kez gerçekleşiyor, cevap kaydediliyor ve tekrar sormak hiçbir şey yapmıyor. İkisi de yeni kurulumlarda varsayılanı kapalıya çekti. Yani üzerine vakit harcanmaya değer soru bildirimin ne dediği değil — o tek isteği neye harcadığınız ve harcamaktan hiç kaçınıp kaçınamayacağınız.

Bu konudaki tavsiyelerin çoğu metin üzerine. Bir uygulamanın bildirim iznini koruyup koruyamayacağını belirleyen kararlar ise tek bir mesaj yazılmadan önce veriliyor.

İki platformda da tek pencere

Apple'ın izin isteme dokümantasyonu net:

"Uygulamanız bu yetkilendirme isteğini ilk kez yaptığında sistem kişiden isteği kabul etmesini ya da reddetmesini ister ve bu yanıtı kaydeder. Sonraki yetkilendirme istekleri kişiye sorulmaz."

Android'in karşılığı, güncel kalmamış uygulamalar için daha sert. Google'ın bildirim izni dokümantasyonu, API 32 ya da altını hedefleyen uygulamalar için şu uyarıyı taşıyor:

"Uygulamanız 12L ya da altını hedefliyorsa ve kullanıcı bir kez bile İzin verme'ye dokunursa, uygulamanızı kaldırıp yeniden kurana ya da siz uygulamanızı Android 13 veya üstünü hedefleyecek şekilde güncelleyene kadar bir daha sorulmaz."

Bundan iki sonuç çıkıyor. Birincisi, bir ret o kurulum için fiilen kalıcıdır. İkincisi, uygulamanız eski bir hedef seviyesindeyse güncel bir seviyeyi hedefleyen bir güncelleme yayınlamak başlı başına bir kurtarma mekanizmasıdır — platform SDK son tarihlerinin yalnızca uyum yükü olmamasının bir sebebi daha.

Varsayılan değişti ve eski rakamlarınız yalan söylüyor

Android 13, çalışma zamanı POST_NOTIFICATIONS iznini getirdi. Google sonucu açıkça yazıyor:

"Kullanıcı uygulamanızı Android 13 veya üstü çalıştıran bir cihaza kurarsa, uygulamanızın bildirimleri varsayılan olarak kapalıdır."

Ama Android 13'e yükseltilen cihazlarda izin uygun uygulamalara önceden verildi. Yani uzun ömürlü bir kurulum tabanı olan bir uygulama, yeni kullanıcıların ne yaptığı hakkında hiçbir şey söylemeyen sağlıklı bir bildirim onay oranı gösterebilir. Elde tutma modeliniz push'ın kullanıcıların çoğuna ulaştığını varsayıyorsa, üzerine bir şey inşa etmeden önce oranı özellikle son çeyrekteki kurulumlar için kontrol edin.

iOS'ta neredeyse hiç kimsenin kullanmadığı seçenek

Apple ikinci bir yol belgeliyor ve bu yol bize ulaşan uygulama şartnamelerinde neredeyse hiç görünmüyor. Geçici yetkilendirme, bildirimleri hiç pencere göstermeden, deneme amaçlı gönderiyor:

"Sistem geçici bildirimleri sessizce iletir — kişiyi sesle ya da başlıkla bölmezler, kilit ekranında görünmezler. Bunun yerine yalnızca bildirim merkezinin geçmişinde görünürler. Bu bildirimler ayrıca kişiye bildirimi tutmayı ya da kapatmayı öneren düğmeler içerir."

Kişi Tut'a basarsa sistem Hemen İlet ile Planlanan Özette İlet arasında seçim sunuyor.

Bunun neyi değiştirdiğini okuyun. Apple'ın normal pencereye dair sorun tanımı şu: "Bildirim göndermek için açıkça izin istediğinizde, kişiler uygulamanızdan bir bildirim görmeden önce izni verip vermeyeceklerine karar etmek zorunda kalır." Geçici yetkilendirme bunu tersine çeviriyor: bildirimler izin için seçmeye giriyor. Artık birinden bir vaade güvenmesini değil, zaten aldığı bir şeyi değerlendirmesini istiyorsunuz.

Takas gerçek — sessiz iletim ses, başlık ve kilit ekranı yok demek; yani gerçekten zaman kritik bir uyarıyı bu şekilde denemek yanlış olur. Ama bildirimleri acil değil yararlı olan bir uygulama için huninin en kötü anını ortadan kaldırıyor.

Pencereyi neye harcamalı

Standart pencereyi kullanacaksanız, Apple'ın rehberi metinden çok zamanlamayla ilgili:

"İsteği, kişilerin uygulamanızın neden yetkilendirmeye ihtiyaç duyduğunu anlamasına yardımcı olan bir bağlamda yapın. Hatırlatma bildirimleri gönderen bir görev takip uygulamasında, isteği kişi ilk görevini planladıktan sonra yapabilirsiniz."

İlke genelleşiyor: kullanıcı, bildirimin hakkında olacağı şeyi oluşturduktan sonra sorun. İlk siparişten sonra, kayıt sırasında değil. İlk kaydedilen aramadan sonra, açılışta değil. İlk rezervasyondan sonra, tanıtım akışında değil.

İlk açılışta sormak hem en yaygın hem en kötü kalıp; çünkü kullanıcının cevap verecek bir dayanağı yok ve güvenli cevap hayır — kalıcı olarak.

Uygulamayı asıl sildiren kısım

İzin içeriği değil kanalı kapsar ve uygulamaların silindiği yer bu boşluktur.

Teslimatının ne zaman geleceğini bilmek için bildirimlere izin veren biri hafta sonu kampanyasını kabul etmemiştir. Teknik olarak rızanız var. Pratikte geri alamayacağınız bir şeyi harcamışsınızdır; çünkü istenmeyen ikinci mesaj, insanı ayarlara — ya da kendi açısından sorunu yine çözen kaldır düğmesine — gönderen mesajdır.

Bunu önleyen disiplin teknik değil, sıkıcı ve kurumsal:

  • Ayrı sebepler için ayrı kanallar. Android'de bildirim kanalları tam da bu yüzden Android 8'den beri var: bir insan lojistiği kapatmadan pazarlamayı kapatabilsin. Kullanın ve kullanıcının yararlı yarıyı tutmasına izin verin.
  • İlk on mesajı özelliği kurmadan önce yazın. Yazamıyorsanız uygulamanın henüz push'a ihtiyacı yok.
  • Bir sahip belirleyin. Bir ekip değil — neyin gideceğine karar veren ve hayır diyebilen bir kişi.
  • Bir sıklık tavanı koyun ve birinin kampanya istediği hafta da ona uyun.

Aynı noktayı uygulamaya gerçekten ihtiyacınız var mı yazısında da söylüyoruz: tüm gerekçesi, kimsenin yazmayı planlamadığı bildirimler olan bir uygulama, tam da o sebeple silinecek bir uygulamadır.

Nerede hayır diyoruz

İçeriğin sahibinin kim olduğuna karar vermemiş bir müşteriye push sistemi kurmayız. Mühendislik bir hafta; editoryal taahhüt kalıcı ve sahibi yoksa kanal, içerideki en gür sesli talebin istediği şeye dönüşür.

İstense de izin penceresini ilk açılışa koymayız. Elinizdeki tek isteği, kullanıcının evet demek için en az sebebi olduğu anda ölçülebilir biçimde harcar; Android'de eski bir hedef seviyesi de o hayırı kalıcı hâle getirir.

Ve bildirimleri bir etkileşim sorununu kurtarmak için kullanmayız. İnsanlar geri dönmüyorsa push bunu düzeltmez — silinmeyi hızlandırır. O durum genelde bir ürün sorusudur ve nasıl kapsamlandırdığımızı mobil uygulama geliştirme rehberimiz anlatıyor.

Kontrol listesi

  1. Onay oranınıza yalnızca yeni kurulumlar için bakın. Önceden verilmiş yükseltme izinleri gerçek rakamı gizliyor.
  2. Pencereyi ilk anlamlı eylemden sonrasına taşıyın. Asla ilk açılış değil.
  3. iOS'ta geçici yetkilendirmeyi değerlendirin — yararlı ama acil olmayan her şey için; izni bildirimler kazansın.
  4. Ayrı kanallar kullanın ki bir insan pazarlamayı reddedip lojistiği tutabilsin.
  5. İlk on mesajı yazın ve on birinci mesajın sahibi olan kişinin adını koyun.

İzin akışının ve kanal tasarımının ilk şikâyetten sonra değil yapımdan önce belirlenmesini isterseniz, uygulamanın insanlara ne söylemesi gerektiğini bize anlatın — ya da mobil uygulama geliştirme sayfasından başlayın.

Bir fikriniz mi var?

Kısa bir görüşmede kapsamlandırıp sabit fiyat verelim.

Proje başlat →