- Kimler için?
- Mobil uygulamasına bildirim ve deep link akışı ekleyen geliştiriciler.
- Başlamadan önce
- FCM/APNs yapılandırması, kullanıcı oturumu ve sunucuda güvenli sağlayıcı kimliği.
1. Cihaz kaydını kullanıcıdan ayrı tutun
Bir kullanıcının birden fazla cihazı olabilir; bir cihaz da zaman içinde farklı hesaplara giriş yapabilir. Token kaydında kullanıcı, platform, uygulama ortamı, son güncelleme ve izin durumu bulunmalıdır. İstemci token değişince backend’e güncel kaydı gönderir. Çıkışta eski hesap ilişkisini kaldırın. Ortak kullanılan cihazda önceki hesaba ait mesajların görünmemesi kritik bir testtir.
2. Bildirim içeriğini en az veriyle taşıyın
Kilit ekranında hassas belge, sağlık veya ödeme detayını göstermeyin. Bildirim yalnızca kullanıcıyı ilgili akışa davet etsin; gerçek içerik API’den yetki kontrolüyle alınsın. Deep link içindeki kaynak kimliği erişim izni değildir. Silinmiş veya artık erişilemeyen kayıt için uygulama anlaşılır bir boş durum göstermelidir.
3. Gönderimi kalıcı iş kuyruğuna alın
Kullanıcı işleminin request süresinde binlerce cihazı tek tek çağırmayın. Olayı kaydedin, uygun cihaz listesini seçin ve gönderim işini kuyrukta çalıştırın. Aynı olayın iki kez kuyruğa alınması için tekrar güvenliği tasarlayın. Sağlayıcının rate limit veya geçici hata cevabını sınırlı geri çekilmeyle ele alın; kalıcı hatayı sonsuza kadar tekrar etmeyin.
| Sonuç | İşlem |
|---|---|
| Sağlayıcı kabul etti | Kabul kaydını tut; teslim garantisi varsayma |
| Geçici hata / limit | Sınırlı backoff ve jitter |
| Geçersiz token | Kayıt ilişkisini temizleme |
| Yetki / kimlik hatası | Yapılandırmayı düzelt; sırları loglama |
4. Teslim ve açılmayı farklı metrikler sayın
Sağlayıcının kabulü, cihaz teslimi ve kullanıcının açması farklı aşamalardır. Platformun gerçekten sunduğu ölçümleri kullanın; eksik teslim metriğini yüzde 100 başarı gibi göstermeyin. Operasyon için kuyruk yaşı, geçersiz token oranı ve gönderim hata sayısı yararlıdır. Analitik olayına mesaj metnini veya tokenı eklemeyin.
5. Arka plan ve izin davranışını test edin
Bildirim izni kapalıyken, uygulama kapalıyken, token yenilenmişken ve ağ kesikken akışı deneyin. Kullanıcının bildirime dokunması uygulamanın oturumunu hazır bulacağı anlamına gelmez; gerekirse girişten sonra hedefe devam edin. FCM’nin ücretsiz mesajlaşma ürünü olması, kendi backend, kuyruk veya ek hizmet giderlerinin de ücretsiz olduğu anlamına gelmez.
6. Yayın kontrol listesi
Development ve production kimliklerini karıştırmayın. Sağlayıcı anahtarlarını sadece sunucuda saklayın. Aynı kullanıcıya aynı olay için tekrar uyarı gitmesini ürün politikasına göre sınırlayın. Kullanıcının sessiz saatleri, opt-out tercihi ve pazarlama izinleri ayrı alanlarda tutulabilir; işlem bildirimi ile kampanyayı aynı izin varsayımıyla tasarlamayın.
- Token değişimi ve çıkış akışı test edildi.
- Deep link sonrasında kaynak yetkisi doğrulanıyor.
- Geçici ve kalıcı hata farklı ele alınıyor.
- Bildirim olmadan da ekran güncel veri alabiliyor.
Uygulama özeti
- Token yaşam döngüsünü yönetim altına alın.
- Gönderimi kuyrukla ve sınırlı retry ile yapın.
- Bildirimden sonra yetkili API verisini okuyun.
Sık sorulan sorular
Sağlayıcı kabulü teslim garantisi mi?
Hayır. Kabul, cihazdaki görünür teslim ve kullanıcı açılması farklıdır.
Token hiç değişmez mi?
Değişebilir; istemcinin yenileme ve backend eşleştirme akışı olmalıdır.
Kaynaklar ve kapsam
Teknik kaynaklar aşağıda. Örnekler açıklama ve kendi ortamınızda uygulama içindir; gerçek müşteri ölçümü veya çalışan Uygulama Cloud servisi iddiası içermez. Sağlayıcı ayarlarını uygulamadan önce ilgili belgenin güncel sürümünü kontrol edin.
Kaynak kontrolü: