Web push bildirimleri: nasıl çalışır ve nasıl iyi kullanılır

Web push bildirimleri, tek bir kötü tasarım kararının sizi bir müşteriye kalıcı olarak kapatabildiği tek pazarlama kanalıdır. İzni yanlış anda isteyin, ziyaretçi Engelle’ye tıklasın, o tarayıcı size sonsuza kadar kapanır. Yeniden istem yok, ikinci kampanya yok, geri kazanım e-postası yok. Bu asimetri, tek bir mesaj yazmadan önce mekanizmayı anlamaya değmesinin sebebidir.

Web push bildirimleri nedir

Bir web push bildirimi, sunucunuzdan bir abonenin tarayıcısına gönderilen, işletim sisteminin bildirim merkezi tarafından gösterilen ve siteniz kapalıyken bile teslim edilen bir mesajdır. Son kısım işin tamamıdır: sayfa içi bir açılır pencerenin aksine, web push şu anda web sitenize bakmayan birine ulaşır.

Birlikte çalışan üç web platformu API’sinden oluşur ve aralarındaki iş bölümü kanalın davranışının çoğunu açıklar: Service Worker API, Push API ve Notifications API.

Web push kaputun altında nasıl çalışır

Service worker

Service worker, web uygulamanız, tarayıcı ve ağ arasında bir vekil gibi davranan bir JavaScript worker’ıdır. Kendi iş parçacığında çalışır, DOM erişimi yoktur ve onu kaydeden sayfa kapandıktan sonra da var olmayı sürdürür. Bu kalıcılık, kimse sekmenizi açık tutmazken bir push mesajı almasını ve bir bildirim göstermesini sağlayan şeydir. Service worker’lar yalnızca güvenli bağlamlarda çalışır, yani HTTPS ile; geliştirme için http://localhost güvenli sayılır.

Abonelik: bir endpoint artı iki anahtar

Bir service worker etkin olduğunda sayfa registration.pushManager.subscribe() çağrısını yapar. Tarayıcı, sağlayıcısının push hizmetiyle konuşur ve şunları içeren bir PushSubscription döndürür:

• endpoint, push hizmetinin mesaj kabul ettiği benzersiz bir yetki URL’si
• keys.p256dh, P-256 eğrisinde bir Elliptic Curve Diffie-Hellman açık anahtarı
• keys.auth, bir kimlik doğrulama sırrı

Sunucunuz üçünü de saklar ve endpoint’i bir sır gibi ele alır, çünkü onu elinde tutan herkes o aboneye gönderim yapabilir. Anahtarlar, yüklerin uçtan uca şifrelenmesi nedeniyle vardır. RFC 8291 bunun nasıl olacağını belirtir: P-256 üzerinde bir ECDH değişimi paylaşılan bir sır kurar, HKDF bundan anahtarlar türetir ve yük aes128gcm içerik kodlaması altında AES-128-GCM ile mühürlenir. Push hizmeti okuyamadığı bir şifreli metni aktarır.

Push hizmeti

Push mesajlarını doğrudan bir cihaza göndermezsiniz. Onları tarayıcı sağlayıcısının işlettiği bir push hizmetine gönderirsiniz: Chrome için Google’ın FCM endpoint’leri, Firefox için Mozilla’nın autopush’u, Safari için Apple’ın push hizmeti. Protokolü, “Generic Event Delivery Using HTTP Push” başlıklı RFC 8030 tanımlar. Sunucunuz abonelik endpoint’ine POST yapar ve push hizmeti mobil teslimatın zor kısımlarını üstlenir: cihaza tek bir pil dostu bağlantı, çevrimdışıyken kuyruğa alma, mesaj geldiğinde tarayıcıyı uyandırma. Teslimatın garanti edilememesinin sebebi de budur. Cihaz yeterince uzun süre kapalı kalırsa mesajlar TTL sürelerine göre sona erer ve düşürülür.

VAPID: kimin gönderdiğini kanıtlamak

Endpoint’in bir sır olması zayıf bir güvenliktir. RFC 8292, bir push hizmetinin bir mesajın hangi uygulama sunucusundan geldiğini anlayabilmesi için Voluntary Application Server Identification, kısaca VAPID’i ekler.

