Uygulama İçi Bildirim Stratejisi: İzin, Zamanlama, Sınır

İzin isteği, kullanıcı bir işlemi tamamladıktan hemen sonra gelir; bir sipariş verildiğinde, bir randevu alındığında ya da bir favori kaydedildiğinde. Bu anda kullanıcı zaten uygulamadan bir fayda beklediği için, «bu işlemin durumunu bildirimle takip edin ister misiniz» sorusu doğal bir devam gibi görünür.

Açılış ekranında ya da ilk oturumda gelen izin isteği en düşük onay oranını verir, çünkü kullanıcı henüz uygulamanın kendisine ne kazandıracağını görmemiştir. Bir spor kulübü üyelik uygulamasında izin isteği kullanıcı ilk antrenman rezervasyonunu yaptıktan sonra gelirse, kabul oranı ilk açılışta sorulmasına göre gözle görülür biçimde yükselir.

Sistem diyaloğundan önce bir ön ekran göstermek de yaygın bir yöntemdir; bu ekranda bildirimin ne işe yarayacağı anlatılır, kullanıcı hazır olduğunda sistem diyaloğu tetiklenir. Bu ön ekran, reddetme sonrası tekrar soramama kısıtını bir ölçüde telafi eder.

Bir olay, yalnız kullanıcının kendisi için anlam taşıyorsa bildirime dönüşür. Sipariş kargoya verildi, randevu saati yaklaştı, sepette bıraktığı ürün stokta azaldı gibi bilgiler bu tanıma girer; bunlar kullanıcının kendi işlemiyle ilgilidir.

Genel duyuru, kampanya hatırlatması ya da uygulama güncellemesi gibi bilgiler farklı bir kategoridir; bu tür içerikler herkese aynı anda gider ve kişisel bir aciliyet taşımaz. Bir iş elbisesi üreticisinin uygulamasında «yeni koleksiyon geldi» bildirimi ile «siparişiniz kargoya verildi» bildirimi aynı sıklıkta gönderilirse, ikincinin taşıdığı güven ilkiyle birlikte aşınır.

Bu ayrım, uygulama içinde iki ayrı bildirim kanalı tanımlamayı gerektirir; kullanıcı işlem bildirimlerini açık bırakıp pazarlama bildirimlerini kapatabilir. Bu seçenek sunulmazsa kullanıcı ikisini de kapatarak işlemsel bilgiyi de kaybeder.

Zamanlama, kullanıcının o an telefonuyla ilgilenip ilgilenmediğine değil, bildirimin o an için anlamlı olup olmadığına bakar. Bir restoran rezervasyon uygulamasında masaya oturma saatinden bir saat önce gelen hatırlatma anlamlıdır; aynı bildirim gece yarısı gelirse rahatsız edici olur.

Sıklık için tek bir doğru sayı yoktur, duruma bağlıdır. İşlemsel bildirimler olayla birlikte anında gider, pazarlama bildirimleri ise haftada birkaç kereyi geçmeyecek şekilde planlanır. Bir spa zincirinin uygulamasında günde birden fazla pazarlama bildirimi gönderildiğinde bildirim kapatma oranının belirgin biçimde arttığı gözlemlenir; bu gözlem her uygulama için ayrı ayrı ölçülmelidir.

Zaman dilimi de gözden kaçmaz; kullanıcının bulunduğu saat dilimine göre gönderim yapılmazsa sabah üçte gelen bir kampanya bildirimi markaya zarar verir. Çok ülkeli bir uygulamada bu ayar tek bir sunucu saatine bağlı kalmamalıdır.

Kişiselleştirme, bildirim metninde kullanıcının adını yazmak değil, kullanıcının kendi davranışına göre farklı bir mesaj kurmaktır. Bir e-ticaret uygulamasında sepette ürün bırakan kullanıcıya giden bildirim ile yeni ürün gezinen kullanıcıya giden bildirim aynı olmamalı; birincisi tamamlanmamış bir işleme, ikincisi keşfe işaret eder.

Kohort bazlı gönderim, kullanıcıları son giriş tarihine, satın alma geçmişine ya da ilgi alanına göre gruplayıp her gruba farklı bir mesaj göndermek demektir. Bu yapı kurulmadan tek tip bildirim herkese aynı anda gidiyorsa bir kısmı için gereksiz, bir kısmı için geç kalmış olur.

Kişiselleştirme veri toplamayı da beraberinde getirir; hangi verinin toplandığı ve nasıl saklandığı ayrı bir konudur, KVKK ve GDPR kapsamında uygulama gizlilik politikasında açıkça belirtilmelidir.

Üç hata tekrar eder: izni doğru zamanda değil ilk açılışta istemek, işlemsel ve pazarlama bildirimlerini aynı kanalda tutmak, kullanıcıya bildirim tercihlerini yönetebileceği bir ekran sunmamak.

• İlk açılışta, kullanıcı fayda görmeden izin istemek
• İşlemsel ve pazarlama bildirimlerini ayrı kanallara ayırmamak
• Bildirim sıklığını kullanıcının kendisinin ayarlayamaması
• Aynı bilgiyi hem push bildirim hem e-posta hem uygulama içi mesajla art arda göndermek
• Zaman dilimini hesaba katmadan toplu gönderim yapmak

İzin reddedildiğinde uygulama kapanmaz; bildirim yerine uygulama içi rozet, liste görünümünde durum güncellemesi ya da e-posta gibi alternatif kanallar devreye girer. Bir tesis yönetim uygulamasında bildirim izni olmayan bir sakin, aidat hatırlatmasını uygulama açıldığında ana ekranda görebilir.

Kullanıcıyı ayarlar sayfasına yönlendiren bir bağlantı uygulama içinde nazikçe sunulabilir; ama bu bağlantı her açılışta karşısına çıkarsa rahatsızlığa dönüşür. Bir kere gösterilip bir süre beklenmesi, kullanıcı deneyimi açısından daha doğru bir yoldur.