Push Bildirimi Tasarımı: Uygulama Silinmeden Bildirmek

Push bildirimi tasarımı, mobil uygulamalarda kullanıcıyı geri getiren en güçlü araç ve aynı zamanda uygulamanın silinmesinin en sık sebebi. İkisi arasındaki fark teknik değil: gönderim altyapısını kurmak bir günlük iş, ne zaman ve neyi göndereceğine karar vermek asıl mesele.

İzin: tek atışlık bir hak

Sistem izin kutusu bir kez gösterilir. Kullanıcı reddettiğinde uygulama içinden yeniden soramazsınız; kullanıcının kendi iradesiyle ayarlara girip açması gerekir ki bu pratikte neredeyse hiç olmaz.

Buna rağmen pek çok uygulama izni ilk açılışta, kullanıcı henüz hiçbir şey görmeden istiyor. O anda kullanıcının elinde karar verecek bilgi yok, refleks olarak reddediyor.

Daha iyi kurgu iki adımlı: önce uygulama içinde, kendi tasarımınızla, neden bildirim göndereceğinizi somut olarak anlatan bir ekran gösterin ("Siparişiniz yola çıktığında haber verelim mi?"). Kullanıcı burada olumlu yanıt verirse sistem kutusunu açın. Reddederse sistem kutusunu hiç açmayın — hakkınızı harcamamış olursunuz ve birkaç gün sonra, daha uygun bir anda tekrar deneyebilirsiniz.

Bildirimi tetikleyen şey ne?

Bildirimleri iki kategoriye ayırın, çünkü kullanıcı da öyle algılıyor:

• İşlemsel: kullanıcının kendi eyleminin sonucu. Sipariş durumu, mesaj, randevu hatırlatması. Bunlar beklenen bildirimlerdir, sıklık sınırı gerektirmez.
• Pazarlama: sizin başlattığınız. Kampanya, yeni özellik duyurusu, "sizi özledik". Asıl risk buradadır.

İki kategoriyi ayrı ayarlarla yönetin. Kullanıcı pazarlama bildirimlerini kapatabilmeli ama sipariş bildirimini almaya devam edebilmeli. Tek bir aç/kapa düğmesi sunan uygulamalar, kullanıcıyı "hepsini kapat" seçeneğine itiyor ve işlemsel bildirimleri de kaybediyor.

Segmentasyon: herkese aynı mesaj en pahalı seçenek

Tüm kullanıcı tabanına aynı bildirimi göndermek kolay olduğu için yaygın. Sonuç da öngörülebilir: mesajın ilgili olduğu küçük bir grup tıklar, kalan büyük çoğunluk rahatsız olur ve bir kısmı bildirimleri tamamen kapatır.

Basit ve etkili bölümleme ölçütleri: son giriş tarihi, uygulamada tamamlanan ana eylem (satın alma, içerik ekleme), platform ve dil. Bu dört ölçüt bile gönderim listesini anlamlı biçimde daraltıyor ve tıklama oranını belirgin şekilde yükseltiyor.

Zamanlama ve sessiz saatler

Kullanıcının yerel saatine göre gönderin, sunucunun saatine göre değil. Bu, çok bölgeli uygulamalarda en sık yapılan hata: İstanbul'da öğlen gönderilen kampanya, Kaliforniya'daki kullanıcının telefonunu gece ikide çaldırıyor. Zaman dilimi hatalarının nasıl önleneceği başlı başına bir konu ve genellikle sanılandan daha çok yeri etkiliyor.

Sunucu tarafında basit bir kural yeterli:

// Kullanıcının yerel saatine göre sessiz saat kontrolü
$yerel = new DateTime('now', new DateTimeZone($kullanici->zaman_dilimi ?: 'Europe/Istanbul'));
$saat  = (int) $yerel->format('G');

if ($saat < 9 || $saat >= 21) {
    // Ertesi günün ilk uygun saatine ötele — iptal etme
    $gonderimZamani = (clone $yerel)->setTime(9, 30);
    $kuyruk->planla($bildirim, $gonderimZamani);
    return;
}

Dikkat: sessiz saate denk gelen bildirimi iptal etmeyin, öteleyin. İptal edilen kampanyalar sessizce kayboluyor ve raporlarda "gönderildi" görünmediği için fark edilmiyor.

Derin bağlantı olmadan bildirim yarım

Bildirim, konusu olan ekrana götürmeli. Ana sayfaya düşen kullanıcı aradığını bulamıyor ve ikinci bildirime tıklama olasılığı belirgin biçimde düşüyor. Derin bağlantı kurulumu bir kerelik iştir; uygulamanın kaldırılmış olduğu durumda mağazaya, kurulu olduğu durumda ilgili ekrana yönlendirmeyi de aynı anda çözmek gerekiyor.

Mobil tarafın diğer ayrıntıları için offline-first tasarım ve pil tüketimini artıran hatalar yazılarına bakmakta fayda var; bildirim altyapısı bu iki konuyla doğrudan kesişiyor.

Ölçüm: açılma oranı tek başına yalan söyler

"Kampanya başarılı, açılma oranı %14" cümlesi eksik bir cümle. Yanına şu iki sayı gelmeden anlamı yok: aynı kampanyadan sonra kaç kullanıcı bildirim iznini kapattı, kaç kullanıcı uygulamayı sildi?

Mağaza tarafı

Bildirim iznini zorunlu tutan, yani izin verilmeden uygulamanın kullanılmasına engel olan akışlar mağaza incelemesinde ret sebebi olabiliyor. Aynı şekilde, izin isteme metninin gerçek kullanımı yansıtması gerekiyor. Mağaza reddini önleyen kontrol listesi yazısındaki maddeleri bildirim akışını yazarken de gözden geçirin.

Sonuç

Push bildirimi tasarımı bir gönderim problemi değil, bir güven problemi. İzni doğru anda isteyin, işlemsel ve pazarlama bildirimlerini ayırın, kullanıcının saatine saygı gösterin, tıklayanı doğru ekrana götürün ve her kampanyada yalnızca açılmayı değil kaybı da ölçün. Bu beş kural uygulandığında bildirim, uygulamayı sildiren şey olmaktan çıkıp geri getiren şeye dönüşüyor.

Platform tarafındaki güncel kurallar için: Android — Bildirimler dokümantasyonu.