Anlık Bildirim Stratejisi: Hangi Olayda Ne Gönderilir?

Bir mobil uygulamada bildirim göndermenin teknik kurulumu bir günlük iştir; asıl zor olan hangi olayda, kime ve ne sıklıkla gönderileceğine karar vermektir. Stratejisiz eklenen bildirimler kısa vadede açılma oranını artırsa da orta vadede tam tersi bir etki yaratır: kullanıcı ya bildirimleri kapatır ya da uygulamayı siler. Bu yazıda hangi olayların bildirime değdiğini, iOS ve Android'de izin isteme farkını, sıklığın nereye kadar tolere edildiğini ve bir bildirim stratejisinin nasıl kurulacağını sırayla anlatıyoruz.

Bildirimi hak eden olay hangisi?

Her olay bir bildirimi hak etmez. Bir bildirim göndermeden önce sorulması gereken tek soru şu: bu bilgi, kullanıcı şu anda telefonuna bakmasa bile onun için değerli mi? Cevap hayırsa, bildirim yerine uygulama içi bir rozet veya e-posta yeterlidir.

1. Kullanıcının başlattığı bir işlemin sonucu. Sipariş kargoya verildi, ödeme onaylandı, randevu teyit edildi — kullanıcı bu bilgiyi zaten bekliyor.
2. Zamana bağlı ve geri alınamaz bir durum. Randevu bir saat sonra, stok son bir adet kaldı, teklif bugün bitiyor.
3. Kullanıcının kendi tetiklediği bir sosyal etkileşim. Birisi yorumuna cevap verdi, bir talebi onayladı.
4. Güvenlik veya hesapla ilgili kritik bir uyarı. Yeni cihazdan giriş, şifre değişikliği, ödeme yönteminin süresi doluyor.

Hangi olaylar bildirime değmez?

• Genel duyurular sık aralıklarla. "Yeni özellikleri keşfedin" gibi bildirimler kullanıcı için hazır bir aksiyon içermez ve hızla gürültüye dönüşür.
• Uygulama içinde zaten görünen bir bilgi. Kullanıcı uygulamayı açtığında göreceği bir sayıyı ayrıca bildirimle tekrarlamak gereksizdir.
• Kişiselleştirilmemiş toplu kampanya. Segmentlenmemiş, herkese aynı anda giden bir mesaj, en yüksek kapatma oranını üreten bildirim türüdür.
• Test veya hata amaçlı gönderilen içerik. Üretim ortamında yanlışlıkla tetiklenen bir bildirim, güveni tek seferde kırabilir.

iOS ve Android'de izin isteme farkı

İki platform bildirim iznini farklı ele alır ve bu fark stratejiyi doğrudan etkiler. iOS'ta kullanıcı bildirimlere açıkça evet demek zorundadır; Android'de ise 13. sürüme kadar bildirimler varsayılan olarak açıktı. Android 13 ile birlikte Android da açık izin istemeye geçti ve bu değişiklik iki platform arasındaki farkı büyük ölçüde kapattı.

Sıklık: kaç bildirim çok?

Sıklık, bir bildirim stratejisinin en çok gözden kaçırılan parçasıdır. Kullanıcı davranışını izleyen araştırmalar tekrarlayan bir eşik gösteriyor: haftada tek bir bildirim bile bir kısım kullanıcıyı bildirimleri kapatmaya iterken, haftada birkaçı bu oranı belirgin biçimde artırıyor.

Buradaki ders sıfır bildirim göndermek değil, her bildirimin gerçekten karşılığı olan bir bilgi taşımasıdır. İyi yönetilen programlarda uygulama silme oranı %1'in altında kalıyor; çoğu ekip haftada iki-üç tanıtım amaçlı bildirimle başlayıp performansa göre ayarlıyor.

Bildirim türleri: hangisi hangi işi yapar

Tüm bildirimleri tek bir kategoride düşünmek, doğru sıklık ve tonu belirlemeyi zorlaştırır. Dört tür birbirinden ayrı kurallarla yönetilmeli.