NIST P-256 eğrisinde bir kez bir ECDSA anahtar çifti üretirsiniz. Tarayıcı abone olurken açık anahtar applicationServerKey içine girer ve aboneliği sunucunuza bağlar. Her push için sunucunuz, eşleşen özel anahtarla ES256 kullanarak imzalanmış bir JWT gönderir; bu JWT push hizmeti kaynağı için bir aud talebi, 24 saatten uzak olmayan bir exp talebi ve isteğe bağlı olarak iletişim bilgisi içeren bir sub talebi taşır. Push hizmeti imzayı doğrular, dolayısıyla çalınmış bir endpoint tek başına abonelerinize spam göndermeye artık yetmez.

Uçtan uca teslimat yolu

1. Sayfa bir service worker kaydeder ve izin verildikten sonra VAPID açık anahtarınızla subscribe() çağrısını yapar.
2. Sunucunuz dönen endpoint ve anahtarları abone kaydına karşılık saklar.
3. Göndermek için sunucunuz yükü p256dh ve auth ile şifreler, bir VAPID JWT imzalar ve endpoint’e POST yapar.
4. Push hizmeti isteği doğrular ve şifreli mesajı teslim eder.
5. Tarayıcı service worker’ı bir push olayıyla uyandırır; service worker yükü çözer ve ServiceWorkerRegistration.showNotification() çağrısını yapar.
6. Bir tıklama, service worker içinde notificationclick olayını tetikler ve orada hedef URL’yi açarsınız.

İzin modeli neden bu kadar katı

Bir aboneliğin neyi verdiğine bakın: siteniz açık olmadan çalışan bir arka plan süreci ve işletim sisteminin bildirim yüzeyine çizim yapabilme yetkisi. Bu yüzden tarayıcılar bunu açık, kaynak başına ve kullanıcı tarafından verilen bir iznin arkasına koyar ve çoğu, isteğin gerçek bir kullanıcı hareketini izlemesini şart koşar.

İkinci bir kısıt insanları şaşırtır. Chrome ve Edge, abone olurken userVisibleOnly: true değerini zorunlu kılar; bu, her push’un kullanıcıya görünür bir bildirim üreteceği sözüdür, dolayısıyla sessiz arka plan push’ları API’nin desteklenen bir kullanımı değildir. Firefox da bildirim üretmeyen push mesajlarına bir kota uygular.

Tarayıcı ve platform desteği

MDN’e göre Push API, Mart 2023’ten bu yana Baseline olarak yaygın biçimde kullanılabilir durumda; yani masaüstünde Chrome, Edge, Firefox ve Safari’nin güncel sürümlerinde ve Android için Chrome ile Firefox’ta çalışıyor. İki uyarı manşetten daha önemli.

Birincisi, Notifications API her yerde aynı biçimde mevcut değil. MDN bunu sınırlı kullanılabilirlik olarak işaretliyor, çünkü Notification() yapıcısı çoğu mobil tarayıcıda bir TypeError fırlatıyor. Telefonlarda çalışması gereken her şey için bunun yerine ServiceWorkerRegistration.showNotification() üzerinden kalıcı bildirimler kullanın; zaten içinde olduğunuz service worker yolu budur.

İkincisi, bildirim seçenekleri dengesiz biçimde uygulanmış durumda. Eylem düğmeleri, rozetler, görseller ve requireInteraction tarayıcılar ile işletim sistemleri arasında değişiyor, bu yüzden yalnızca bir başlık, bir gövde ve bir simgeyle de doğru okunan bildirimler tasarlayın.

iOS ve iPadOS koşulu

Bu uyarı, web push’un mobil ağırlıklı bir kitle için uygulanabilir olup olmadığını belirler ve neredeyse her yerde yanlış aktarılır.

Apple Web Push’u iOS ve iPadOS 16.4’te ekledi ve bu yalnızca Ana Ekran’a eklenmiş web uygulamaları için çalışıyor. WebKit’in ifadesiyle, “Ana Ekran web uygulamaları için Web Push desteği ekliyoruz” ve “Ana Ekran’a eklenmiş bir web uygulaması push bildirimi almak için izin isteyebilir”. Kullanıcı bunu Paylaş menüsü ve “Ana Ekrana Ekle” ile ekler ve iznin ardından, örneğin bir abone ol düğmesine dokunmak gibi doğrudan bir kullanıcı etkileşimine yanıt olarak istenmesi gerekir.

iPhone’da sıradan bir Safari sekmesinde açık olan bir site push aboneliği oluşturamaz. Bu gerçek bir engeldir: izin isteyebilmek için bile önce bir kurulum adımı istiyorsunuz. macOS’ta durum daha kolay, çünkü macOS Ventura üzerindeki Safari 16.1 sıradan web siteleri için kurulum adımı olmadan standartlara dayalı Web Push’u ekledi.

Asgari bir abonelik örneği

İstemci tarafındaki akışın tamamı budur. Sayfa yüklenmesine değil, bir tıklama işleyicisine aittir.

async function subscribeToPush(vapidPublicKey) {
  // Push ve service worker'lar güvenli bir bağlam (HTTPS) gerektirir.
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

  const registration = await navigator.serviceWorker.register("/sw.js");

  // Bir kullanıcı hareketinden çağrılmalı ve kullanıcı başına yalnızca bir kez.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // base64url kodlanmış P-256 açık anahtarı
  });

  // Endpoint ve anahtarları sunucu tarafında saklayın; endpoint'i bir sır gibi ele alın.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

sw.js içinde push olayını ele alır, self.registration.showNotification(title, options) çağrısını yapar ve hedef URL’yi açmak için notificationclick olayını işlersiniz.

İzin deneyimi: programların çoğu burada başarısız oluyor

Asla sayfa yüklenirken sormayın

Lighthouse’un bunun için ayrı bir denetimi var: “sayfanız yüklenirken bildirim gönderme izni istiyorsa, bu bildirimler kullanıcılarınızla veya ihtiyaçlarıyla alakalı olmayabilir”. Önerisi, belirli bir bildirim türü sunmak ve izni ancak kullanıcı o türe katıldıktan sonra istemektir. Safari 12.1 ve diğer tarayıcılar bir adım daha ileri gitti ve istek yapılabilmesi için sayfayla etkileşimi şart koştu.

Yumuşak bir ön istem kullanın

Önce kendi sayfa içi davetinizi gösterin. Bu davet değer önerisini adlandırır, kalıcı bir bedeli olmadan kapatılabilir ve gerçek tarayıcı istemini yalnızca üzerine yapılan bir tıklama tetikler. Bugün yumuşak isteminizi yok sayan birine gelecek ay yeniden sorulabilir. Engelle’ye tıklayana sorulamaz. İki kural bunu işler kılar: “güncellemeleri alın” yerine gerçekte ne göndereceğinizi anlatın ve asla yanlışlıkla tıklamayı mühendislikle üretmeyin, çünkü kazara verilen bir onay anında abonelikten çıkma üretir.

Bağlam içinde sorun

Chrome’un kendi önerisi, geçiş anahtarlarını mevcut arayüz yüzeylerinin içine sade biçimde yerleştirerek “kullanıcılarınızın inisiyatifi almasına ve bildirimleri kendi hızlarında açmasına izin vermek” ve “bağlamsız ya da kullanıcı siteye iner inmez istem veya katman göstermekten” kaçınmaktır.

Ticarette işe yarayan anlar spesifiktir: tükenmiş bir üründe “stoğa gelince haber ver” kontrolü, teslimat güncellemeleri sunan bir sipariş onay sayfası, sık görüntülenen bir üründe fiyat takibi anahtarı. İzin, toplanmak yerine adı konmuş bir faydayla takas edilir.

Bir ret kararı fiilen kalıcıdır

Biri bildirimleri engellediğinde tarayıcı bu kararı sizin kaynağınız için saklar. Notification.requestPermission() çağrıları sonrasında hiçbir şey göstermeden saklanan denied değerine çözümlenir; MDN’nin kendi örneğinin requestPermission() çağrısı yapmadan önce Notification.permission değerini kontrol etmesinin sebebi de budur. Bir engeli geri almak site ayarlarının derinine inmeyi gerektirir ve bunu fiilen kimse yapmaz.

Yanlış yaptığınızda tarayıcılar ne yapar

Sonuçlar artık yalnızca düşük bir katılım oranından ibaret değil.

• Chrome, kabul oranı çok düşük olan kaynakları cihaz türüne göre ayrı ayrı otomatik olarak daha sessiz bir izin arayüzüne alır ve istemi herkes için bastırır.
• Chrome, yüksek push hacmini düşük etkileşimle birleştiren sitelere hız sınırı uygular ve HTTP 429 döndürür. Yükseltme bir gün, sonra yedi gün, sonra on dört gün sürer ve yalnızca 42 ardışık rahatsız etmeyen günden sonra sıfırlanır.
• Chrome artık kullanıcının yakın zamanda etkileşime girmediği siteler için, “çok düşük kullanıcı etkileşimi ve gönderilen yüksek bildirim hacmi” olduğunda bildirim iznini otomatik olarak geri alıyor. Google’ın gerekçesi çarpıcı: “Tüm bildirimlerin yüzde 1’inden azı kullanıcılardan herhangi bir etkileşim alıyor.”

Zaten kazandığınız aboneleri sadece kötü göndererek kaybedebilirsiniz.

Web push’un e-posta ve SMS ile karşılaştırması

Stratejiyi değiştiren sahiplik farkı

Bir push aboneliği, tek bir cihazdaki tek bir tarayıcı profiline bağlı bir yetki URL’sidir. Bir kişi değildir. Dizüstünde Chrome, telefonda Firefox kullanan aynı müşteri, birbiriyle ilgisiz iki aboneliktir ve kendisi kimliğini belirtmedikçe aynı insan olduklarını bilemezsiniz.

Taşınabilir de değildir. Bir e-posta listesini dışa aktarıp yarın başka bir platforma yükleyebilirsiniz. Push aboneliklerini sağlayıcılar arasında taşıyamazsınız, çünkü anahtarlar ve VAPID bağlantısı belirli bir uygulama sunucusu anahtarına karşı oluşturulmuştur.

Bu yüzden web push’u sahip olduğunuz bir kanalın hızlandırıcısı olarak görün, asla yerine geçen bir şey olarak değil. Push anını bir e-posta adresi ya da telefon numarası kazanmak için kullanın, tersini değil. Pazarlama otomasyonu eksiksiz kılavuzu birden fazla kanalı tek bir yolculuğa bağlamayı anlatıyor.

Gerçekten işe yarayan kullanım senaryoları

Kanal, zamana duyarlı, kişisel olarak alakalı ve tek dokunuşla eyleme geçirilebilir mesajları ödüllendirir.

• Sepet terki. Bir saat içinde bir push, ardından sonradan bir e-postayla pekiştirilir. Terk edilmiş sepet e-postası kılavuzu sıralamayı anlatıyor.
• Stoğa geri geldi uyarıları. En güçlü senaryo, çünkü kullanıcı haber verilmesini açıkça istemiştir.
• Takip edilen ürünlerde fiyat düşüşleri. Aynı mantık, kullanıcının kendi seçtiği alaka.
• Teslimat ve sipariş durumu. Yüksek açma niyeti, düşük şikâyet riski.
• Abone olunan bir konuda son dakika güncellemeleri. Haberler, sonuçlar, uygunluk pencereleri.

Başarısız olanlar da aynı ölçüde nettir: genel “yeni bir yazı yayımladık” duyuruları, farklılaştırılmamış günlük fırsatlar, bir başlık ve bir satırdan fazlasını gerektiren her şey, son yirmi bildirimi yok saymış abonelere gönderilen yeniden etkileşim bombardımanı ve kalıcı bir kayda ihtiyaç duyan işlemsel içerik.

Sıklık, zamanlama ve segmentasyon

Temkinli başlayın: abone başına haftada bir ila üç bildirim ve yalnızca çıkma ile tıklama oranları korunuyorsa artırın. Yorgunluk e-postadakinden daha hızlı ortaya çıkar, çünkü sessize almak işletim sisteminin zaten gösterdiği bir bildirimde tek dokunuşa mal olur.

Zamanlama hem bir avantaj hem bir tehlikedir. Push anında ulaşır, dolayısıyla saat 02.00’de gönderilen bir mesaj 02.00’de varır. Abonenin saat dilimini abone olma anında saklayın veya çıkarsayın ve gönderimleri tanımlı bir pencere içinde tutun.

Segmentasyon, bir kişi hakkında değil bir abonelik hakkında bildiklerinizle sınırlıdır, bu yüzden işe yarayan boyutlar davranışsaldır: görüntülenen sayfalar, takip edilen ürünler, sepet durumu, satın alma yakınlığı, platform. Müşteri segmentasyonu kılavuzu konuyu daha derin ele alıyor.

Web push’u ölçmek

Dört metrik önemlidir ve hepsi aynı şekilde ölçülebilir değildir.

• Teslimat. Push hizmetinin isteği kabul edip etmediği. 201 kabul edildi demektir, teslim edildi değil. 404 veya 410 aboneliğin öldüğü anlamına gelir.
• Gösterim. Bildirimin gösterilip gösterilmediği. Bunu ancak showNotification() çözümlendiğinde service worker geri bildirim yaparsa bilirsiniz.
• Tıklama oranı. Tıklamaların gösterimlere bölümü. Optimize etmeye değer rakam budur.
• Çıkma oranı. Gönderim başına abonelikten çıkmalar ve izin geri almaları. Bunu tıklama oranından daha yakından izleyin, çünkü kanalın ölümünün öncü göstergesidir.

