Push İzin Oranını Artırmak: Zamanlama, Bağlam ve Ölçüm

Push bildirim izin oranı, kullanıcının uygulamanla kurduğu ilk ciddi güven testidir: sistem diyaloğu bir kez çıkar, kullanıcı "İzin Ver" ya da "İzin Verme" der ve bu karar genellikle kalıcıdır. Bu yazıda iOS ve Android'in resmi dokümantasyonuna dayanarak ön-izin (priming) ekranlarını, doğru zamanlamayı, provisional yetkilendirmeyi ve izin oranını nasıl ölçeceğini adım adım göreceksin.

💡 Pro Tip: İzin diyaloğunu göstermeden önce kendine şunu sor — kullanıcı şu an bildirimin _ne işine yarayacağını_ biliyor mu? Cevap hayırsa diyaloğu henüz göstermemelisin.

İçindekiler

• Sistem Diyaloğunun Tek Şansı: Neden Geri Dönüşü Zor
• iOS: Bir Kez Sor, Bir Daha Sorma
• Android: 12L ve Altında Ret Sonrası Kısıtlı Erişim
• Ön-izin (Priming) Ekranı: Bağlamla İzin İstemek
• Neden Bağlam Önemli
• Zamanlama: Değer Anını Bulmak
• iOS: İlk Somut Eylem Sonrası
• Android: Tanışma Süresi ve Eylem Tetikleyicileri
• Zamanlama Kararını Nasıl Doğrularsın
• Geçici (Provisional) Yetkilendirme Ne Zaman İşe Yarar
• `provisional` Seçeneği Nasıl Çalışır
• Reddedenler İçin Ayarlara Yönlendirme Akışı
• Ölçüm: İzin Oranı, Teslim, Açılma ve Kapatma
• Sık Yapılan 6 Hata
• SSS
• Push bildirim izin oranı nasıl artırılır?
• İzni ne zaman istemeliyim?
• Reddedilen izin geri kazanılabilir mi?
• Provisional yetkilendirme her bildirim türü için uygun mu?
• İzin oranı ile teslim oranı aynı şey mi?
• Ön-izin ekranı gerçekten izin oranını artırır mı?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Sistem Diyaloğunun Tek Şansı: Neden Geri Dönüşü Zor

iOS'ta sistem izin diyaloğu pratikte tek seferliktir. Apple'ın kendi dokümantasyonu bunu açıkça belirtir: ilk istekten sonraki çağrılar kullanıcıya tekrar sorulmaz.

iOS: Bir Kez Sor, Bir Daha Sorma

Apple'ın UserNotifications framework dokümantasyonunda şu cümle geçer: "Subsequent authorization requests don't prompt the person." Yani requestAuthorization metodunu ikinci kez çağırdığında sistem kullanıcıya yeni bir diyalog göstermez; önceki kararı (verildi/reddedildi) aynen döner. Kullanıcı fikrini değiştirmek isterse tek yol Ayarlar uygulamasıdır.

Bu, advanced-push-notifications yazısının ele aldığı APNs teslim mekanizmasından bağımsız bir konudur — orada "nasıl gönderirim" sorusuna, burada "nasıl izin alırım" sorusuna odaklanıyorsun. Detaylı APNs ve rich media kurulumu için Advanced Push Notifications: APNs'ten Rich Media'ya Her Şey yazısına bakabilirsin.

Apple ayrıca bildirim teslimini garanti etmediğini de belirtiyor: "The system makes every attempt to deliver local and remote notifications in a timely manner, but delivery isn't guaranteed." Yani izin oranını yükseltmek teslim oranını otomatik garanti etmez — iki farklı metriktir, ayrı ayrı izlenmeli.

Android: 12L ve Altında Ret Sonrası Kısıtlı Erişim

Android tarafında durum sürüm hedeflemesine göre değişir. Google'ın resmi dokümantasyonu şöyle diyor: "If your app targets 12L or lower and the user taps Don't allow, even just once, they aren't prompted again until they uninstall and reinstall your app, or you update your app to target Android 13 or higher." Yani API 32 ve altını hedefleyen bir uygulamada tek bir "İzin Verme" tıklaması, uygulamayı silip yeniden kurana ya da targetSdkVersion'ı 33+'a yükseltene kadar geçerli bir ret anlamına gelir. Sistem bu diyaloğu genelde ilk bildirim kanalını oluşturduktan sonraki ilk activity başlatmasında gösterir — Google'ın ifadesiyle "usually on app startup".

Android 13 (API 33) ile gelen POST_NOTIFICATIONS çalışma zamanı izni bu davranışı biraz yumuşatır, ama temel kural aynı kalır: kullanıcı reddettikten sonra tekrar sorma hakkın sistem tarafından kısıtlanır (ya da targetSdk yükseltmesiyle geri gelir). Bu yüzden her iki platformda da "ilk sorduğunda doğru sormak" tek şansındır.

Stratejiye geçmeden önce iki platformun izin modelini yan yana koymak faydalı — çünkü zamanlama ve geri kazanma taktikleri bu farklara göre şekillenir:

Bu tablo, ilerideki bölümlerde iOS ve Android için neden ayrı zamanlama ve geri kazanma stratejisi önerildiğinin kısa özeti.

Ön-izin (Priming) Ekranı: Bağlamla İzin İstemek

Ön-izin ekranı, sistem diyaloğundan önce gösterdiğin kendi tasarımındaki bir açıklama ekranıdır. Amacı basit: kullanıcı sistem diyaloğunu görmeden önce "neden" sorusuna cevap bulsun.

Neden Bağlam Önemli

Apple'ın kendi tavsiyesi net: "Make the request in a context that helps people understand why your app needs authorization." Ve devamında karşılaştırma yapıyor: "Sending the request in context provides a better experience than automatically requesting authorization on first launch, because people can see the purpose your app's notifications serve."

Bu iki cümle aslında tüm stratejinin özeti: uygulamayı açar açmaz otomatik izin isteme. Bunun yerine kullanıcının bildirimin değerini _deneyimlediği_ ana kadar bekle, sonra iste.

Ön-izin ekranında dikkat etmen gerekenler:

• Somut fayda yaz: "Bildirim gönderelim mi?" değil, "Siparişin kapına geldiğinde haber verelim mi?" gibi net bir vaat.
• Çıkış yolu bırak: "Şimdi değil" seçeneği olmayan bir ekran, kullanıcıyı doğrudan sistem diyaloğuna zorlar ve reddi kalıcı hale getirir.
• Tek soruya odaklan: Aynı ekranda konum + bildirim + kamera izni birlikte istenirse hepsi reddedilme riskiyle karşı karşıya kalır.

Zamanlama: Değer Anını Bulmak

Ön-izin ekranının içeriği kadar, _ne zaman_ gösterildiği de belirleyici. Her iki platform da aynı prensibi farklı kelimelerle anlatıyor: kullanıcı bir değer anı yaşadıktan sonra sor.

iOS: İlk Somut Eylem Sonrası

Apple, görev takibi yapan bir uygulama örneği veriyor: "In a task-tracking app that sends reminder notifications, you might make the request after the person schedules a first task." Yani kullanıcı ilk hatırlatıcısını kurduktan hemen sonra izin iste — bildirimin ne işe yarayacağını az önce kendisi tanımladı.

1func scheduleFirstReminder(for task: ReminderTask) {
2    NotificationScheduler.saveLocally(task)
3 
4    // Kullanıcı ilk görevini planladı — bildirimin
5    // değerini az önce kendisi tanımladı, izin istemek için doğru an.
6    UNUserNotificationCenter.current().requestAuthorization(
7        options: [.alert, .sound, .badge]
8    ) { granted, error in
9        guard granted else { return }
10        NotificationScheduler.scheduleReminder(for: task)
11    }
12}

Android: Tanışma Süresi ve Eylem Tetikleyicileri

Google'ın tavsiyesi de aynı yönde: "Before you ask users to grant any permissions, let them familiarize themselves with your app." Google somut tetikleyici örnekleri de veriyor: "The user taps an 'alert bell' button. The user chooses to follow someone's social media account. The user submits an order for food delivery." Alternatif olarak zaman bazlı bir eşik de öneriliyor: "you might wait until the third or fourth time the user launches your app."

Android 13 ve üstünü hedefleyen uygulamalarda bu zamanlama tamamen senin kontrolünde: "If your app targets Android 13 or higher, your app has complete control over when the permission dialog is displayed." Hedeflemeyen eski uygulamalarda ise sistem izni genelde otomatik ve uygulama açılışında gösterir — bu yüzden targetSdkVersion'ı 33+ yapmak, zamanlama stratejisinin ön koşuludur.

1class OnboardingFlow(private val activity: Activity) {
2 
3    // Kullanıcı ilk siparişini verdi — Google'ın önerdiği
4    // "eylem tetikleyicili" andayız, izin isteği burada.
5    fun onOrderSubmitted() {
6        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
7            val hasPermission = ContextCompat.checkSelfPermission(
8                activity, Manifest.permission.POST_NOTIFICATIONS
9            ) == PackageManager.PERMISSION_GRANTED
10 
11            if (!hasPermission) {
12                ActivityCompat.requestPermissions(
13                    activity,
14                    arrayOf(Manifest.permission.POST_NOTIFICATIONS),
15                    NOTIFICATION_PERMISSION_REQUEST_CODE
16                )
17            }
18        }
19    }
20 
21    companion object {
22        const val NOTIFICATION_PERMISSION_REQUEST_CODE = 1001
23    }
24}

AndroidManifest.xml'e izni eklemeyi unutma — Google'ın ifadesiyle bu, uygulamanın manifest dosyasında tanımlaman gereken izindir:

1<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

Zamanlama Kararını Nasıl Doğrularsın

Zamanlama tavsiyeleri ("ilk görevden sonra", "üçüncü açılışta") bir başlangıç noktasıdır, kesin kural değil. Kendi uygulamanda doğru anı bulmak için şu adımları izleyebilirsin:

1. Uygulamanın kritik değer anını tanımla (ilk sipariş, ilk mesaj, ilk hatırlatıcı gibi kullanıcının "aha" dediği eylem).
2. İzin isteğini bu andan hemen sonraya, mümkünse aynı ekran akışının bir parçası olarak yerleştir.
3. İki farklı kohortta (ör. "eylem sonrası" vs "üçüncü açılışta") izin oranını ayrı ayrı izle ve karşılaştır.
4. Kararı tek bir gün üzerinden değil, en az bir-iki haftalık pencere üzerinden ver — kullanıcı davranışı gün içi dalgalanabilir.

Bu döngüyü tekrarlanabilir kıldığında, "doğru zamanlama" bir tahmin olmaktan çıkıp kendi verinle doğruladığın bir karara dönüşür.

Geçici (Provisional) Yetkilendirme Ne Zaman İşe Yarar

iOS'ta üçüncü bir yol daha var: kullanıcıya hiç sormadan, sessiz bir deneme süreci başlatmak.

`provisional` Seçeneği Nasıl Çalışır

Apple'ın tanımı açık: "Use provisional authorization to send notifications on a trial basis." Bu seçenek eklendiğinde sistem kullanıcıya soru sormadan otomatik yetki verir: "the first time you call this method, it automatically grants authorization." API referansındaki tanım da bunu doğrular: "The ability to post noninterrupting notifications provisionally to the Notification Center."

Provisional bildirimlerin davranışı normal bildirimlerden farklıdır — Apple şöyle açıklıyor: "The system delivers provisional notifications quietly — they don't interrupt the person with a sound or banner, or appear on the lock screen." Yani ses yok, banner yok, kilit ekranında görünmüyor; yalnız Bildirim Merkezi'nde birikir. Kullanıcı bunları gördüğünde karar verebilsin diye "buton"lar da eklenir: "These notifications also include buttons that prompt the person to keep or turn off the notification."

1func requestProvisionalAuthorization() {
2    let center = UNUserNotificationCenter.current()
3 
4    // İlk çağrıda sistem otomatik yetki verir, kullanıcıya
5    // hiçbir diyalog göstermez — bildirimler sessizce birikir.
6    center.requestAuthorization(options: [.alert, .badge, .sound, .provisional]) { granted, error in
7        if let error = error {
8            print("Provisional authorization error: \(error)")
9        }
10    }
11}

Provisional hangi durumda işe yarar, hangisinde yaramaz:

Provisional bir "izin oranını yükseltme hilesi" değildir — kullanıcı hâlâ her bildirimde "sakla/kapat" kararı verir. Amacı, sistem diyaloğunun getirdiği ilk temas sürtünmesini azaltıp bildirimin değerini kullanıcıya _gösterdikten_ sonra tam yetkiye geçmesini kolaylaştırmaktır.

Reddedenler İçin Ayarlara Yönlendirme Akışı

Kullanıcı bir kez reddettiğinde uygulama içinden tekrar sistem diyaloğu tetiklenemez; tek yol kullanıcıyı platformun kendi Ayarlar ekranına yönlendirmektir. Apple bunun teknik temelini şöyle özetliyor: "Always check your app's authorization status before scheduling local notifications." Yani önce mevcut durumu oku, sonra buna göre davran.

Bu kontrolden sonra kullanıcıyı yönlendirmek istersen, her iki platform da bunun için standart, dokümante edilmiş bir sistem API'si sunar: iOS'ta UIApplication.openSettingsURLString, Android'de Settings.ACTION_APP_NOTIFICATION_SETTINGS intent'i uygulamanın kendi bildirim ayar sayfasını açar. Bu akışı UI'da göstermeden önce mutlaka mevcut durumu oku — reddetmemiş bir kullanıcıyı gereksiz yere Ayarlar'a göndermek, deneyimi kötüleştirir.

Android tarafında reddin sonucu daha katıdır. Google şöyle özetliyor: "If the user selects the don't allow option, your app can't send notifications unless it qualifies for an exemption." Sayfanın kendi ifadesiyle bu istisnalar sınırlıdır: "All notification channels are blocked, except for a few specific roles." Somut olarak yalnız ikisi: medya oturumuyla ilişkili bildirimler ("Notifications related to media sessions are exempt from this behavior change.") ve kendi telefon çağrısını Notification.CallStyle ile yöneten uygulamalar (MANAGE_OWN_CALLS + ConnectionService + registerPhoneAccount birlikte sağlanırsa POST_NOTIFICATIONS gerekmez). Foreground service bildirimleri bu istisnaya girmez: izin reddedildiğinde bu bildirimler artık bildirim çekmecesinde görünmez, yalnızca Görev Yöneticisi'nde görünmeye devam eder — bu yüzden Android'de "Ayarlar'a yönlendir" akışı, iOS'a göre daha kritik bir geri kazanma mekanizmasıdır.

Ölçüm: İzin Oranı, Teslim, Açılma ve Kapatma

İzin oranını doğru ölçmek için önce hangi sinyalin neyi söylediğini ayırt etmen gerekir. Apple'ın API'si sana cihaz-taraflı bir durum döner; bu bir analytics platformu değil, ama izin durumunu doğrulamanın tek güvenilir yoludur.

1UNUserNotificationCenter.current().getNotificationSettings { settings in
2    // Cihazdaki gerçek durum — sunucu tarafı tahmin değil.
3    // Apple'ın kendi ölçüm örneği authorized ve provisional'ı birlikte
4    // kontrol eder; burada ikisini AYRI logla ki provisional
5    // kullanıcılar "izinsiz" sayılıp yanlış rapor üretmesin.
6    let isAuthorized = settings.authorizationStatus == .authorized
7    let isProvisional = settings.authorizationStatus == .provisional
8    let alertsEnabled = settings.alertSetting == .enabled
9 
10    AnalyticsLogger.log(
11        event: "notification_status_checked",
12        properties: [
13            "authorized": isAuthorized,
14            "provisional": isProvisional,
15            "alerts_enabled": alertsEnabled
16        ]
17    )
18}

Bu dört sinyali tek seferlik değil, kohort bazında izlemek daha anlamlı sonuç verir. Örneğin bu hafta yeni kayıt olan kullanıcıların izin oranını, geçen ay kayıt olanlarla karşılaştırmak; ön-izin ekranında yaptığın bir metin değişikliğinin gerçekten işe yarayıp yaramadığını gösterir. Tek bir günlük anlık ölçüm, hafta içi/hafta sonu farkı veya kampanya dönemleri gibi gürültüden kolayca etkilenir.

