Web Push Notification: Cara Kerjanya dan Cara Memakainya dengan Benar

Web push notification adalah satu-satunya kanal marketing di mana satu keputusan desain yang keliru bisa mengunci Anda dari seorang pelanggan secara permanen. Minta izin pada saat yang salah, pengunjung menekan Block, dan browser itu tertutup untuk Anda selamanya. Tidak ada permintaan ulang, tidak ada kampanye kedua, tidak ada email win-back. Ketimpangan itulah yang membuat mekanismenya layak dipahami sebelum Anda menulis satu pesan pun.

Apa itu web push notification

Web push notification adalah pesan yang dikirim dari server Anda ke browser seorang pelanggan email, ditampilkan oleh pusat notifikasi sistem operasi, dan terkirim bahkan ketika situs Anda sedang tertutup. Bagian terakhir itulah intinya: tidak seperti popup di halaman, web push menjangkau orang yang saat ini tidak sedang melihat situs Anda.

Web push dibangun dari tiga API platform web yang bekerja bersama, dan pembagian di antara ketiganya menjelaskan sebagian besar perilaku kanal ini: Service Worker API, Push API, dan Notifications API.

Cara kerja web push di balik layar

Service worker

Service worker adalah worker JavaScript yang bertindak sebagai proxy antara web app Anda, browser, dan jaringan. Ia berjalan di thread-nya sendiri, tidak punya akses DOM, dan tetap hidup setelah halaman yang mendaftarkannya ditutup. Ketahanan itulah yang membuatnya bisa menerima pesan push dan menampilkan notifikasi ketika tidak ada seorang pun yang membuka tab Anda. Service worker hanya berjalan dalam secure context, yang berarti HTTPS, dengan http://localhost diperlakukan aman untuk pengembangan.

Langganan: satu endpoint plus dua kunci

Setelah service worker aktif, halaman memanggil registration.pushManager.subscribe(). Browser berkomunikasi dengan push service milik vendornya dan mengembalikan sebuah PushSubscription yang berisi:

• endpoint, URL kapabilitas unik tempat push service menerima pesan
• keys.p256dh, kunci publik Elliptic Curve Diffie-Hellman pada kurva P-256
• keys.auth, sebuah rahasia autentikasi

Server Anda menyimpan ketiganya dan memperlakukan endpoint sebagai rahasia, karena siapa pun yang memegangnya bisa mengirim ke pelanggan tersebut. Kunci-kunci itu ada karena payload dienkripsi ujung ke ujung. RFC 8291 menetapkan caranya: pertukaran ECDH pada P-256 membentuk rahasia bersama, HKDF menurunkan kunci darinya, dan payload disegel dengan AES-128-GCM di bawah content encoding aes128gcm. Push service hanya meneruskan ciphertext yang tidak bisa dibacanya.

Push service

Anda tidak mengirim pesan push langsung ke perangkat. Anda mengirimnya ke push service yang dijalankan vendor browser: endpoint FCM milik Google untuk Chrome, autopush milik Mozilla untuk Firefox, push service milik Apple untuk Safari. RFC 8030, “Generic Event Delivery Using HTTP Push”, mendefinisikan protokolnya. Server Anda melakukan POST ke endpoint langganan, dan push service menangani bagian sulit dari pengiriman ke perangkat mobile: satu koneksi hemat baterai ke perangkat, antrean saat offline, dan membangunkan browser ketika pesan tiba. Ini juga alasan pengiriman tidak bisa dijamin. Kalau perangkat mati cukup lama, pesan kedaluwarsa sesuai TTL-nya dan dibuang.

VAPID: membuktikan siapa yang mengirim

Endpoint yang bersifat rahasia adalah keamanan yang tipis. RFC 8292 menambahkan Voluntary Application Server Identification, atau VAPID, supaya push service bisa mengetahui dari application server mana sebuah pesan berasal.

