Anlık bildirimde strateji tartışması genelde yanlış yerden başlıyor: "ne zaman gönderelim" değil, gönderdiğiniz kaçı gerçekten teslim ediliyor ve neden sessizce düşüyor. Cevabın büyük kısmı iki dokümanda yazılı ve rakamlı. Bu yazı APNs ile FCM'in gerçek limitlerini, Android 13'ten sonra değişen izin modelini ve Türkiye'de kimsenin netleştirmediği İYS sorusunu ele alıyor.
Android 13'ten sonra bildirim varsayılan olarak kapalı
Android 13 (API 33) ile POST_NOTIFICATIONS bir çalışma zamanı izni hâline geldi ve yeni kurulan uygulamalarda bildirimler varsayılan olarak kapalı. API 32 ve altını hedefleyen uygulamalarda sistem izin diyaloğunu ilk açılışta kendisi gösteriyordu; 33 ve üstünü hedefliyorsanız zamanlamayı siz seçiyorsunuz.
Bu, yıllardır "Android'de izin sormaya gerek yok" varsayımıyla kurulmuş tüm büyüme modellerini geçersiz kıldı. Karar noktası şu: izni ne zaman isteyeceksiniz? İlk açılışta sorarsanız kullanıcı neden bildirim isteyeceğinizi henüz bilmiyor. Dokümanın söylediği de bu: 33 ve üstünü hedeflemenin avantajı, izni uygulamanın işlevi bağlamında isteyebilmek.
Pratik kural: izni bir değer anından hemen sonra isteyin. Sipariş verildikten sonra "kargo durumunu bildirelim mi", favoriye eklendikten sonra "fiyat düşünce haber verelim mi". Ret aldığınızda ise Android tarafında kullanıcı yeniden sorulmuyor; izni kaybettiyseniz kullanıcıyı sistem ayarlarına yönlendirmekten başka yol kalmıyor.
APNs: başlıklar davranışı belirliyor
Apple tarafında teslim davranışını yükün içeriği değil HTTP/2 başlıkları belirliyor (bkz. Apple Developer, "Sending notification requests to APNs"):
| Başlık | Değer | Ne işe yarar |
|---|---|---|
apns-topic | Bundle identifier | Zorunlu. Eksikse istek reddediliyor |
apns-push-type | alert, background, voip, complication, fileprovider, mdm | Her istekte gönderilmesi öneriliyor; yanlış tip sessiz düşmenin ana sebebi |
apns-priority | 10 (hemen) veya 5 (güç dostu), varsayılan 10 | Arka plan bildirimlerinde 5 kullanın |
apns-expiration | Unix epoch (saniye) | Geçerlilik süresi; zaman duyarlı bildirimde mutlaka verin |
apns-collapse-id | Serbest metin | Benzer bildirimleri grupluyor; yalnızca sonuncusu gönderiliyor |
apns-id | UUID | İz sürme ve hata ayıklama; log'unuza yazın |
Yük sınırı: normal bildirimlerde 4 KB, VoIP bildirimlerinde 5 KB. Bu sınır, "bildirimin içine tüm sipariş nesnesini koyalım, uygulama açılınca kullanır" tasarımını doğrudan reddediyor. Yüke yalnızca kimlik koyun, gerisini uygulama açılınca çekin.
FCM: dört collapse key, 28 gün, 4096 bayt
Firebase Cloud Messaging tarafında ezberlenmesi gereken üç sayı ve iki kota var.
Yük: her iki mesaj tipi için azami 4096 bayt (Firebase konsolundan gönderimde 1000 karakter sınırı uygulanıyor). TTL: 0 ile 2.419.200 saniye (28 gün) arasında; bu, FCM'in mesajı saklayıp teslim etmeye çalışacağı azami süre.
Daraltma (collapse): FCM sunucusu cihaz başına aynı anda dört farklı collapse key saklıyor. Bu sayıyı aştığınızda FCM yalnızca dördünü tutuyor ve hangilerinin tutulacağını belirleyen bir kural yok. Yani her bildirim tipine ayrı collapse key veren bir tasarım, cihaz çevrimdışıyken sessizce mesaj kaybediyor. Collapse key sayınızı dörtte tutun ve gerçekten daraltılması gereken tiplere ayırın.
Kotalar: HTTP v1 API'sinde proje başına varsayılan kota dakikada 600.000 mesaj. Cihaz bazında Android tarafında dakikada 240 ve saatte 5.000 mesaj sınırı var. Daraltılabilir mesajlarda cihaz ve uygulama başına 20 mesajlık bir patlama hakkı, ardından 3 dakikada 1 mesaj yeniden dolum uygulanıyor. Bu son kural, "her fiyat değişiminde bildirim" tasarımını pratikte imkânsız kılıyor.
Teslim raporlarınızı gönderim sayısı üzerinden kurmayın. Gönderim başarılı sayılıyor ama cihaz çevrimdışıysa, TTL dolduysa, collapse key sınırına takıldıysa ya da kullanıcı izni kapattıysa kullanıcı hiçbir şey görmüyor. Tek dürüst metrik, uygulamanın bildirimi aldığını sunucuya bildirmesi. Bunu ölçmüyorsanız kampanya raporunuz gerçeği göstermiyor.
Token yönetimi: sessiz kaybın en büyük kaynağı
Kayıt jetonları (token) kalıcı değil. Uygulama yeniden kurulduğunda, veri temizlendiğinde veya platform gerekli gördüğünde değişiyor. Token tablonuzu şöyle kurun:
- Token kullanıcıya değil, kullanıcı-cihaz çiftine bağlansın. Tek kullanıcının üç cihazı olabilir.
- Her token için son görülme tarihi tutun ve uygulama her açılışında güncelleyin.
- Gönderimde kalıcı hata dönen tokenları aynı gün pasife alın. Ölü tokenlara gönderim yapmak kotanızı yiyor ve teslim oranınızı yanlış gösteriyor.
- Çıkış (logout) yapıldığında tokenı silin. Aksi hâlde cihazı kullanan bir sonraki kişiye önceki kullanıcının bildirimi gidiyor. Bu bir hata değil, veri ihlali.
Türkiye sorusu: anlık bildirim İYS kapsamında mı?
Ticari İletişim ve Ticari Elektronik İletiler Hakkında Yönetmelik'in 4/1-m maddesi ticari elektronik iletiyi "telefon, çağrı merkezleri, faks, otomatik arama makineleri, akıllı ses kaydedici sistemler, elektronik posta, kısa mesaj hizmeti gibi vasıtalar" ile gönderilen iletiler olarak tanımlıyor. Mobil uygulama anlık bildirimi bu sayımda geçmiyor; ancak "gibi" ifadesi listeyi kapalı olmaktan çıkarıyor.
Bağlayıcı bir Bakanlık görüşü doğrulayamadık; bu yüzden "push İYS dışındadır" gibi bir cümle kurmuyoruz. Riskten kaçınan tasarım şu: pazarlama amaçlı bildirimler için ayrı ve geri alınabilir bir izin tutun, işlem bildirimlerini (sipariş durumu, kargo, ödeme) ayrı kanalda yönetin.
Bu ayrımın ikinci gerekçesi de aynı yönetmelikte: md. 6, devam eden abonelik ve teslimat gibi bildirimleri onaydan muaf tutarken bu bildirimlerde mal veya hizmetin özendirilemeyeceğini ve tanıtımının yapılamayacağını söylüyor. "Siparişiniz kargoda" bildiriminin altına indirim kuponu iliştirmek, o bildirimi ticari iletiye dönüştürüyor.
Bugün bakılacak üç sayı
Birincisi: aktif kullanıcılarınızın kaçında geçerli bir token var? Bu oran %60'ın altındaysa sorun içerikte değil izin akışında.
İkincisi: kaç farklı collapse key kullanıyorsunuz? Dörtten fazlaysa FCM tarafında sessiz kayıp yaşıyorsunuz. Üçüncüsü: bildirim gönderdiğinizde uygulama tarafında bir "alındı" olayı üretiyor musunuz? Üretmiyorsanız teslim oranınızı bilmiyorsunuz.
Mobil tarafındaki kapsam ve ekip kurgusu için mobil uygulama geliştirme firması seçimi, framework kararı için React Native ve Flutter karşılaştırması, mağaza tarafı için ASO rehberine, izin mimarisi için sadakat programı yazısına bakabilirsiniz. Hizmet kapsamımız mobil uygulama geliştirme sayfasında; kapsam için iletişim sayfasından yazabilirsiniz.
APNs başlıkları ve yük sınırları 25 Eylül 2026'da Apple Developer "Sending notification requests to APNs" dokümanından; FCM yük, TTL, collapse key ve kota değerleri Firebase Cloud Messaging dokümanlarından; bildirim izni davranışı developer.android.com "Notification runtime permission" sayfasından doğrulanmıştır. Google, FCM limitlerinin değişebileceğini belirtiyor. Açılma oranı gibi sektör ortalamaları verilmemiştir; birincil kaynak bulunamamıştır.