• İşlemsel (transactional) bildirim. Sipariş durumu, ödeme onayı, randevu hatırlatması. Sıklık sınırı yoktur çünkü kullanıcı bu bilgiyi zaten bekliyordur.
• Etkileşim (engagement) bildirimi. Yarım bırakılan bir işlemi tamamlama daveti, kullanıcının kendi verisiyle ilgili bir güncelleme. Haftada birkaç taneyle sınırlı tutulmalı.
• Pazarlama (marketing) bildirimi. Kampanya, indirim, yeni özellik duyurusu. En düşük tolerans burada görülür; segmentlenmemiş gönderim hızla kapatma oranını yükseltir.
• Sessiz (silent) push. Kullanıcıya görünmeyen, arka planda veri senkronize eden bildirim türü. İzin gerektirmez ama pil ve veri kullanımına dikkat edilmeli.

Zamanlama ve segmentasyon

Doğru olay ve doğru sıklık bile yanlış saatte gönderilirse karşılığını vermez. Kullanıcının kendi saat diliminde, makul saatlerde (genelde sabahın geç saatleri ve akşam) gönderilen bildirimler, gece yarısı gönderilenlere kıyasla belirgin biçimde daha yüksek açılma oranı alır. Segmentasyon da aynı derecede önemli: son bir haftadır uygulamayı açmamış bir kullanıcıyla her gün aktif olan bir kullanıcıya aynı mesajı aynı sıklıkla göndermek, ikisinden birini kaybetmek demektir.

Bildirim stratejisi nasıl kurulur? 5 adım

1. Olay listesini çıkarın. Uygulamadaki her kullanıcı eylemini ve sistem durumunu listeleyin; hangisinin bildirime değdiğine yukarıdaki kritere göre karar verin.
2. Her bildirime bir sahip ve bir amaç yazın. "Bu bildirim kimin hangi eylemi yapmasını istiyor" sorusuna cevap veremiyorsanız, o bildirim gönderilmemeli.
3. Sıklık tavanı koyun. Kategori bazında (işlemsel, etkileşim, pazarlama) haftalık üst sınır belirleyin ve bu sınırı teknik olarak zorlayın.
4. İzin isteğini bağlama oturtun. Uygulamanın değerini gösterdiği ilk anda isteyin, genel bir açılış ekranında değil.
5. Kapatma ve silme oranını izleyin. Bu iki metrik, bildirim stratejisinin gerçek skor tablosudur; açılma oranından daha çok şey söyler.

En sık yapılan 4 hata

• Tüm kullanıcılara aynı mesajı göndermek. Segmentsiz gönderim, en yüksek kapatma oranını üreten tek karardır.
• İzni açılış ekranında istemek. Kullanıcı uygulamanın ne işe yaradığını görmeden verilen izin isteği, en düşük onay oranını alır.
• Bildirimi tek yönlü bir kanal gibi kullanmak. Kullanıcının bildirim tercihlerini uygulama içinden ayarlayabildiği bir ekran olmadan, tek seçenek bildirimleri tamamen kapatmaktır.
• Sessiz push'u aşırı kullanmak. Sık tetiklenen arka plan senkronizasyonu pil tüketimini artırır ve işletim sistemi bunu fark edip uygulamanın arka plan önceliğini düşürebilir.

Ne kadar sürer, nasıl başlanır?

Temel bir bildirim altyapısı — izin akışı, olay bazlı tetikleme ve tercih ekranı — mobil uygulama geliştirme hizmetimizde tipik olarak 1–2 haftalık bir iştir. Segmentasyon, zamanlama motoru ve A/B testi eklenmek istendiğinde bu süre 3–4 haftaya çıkabilir. Bildirim stratejisini erken düşünmek, mobil uygulama yaptırma rehberimizde de değindiğimiz gibi, projenin bütçesini sonradan patlatan kararlardan birini baştan önler.

Uygulamanız için hangi olayların bildirime değdiğinden emin değilseniz, mevcut kullanıcı akışınızı birlikte gözden geçirelim — kısa bir görüşme talep edin.