Anda membuat pasangan kunci ECDSA pada kurva NIST P-256 satu kali. Kunci publiknya masuk ke applicationServerKey ketika browser berlangganan, mengikat langganan itu ke server Anda. Untuk setiap push, server Anda mengirim JWT yang ditandatangani dengan kunci privat pasangannya memakai ES256, membawa klaim aud untuk origin push service, klaim exp tidak lebih dari 24 jam ke depan, dan opsional klaim sub berisi detail kontak. Push service memverifikasi tanda tangannya, sehingga endpoint yang dicuri saja tidak lagi cukup untuk menyebar spam ke pelanggan Anda.

Jalur pengiriman, dari ujung ke ujung

1. Halaman mendaftarkan service worker dan, setelah izin diberikan, memanggil subscribe() dengan kunci publik VAPID Anda.
2. Server Anda menyimpan endpoint dan kunci yang dikembalikan pada record pelanggan.
3. Untuk mengirim, server Anda mengenkripsi payload dengan p256dh dan auth, menandatangani JWT VAPID, lalu melakukan POST ke endpoint.
4. Push service mengautentikasi permintaan dan mengirimkan pesan terenkripsi.
5. Browser membangunkan service worker dengan event push, yang mendekripsi payload lalu memanggil ServiceWorkerRegistration.showNotification().
6. Sebuah klik memicu notificationclick di service worker, tempat Anda membuka URL tujuan.

Mengapa model izinnya begitu ketat

Lihat apa yang diberikan sebuah langganan: proses latar belakang yang berjalan tanpa situs Anda terbuka, ditambah kemampuan menggambar pada permukaan notifikasi sistem operasi. Karena itu browser memagarinya dengan izin eksplisit per origin yang diberikan pengguna, dan sebagian besar mensyaratkan permintaan itu mengikuti gestur pengguna yang sungguhan.

Ada kendala kedua yang mengejutkan banyak orang. Chrome dan Edge mewajibkan userVisibleOnly: true saat subscribe, yaitu janji bahwa setiap push akan menghasilkan notifikasi yang terlihat pengguna, sehingga push latar belakang yang senyap bukan penggunaan API ini yang didukung. Firefox juga menerapkan kuota untuk pesan push yang tidak menghasilkan notifikasi.

Dukungan browser dan platform

Menurut MDN, Push API sudah berstatus Baseline widely available sejak Maret 2023, yang berarti berfungsi di versi terkini Chrome, Edge, Firefox, dan Safari di desktop, serta di Chrome dan Firefox untuk Android. Ada dua catatan yang lebih penting daripada judulnya.

Pertama, Notifications API tidak tersedia secara merata. MDN menandainya sebagai limited availability karena konstruktor Notification() melempar TypeError di sebagian besar browser mobile. Untuk apa pun yang harus berjalan di ponsel, gunakan notifikasi persisten melalui ServiceWorkerRegistration.showNotification(), yang memang jalur service worker yang sudah Anda pakai.

Kedua, opsi notifikasi diimplementasikan secara tidak merata. Tombol aksi, badge, gambar, dan requireInteraction berbeda-beda antar browser dan sistem operasi, jadi rancang notifikasi yang tetap terbaca benar hanya dengan judul, isi, dan ikon.

Persyaratan iOS dan iPadOS

Catatan ini menentukan apakah web push layak untuk audiens yang didominasi mobile, dan hampir di mana-mana catatan ini dinyatakan keliru.

Apple menambahkan Web Push di iOS dan iPadOS 16.4, dan itu hanya berfungsi untuk web app yang sudah ditambahkan ke Home Screen. Seperti dikatakan WebKit, “we are adding support for Web Push to Home Screen web apps”, dan “a web app that has been added to the Home Screen can request permission to receive push notifications”. Pengguna menambahkannya lewat menu Share dan “Add to Home Screen”, lalu izin harus diminta sebagai respons atas interaksi langsung pengguna, misalnya mengetuk tombol berlangganan.

Situs yang terbuka di tab Safari biasa pada iPhone tidak bisa membuat langganan push. Itu hambatan nyata: Anda meminta langkah instalasi sebelum bisa meminta izin sama sekali. Di macOS keadaannya lebih mudah, karena Safari 16.1 di macOS Ventura menambahkan Web Push berbasis standar untuk situs web biasa tanpa langkah instalasi.

