# Uygulama içi mesaj ve push bildirim: farkı ne, hangisi ne zaman?

Sayfa: https://alidemirbas.com.tr/blog/uygulama-ici-mesaj-push-bildirim

2026-11-02 · CRM ve Lifecycle · Ali Demirbaş

Push bildirim ile uygulama içi mesaj farkı: kime ulaşırlar, Android 13 ve iOS bildirim izni, uygulama içi mesaj türleri, çakışma kuralları ve ilk mesaj seti.

Uygulama içi mesaj (in-app message), kullanıcı uygulamayı açtığında uygulamanın kendi ekranında gösterilen mesajdır. Push bildirim (anlık bildirim) ise uygulama kapalıyken bile telefonun kilit ekranına ve bildirim merkezine düşer.

Aradaki temel fark şu: push bildirim uygulamanın dışındaki kullanıcıya ulaşır ama işletim sisteminin izni gerekir. Uygulama içi mesaj izin istemez ama yalnızca uygulamayı açan kullanıcıyı görür.

Bu yazı iki kanalın kime ulaşıp kime ulaşamadığını, Android 13 ve iOS'taki güncel bildirim izni kurallarını, uygulama içi mesaj türlerini ve hangi durumda hangisinin seçileceğini anlatıyor. Kullanıcıların birbirine yazdığı uygulama içi sohbet (chat) bu yazının konusu değil. Burada kastedilen, ürün ve pazarlama ekiplerinin kullanıcıya gönderdiği mesajlar.

## Temel fark: kullanıcı uygulamanın içinde mi, dışında mı?

İki kanalı ayıran şey içerik ya da tasarım değil, kullanıcının o anda nerede olduğu. Android'in [geliştirici dokümanı](https://developer.android.com/develop/ui/compose/notifications) bildirimi, Android'in uygulamanın arayüzü dışında gösterdiği bir mesaj olarak tanımlıyor. Apple da bildirimlerin uygulama çalışmıyorken ya da arka plandayken kullanıcının dikkatini çektiğini yazıyor.

Uygulama içi mesaj ise tam tersine, kullanıcı uygulamanın içindeyken çalışır. Firebase'in [In-App Messaging dokümanı](https://firebase.google.com/docs/in-app-messaging) bunu "kullanıcılar uygulamanın içindeyken" gönderilen mesajlar olarak anlatıyor.

### Push bildirimin yapabildiği

Push bildirim, uygulamayı o an kullanmayan birine ulaşabilen tek uygulama kanalı. Bir siparişin yola çıktığını, bir randevunun yaklaştığını ya da bir ödemenin başarısız olduğunu kullanıcı uygulamayı açmadan öğrenebilir. Bunun karşılığında iki sınırı var: kullanıcının izni gerekir ve kullanıcı bu izni ayarlardan istediği an kapatabilir. Gönderilen bildirim, kullanıcı uygulamayı açmasa da bildirim merkezinde bekler.

### Uygulama içi mesajın yapabildiği

Uygulama içi mesaj, kullanıcının o an baktığı ekrana göre konuşabilir. Bir özelliğin nasıl kullanılacağını o özelliğin ekranında gösterebilir, ödeme adımında takılan kullanıcıya o adımda yardım edebilir. İşletim sisteminin bildirim iznine bağlı değildir.

