---
title: "Push Bildirimi Tasarımı: Uygulama Silinmeden Bildirmek"
url: "https://cilginyazilim.com/blog/push-bildirimi-tasarimi-uygulama-silinmeden"
description: "Push bildirimi tasarımı yanlış yapıldığında uygulama silinir. İzin isteme zamanı, sıklık, segmentasyon ve derin bağlantı: sahadan çıkan kurallar."
published: "2026-10-25T10:00:00+03:00"
modified: "2026-10-25T10:00:04+03:00"
author: "Çılgın Yazılım"
category: "Mobil ve Oyun Geliştirme"
tags: ["mobil geliştirme", "kullanıcı deneyimi", "analitik", "izin yönetimi", "deep link", "bildirim", "push bildirimi", "firebase", "segmentasyon", "uygulama tutundurma", "mobil uygulama", "ux"]
site: "Çılgın Yazılım"
language: "tr"
---

# Push Bildirimi Tasarımı: Uygulama Silinmeden Bildirmek

Bildirim izni bir kez reddedildiğinde geri kazanmak neredeyse imkânsız. Bu yüzden asıl soru "nasıl gönderilir" değil, "ne zaman ve ne sıklıkta". Rakamlarla birlikte.

Push bildirimi tasarımı, mobil uygulamalarda kullanıcıyı geri getiren en güçlü araç ve aynı zamanda uygulamanın silinmesinin en sık sebebi. İkisi arasındaki fark teknik değil: gönderim altyapısını kurmak bir günlük iş, ne zaman ve neyi göndereceğine karar vermek asıl mesele.