Contoh langganan minimal

Ini keseluruhan alur di sisi klien. Tempatnya di dalam click handler, bukan saat halaman dimuat.

async function subscribeToPush(vapidPublicKey) {
  // Push dan service worker memerlukan secure context (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

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

  // Harus dipanggil dari gestur pengguna, dan hanya sekali per pengguna.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // kunci publik P-256 berformat base64url
  });

  // Simpan endpoint + kunci di sisi server; perlakukan endpoint sebagai rahasia.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Di dalam sw.js Anda menangani event push, memanggil self.registration.showNotification(title, options), dan menangani notificationclick untuk membuka URL tujuan.

UX izin: tempat sebagian besar program gagal

Jangan pernah meminta saat halaman dimuat

Lighthouse punya audit khusus untuk ini: “if your page asks for permission to send notifications on page load, those notifications may not be relevant to your users or their needs”. Rekomendasinya adalah menawarkan jenis notifikasi yang spesifik dan meminta izin hanya setelah pengguna memilih ikut untuk jenis itu. Safari 12.1 dan browser lain melangkah lebih jauh dengan mewajibkan interaksi dengan halaman sebelum permintaan bisa diajukan sama sekali.

Gunakan soft pre-prompt

Tampilkan undangan Anda sendiri di dalam halaman terlebih dahulu. Undangan itu menyebutkan nilai yang ditawarkan, bisa ditutup tanpa biaya permanen, dan hanya klik padanya yang memicu prompt browser yang sesungguhnya. Orang yang mengabaikan soft prompt Anda hari ini bisa ditanya lagi bulan depan. Orang yang menekan Block tidak bisa. Dua aturan membuatnya berhasil: jelaskan apa yang benar-benar akan Anda kirim alih-alih “dapatkan update”, dan jangan pernah merekayasa klik yang keliru, karena penerimaan yang tidak sengaja menghasilkan berhenti berlangganan seketika.

Minta izin dalam konteks

Rekomendasi Chrome sendiri adalah “let your users take the initiative and turn on notifications at their own pace” dengan menempatkan toggle secara diskret di dalam permukaan antarmuka yang sudah ada, serta menghindari “showing prompts and/or overlays without context or immediately after a user lands on the site”.

Momen yang berhasil di ranah commerce sangat spesifik: kontrol “beri tahu saya kalau stok kembali” pada produk yang habis, halaman konfirmasi pesanan yang menawarkan update pengiriman, toggle pantau harga pada produk yang sering dilihat. Izinnya ditukar dengan manfaat yang jelas, bukan dipanen.

Penolakan praktis bersifat permanen

Ketika seseorang memblokir notifikasi, browser menyimpan keputusan itu untuk origin Anda. Panggilan Notification.requestPermission() berikutnya langsung menghasilkan nilai denied yang tersimpan tanpa menampilkan apa pun, itulah sebabnya contoh milik MDN sendiri memeriksa Notification.permission sebelum memanggil requestPermission(). Membatalkan blokir berarti menggali pengaturan situs, yang praktis tidak dilakukan siapa pun.

Apa yang dilakukan browser ketika Anda salah langkah

Konsekuensinya bukan lagi sekadar opt-in rate yang rendah.

• Chrome secara otomatis memasukkan origin dengan tingkat penerimaan sangat rendah ke UI izin yang lebih senyap, terpisah menurut jenis perangkat, sehingga prompt ditekan untuk semua orang.
• Chrome menerapkan rate limit pada situs yang menggabungkan volume push tinggi dengan engagement rendah, dan mengembalikan HTTP 429. Eskalasinya berjalan satu hari, lalu tujuh hari, lalu empat belas hari, dan baru direset setelah 42 hari berturut-turut tanpa gangguan.
• Chrome kini otomatis mencabut izin notifikasi untuk situs yang belum lama ini tidak diinteraksikan pengguna, ketika ada “very low user engagement and a high volume of notifications being sent”. Alasan Google terdengar keras: “Less than 1% of all notifications receive any interaction from users.”