Braze, [uygulama içi mesajların](https://www.braze.com/docs/user_guide/channels/in_app_messages/faq/) çalışmak için push bildirime ihtiyaç duymadığını ve aktif bir uygulama oturumunda gösterildiğini yazıyor. Airship ve Klaviyo da bu mesajların push iznini kapatmış kullanıcılara da ulaştığını belirtiyor.

Uygulama içi mesajın nasıl teslim edildiği de önemli. Çoğu araç mesajları uygulama açıldığında ya da oturum başladığında cihaza indiriyor ve bir tetikleyici gerçekleştiğinde gösteriyor. Braze, oturum sırasında hedef kitleye giren kullanıcının mesajı bir sonraki oturum başlangıcında aldığını belirtiyor. OneSignal da segment koşulları oturum sırasında değişirse kullanıcının mesajı görmek için uygulamayı yeniden açması gerektiğini yazıyor.

*Apple, Android ve araçların kendi dokümanlarına göre.*

| Özellik | Push bildirim | Uygulama içi mesaj |
| --- | --- | --- |
| Nerede görünür | Kilit ekranı, banner, bildirim merkezi | Uygulamanın kendi ekranında |
| İşletim sistemi izni | Gerekir, kullanıcı istediği an kapatabilir | Gerekmez |
| Kime ulaşır | Yalnızca izin vermiş kullanıcılara | Yalnızca uygulamayı açan kullanıcılara |
| Ne zaman gösterilir | Gönderildiği anda, uygulama kapalıyken de | Uygulama açıkken, bir tetikleyici gerçekleşince |
| Ne kadar kalır | Bildirim merkezinde bekler | Kısa süreli, kalıcı olan uygulama içi gelen kutusu |
| Tipik işi | Kullanıcıyı uygulamaya geri getirmek | Uygulamanın içindeki bir adımı tamamlatmak |

### Hangi kanal kime ulaşamaz?

Her iki kanalın da göremediği bir kitle var ve bir müşteri ilişkileri yönetimi (CRM) akışı kurarken önce bunu bilmek gerekir.

Uygulamayı açmayan kullanıcı, uygulama içi mesajı hiç görmez. Braze bunu yazıyor: kullanıcı uygulamayı yeniden başlatmaz ya da bir oturum açmazsa, uygulama kullanıcının mesaja uygun olup olmadığını öğrenemez ve mesaj gönderilmez. Bu yüzden uzun süredir uygulamaya girmeyen bir kullanıcıyı geri getirmek uygulama içi mesajın işi değil.

Bu durumda push izni varsa push, yoksa e-mail, SMS gibi uygulama dışı kanallar devreye girer. [Uygulama kanalını geri kazanma](https://alidemirbas.com.tr/lab/journeys/uygulama-kanalini-geri-kazanma) journey'si 30 gündür uygulamayı açmayan kullanıcıya izinli ve ulaşılabilir ilk kanaldan nasıl gidileceğini gösteriyor. [Kullanım alışkanlığını geri kazanma](https://alidemirbas.com.tr/lab/journeys/kullanim-aliskanligini-geri-kazanma) da kullanımı düşen kullanıcı için bir örnek.

Bildirim izni vermemiş kullanıcıya push ulaşmaz ama uygulamayı açtığı sürece uygulama içi mesaj ulaşır. Bu kullanıcılar için kalıcı bir yüzey de kurulabilir. Airship'in [Message Center](https://www.airship.com/docs/guides/features/messaging/message-center/) özelliği push iznine bağlı değil ve mesajlar süresi dolana ya da silinene kadar gelen kutusunda kalıyor. Braze'in Content Cards özelliği de izin istemiyor ve Braze bunu kısa ömürlü uygulama içi mesajın kalıcı karşılığı olarak tanımlıyor.

Varsayımsal bir örnek iki boşluğu birlikte gösteriyor. Uygulaması 100.000 cihazda kurulu bir marka düşün. Son 30 günde bu kullanıcıların 40.000'i uygulamayı açmış, 60.000'i açmamış olsun. Bildirim izni verenler aktif kullanıcıların 22.000'i, pasif kullanıcıların 15.000'i olsun:

*Varsayımsal örnek: hangi kanalın hangi gruba ulaştığı.*

| Grup | Kullanıcı | Uygulama içi mesaj | Push bildirim |
| --- | --- | --- | --- |
| Aktif, bildirim izni var | 22.000 | Ulaşır | Ulaşır |
| Aktif, bildirim izni yok | 18.000 | Ulaşır | Ulaşmaz |
| Pasif, bildirim izni var | 15.000 | Ulaşmaz | Ulaşır |
| Pasif, bildirim izni yok | 45.000 | Ulaşmaz | Ulaşmaz |

Bu örnekte uygulama içi mesaj kitlenin %40'ına, push bildirim %37'sine ulaşıyor. İki kanal birlikte 55.000 kişiye ulaşıyor ve 45.000 kişiye, yani kitlenin %45'ine hiç ulaşamıyor. Bu kullanıcılara ancak e-mail ya da SMS gibi uygulama dışı kanallarla, o kanallarda da izinleri varsa ulaşılabilir.

## Bildirim izni: Android 13, iOS ve doğru anda istemek

Push bildirim izni artık iki platformda da kullanıcının açık onayına bağlı. Bu, push kitlesinin uygulama kullanıcılarının tamamı olmadığı anlamına geliyor.

### Android 13 ile gelen çalışma zamanı izni

Android'in [bildirim izni dokümanına](https://developer.android.com/develop/ui/views/notifications/notification-permission) göre Android 13 (API 33) ve sonrasında bildirim göndermek POST_NOTIFICATIONS adlı bir çalışma zamanı izni gerektiriyor. Android 13 ve üstü bir cihaza uygulamayı yeni kuran kullanıcıda bildirimler varsayılan olarak kapalı geliyor ve uygulama, izni isteyip kullanıcı onaylayana kadar bildirim gönderemiyor. Android'in izin dokümanı ayrıca kullanıcının bir izni uygulamanın o cihazdaki ömrü boyunca birden fazla kez reddetmesi halinde, sistem izin penceresinin bir daha gösterilmediğini belirtiyor. Android 8.0'dan beri de her bildirim bir kanala atanıyor ve kullanıcı her kanalın davranışını ayrı ayrı kontrol edebiliyor.

### iOS'ta tek seferlik izin ve sessiz bildirim

Apple'ın [izin dokümanına](https://developer.apple.com/documentation/usernotifications/asking-permission-to-use-notifications) göre uygulama izni ilk kez istediğinde sistem kullanıcıya sorar ve cevabı kaydeder. Sonraki istekler kullanıcıya tekrar sorulmaz.

Apple'ın bir alternatifi de var: provisional (geçici) izin. Bu izinle gönderilen bildirimler ses ya da banner olmadan, kilit ekranına düşmeden yalnızca bildirim merkezinin geçmişinde görünüyor ve kullanıcıya izin sorulmuyor. Kullanıcı bildirimi aldığında onları tutmak ya da kapatmak arasında seçim yapıyor.

Pazarlama tarafında Apple'ın kuralı net. App Store [inceleme kurallarının](https://developer.apple.com/app-store/review/guidelines/) 4.5.4 maddesine göre push bildirimler, kullanıcı uygulamanın arayüzünde gösterilen bir onay metniyle açıkça kabul etmedikçe promosyon ya da doğrudan pazarlama için kullanılmamalı ve uygulama içinde bu mesajlardan çıkmanın bir yolu sunulmalı. Apple'ın tasarım kılavuzu da pazarlama bildirimi için Time Sensitive seviyesinin hiçbir zaman kullanılmamasını söylüyor.

### Önce uygulama içinde anlat, sonra iste

İzin sistem penceresi bir kez kaybedildiğinde geri gelmediği için ne zaman sorulduğu önemli. Apple, izni ilk açılışta otomatik istemek yerine bağlam içinde istemenin daha iyi bir deneyim sunduğunu yazıyor, çünkü kullanıcı bildirimlerin neye yarayacağını görebiliyor. Android de herhangi bir izni istemeden önce kullanıcının uygulamayı tanımasına fırsat vermeyi öneriyor.

Burada uygulama içi mesaj işe yarıyor: kullanıcı bildirimin faydalı olacağı bir işlemi tamamladığında, önce uygulama içi bir mesajla bildirimlerin ona ne sağlayacağını anlatırsın, kullanıcı devam ederse sistem penceresini açarsın. OneSignal, bu tür bir ön mesajın kapatılmasının sistem izin hakkını tüketmediğini belirtiyor. [Bildirim izni öncesi fayda anlatımı](https://alidemirbas.com.tr/lab/journeys/bildirim-izni-oncesi-fayda-anlatimi) journey'si bu akışı adım adım gösteriyor.

## Uygulama içi mesaj ne zaman, push bildirim ne zaman?

Karar için sorulacak ilk soru: mesaj, kullanıcının o an uygulamanın içinde olmasını mı gerektiriyor, yoksa onu bulunduğu yerden mi çağırmalı? Uygulama içi mesaj, ekrandaki bağlama bağlı işler için uygun: onboarding'in bir sonraki adımı, kullanıcının sahip olduğu ama hiç kullanmadığı bir avantaj ya da yarım kalmış bir yükseltme. [Uygulama kurulumundan ilk değere](https://alidemirbas.com.tr/lab/journeys/uygulama-kurulumundan-ilk-degere), [kullanılmayan avantajı keşfetme](https://alidemirbas.com.tr/lab/journeys/kullanilmayan-avantaji-kesfetme) ve [yükseltme tamamlama hatırlatması](https://alidemirbas.com.tr/lab/journeys/yukseltme-tamamlama-hatirlatmasi) journey'leri bu işlerde uygulama içi mesajın nereye oturduğunu gösteriyor.

Push bildirim ise zamana bağlı ve uygulamanın dışında karşılanması gereken anlar için: bir kargo teslimatı, bir ödeme hatası, kullanıcının başlattığı ve sonucunu beklediği bir işlem. Google'ın [bildirim tasarım kılavuzu](https://developer.android.com/design/ui/mobile/guides/home-screen/notifications) da bildirimin neler için kullanılmaması gerektiğini sıralıyor: uygulamayı hiç açmamış kullanıcılar, kullanıcıyı doğrudan bir değer sunmadan uygulamaya geri çağırmak, uygulamayı puanlama istekleri, bayram ve doğum günü mesajları ve başka bir ürünün tanıtımı.

Üçüncü soru mesajın ömrüyle ilgili: mesaj, kullanıcının uygulamayı bir sonraki açışında hâlâ doğru olacak mı? Uygulama içi mesaj ancak kullanıcı uygulamayı açtığında görünür. Bu yüzden saatler içinde geçersiz kalacak bir bilgi için uygun değil.

Braze de uygulama içi mesajlardan ve benzeri kanallardan kritik ve zamana duyarlı güncellemeler için kaçınmayı öneriyor. Uygulama içi bir mesaj gönderiyorsan bir geçerlilik süresi tanımlamak, eskiyen mesajın yanlış bir anda görünmesini engeller.

Uygulamayı puanlama isteği bu ayrımın iyi bir örneği. Apple, puanlama için kendi sistem penceresinin kullanılmasını istiyor ve özel tasarlanmış puanlama pencerelerine izin vermiyor. Sistem bu pencereyi 365 gün içinde en fazla üç kez gösteriyor.

Google Play de puanlama penceresi için süreye bağlı bir kota uyguluyor ama kotanın değerini açıklamıyor. Yani puanlama isteği ne push bildirimle ne de serbest tasarımlı bir uygulama içi mesajla gönderilecek bir iş.

## Uygulama içi mesaj türleri: ne kadar böldüğüne göre seçmek

Araçlar aynı formatlara farklı isimler veriyor. Braze slide-up, modal ve tam ekran diyor, Firebase kart, banner, modal ve yalnızca görsel diyor, Airship banner, modal, tam ekran ve özel HTML diyor. İsimden çok, formatın kullanıcının akışını ne kadar böldüğüne bakarak seçim yapmak daha kullanışlı:

- **Akışı durduranlar (modal, tam ekran):** Kullanıcı bir aksiyon alana ya da kapatana kadar ekranı kaplar. Gerçekten şimdi karar verilmesi gereken işler için uygundur, örneğin bir hesap uyarısı ya da zorunlu bir güncelleme.
- **Geçip gidenler (banner, slide-up):** Ekranın bir kenarında belirir ve kendiliğinden kaybolur. Airship, banner mesajların varsayılan olarak 15 saniye sonra kaybolduğunu yazıyor. Kullanıcıyı durdurmadan bilgi vermek için uygundur.
- **Yerinde duranlar (ipucu, sayfa içi kart):** Ekranın bir parçası gibi görünür ve kullanıcının akışını kesmez. Braze'in Banners, Airship'in Embedded Content ve CleverTap'in Native Display özellikleri bu türden.
- **Kalıcı olan (uygulama içi gelen kutusu):** Mesajlar kullanıcı açana ya da süresi dolana kadar bekler. Airship'in Message Center'ında mesajlar varsayılan olarak bir yıl sonra, Dengage'in gelen kutusunda en fazla yedi gün sonra siliniyor.

### Mesajların çakışmaması için kurallar

Bir uygulamada birden fazla uygulama içi kampanya çalıştığında en sık sorun, aynı oturumda birkaç mesajın üst üste gelmesi. Araçların varsayılan davranışları bunu kısmen engelliyor.

Braze'de oturum başlangıcıyla tetiklenen mesajlarda bir oturumda yalnızca bir mesaj gösteriliyor. Insider One da olay tetiklemeli durumlar dışında oturum başına tek mesaj gösteriyor.

Airship, bir mesaj kapandıktan sonra bir sonrakini göstermeden önce 30 saniye bekliyor. Firebase'de bir kampanya varsayılan olarak kullanıcıya bir kez gösterildikten sonra tekrar gösterilmiyor. CleverTap ise uygulama içi kampanyalara 1 ile 10 arasında öncelik verilmesine izin veriyor.

Ancak bu varsayılanlar bir öncelik politikasının yerini tutmaz. Braze, uygulama içi mesajların kampanyalar için tanımlanan genel sıklık sınırlarına sayılmadığını belirtiyor. Yani push için kurduğun sıklık kuralı uygulama içi mesajı kapsamayabilir. Bu yüzden kendi kurallarını yazmak gerekiyor: oturum başına en fazla bir engelleyici mesaj, işlemsel mesajların lifecycle mesajlarından, lifecycle mesajlarının da kampanyalardan önce gelmesi, ödeme ve form ekranlarında hiç mesaj gösterilmemesi ve mesajın hedeflediği aksiyon gerçekleştiğinde mesajın durması.

## Push ve uygulama içi mesaj aynı journey'de

İki kanal birbirinin rakibi değil, aynı akışın iki adımı. Push bildirim kullanıcıyı uygulamaya geri getirir, uygulama içi mesaj da kullanıcının indiği ekranda konuşmayı devam ettirir.

Önemli olan, uygulama içi mesajın push'u tekrar etmemesi. Kullanıcı push'a dokunup bir derin bağlantıyla (deep link) ilgili ekrana geldiyse, aynı cümleyi bir modalla tekrar göstermek yerine o ekrandaki bir sonraki adımı göstermek gerekir. Klaviyo bu ilişkiyi şöyle özetliyor: push bildirimler uygulamanın açılmasını sağlar, uygulama içi formlar ise uygulama deneyimine entegre görsel içerik sunar.

Bir ayrıntıyı da unutmamak gerekiyor. Dengage, push gelip kullanıcı ona dokunmadığında ve uygulamaya girmediğinde hiçbir uygulama içi mesajın görünmeyeceğini yazıyor. CleverTap da push ile gelen kutusu mesajını birlikte gönderdiğinde push'un anında teslim edildiğini, gelen kutusu mesajının ise bir sonraki uygulama açılışında göründüğünü belirtiyor. Push'a dokunmayan kullanıcıya uygulamayı bir sonraki açışında ne gösterileceğini de akışa eklemek gerekir.

Bu adımların tetikleyicileri uygulamanın event verisinden gelir. Mevcut event'lerinin hangi akışları desteklediğini görmek istersen [Journey oluşturucu](https://alidemirbas.com.tr/lab/journey-olusturucu) bunu çıkarıyor. [Onboarding yardımı](https://alidemirbas.com.tr/lab/journeys/onboarding-yardimi) journey'si de iki kanalın aynı akışta nasıl birlikte çalıştığına bir örnek.

## Bildirim izni ile ticari ileti onayı aynı şey değil

İşletim sisteminin bildirim izni, kullanıcının telefonuna bildirim düşmesine izin verir. Bu, ticari ileti göndermek için gereken yasal onayla aynı şey değil.

Türkiye'de [İYS'nin sıkça sorulan sorular sayfası](https://iys.org.tr/iys/sss), alıcılarına yalnızca mobil uygulama üzerinden anlık bildirim gönderen hizmet sağlayıcıların bu alıcıları İYS'ye bildirmesi gerekip gerekmediği sorusuna "bugünkü uygulama kapsamında" gerekmediği cevabını veriyor. Bu cevap yalnızca İYS'ye kayıtla ilgili ve push bildirimin ticari elektronik ileti tanımının dışında olduğunu söylemiyor. Aynı sayfa, bir iletinin ticari mi bilgilendirme mi olduğuna karar vermenin hizmet sağlayıcının sorumluluğunda olduğunu da belirtiyor.

Uygulama içi mesajlarla ilgili resmi bir açıklama bulamadım. Pazarlama amaçlı push için Apple'ın açık onay ve uygulama içi çıkış kuralı ise zaten geçerli. Bu bölüm hukuki görüş değil, kendi kullanımın için hukuk ekibinle konuşmalısın.

## Uygulama içi mesajın etkisini doğru okumak

Uygulama içi mesajların tıklama oranı genellikle yüksek görünür, çünkü mesajı gören herkes zaten uygulamanın içindedir. Bu oran mesajın bir davranışı değiştirip değiştirmediğini göstermez. Mesajı görmeyen bir kontrol grubunu ayırıp hedeflenen aksiyonun (bir özelliğin ilk kullanımı, bir adımın tamamlanması) iki grupta ne kadar gerçekleştiğine bakmak daha doğru sonuç verir. Bunun yanında mesajın kapatılma oranına, push izninden çıkan kullanıcı sayısına ve oturum süresindeki değişime bakmak, mesajın kullanıcıyı rahatsız edip etmediğini gösterir.

## Bir mobil uygulama için ilk mesaj seti

Sıfırdan başlayan bir ekip için kanal ve format seçimiyle birlikte ilk kurulabilecek mesajlar şöyle sıralanabilir:

1. **Bildirim izni öncesi anlatım:** Uygulama içi mesaj, ardından sistem izin penceresi. Kullanıcı bildirimin faydalı olacağı bir işlemi tamamladığında gösterilir.
2. **İlk değere ulaşma:** Onboarding adımları için ekran içi ipuçları ve kartlar. Adım yarım kalırsa ve izin varsa bir push hatırlatması.
3. **Kullanılmayan avantaj:** İlgili ekranda bir uygulama içi mesaj, kullanılmazsa birkaç gün sonra e-mail.
4. **Yarım kalan yükseltme:** Kullanıcının takıldığı adımda bir banner ya da sayfa içi kart.
5. **İşlem bildirimleri:** Sipariş, ödeme ve hesap güvenliği gibi zamana bağlı bilgiler için push bildirim.
6. **Push izni olmayanlar için gelen kutusu:** Kampanya ve duyuruların kalıcı bir kopyası uygulama içi gelen kutusunda.

Bu sette her mesaj, kullanıcının o anki durumuna göre kanalını seçiyor: uygulamanın dışındaysa push ya da e-mail, içindeyse uygulama içi mesaj, mesaj kalıcı olmalıysa gelen kutusu. Hangi CRM ve pazarlama otomasyonu araçlarının bu kanalları desteklediğine bakmak istersen [CRM ve pazarlama otomasyonu araçları](https://alidemirbas.com.tr/blog/crm-pazarlama-otomasyonu-araclari) yazısı araçları yan yana koyuyor.