Pratik bir yöntem: kullanıcıyı ilk oturumundan itibaren bir kohort kimliğiyle etiketle, izin isteğinin gösterildiği ve cevaplandığı anları event olarak logla, sonra her kohort için izin oranını (authorized / toplam istek gösterilen) haftalık olarak raporla. Bu, ön-izin ekranındaki her değişikliğin etkisini izole bir şekilde görmeni sağlar.

Bu dört sinyali karıştırmamak önemli — her biri farklı bir sorunun cevabıdır:

Apple'ın da hatırlattığı gibi teslim garanti edilmez, bu yüzden "gönderdim" ile "ulaştı" arasındaki farkı ayrı bir metrik olarak tutmak, izin oranı optimizasyonunun neyi değiştirdiğini net görmeni sağlar.

Sık Yapılan 6 Hata

• Otomatik ilk-açılış isteği: Apple'ın "bağlam içinde iste" tavsiyesinin tam tersi — kullanıcı uygulamayı ne olduğunu bile anlamadan diyalogla karşılaşır ve genelde reddeder.
• 12L ve altı hedeflerken sistemin otomatik zamanlamasına güvenmek: Android'de bu, kendi bağlamını kurmadan sorulan bir istek anlamına gelir; tek bir ret, uygulamayı silip yeniden kurana ya da targetSdkVersion'ı 33+'a yükseltene kadar geçerli olur.
• POST_NOTIFICATIONS iznini manifest'e eklemeden veya runtime'da istemeden bildirim göndermeye çalışmak: kullanıcı izni onaylamadığı sürece bildirimler kullanıcıya ulaşmaz — bu durum hata fırlatmaz, log'da fark etmeyebilirsin.
• Provisional'ı izin oranını "yükseltmek" için kötüye kullanmak: Kritik veya zaman-hassas bildirimleri provisional göndermek, kullanıcının en çok görmesi gereken anda sessiz kalır.
• Tüm izinleri tek ekranda birden istemek: Bildirim + konum + kamera aynı akışta sorulunca reddedilme riski birikir; her izni kendi bağlamında, ayrı ayrı iste.
• Durumu hiç kontrol etmeden yeniden istek göndermek: getNotificationSettings/checkSelfPermission çağırmadan tekrar requestAuthorization denemek, zaten reddedilmiş bir kullanıcıya hiçbir şey göstermeyen ölü kod yazmaktır.

SSS

Push bildirim izin oranı nasıl artırılır?

İzin oranını artırmanın temeli, sistem diyaloğunu kullanıcının bildirimin değerini deneyimlediği anda göstermektir. Apple ve Android'in ortak tavsiyesi budur: otomatik ilk-açılış isteği yerine, bağlam içinde ve ilk somut eylemden sonra iste. iOS'ta ayrıca provisional yetkilendirme ile düşük riskli bildirimleri sessizce deneyime sokup kullanıcının kendi kararını vermesini sağlayabilirsin.

İzni ne zaman istemeliyim?

Kullanıcı uygulamanla en az bir kez anlamlı bir eylem tamamladıktan sonra. Apple bunu "kullanıcı ilk görevini planladıktan sonra" örneğiyle anlatıyor; Google ise "üçüncü-dördüncü açılış" veya belirgin bir eylem (sipariş verme, birini takip etme) tetikleyicisini öneriyor. Apple, bağlamı özenle kursan bile kullanıcının karar vermek için yeterli bilgiye sahip olmayabileceğini ve isteği yine de reddedebileceğini belirtiyor.

Reddedilen izin geri kazanılabilir mi?

Uygulama içinden değil. Sistem diyaloğu bir kez cevaplandıktan sonra tekrar tetiklenmez; tek yol kullanıcıyı platformun kendi bildirim ayarları ekranına yönlendirmektir (iOS'ta openSettingsURLString, Android'de ACTION_APP_NOTIFICATION_SETTINGS). Android 12L ve altını hedefleyen uygulamalarda tek bir ret, uygulamayı silip yeniden kurana ya da targetSdkVersion'ı 33+'a güncelleyene kadar geçerlidir.

Provisional yetkilendirme her bildirim türü için uygun mu?