İlişkilendirme tuzakları

Push ilişkilendirmesi kendini olduğundan iyi gösterir. Bildirim, abonenin zaten elinde tuttuğu bir cihaza gelir, dolayısıyla zaten gerçekleşecek bir oturumun kredisini sıklıkla üstlenir. Artımlılığı varsaymak yerine kontrol grupları çalıştırın. Gösterimler eksik sayılırken her tıklama kaydedilir, bu yüzden gönderimlere göre hesaplanan bir tıklama oranı performansı olduğundan iyi gösterir. Ve bir abonelik bir kişi değil bir tarayıcı olduğu için, telefonda tıklanıp masaüstünde satın almayla biten bir push, birbiriyle ilgisiz iki olay gibi görünür. E-posta pazarlaması metrikleri kılavuzu kanallar genelinde ölçüm hijyenini anlatıyor.

Rıza, GDPR ve çıkış

Tarayıcı izin istemi teknik bir kapıdır. Otomatik olarak pazarlama için eksiksiz bir hukuki dayanak değildir.

AB’deki veya Birleşik Krallık’taki kişilere pazarlama yapıyorsanız, push’a e-postaya davrandığınız gibi davranın. İstem görünmeden önce ne göndereceğinizi açıklayın ki rıza bilgilendirilmiş ve belirli olsun. Aboneliğin ne zaman ve nerede oluşturulduğunu kaydedin ve push rızasını asla ilgisiz bir eyleme iliştirmeyin. Abonelikleri kimliği belirli müşterilere bağlıyorsanız, o veri silme talepleri dahil kişisel veri yükümlülüklerinizin içindedir.

Çıkış hijyeni de aynı ölçüde önemlidir. İnsanların engellemek yerine sıklığı azaltabilmesi için site içinde bir tercih kontrolü sunun, bunu yaptıklarında PushSubscription.unsubscribe() çağrısını yapın ve kaydı sunucu tarafında silin, 404 veya 410 aldığınızda abonelikleri temizleyin. MDN’nin yönlendirmesi kısa ve doğru: kullanıcılara “gelecekte daha fazlasını almaktan vazgeçmenin kolay bir yolu sunulmalıdır”.

Web push kanal yığınında nereye oturur

Web push iyi bir üçüncü kanal, kötü bir ilk kanaldır: hızlı, marjda ücretsiz ve zaman kritik uyarılarda rakipsiz, ama cihaza bağlı, dışa aktarılamaz ve kalıcı kayba tek tıklama uzaklıkta.

Bu da asıl sorunu orkestrasyon yapar. Hangi mesajın hangi kanala gideceği, push zaten dönüşüm sağladığında e-postayı nasıl bastıracağınız ve kişileri farklı biçimde tanımlayan yüzeyler arasında müşterinin tek görünümünü nasıl koruyacağınız. Brevo, e-posta ve SMS’in yanında web ve mobil push sunuyor ve Tajo Shopify mağazaları için bu kanallar arası mantığı koordine etmek üzere Brevo’nun üstünde yer alıyor. SMS tarafı için SMS otomasyonu kılavuzuna bakın.

Önemli çıkarımlar

• Web push, iş birliği yapan üç API’dir: arka planda çalışma için bir service worker, abonelik ve taşıma için Push API, gösterim için Notifications API. Bir abonelik, bir endpoint artı bir p256dh anahtarı ve bir auth sırrıdır; yükler uçtan uca şifrelenir ve göndericiyi VAPID kanıtlar.
• Push, Mart 2023’ten bu yana Baseline olarak yaygın biçimde kullanılabilir, ancak iOS ve iPadOS’ta yalnızca Ana Ekran’a eklenmiş web uygulamaları için çalışır.
• İzni asla sayfa yüklenirken istemeyin. Yumuşak bir ön istem kullanın, bağlam içinde sorun ve bir engellemenin o kaynak için kalıcı olduğunu unutmayın.
• Chrome artık daha sessiz istemleri, hız sınırlarını ve otomatik izin geri almayı uyguluyor, dolayısıyla kötü gönderim size zaten sahip olduğunuz abonelere mal olur.
• Bir abonelik bir kişi değil bir tarayıcıdır ve dışa aktarılamaz. Önce e-posta listesini kurun ve push’u onu hızlandırmak için kullanın.