![Push bildiriminde izlenmesi gereken göstergeler](https://cilginyazilim.com/uploads/blog/2026/08/push-bildirimi-tasarimi-uygulama-silinmeden-ozet.png)
*Açılma oranı tek başına yanıltır; onun yanında izin iptali ve uygulama silme oranını da izlemek gerekir.*

## İzin: tek atışlık bir hak

Sistem izin kutusu bir kez gösterilir. Kullanıcı reddettiğinde uygulama içinden yeniden soramazsınız; kullanıcının kendi iradesiyle ayarlara girip açması gerekir ki bu pratikte neredeyse hiç olmaz.

Buna rağmen pek çok uygulama izni ilk açılışta, kullanıcı henüz hiçbir şey görmeden istiyor. O anda kullanıcının elinde karar verecek bilgi yok, refleks olarak reddediyor.

Daha iyi kurgu iki adımlı: önce uygulama içinde, kendi tasarımınızla, neden bildirim göndereceğinizi somut olarak anlatan bir ekran gösterin ("Siparişiniz yola çıktığında haber verelim mi?"). Kullanıcı burada olumlu yanıt verirse sistem kutusunu açın. Reddederse sistem kutusunu hiç açmayın — hakkınızı harcamamış olursunuz ve birkaç gün sonra, daha uygun bir anda tekrar deneyebilirsiniz.

## Bildirimi tetikleyen şey ne?

Bildirimleri iki kategoriye ayırın, çünkü kullanıcı da öyle algılıyor:

- **İşlemsel:** kullanıcının kendi eyleminin sonucu. Sipariş durumu, mesaj, randevu hatırlatması. Bunlar beklenen bildirimlerdir, sıklık sınırı gerektirmez.
- **Pazarlama:** sizin başlattığınız. Kampanya, yeni özellik duyurusu, "sizi özledik". Asıl risk buradadır.

İki kategoriyi ayrı ayarlarla yönetin. Kullanıcı pazarlama bildirimlerini kapatabilmeli ama sipariş bildirimini almaya devam edebilmeli. Tek bir aç/kapa düğmesi sunan uygulamalar, kullanıcıyı "hepsini kapat" seçeneğine itiyor ve işlemsel bildirimleri de kaybediyor.

## Segmentasyon: herkese aynı mesaj en pahalı seçenek

Tüm kullanıcı tabanına aynı bildirimi göndermek kolay olduğu için yaygın. Sonuç da öngörülebilir: mesajın ilgili olduğu küçük bir grup tıklar, kalan büyük çoğunluk rahatsız olur ve bir kısmı bildirimleri tamamen kapatır.

Basit ve etkili bölümleme ölçütleri: son giriş tarihi, uygulamada tamamlanan ana eylem (satın alma, içerik ekleme), platform ve dil. Bu dört ölçüt bile gönderim listesini anlamlı biçimde daraltıyor ve tıklama oranını belirgin şekilde yükseltiyor.

## Zamanlama ve sessiz saatler

Kullanıcının yerel saatine göre gönderin, sunucunun saatine göre değil. Bu, çok bölgeli uygulamalarda en sık yapılan hata: İstanbul'da öğlen gönderilen kampanya, Kaliforniya'daki kullanıcının telefonunu gece ikide çaldırıyor. Zaman dilimi hatalarının nasıl önleneceği başlı başına bir konu ve genellikle sanılandan daha çok yeri etkiliyor.

Sunucu tarafında basit bir kural yeterli:

```php
// Kullanıcının yerel saatine göre sessiz saat kontrolü
$yerel = new DateTime('now', new DateTimeZone($kullanici->zaman_dilimi ?: 'Europe/Istanbul'));
$saat  = (int) $yerel->format('G');

if ($saat < 9 || $saat >= 21) {
    // Ertesi günün ilk uygun saatine ötele — iptal etme
    $gonderimZamani = (clone $yerel)->setTime(9, 30);
    $kuyruk->planla($bildirim, $gonderimZamani);
    return;
}
```

Dikkat: sessiz saate denk gelen bildirimi iptal etmeyin, öteleyin. İptal edilen kampanyalar sessizce kayboluyor ve raporlarda "gönderildi" görünmediği için fark edilmiyor.

## Derin bağlantı olmadan bildirim yarım

Bildirim, konusu olan ekrana götürmeli. Ana sayfaya düşen kullanıcı aradığını bulamıyor ve ikinci bildirime tıklama olasılığı belirgin biçimde düşüyor. Derin bağlantı kurulumu bir kerelik iştir; uygulamanın kaldırılmış olduğu durumda mağazaya, kurulu olduğu durumda ilgili ekrana yönlendirmeyi de aynı anda çözmek gerekiyor.

Mobil tarafın diğer ayrıntıları için [offline-first tasarım](https://cilginyazilim.com/blog/offline-first-mobil-uygulama-detaylar) ve [pil tüketimini artıran hatalar](https://cilginyazilim.com/blog/mobil-uygulamada-pil-tuketimini-artiran-hatalar) yazılarına bakmakta fayda var; bildirim altyapısı bu iki konuyla doğrudan kesişiyor.

## Ölçüm: açılma oranı tek başına yalan söyler

"Kampanya başarılı, açılma oranı %14" cümlesi eksik bir cümle. Yanına şu iki sayı gelmeden anlamı yok: aynı kampanyadan sonra kaç kullanıcı bildirim iznini kapattı, kaç kullanıcı uygulamayı sildi?

| Gösterge | Ne söyler |
| --- | --- |
| Teslim oranı | Altyapı ve geçersiz jeton sağlığı |
| Açılma oranı | Mesajın ve zamanlamanın isabeti |
| İzin iptal oranı | Rahatsızlık eşiğini aştınız mı |
| Silme oranı | Kalıcı kayıp — en pahalı gösterge |

> Geçersiz jetonları düzenli temizleyin. Uygulamayı silen kullanıcıların jetonları listede kalırsa hem gönderim raporlarınız yanıltıcı olur hem de gereksiz istek yaparsınız. Sağlayıcının döndürdüğü "kayıtlı değil" hatasını yakalayıp jetonu aynı anda pasifleştirin.

## Mağaza tarafı

Bildirim iznini zorunlu tutan, yani izin verilmeden uygulamanın kullanılmasına engel olan akışlar mağaza incelemesinde ret sebebi olabiliyor. Aynı şekilde, izin isteme metninin gerçek kullanımı yansıtması gerekiyor. [Mağaza reddini önleyen kontrol listesi](https://cilginyazilim.com/blog/uygulama-magazasi-reddini-onleyen-kontrol-listesi) yazısındaki maddeleri bildirim akışını yazarken de gözden geçirin.

## Sonuç

Push bildirimi tasarımı bir gönderim problemi değil, bir güven problemi. İzni doğru anda isteyin, işlemsel ve pazarlama bildirimlerini ayırın, kullanıcının saatine saygı gösterin, tıklayanı doğru ekrana götürün ve her kampanyada yalnızca açılmayı değil kaybı da ölçün. Bu beş kural uygulandığında bildirim, uygulamayı sildiren şey olmaktan çıkıp geri getiren şeye dönüşüyor.

Platform tarafındaki güncel kurallar için: [Android — Bildirimler dokümantasyonu](https://developer.android.com/develop/ui/views/notifications).

## Sıkça Sorulan Sorular

### Push bildirimi tasarımı için izin ne zaman istenmeli?

Uygulamanın ilk saniyesinde değil. Kullanıcı henüz neyin bildirileceğini bilmiyorken gelen izin kutusu yüksek oranda reddediliyor ve iOS tarafında sistem kutusu bir kez reddedildiğinde tekrar gösterilemiyor. Doğru an, kullanıcının bildirimden fayda göreceği bir eylemi tamamladığı andır: sipariş verdikten, takip başlattıktan veya bir içeriği kaydettikten hemen sonra.

### Haftada kaç bildirim çok fazla?

Tek bir doğru sayı yok; belirleyici olan alaka düzeyi. Yine de pratik bir sınır olarak, kullanıcının kendi eylemiyle tetiklenmemiş (pazarlama amaçlı) bildirimlerde haftada ikiyi geçmemek makul. Asıl ölçüt sayı değil: her kampanyadan sonra izin iptal oranı yükseliyorsa sınırı aşmışsınız demektir.

### Bildirime tıklayınca kullanıcı nereye gitmeli?

Bildirimin konusu olan ekrana, doğrudan. Ana sayfaya düşürmek en yaygın ve en maliyetli hata; kullanıcı ilgilendiği içeriği aramak zorunda kalıyor ve bir daha tıklamıyor. Derin bağlantı kurulumu bir kereliktir, getirisi kalıcıdır.

### Bildirim gönderiminde hangi metriği izlemeliyim?

Açılma oranının yanında mutlaka izin iptali ve uygulama silme oranını izleyin. Yüksek açılma oranlı bir kampanya, aynı anda binlerce kullanıcının bildirimleri kapatmasına yol açıyorsa kısa vadeli kazanç uzun vadeli kayıptır. Kanal başına bu üçlüyü birlikte raporlamak doğru resmi veriyor.

---

Kaynak: [Push Bildirimi Tasarımı: Uygulama Silinmeden Bildirmek](https://cilginyazilim.com/blog/push-bildirimi-tasarimi-uygulama-silinmeden)