Mobil Uygulama Push Bildirimlerinde İzin, Segment ve Derin Bağlantı Nasıl Planlanır?

Mobil uygulama push bildirimleri, kullanıcıyı uygulamaya geri çağıran kısa mesajlardan daha fazlasıdır. İzin zamanı, hedef kitle, içerik, gönderim sıklığı ve bildirimin açtığı ekran birlikte planlanmazsa bildirimler kolayca rahatsız edici bir deneyime dönüşebilir. Teknik olarak gönderimin başarılı olması, mesajın kullanıcı için doğru olduğu anlamına gelmez.

Sağlıklı bir bildirim altyapısı ürün hedefiyle başlar. Sipariş durumu, randevu hatırlatması, güvenlik uyarısı ve kampanya mesajı aynı öncelikte değildir. Her bildirim türünün amacı, gerekli verisi ve kullanıcı kontrolü ayrı tanımlanmalıdır.

Bildirim türlerini iş amacına göre sınıflandırın

İlk adım gönderilebilecek bütün mesajları listelemek değil, gerçekten gerekli bildirim türlerini belirlemektir. İşlemsel bildirimler kullanıcının başlattığı bir sürecin durumunu anlatır. Bilgilendirici veya pazarlama bildirimleri ise farklı izin ve tercih yaklaşımı gerektirebilir.

Bildirim kataloğunda şu alanlar bulunabilir:

• Bildirim adı ve amacı
• Hangi olayın mesajı tetiklediği
• Hedef kullanıcı veya rol
• Gerekli izin ve tercih
• Kullanılacak başlık ve içerik şablonu
• Açılacak uygulama ekranı
• Tekrar ve süre sınırı
• Başarısız gönderimde izlenecek yol

Bu katalog ürün, pazarlama ve yazılım ekiplerinin aynı tanımları kullanmasını sağlar. Yeni bir bildirim eklenirken mevcut mesajlarla çakışma da daha kolay görülür.

İzni bağlam oluştuğunda isteyin

Uygulama ilk açılır açılmaz sistem izni istemek, kullanıcıya neden bildirim alacağını anlatmak için yeterli bağlam sunmayabilir. İzin, kullanıcının değerini anlayacağı bir aşamada istenebilir. Örneğin sipariş takibi açıldığında durum bildirimlerinin amacı açıklanabilir.

Sistem izin ekranından önce uygulama içinde kısa bir bilgilendirme gösterilebilir. Bu ekran yanıltıcı olmamalı ve izin vermeyen kullanıcıyı temel işlevlerden gereksiz yere mahrum bırakmamalıdır. Kullanıcı reddettiğinde sürekli tekrar sorulmamalıdır.

İşletim sistemi izin durumu ile uygulama içindeki bildirim tercihleri aynı şey değildir. Kullanıcı sistem düzeyinde izin verse bile yalnızca belirli mesaj türlerini almak isteyebilir. Ayarlar ekranında anlamlı kategoriler sunulmalıdır.

Kullanıcı tercihlerini açık ve geri alınabilir yapın

Bildirim seçenekleri teknik kanal adlarıyla değil, kullanıcının anlayacağı amaçlarla gösterilmelidir. “Pazarlama push” yerine “Kampanyalar ve fırsatlar”, “transactional” yerine “Sipariş ve teslimat güncellemeleri” gibi ifadeler kullanılabilir.

Zorunlu güvenlik mesajları ile isteğe bağlı tanıtım mesajları aynı anahtara bağlanmamalıdır. Kullanıcı bir kategoriyi kapattığında bu tercih sunucu tarafında da uygulanmalı; yalnızca cihaz arayüzüne güvenilmemelidir.

Hesaptan çıkış, cihaz değişikliği ve hesap silme durumlarında bildirim aboneliğinin nasıl yönetileceği belirlenmelidir. Eski cihazın başka bir kullanıcıya ait mesajları almaması için cihaz belirteci kullanıcı oturumuyla güvenli biçimde ilişkilendirilmelidir.