Anda bisa kehilangan pelanggan yang sudah Anda peroleh hanya karena cara mengirim yang buruk.

Web push dibandingkan email dan SMS

Perbedaan kepemilikan yang mengubah strategi

Langganan push adalah URL kapabilitas yang terikat pada satu profil browser di satu perangkat. Itu bukan seorang manusia. Pelanggan yang sama yang memakai Chrome di laptop dan Firefox di ponsel adalah dua langganan yang tidak berhubungan, dan Anda tidak bisa tahu keduanya orang yang sama kecuali mereka mengidentifikasi diri.

Langganan itu juga tidak portabel. Anda bisa mengekspor daftar email dan memuatnya ke platform lain besok. Anda tidak bisa memindahkan langganan push antar vendor, karena kunci dan pengikatan VAPID dibuat terhadap application server key tertentu.

Jadi perlakukan web push sebagai akselerator bagi kanal yang Anda miliki, jangan pernah sebagai pengganti. Gunakan momen push untuk memperoleh alamat email atau nomor telepon, bukan sebaliknya. Panduan lengkap otomatisasi marketing membahas cara merangkai beberapa kanal menjadi satu perjalanan.

Kasus penggunaan yang benar-benar berhasil

Kanal ini memberi imbalan pada pesan yang sensitif waktu, relevan secara pribadi, dan bisa ditindaklanjuti dalam satu ketukan.

• Keranjang terbengkalai. Satu push dalam sejam, diperkuat email menyusul. Panduan email keranjang terbengkalai membahas urutannya.
• Notifikasi stok kembali. Kasus terkuat, karena pengguna secara eksplisit meminta diberi tahu.
• Penurunan harga pada barang yang dipantau. Logika yang sama, relevansi yang dipilih sendiri.
• Status pengiriman dan pesanan. Niat membuka tinggi, risiko keluhan rendah.
• Update penting pada topik yang dilanggan. Berita, hasil, jendela ketersediaan.

Yang gagal juga sama jelasnya: siaran generik “kami menerbitkan artikel baru”, promo harian tanpa pembeda, apa pun yang butuh lebih dari satu judul dan satu baris, blast re-engagement ke pelanggan yang mengabaikan dua puluh notifikasi terakhir, dan konten transaksional yang butuh catatan yang tahan lama.

Frekuensi, waktu, dan segmentasi

Mulailah konservatif: satu sampai tiga notifikasi per pelanggan per minggu, dan tambah hanya jika tingkat opt-out dan klik tetap terjaga. Kelelahan muncul lebih cepat daripada di email karena membisukan hanya butuh satu ketukan pada notifikasi yang sudah dimunculkan sistem operasi.

Waktu adalah keunggulan sekaligus bahaya. Push tiba seketika, jadi pesan yang dikirim pukul 02.00 tiba pukul 02.00. Simpan atau simpulkan zona waktu pelanggan saat mereka berlangganan dan tahan pengiriman di dalam jendela waktu yang ditentukan.

Segmentasi dibatasi oleh apa yang Anda ketahui tentang sebuah langganan, bukan tentang seseorang, jadi dimensi yang bisa dipakai bersifat perilaku: halaman yang dilihat, produk yang dipantau, status keranjang, kebaruan pembelian, platform. Panduan segmentasi pelanggan membahasnya lebih dalam.

Mengukur web push

Ada empat metrik yang penting, dan tidak semuanya bisa diukur dengan cara yang sama.

• Pengiriman. Apakah push service menerima permintaannya. Kode 201 berarti diterima, bukan terkirim. Kode 404 atau 410 berarti langganannya mati.
• Tampilan. Apakah notifikasinya ditampilkan. Anda hanya tahu ini kalau service worker melaporkan balik ketika showNotification() selesai.
• Click-through rate. Klik dibagi tampilan. Inilah angka yang layak dioptimalkan.
• Tingkat opt-out. Berhenti berlangganan dan pencabutan izin per pengiriman. Awasi lebih ketat daripada CTR, karena ini indikator awal matinya sebuah kanal.

