Mobil push notification 2026’da hala en yüksek geri dönüş oranını sağlayan kanaldır; Airship Mobile Consumer Report 2025 verisine göre iyi tasarlanmış uygulamalarda opt-in oranı %78’e ulaşırken kötü kurulmuş akışlarda %32’de kalıyor. Bu açık, milyon kullanıcılı bir uygulamada yıllık 4 ila 9 milyon ABD doları gelir farkına dönüşüyor. iOS 18 ve Android 15 ile birlikte Apple Push Notification service (APNs) ve Firebase Cloud Messaging (FCM) tarafındaki davranış sözleşmeleri sıkılaştırıldı: agresif gönderim yapan uygulamalar otomatik olarak Focus modları ve Android Modes ile filtreleniyor. Bu rehberde APNs ve FCM mimarisini, pre-permission stratejisini, rich push payload yapısını, vendor karşılaştırmasını, ölçüm çerçevesini ve 2026’nın yeni izin disiplinini uçtan uca ele alıyoruz.
APNs ve FCM mimarisi: iki gateway, tek hedef
Push notification, sunucudan cihaza doğrudan değil işletim sistemine ait güvenilir bir gateway üzerinden teslim edilir. iOS ve macOS için bu gateway Apple Push Notification service’tir; HTTP/2 protokolü ve JWT veya sertifika tabanlı kimlik doğrulama ile çalışır. Android tarafında Firebase Cloud Messaging dominanttır ve 2024’ten itibaren HTTP v1 API zorunlu hale getirildi. FCM, iOS’a gönderim yaparken kapağın altında yine APNs ile konuşur; başka bir deyişle FCM iOS açısından bir soyutlama katmanıdır. Ekibin teknik kararı “ham APNs vs FCM” değil “tek SDK abstraction mı, iki SDK direkt entegrasyon mu” sorusudur.
Gateway seçimi mimari kararla biter; ürün ekibinin asıl odağı opt-in funnel ve segmentasyon stratejisidir. Bu nedenle mobil mühendislik tarafıyla CRM tarafının ortak çalışması gerekir. Mobil tarafta token yönetimi, rich push extension’ları ve channel/category tanımları; CRM tarafında segment kuralları, frekans tavanları ve send-time optimization mantığı kurulur. Mobil CI/CD pipeline’ı ve token kayıt servisinin güvenliği de bu mimarinin ayrılmaz parçasıdır.
| Kriter | APNs (doğrudan) | FCM |
|---|---|---|
| Platform kapsamı | iOS, iPadOS, macOS, watchOS, tvOS | Android + iOS (APNs köprüsü) + web push |
| Protokol | HTTP/2, binary frames | HTTP v1 REST + Admin SDK |
| Kimlik doğrulama | JWT veya APNs sertifikası | Service account JWT (OAuth2) |
| Maksimum payload | 4 KB (alert), 5 KB (VoIP) | 4 KB |
| Topic gönderimi | Yok (uygulama kendi yönetir) | Var (FCM Topics, condition language) |
| Teslim raporu | Token feedback API, status codes | Delivery receipt + BigQuery export |
| Ortalama teslim süresi | Saniyenin altında (high priority) | 1-3 saniye |
| Maliyet | Ücretsiz | Ücretsiz (Spark/Blaze plan kapsamında) |
Payload limitleri, priority seviyeleri ve teslim güvenilirliği
Push payload tasarımı, sınırların farkında olmadığında sessiz biçimde başarısız olur. APNs alert payload limiti 4 KB’tır; bu sınır JSON serileştirme sonrası ölçülür, dolayısıyla emoji ve uzun başlıklar limiti hızla doldurur. FCM tarafında data message ve notification message ayrımı önemlidir: notification mesajı sistem tarayıcısına otomatik düşerken, data message uygulama foreground’ta değilse arka plan service’e teslim edilir. Hibrit payload’lar her iki davranışı birleştirir ancak öncelik (priority) ve TTL (time-to-live) alanlarını doğru ayarlamak gerekir.
| Priority seviyesi | APNs karşılığı | FCM karşılığı | Kullanım senaryosu | Pil etkisi |
|---|---|---|---|---|
| Yüksek | apns-priority: 10 | priority: “high” | Mesajlaşma, alert, finansal işlem | Cihaz uyanır, ekran açılabilir |
| Normal | apns-priority: 5 | priority: “normal” | İçerik güncelleme, pazarlama push | Batched delivery, pil dostu |
| Background (sessiz) | content-available: 1 | contentAvailable: true | İçerik senkronu, telemetri | iOS sıkı throttling uygular |
| VoIP / call | PushKit (apns-push-type: voip) | Yok (CallKit + APNs üzerinden) | Sesli/görüntülü arama | Maksimum öncelik, gecikme yok |
| Critical alert | apns-push-type: alert + entitlement | Yok | Sağlık, güvenlik, acil durum | Sessizde bile çalar, özel onay ister |
2025 Iterable Mobile Benchmark raporuna göre dünya genelinde push delivery rate ortalaması %96,4 seviyesinde; ancak bu rakam coğrafyaya ciddi şekilde bağlıdır. Çin’deki Android cihazlarda FCM bağlantısı kısıtlı olduğu için Huawei HMS Push, Xiaomi MiPush ve OPPO ColorOS Push gibi alternatifler zorunludur. Hindistan ve Brezilya’da OEM (cihaz üreticisi) battery saver politikaları arka plan FCM bağlantısını agresif şekilde keser; delivery rate bu pazarlarda %85’e düşebilir. Avrupa ve Kuzey Amerika tarafında ise odak Focus modu ve Android Modes filtreleri olduğundan teknik teslim yüksek ama “kullanıcıya ulaşan” rakam farklılaşır.
Pre-permission stratejisi: opt-in funnel’ı tasarlamak
iOS’ta push izni varsayılan kapalıdır; kullanıcının uygulama içinde sistem promptunu görüp onaylaması gerekir. Bir kez reddedildiğinde sistem promptu bir daha gösterilemez ve kullanıcıyı geri kazanmak iOS Ayarlar > Bildirimler ekranına yönlendirmeyi gerektirir. Bu pratikte kullanıcı kaybı demektir. Pre-permission deseni, sistem prompt’unu göstermeden önce kullanıcıya uygulama içi bir ekran sunup niyet ölçmeye dayanır. Reddeden kullanıcıya sistem prompt’u hiç gösterilmez; ileride yeniden, doğru bağlamda sorulabilir.
Android 13 ile birlikte aynı izin modelinin Android’e gelmesi pre-permission’ı çapraz platform standardı haline getirdi. Apple Human Interface Guidelines’ın “Notifications” bölümü de pre-permission ekranı için açık öneriler içerir: değer cümlesi net olmalı, kullanıcı reddetme hakkına sahip olmalı, sistem prompt’u kullanıcı pozitif sinyal verdikten sonra tetiklenmeli.
| Pre-permission stratejisi | Tetik zamanı | Tipik opt-in oranı | Uygunluk |
|---|---|---|---|
| Cold prompt (anti-pattern) | Uygulama ilk açılış | %28-38 | Hiçbir senaryo |
| Value-first soft ask | Kullanıcı 3-5. etkileşim sonrası | %62-74 | İçerik, sosyal, e-ticaret |
| Contextual trigger | İlgili özelliğe ilk dokunuş (örn. fiyat alarmı) | %70-82 | Fintech, marketplace, takip |
| Onboarding değer hediyesi | İlk başarılı aksiyon (sepete ekleme, ilk transfer) | %66-78 | SaaS, ödeme, dijital cüzdan |
| Re-engagement prompt | Reddeden kullanıcıya 30-60 gün sonra in-app banner | %18-26 ek kazanım | Tüm sektörler |
Pre-permission ekranını uygulama açılışında değil, kullanıcıya değer sağlayan ilk etkileşim sonrası göstermek altın kuraldır. Braze Engagement Index 2025 raporu, retail uygulamalarında ilk sepete ekleme sonrası gösterilen pre-permission ekranlarının soğuk açılış prompt’una göre 2,2 kat daha yüksek opt-in oranı ürettiğini saptıyor. Mesaj tonu da kritik: A/B testlerde “Bildirimleri Aç” yerine “Fırsatları kaçırma” ya da “Siparişini takip et” gibi somut fayda cümlelerinin opt-in oranını %15-25 oranında artırdığı gözlemleniyor.
Rich push, Notification Service Extension ve action button’lar
Sade text push, 2026’da artık baseline değil minimum sözleşmedir. Görsel, video önizleme, action button ve inline reply destekleyen rich push, open rate’i 2,3 kat artırıyor (OneSignal benchmark, 2025). iOS tarafında bunu Notification Service Extension (NSE) ve Notification Content Extension (NCE) ile yaparsınız: NSE, payload teslim edilmeden önce çalıştığı için indirilebilir görsel ekleme, payload decryption ve dinamik içerik mümkündür. Android tarafında ise BigPictureStyle, MessagingStyle ve InboxStyle gibi NotificationCompat builder’ları aynı zenginlik seviyesini sağlar; data message + custom rendering kombinasyonu en esnek yaklaşımdır.
| Rich push bileşeni | iOS gereksinim | Android gereksinim | Etki (open rate) |
|---|---|---|---|
| Görsel (image) | NSE + mutable-content: 1 | BigPictureStyle | +%56 |
| Video önizleme | NSE + MP4 attachment | BigPictureStyle (statik) | +%72 |
| Action button (örn. Beğen / Yanıtla) | UNNotificationCategory + actions | NotificationCompat.Action | +%38 |
| Inline reply | UNTextInputNotificationAction | RemoteInput | +%64 |
| Custom UI (özel görünüm) | NCE (UIViewController) | Custom RemoteViews | +%41 |
| Live Activity / Ongoing notification | ActivityKit + Dynamic Island | OngoingActivity + Wear OS | +%88 (transactional) |
2024-2025 döneminde iOS Live Activity ve Dynamic Island, mobil push paradigmasını “anlık alert” yerine “yaşayan durum” yönünde genişletti. Yemek siparişi takibi, ulaşım, spor skoru gibi senaryolarda Live Activity, ana ekranda sürekli güncel bilgi tutar ve klasik push’a göre 3-4 kat daha yüksek tekrar açılma sağlar. Android tarafında karşılığı OngoingActivity API’sidir ancak adaptasyon daha yavaştır. iOS Native vs Cross-Platform kararı, Live Activity ve Widget gibi platform-spesifik yetenekleri kullanma niyetiyle doğrudan bağlantılıdır.
Silent push, background fetch ve content update desenleri
Silent push, kullanıcıya görünür alert göstermeden uygulamayı arka planda uyandırmaya yarar; cache invalidation, içerik senkronizasyonu ve token refresh için kullanılır. iOS’ta bunu aps objesi içine content-available: 1 ekleyip alert/sound/badge alanlarını boş bırakarak yaparsınız. Apple, silent push’u pil tasarrufu için agresif şekilde throttling yapar; günde uygulama başına teorik olarak sınırsız değil, pratikte 2-3 silent push kullanıcı davranışına göre teslim edilir. Yüksek frekanslı silent push gönderen uygulamalar Apple tarafından sessiz şekilde rate-limit’e tabi tutulur.
- Cache invalidation: Sunucu tarafında değişen bir kaynak için silent push tetiklenir; uygulama lokal cache’i temizler ve sonraki açılışta taze veri çeker.
- Token rotation: Auth token’ı süre dolmadan refresh etmek için arka plan görevi tetiklenir; özellikle fintech uygulamalarında oturum güvenliğini artırır.
- Pre-fetch (içerik ön yükleme): Sabah saatlerinde haber özetinin ön yüklenmesi; kullanıcı uygulamayı açtığında 0 ms loading hissi yaratır.
- Geofencing tetikleyici: Sunucu tarafı geofence işleyişi için cihazdaki bir hesaplamayı tetiklemek.
- Telemetri toplama: Crash / performance metric’lerinin uzun süre kuyrukta beklemesi yerine periyodik flush tetiklenmesi.
Android tarafında silent push, FCM data message ile yapılır. WorkManager ve BroadcastReceiver kombinasyonu içeriğin işlenmesini esnek hale getirir. Ancak Android 12+ ile birlikte gelen Foreground Service kısıtlamaları, data message’ın uzun süreli işlemi tetiklemesini güçleştiriyor; uzun iş ihtiyacı varsa expedited WorkManager job ve “high priority” data message kombinasyonu önerilir. Yanıltıcı silent push kullanımı (örn. visible alert göstermeden kullanıcı verisi toplama) Google Play ve App Store review süreçlerinde red sebebidir.
OneSignal, Airship, Braze, Iterable: vendor karşılaştırması
APNs ve FCM altyapısını doğrudan kullanmak teknik olarak mümkündür ancak segmentasyon, journey orchestration, A/B test ve raporlama için çoğu ekip vendor SDK’sı tercih ediyor. Pazarda dört büyük oyuncu var: OneSignal (geniş freemium), Airship (kurumsal, yüksek hacim), Braze (omnichannel CRM odaklı) ve Iterable (B2C marketing automation). Seçim, kullanıcı tabanı büyüklüğüne, kanal çeşitliliğine ve veri ekipliğinin self-serve kapasitesine bağlıdır.
| Vendor | Güçlü tarafı | Zayıf tarafı | Tipik müşteri profili | Lisans modeli |
|---|---|---|---|---|
| OneSignal | Hızlı entegrasyon, generous free tier, geniş SDK desteği | Kurumsal segment/journey yetenekleri sınırlı | Startup, indie geliştirici, orta ölçek | Freemium + MAU bazlı |
| Airship | Live Activity, contextual notification, kurumsal SLA | Maliyet yüksek, learning curve dik | Havayolu, perakende devleri, medya | Volume + feature pack |
| Braze | Canvas journey builder, multi-channel orchestration, Liquid templating | Implementasyon süresi uzun, pricing opak | D2C marka, retail, fintech | MAU + message volume |
| Iterable | Email + push + SMS unified, AI Optimizer | Mobil-first değil, push bazı senaryolarda eksik | SaaS, e-ticaret, B2C marketing | Contact + send bazlı |
| Self-hosted (APNs+FCM direkt) | Maliyet 0, full kontrol, veri sahipliği | Segment, journey, raporlama kod ile | Büyük ekip, regülasyon ağır sektörler | Geliştirme efforu |
Vendor seçiminde sık yapılan hata, “en güçlü olanı al” yaklaşımıdır. Aktif kullanıcı sayısı 100 binin altında olan bir uygulamanın Airship lisans maliyetini absorbe etmesi mümkün değildir; OneSignal veya self-hosted çözüm daha mantıklıdır. Öte yandan haftalık 50 milyon push gönderen bir e-ticaret platformu için Braze veya Airship’in journey builder ve A/B test motoru, kendi içeride kurmaya çalışacağı sistemden hem ucuz hem daha hızlı sonuç verir. Build vs Buy değerlendirme çerçevesi push platformu için de aynen geçerlidir.
Segmentasyon, frekans tavanı ve send-time optimization
Push kanalını “broadcast” mantığıyla kullanmak en hızlı kullanıcı kaybı yoludur. Localytics 2025 churn raporuna göre günde 3’ten fazla pazarlama push’u alan kullanıcıların %71’i bir hafta içinde uygulamayı silmiş ya da bildirimleri kapatmıştır. Modern push programı segmentasyon temellidir; kullanıcılar davranış kategorisine, hayat döngüsü aşamasına ve zaman dilimine göre bölünür.
- Lifecycle segmenti: Yeni kayıtlı, aktif, dormant (15+ gün etkileşimsiz), risk altında (30+ gün), churn (90+ gün) gruplarına ayır.
- Behavior segmenti: Sık satın alan, browse-only, kategori-spesifik takipçi (örn. sadece spor ayakkabı), promosyon avcısı, premium üye.
- Frequency cap: Kullanıcı başına günlük 2, haftalık 7 pazarlama push tavanı; transactional (sipariş, ödeme) push’lar bu limitin dışında tutulur.
- Send-time optimization: Kullanıcının uygulamada aktif olduğu saati öğrenip o pencerede gönderim; Airship verilerine göre open rate’i %20-35 artırır.
- Channel preference: Aynı içeriği farklı bildirim kategorilerine (NotificationChannel / UNNotificationCategory) ata; kullanıcı sadece “sipariş durumu” ya da sadece “kampanyalar” kategorisini kapatabilsin.
- Quiet hours: 22:00-08:00 lokal saat aralığında sadece kritik (transactional) push; pazarlama mesajları kuyruğa alınır.
- Holdout grubu: Her kampanyanın %5-10’una push hiç gönderme; gerçek inkremental etkiyi ölç.
Send-time optimization, 2026’da artık premium vendor özelliği değil, OneSignal dahil çoğu platformun varsayılan kapasitesi. Yapay zeka tabanlı model her kullanıcı için “muhtemel açma penceresi” tahmini yapar ve mesaj o ana kuyruklanır. Bunun sınırı, kampanyanın zamana duyarlı olup olmamasıdır: indirim kuponu bugün geçerliyse “ideal saat” yarın olamaz; bu durumda time-bound gönderim ve send-time optimization birlikte kullanılır.
Ölçüm çerçevesi: opt-in, delivery, open, conversion ve unsubscribe
Başarılı push programının ölçümü tek bir metrikle yapılmaz; tüm huniyi takip eder. Yatırımın geri dönüşünü, push’tan gelen kullanıcının uzun vadeli LTV katkısıyla değerlendirmek gerekir. Aşağıdaki metrikler 2026’da endüstri standardı kabul edilen referans aralıklarla birlikte verilmiştir.
- Opt-in rate: Sistem izni veren kullanıcı / aktif kullanıcı. Hedef: iOS’ta %60+, Android’de %75+. Pre-permission düzgün kurulduğunda iOS’ta %70’e ulaşılabilir.
- Delivery rate: Teslim edilen / gönderilen. APNs/FCM feedback ile ölçülür. Hedef %95+; düşükse token temizliği yapılmalı (uninstall, geçersiz token).
- Open rate (CTR): Push’a tıklayan / teslim edilen. Sektör ortalaması %4-8, iyi kampanyada %15+, rich push ile %20+.
- Direct conversion: Push’tan gelen kullanıcının hedef aksiyonu (satın alma, kayıt, etkileşim) tamamlama oranı.
- Influenced conversion: 24 saat içinde organik olarak dönen ancak push’a maruz kalmış kullanıcılar; gerçek etkinin büyük kısmı buradadır.
- Unsubscribe rate: Bildirim iznini geri çekenler. %2’nin altında tutulmalı; üzerinde ise frekans veya alaka problemi vardır.
- App uninstall after push: 7 gün içinde push aldıktan sonra uygulamayı silenler; spam sinyalinin nihai göstergesi.
Ölçüm tarafında en kritik araç attribution platformudur. Push’tan gelen kullanıcının organik mi yoksa push tetikli mi olduğunu ayırmak için Adjust, AppsFlyer veya Branch entegrasyonu gerekir. Universal Link ve App Link yapılandırması doğru kurulmadığında push tıklamaları yanlış kanal’a atfedilir ve ROI hesabı bozulur. Deep link parametre standardı (kampanya, segment, varyant) her push’ta tutarlı olmalı ve sunucu tarafında loglama yapılmalıdır.
2026 sınırlamaları: iOS 18 Focus, Android 15 Modes ve OEM filtreleri
iOS 18 ile birlikte Focus modu (Çalışma, Uyku, Konsantrasyon vb.) daha güçlü bir bildirim akış kontrol mekanizması haline geldi; kullanıcılar artık uygulama bazında değil “bağlam” bazında bildirimleri filtreleyebiliyor. Apple WWDC 2024 sunumlarında belirtildiği gibi, Time Sensitive ve Critical Alert işaretlemesi yapmayan pazarlama push’ları varsayılan olarak özet kuyruğa düşüyor; bu özetler sabah ve akşam toplu sunuluyor. Pratikte bu, “doğru saatte gönder” kuralının daha da önemli hale gelmesi demek.
Android 15 Modes özelliği, iOS Focus’un kavramsal benzeridir ve kullanıcının bildirim filtresini görev/durum bazında yönetmesini sağlar. Aynı zamanda Samsung One UI 7, Xiaomi HyperOS, OPPO ColorOS gibi OEM katmanlarında bağımsız agresif battery saver’lar mevcut; bunlar FCM bağlantısını uyku modunda kesiyor. Don’t Kill My App benzeri toplulukların belgelediği gibi, bazı cihazlarda push delivery rate’i %60’a kadar düşebiliyor. Çözüm: kullanıcıdan ilgili pil ayarına uygulamayı eklemesini istemek ve high-priority data message kullanmak.
Regülasyon tarafında KVKK ve GDPR, transactional push’u (sipariş onayı, ödeme bildirimi) “rıza gerektiren bir işleme” olarak görmez; ancak pazarlama push’ları için açık rıza zorunludur. Pre-permission ekranı pazarlama izninin nasıl alındığını ve kapsamını kayıt altına almalıdır. Apple App Store inceleme rehberinin 4.5.4 numaralı maddesi push notification’ın spam veya yanıltıcı amaçla kullanılmasını yasaklar; ihlali uygulama reddi anlamına gelir. Google Play Developer Program Policies aynı çerçeveyi 2024 itibariyle daha sıkı yorumluyor.
Sık Sorulan Sorular
FCM her zaman APNs üzerine tercih edilmeli mi?
Hayır, ihtiyaca göre değişir. FCM çapraz platform geliştirme verimliliği, topic gönderimi ve Firebase Analytics entegrasyonu açısından avantajlıdır; çoğu orta ölçekli ekip için doğru karar FCM’dir. Ancak finansal uygulamalar, gerçek zamanlı alert ve VoIP senaryolarında APNs’i doğrudan kullanmak en düşük gecikmeyi ve maksimum kontrolü sağlar. Büyük ekipler genelde “FCM ile Android, doğrudan APNs ile iOS” hibrit kurulumu yapar; veri sahipliği ve gizlilik kaygıları olan kurumlar self-hosted segmentasyon motoru üstüne APNs+FCM ham kullanımı tercih eder.
Pre-permission yasal olarak gerekli mi?
Yasal zorunluluk değildir ancak Apple Human Interface Guidelines ve App Store inceleme rehberi tarafından kuvvetle önerilir. KVKK ve GDPR push bildirimini “rıza gerektiren işleme” olarak görmez; transactional (örn. sipariş bilgisi) push için ayrı rıza gerekmez, sözleşmenin ifası kapsamındadır. Pazarlama push’ları için açık rıza şarttır; pre-permission ekranı bu rızanın hangi kapsamda, hangi tarihte ve hangi sürümle alındığını kayıt altına almalıdır. Kullanıcıya iznini geri çekme yolunu (in-app preferences) açık biçimde sunmak da regülatif beklenti.
Web push ile mobil push arasındaki temel farklar nelerdir?
Web push, tarayıcı üzerinden Service Worker ile gönderilir ve VAPID protokolünü kullanır; payload boyutu sınırlı, deep link yetenekleri kısıtlı, opt-in oranı ortalama %5-12 seviyesindedir. Mobil push native SDK üzerinden APNs/FCM ile gönderilir; çok daha zengin payload (görsel, video, action button), deep link, Universal Link, silent background tetikleme ve Live Activity gibi yetenekler destekler. Opt-in oranı pre-permission ile %60-80 aralığında. İki kanal birbirinin tamamlayıcısıdır; web push, mobil app indirmek istemeyen kullanıcılarla iletişimi sürdürmenin tek yoludur, mobil push ise sadık kullanıcı tabanı için yüksek ROI kanalıdır.
Push gönderimi için optimum saat var mı?
Tek bir global “en iyi saat” yoktur; kullanıcı zaman dilimi, vertikal ve davranış kalıbına göre belirlenir. Airship Mobile Consumer Report 2025 verisine göre haber ve perakende uygulamaları 10:00-12:00 ve 19:00-21:00 lokal saatlerde en yüksek açılma oranı görür; fintech alert’leri sabah 08:00-09:00 ve akşam 17:00-18:00 saatlerinde; oyun uygulamaları akşam 20:00-23:00 aralığında. Send-time optimization (STO) algoritması kullanıcı bazında öğrenir ve genel kuralları aşar; STO açık olduğunda open rate %20-35 oranında iyileşir. Time-bound kampanyalarda (örn. flaş indirim) STO devre dışı bırakılır.
Push kullanıcıları çok hızlı tükenirse ne yapılmalı?
Unsubscribe rate’i %2 üzerine çıkıyorsa veya 7 gün içinde push aldıktan sonra uninstall eden kullanıcı oranı artıyorsa üç müdahale gerekir: önce frekans tavanını sıkılaştırın (günde 1-2 pazarlama push’a düşürün), ikinci olarak segmentasyonu derinleştirin (geniş broadcast yerine davranış tabanlı küçük segmentler), üçüncü olarak alaka kalitesini ölçmek için A/B test ve holdout grubu açın. Bildirim kategorileri (NotificationChannel) sayesinde kullanıcı her kategoriyi ayrı kapatabilir; bu, “ya hep ya hiç” izin modeline göre uninstall’u %40 azaltır (Braze, 2024). Son çare olarak “Bildirimleri geçici sustur” (snooze) seçeneği sunmak da retention’a olumlu yansır.
Sonuç: vertikale göre push stratejisi kararı
Push doğru tasarlandığında en yüksek ROI veren kanaldır; yanlış tasarlandığında en hızlı uninstall sebebidir. Vertikale göre öneri: E-ticaret için contextual pre-permission, Braze/Iterable journey, STO aktif; fintech için APNs doğrudan, Critical Alert, transactional/pazarlama ayrımı; haber-medya için kategori bazlı opt-in, breaking-news ayrı kanal; oyun için event-driven tetikleyici ve retention bazlı segment; SaaS için Live Activity ve düşük frekans yüksek alaka. 2026’nın kısıtlayıcı izin modelinde başarı, teknik kurulumdan çok kullanıcı niyetine saygılı tasarım ve disiplinli frekans yönetimi ile gelir.
İlgili rehberler: Mobil Deep Link ve Universal Link, Mobil CI/CD, Mobil Crash Reporting, React Native vs Flutter 2026. Otorite kaynaklar: Apple User Notifications, Firebase Cloud Messaging, Airship, Braze, OneSignal, Iterable, Apple HIG Notifications.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.