Segmentasyonu gerekli verilerle sınırlayın

Her kullanıcıya aynı mesajı göndermek ilgisiz bildirimleri artırabilir. Segmentler kullanıcı rolü, tercih edilen dil, aktif sipariş durumu veya seçilmiş hizmet gibi ürünle doğrudan ilişkili verilere dayanabilir.

Segment oluştururken hassas veya gereksiz kişisel veriler kullanılmamalıdır. “Bu alan gerçekten mesajı daha ilgili kılıyor mu?” sorusu veri kapsamını sadeleştirir. Segment kuralı ekip tarafından anlaşılır olmalı; yalnızca teknik sorgu olarak kalmamalıdır.

Kullanıcı aynı anda birden fazla segmente girebilir. Aynı bildirimin iki kez gönderilmesini önlemek için hedef birleştirme ve tekrar kontrolü gerekir. Segment güncellemelerinin ne sıklıkla hesaplandığı da zaman hassasiyeti olan mesajlarda önemlidir.

Gönderim zamanını kullanıcının bağlamına göre belirleyin

İşlemsel bir durum değişikliği çoğunlukla olay gerçekleştiğinde iletilir. Kampanya veya içerik bildirimi ise kullanıcının saat dilimi ve sessiz saat tercihi dikkate alınarak planlanabilir. Sunucunun saatine göre toplu gönderim yapmak farklı bölgelerde uygunsuz zamanlara denk gelebilir.

Bildirim gecikirse anlamını kaybedebilir. Süresi geçen mesajlar kuyrukta bekletilip daha sonra gönderilmemelidir. Her bildirim türü için geçerlilik süresi tanımlanabilir.

Aynı süreçte çok sayıda küçük durum değişikliği oluşuyorsa mesajlar birleştirilebilir. Amaç kullanıcıya her teknik olayı bildirmek değil, karar vermesi veya bilgi sahibi olması gereken değişikliği ulaştırmaktır.

İçerik şablonlarını veriyle güvenli birleştirin

Bildirim başlığı ve metni kısa, açık ve eylemle uyumlu olmalıdır. Kullanıcı bildirimi kilit ekranında görebileceği için hassas sipariş, sağlık, ödeme veya hesap bilgileri gereksiz yere yazılmamalıdır.

Şablon değişkenleri eksik olduğunda bozuk metin gönderilmemelidir. Ürün adı veya tarih bulunamazsa kullanılacak güvenli yedek metin belirlenir. Çok dilli uygulamalarda şablonlar kullanıcı tercihine göre seçilmeli ve eksik çeviri davranışı test edilmelidir.

Pazarlama metinlerinde kesin olmayan vaatler ve yanıltıcı aciliyet ifadeleri kullanılmamalıdır. Bildirimin içeriği, açılan ekranda gerçekten karşılanmalıdır.

Derin bağlantıyı bildirim türüyle eşleştirin

Kullanıcı bildirime dokunduğunda genel ana sayfa yerine ilgili sipariş, randevu, mesaj veya kampanya ekranı açılmalıdır. Bu yönlendirme derin bağlantı ile kurulabilir. Ancak uygulama kapalı, arka planda veya açıkken davranış ayrı ayrı test edilmelidir.

Kullanıcının ilgili kayda erişim yetkisi yoksa hassas bilgi gösterilmemelidir. Bağlantıdaki kimlik doğrudan güvenilir sayılmamalı; sunucu güncel oturum ve yetki kontrolü yapmalıdır.

İlgili içerik artık mevcut değilse kullanıcı boş veya hatalı ekranda bırakılmamalıdır. Uygun açıklama ve güvenli bir geri dönüş yolu sunulmalıdır. Uygulamanın eski sürümleri yeni bağlantı türünü tanımıyorsa yedek davranış gerekir.