Jebakan atribusi

Atribusi push cenderung memuji dirinya sendiri. Notifikasi tiba di perangkat yang sudah dipegang pelanggan, jadi sering mengklaim sesi yang toh akan terjadi. Jalankan grup holdout alih-alih mengasumsikan inkrementalitas. Tampilan tercatat kurang sementara setiap klik tercatat penuh, sehingga CTR yang dihitung terhadap jumlah kirim melebih-lebihkan performa. Dan karena langganan adalah browser, bukan orang, push yang diklik di ponsel lalu berakhir dengan pembelian di desktop terlihat seperti dua peristiwa yang tidak berhubungan. Panduan metrik email marketing membahas kebersihan pengukuran lintas kanal.

Consent, GDPR, dan opt-out

Prompt izin browser adalah gerbang teknis. Itu tidak otomatis menjadi dasar hukum yang lengkap untuk marketing.

Ketika Anda memasarkan ke orang di Uni Eropa atau Inggris, perlakukan push seperti Anda memperlakukan email. Jelaskan apa yang akan Anda kirim sebelum prompt muncul, supaya consent-nya terinformasi dan spesifik. Catat kapan dan di mana langganan dibuat, dan jangan pernah menggabungkan consent push ke dalam tindakan yang tidak berkaitan. Kalau Anda mengaitkan langganan dengan pelanggan yang teridentifikasi, data itu masuk ke dalam kewajiban data pribadi Anda, termasuk permintaan penghapusan.

Kebersihan opt-out sama pentingnya. Sediakan kontrol preferensi di dalam situs supaya orang bisa mengurangi frekuensi alih-alih memblokir, panggil PushSubscription.unsubscribe() dan hapus record-nya di sisi server ketika mereka melakukannya, serta bersihkan langganan saat menerima 404 atau 410. Panduan MDN singkat dan tepat: pengguna harus “offered an easy way to opt out of getting more in the future”.

Posisi web push dalam tumpukan kanal

Web push adalah kanal ketiga yang baik dan kanal pertama yang buruk: cepat, praktis gratis di margin, dan tak tertandingi untuk peringatan yang genting waktu, tetapi terikat perangkat, tidak bisa diekspor, dan hanya satu klik dari kehilangan permanen.

Karena itu orkestrasi adalah masalah yang sebenarnya. Pesan mana ke kanal mana, bagaimana Anda menekan email ketika push sudah mengonversi, dan bagaimana Anda menjaga satu pandangan tentang pelanggan di seluruh permukaan yang mengidentifikasi orang secara berbeda. Brevo menawarkan push web dan mobile berdampingan dengan email dan SMS, dan Tajo duduk di atas Brevo untuk mengoordinasikan logika lintas kanal itu bagi toko Shopify. Untuk sisi SMS, lihat panduan otomatisasi SMS.

Poin utama

• Web push adalah tiga API yang bekerja sama: service worker untuk eksekusi latar belakang, Push API untuk langganan dan transport, Notifications API untuk tampilan. Sebuah langganan terdiri dari endpoint plus kunci p256dh dan rahasia auth, payload dienkripsi ujung ke ujung, dan VAPID membuktikan pengirimnya.
• Push sudah berstatus Baseline widely available sejak Maret 2023, tetapi di iOS dan iPadOS hanya berfungsi untuk web app yang ditambahkan ke Home Screen.
• Jangan pernah meminta izin saat halaman dimuat. Gunakan soft pre-prompt, minta dalam konteks, dan ingat bahwa blokir bersifat permanen untuk origin tersebut.
• Chrome kini menerapkan prompt yang lebih senyap, rate limit, dan pencabutan izin otomatis, jadi mengirim dengan buruk membuat Anda kehilangan pelanggan yang sudah dimiliki.
• Sebuah langganan adalah browser, bukan orang, dan tidak bisa diekspor. Bangun daftar email lebih dulu dan pakai push untuk mempercepatnya.