Hayır. Provisional, sessiz ve düşük riskli bildirimler için tasarlanmıştır — ses/banner göstermez, kilit ekranında görünmez. Zaman-kritik veya güvenlik amaçlı bildirimlerde kullanıcı bunu fark etmeyebilir, bu yüzden bu tür bildirimler için tam yetkilendirme istemek daha doğrudur.

İzin oranı ile teslim oranı aynı şey mi?

Hayır, ikisi farklı metriklerdir. İzin oranı kaç kullanıcının "İzin Ver" dediğini gösterir; teslim ise gönderdiğin bildirimin gerçekten cihaza ulaşıp ulaşmadığını. Apple'ın kendi dokümantasyonu bile teslimi garanti etmediğini belirtiyor, bu yüzden yüksek izin oranı tek başına yüksek teslim oranı anlamına gelmez — ikisini ayrı ayrı izlemelisin.

Ön-izin ekranı gerçekten izin oranını artırır mı?

Doğru kurgulandığında evet, ama garantisi yok — bu yüzden bu makaledeki Altın İpucu'nda önerilen öncesi/sonrası testini kendi uygulamanda çalıştırmalısın. Apple'ın tavsiyesi net bir yönde: bağlam içinde isteğin, otomatik ilk-açılış isteğinden daha iyi bir deneyim sunduğu belirtiliyor. Ama "daha iyi deneyim" ile "daha yüksek izin oranı" her zaman birebir örtüşmeyebilir; ekranın metni, zamanlaması ve çıkış seçeneği kalitesi sonucu değiştirir.

Güncelleme (Eylül 2026)

Bu makalenin gövdesi 2024-12-11 tarihindeki platform davranışını anlatır. O tarihten bu yana bir gelişme, izin oranı stratejisini doğrudan ilgilendiriyor:

• Android 16 (10 Haziran 2025) Notification.ProgressStyle ile ilerleme-odaklı bildirimleri getirdi; Google bunu Live Updates'in temeli olarak tanımlıyor ve Live Updates'in sonraki bir Android 16 güncellemesinde tamamlanacağını söylüyor. Bu, izin/kategori stratejini kurarken "hangi bildirim türü hangi önceliğe girer" sorusuna yeni bir seçenek ekliyor.

Bu değişiklik provisional API'sini veya POST_NOTIFICATIONS çalışma zamanı iznini değiştirmedi — bu yazının teknik çekirdeği hâlâ geçerli, yukarıdaki yalnızca stratejiye eklenen yeni bir katman.

Sonradan yayımlanan ilgili yazılar:

• TipKit: iOS Onboarding ve Feature Discovery Pattern Rehberi
• App Store Optimization (ASO): Uygulamanı Keşfettir
• iOS App Store'da $1M Kazandım: Gerçek Strateji ve Rakamlar
• WorkManager 2.10 Coroutines: Background Task Modern Yaklaşım

Sonuç

Push bildirim izin oranı tek bir ekranın değil, tüm onboarding akışının sonucudur: doğru zamanlama, bağlamlı bir ön-izin ekranı ve (iOS'ta) provisional yetkilendirmenin doğru kullanımı bir araya geldiğinde kalıcı bir ret riskini azaltır. Reddedenler için geri kazanma akışını da hazırda tutmak, bu oranın zamanla düşmesini engeller.

Bildirimin teknik teslim tarafı için Advanced Push Notifications: APNs'ten Rich Media'ya Her Şey yazısına bakabilirsin.

Kaynaklar

• Apple — Asking permission to use notifications — sistem diyaloğunun tek seferliği, bağlam içinde isteme tavsiyesi ve provisional yetkilendirme tanımı.
• Apple — UserNotifications framework overview — bildirim teslim mekanizmasının garanti edilmediğine dair resmi açıklama.
• Apple — UNAuthorizationOptions.provisional API referansı — provisional seçeneğinin API tanımı.
• Android Developers — Notification runtime permission — POST_NOTIFICATIONS izni, 12L ve altı davranışı, zamanlama tavsiyeleri.
• Android Developers Blog — Android 16 is here — Android 16 genel kullanım tarihi, Notification.ProgressStyle ve Live Updates'in temeli olduğu açıklaması.