Gönderim kuyruğu ve cihaz belirteçlerini yönetin

Push sağlayıcısına mesaj iletmek, son kullanıcının bildirimi gördüğünü garanti etmez. Cihaz çevrimdışı olabilir, izin kapatılmış olabilir veya belirteç geçersizleşmiş olabilir. Sistem sağlayıcı yanıtlarını kaydetmeli ve kalıcı hataları ayırmalıdır.

Geçersiz cihaz belirteçleri temizlenmeli, geçici hatalar kontrollü biçimde yeniden denenmelidir. Aynı olayın birden fazla işleyici tarafından gönderilmesini önlemek için benzersiz işlem kimliği kullanılabilir.

Toplu gönderimler ana uygulama işlemlerini yavaşlatmamalıdır. Kuyruk yapısı, öncelikli işlemsel mesajlarla zaman hassasiyeti düşük kampanya mesajlarını ayrı yönetebilir.

Ölçümü yalnızca açılma oranına bağlamayın

Bildirim performansı değerlendirirken teslim, açılma ve uygulama içindeki anlamlı eylem ayrı aşamalardır. Bir kampanya bildirimi açılmış olabilir fakat hedef ekran yüklenmemiş veya kullanıcı işlemi tamamlamamış olabilir.

Her bildirim türü için başarı ölçütü ürün amacına göre seçilir. Sipariş bildiriminin amacı bilgi vermek olabilir; her zaman tıklama beklenmez. Pazarlama mesajında ise ilgili ürün görüntüleme veya işlem tamamlama gibi sonraki adımlar değerlendirilebilir.

Kişisel veri içeren bildirim metni analiz olayına taşınmamalıdır. Ölçümde şablon kimliği, kampanya kimliği ve genel sonuç durumu gibi güvenli alanlar kullanılabilir.

Test planını gerçek cihazlarla tamamlayın

Simülatör veya geliştirme ortamı ilk kontrolü sağlar; farklı işletim sistemi sürümleri ve gerçek izin durumları da test edilmelidir. Uygulama açık, arka planda ve tamamen kapalıyken bildirim davranışı kontrol edilir.

Test senaryoları şunları kapsayabilir:

• İlk izin isteği ve ret durumu
• Ayarlardan iznin sonradan kapatılması
• Hesap değişimi ve çıkış
• Aynı kullanıcının birden fazla cihazı
• Süresi geçmiş bildirim
• Eksik şablon değişkeni
• Yetkisiz derin bağlantı
• Çift gönderim ve yeniden deneme
• Dil ve saat dilimi değişikliği

İlk sürümde az sayıda, yüksek değerli bildirim türüyle başlamak daha yönetilebilirdir. Kullanıcı tercihleri ve operasyon sonuçları gözlendikçe katalog kontrollü biçimde genişletilebilir.

Webinle, iOS ve Android uygulamalarında bildirim altyapısını kullanıcı deneyimi, sunucu olayları ve ölçüm planıyla birlikte geliştirir. Projeniz için kapsam oluşturmak isterseniz mobil uygulama geliştirme hizmetimizi inceleyebilir ve ihtiyacınızı paylaşabilirsiniz.

Sık sorulan sorular

Bildirim izni uygulama ilk açıldığında istenmeli mi?

Her zaman değil. Kullanıcının bildirimin değerini anlayacağı bağlamlı bir aşama, daha açıklayıcı bir izin deneyimi sağlayabilir.

Push bildirimi teslim edildiğinde görüldüğü anlaşılır mı?

Sağlayıcı teslim ve hata sinyalleri sunabilir; ancak cihaz ve kullanıcı davranışı nedeniyle “iletildi”, “gösterildi” ve “okundu” aynı kavram değildir.

Her bildirim doğrudan ilgili ekranı açmalı mı?

Mümkünse evet. Yetki, içerik bulunabilirliği ve eski uygulama sürümleri için güvenli yedek ekran da tasarlanmalıdır.