Cara Meningkatkan Jumlah Impresi Web Push

"Push sudah terkirim, tetapi jumlah impresi jauh di bawah harapan" adalah salah satu pertanyaan paling umum dari pengguna Web Push. Impresi bukanlah metrik yang berdiri sendiri; impresi adalah hasil dari kehilangan yang terakumulasi di tahap langganan, pengiriman, penyampaian, dan tahap lainnya. Artikel ini membantu Anda menemukan penyebab rendahnya impresi lapis demi lapis di sepanjang funnel, memberikan langkah optimasi untuk setiap jenis penyebab, dan diakhiri dengan pendekatan menyeluruh yang dapat dijalankan secara berkelanjutan.

Samakan Definisi Dulu: Di Lapisan Funnel Mana Impresi Berada

EngageLab mencatat setiap push berdasarkan tahapan berikut. Definisi setiap tahap dapat dilihat di Statistik Push dan API Statistik:

flowchart LR
    plan["Target rencana"]
    targets["Target valid<br/>perangkat aktif dalam 365 hari terakhir"]
    sent["Terkirim<br/>tugas kirim dibuat oleh server"]
    delivered["Tersampaikan<br/>benar-benar sampai ke klien Web"]
    impressions["Impresi<br/>berhasil ditampilkan di perangkat"]
    clicks["Klik"]

    plan --> targets --> sent --> delivered --> impressions --> clicks

Ada tiga hal tentang "impresi" yang harus dipahami terlebih dahulu; jika tidak, masalah definisi statistik mudah disalahartikan sebagai masalah push:

1. Impresi dilaporkan oleh SDK. Di API Callback, status Impression didefinisikan sebagai "notifikasi Web Push dan pesan in-app yang dilaporkan berhasil ditampilkan oleh SDK"; lihat API Callback. Tampilan yang tidak dilaporkan melalui SDK tidak dihitung sebagai impresi.
2. Pesan kustom tidak dihitung sebagai impresi secara default. message (pesan kustom) di API Buat Push tidak ditampilkan di browser, melainkan diteruskan ke halaman web Anda; untuk menghitung impresi, Anda harus memanggil customDisplayReport dari halaman Anda. Lihat API Web SDK.
3. Jendela statistik adalah 5 hari. Penyampaian dan impresi yang terjadi lebih dari 5 hari setelah pengiriman berhasil tidak dihitung dan tidak lagi memicu callback.

Karena itu, saat menyelidiki impresi yang rendah, bedakan dulu antara "tingkat impresi rendah" (tersampaikan tetapi tidak ditampilkan) dan "jumlah impresi rendah tetapi tingkat impresi normal" (masalahnya ada di hulu: langganan, pengiriman, atau penyampaian). Penyebab dan solusi kedua kasus ini sama sekali berbeda.

Bagian 1: Cara Menyelidiki Penyebab Impresi Rendah

Telusuri funnel dari hulu ke hilir; di setiap lapisan lihat datanya lebih dulu, lalu tentukan penyebabnya.

1.1 Apakah Basis Pelanggan Cukup Besar?

Batas atas impresi ditentukan oleh ukuran basis pengguna berlangganan. Jika pelanggan sedikit, tingkat pengiriman dan impresi setinggi apa pun tidak akan menghasilkan jumlah impresi yang berarti.

Di mana melihatnya:

• Ringkasan Pengguna: bandingkan "pengguna berlangganan" dengan "pengguna aktif". Pengguna berlangganan adalah jumlah perangkat pengguna unik yang telah berlangganan dan menyetujui penerimaan notifikasi. Jika jauh lebih rendah daripada pengguna aktif, berarti banyak pengunjung belum menyelesaikan otorisasi.
• Ikhtisar: periksa tingkat aktivasi izin notifikasi perangkat dan jumlah pengguna yang mematikan notifikasi.
• Kueri Data: periksa secara acak status online dan waktu online terakhir Registration ID tertentu untuk memastikan langganan masih valid.

Penyebab umum (lihat FAQ dan Pengaturan Dasar):

• Menggunakan mode "permintaan langsung" yang memunculkan dialog izin native browser. Begitu pengguna mengklik Block / Don't Allow, izin tidak dapat diminta lagi kecuali pengguna mengubah pengaturan browser sendiri.
• Situs tidak menggunakan HTTPS atau domain belum dikonfigurasi di konsol, sehingga prompt izin native tidak dapat muncul dan langganan tidak dapat dilakukan.
• Service Worker tidak ditempatkan di root situs, atau cakupannya berkonflik dengan Service Worker PWA yang sudah ada, sehingga langganan gagal.
• Pengguna iOS belum menambahkan situs ke layar utama, atau permintaan izin tidak dipicu oleh gestur pengguna.
• Pengguna memakai mode penyamaran, penjelajahan pribadi, atau mode tamu, yang tidak mendukung Web Push.
• Ketika user_str yang sama berlangganan di beberapa browser atau perangkat, langganan baru menggantikan yang lama, dan hanya perangkat yang terakhir berlangganan yang menerima pesan.

1.2 Apakah Ada Kehilangan Besar dari Target Valid ke Terkirim?

Di mana melihatnya:

• Riwayat Push: bandingkan target valid dan terkirim untuk satu push, lalu periksa alasan gagal di detail pesan.
• Kueri siklus hidup push di API Statistik: status target_invalid dan sent_failed menunjukkan tahap kehilangan pada perangkat tertentu.

Penyebab umum:

• Target valid didefinisikan sebagai "aktif dalam 365 hari terakhir"; langganan yang lama tidak aktif tidak menjadi target valid.
• Di Pengaturan Lanjutan telah dikonfigurasi batas push per perangkat per jam / hari / minggu atau rentang waktu pengiriman yang diizinkan; pesan yang melebihi batas atau di luar rentang waktu langsung dibuang.

1.3 Apakah Ada Kehilangan Besar dari Terkirim ke Tersampaikan?

Ini adalah lapisan yang paling sering disalahartikan sebagai "impresi rendah". Jika tersampaikan rendah, impresi pasti rendah, tetapi tingkat impresi saat itu mungkin normal.

Di mana melihatnya:

• Tingkat pengiriman satu push di Riwayat Push; data penyampaian yang dipisah per browser (Chrome, Safari, Firefox, Edge, kanal EngageLab, dll.) di Statistik Push.
• Field sub yang dikembalikan API Statistik menampilkan tersampaikan dan impresi secara terpisah untuk notification dan message; field engageLab_web, chrome, safari, firefox, edge memungkinkan pemisahan per kanal.

Penyebab umum (lihat API Buat Push dan FAQ):

• time_to_live diatur ke 0: pesan offline tidak disimpan, hanya pengguna yang sedang online yang dapat menerimanya. Nilai default adalah 86400 detik (1 hari), maksimum 15 hari.
• Perbedaan kanal: kanal EngageLab mengharuskan pengguna membuka halaman situs Anda; kanal sistem (Chrome, Edge, Firefox, dll.) dapat menerima selama proses browser masih ada di sistem operasi, tetapi tidak jika browser sudah benar-benar ditutup; kanal sistem Safari tidak memerlukan browser berjalan.
• Pengguna menghapus cookie / cache browser, sehingga informasi langganan kanal vendor ikut hilang. Jika izin notifikasi masih "izinkan", SDK akan berlangganan ulang secara otomatis saat pengguna kembali ke situs dan mendapat Registration ID baru; jika izin sudah diubah ke "tanya" atau "blokir", tidak ada langganan ulang otomatis.
• Strategi third_party_channel.w3push.distribution tidak sesuai dengan perilaku pengguna Anda, misalnya memaksa mtpush (hanya kanal EngageLab) padahal pengguna jarang berada di situs.
• Kanal vendor browser tidak stabil; FAQ menyarankan beralih ke pengiriman dengan prioritas kanal EngageLab dalam kasus ini.

1.4 Apakah Ada Kehilangan dari Tersampaikan ke Impresi (Tingkat Impresi Rendah)?

Hanya ketika tersampaikan normal tetapi impresi jelas rendah, barulah ini benar-benar masalah "tingkat impresi".

Di mana melihatnya:

• "Tersampaikan / Impresi" dan rasionya per platform di detail Riwayat Push.
• Event Impression dan impression_failed di API Callback.

Penyebab umum:

1.5 Daftar Periksa Penelusuran

Saat menelusuri, periksa item sesuai urutan di bawah; singkirkan dulu masalah definisi dan hulu, baru lihat impresi itu sendiri:

Bagian 2: Cara Mengoptimalkan Setelah Penyebab Ditemukan

2.1 Memperbesar Basis Pelanggan

• Beralih ke permintaan terpandu (soft prompt). Di izin notifikasi pada Pengaturan Dasar, pilih "permintaan terpandu": jelaskan dulu nilai notifikasi dengan tampilan kustom, lalu picu dialog izin native hanya setelah pengguna menunjukkan minat. Ini mencegah pengguna mengklik Block sebelum memahami manfaatnya, yang membuat izin tidak dapat diminta lagi secara permanen. Soft prompt mendukung interval prompt awal (default 3 hari) dan interval lanjutan (default 7 hari) hingga pengguna berlangganan.
• Pastikan prasyarat lengkap. Gunakan HTTPS dan konfigurasikan domain di [Pengaturan Integrasi] - [Domain Situs Web] (maksimal 100). Tempatkan file Service Worker di root situs untuk cakupan maksimal. Jika situs sudah memiliki Service Worker PWA, gabungkan keduanya atau pastikan cakupannya tidak tumpang tindih; lihat Panduan Integrasi Web SDK dan FAQ.
• Pandu pengguna iOS. Safari di iOS / iPadOS 16.4 ke atas mengharuskan pengguna menambahkan situs ke layar utama dan membukanya dari sana, lalu izin dipicu oleh gestur pengguna (misalnya mengetuk tombol berlangganan). Disarankan menempatkan banner panduan di halaman.
• Hindari perangkat saling menggeser. Jika Anda mengidentifikasi pengguna dengan user_str, perhatikan bahwa ketika user_str yang sama berlangganan di beberapa browser / perangkat, hanya perangkat terakhir yang berlangganan yang menerima pesan. Untuk menjangkau semua perangkat pengguna, jangan gunakan user_str yang sama di perangkat berbeda.
• Jangan kehilangan langganan saat migrasi. Saat bermigrasi dari penyedia lain ke EngageLab, tangani Service Worker lama sesuai Cara Menghindari Hilangnya Pelanggan Saat Migrasi Web Push; pengguna yang sudah memberikan izin tidak akan melihat dialog izin lagi setelah inisialisasi.

2.2 Mengurangi Kehilangan dari Target Valid ke Terkirim

• Konfigurasikan batas push per perangkat dan rentang waktu pengiriman di Pengaturan Lanjutan sesuai kebutuhan bisnis. Kontrol frekuensi melindungi pengalaman pengguna, tetapi pengaturan yang terlalu ketat akan langsung membuang pesan; evaluasi bersama rencana push Anda.
• Gunakan API Hapus Pengguna secara berkala untuk membersihkan langganan yang dipastikan tidak aktif, agar target valid lebih akurat mencerminkan pengguna yang dapat dijangkau dan statistik tidak terdilusi oleh langganan tidak valid. Penghapusan tidak dapat dibatalkan; lakukan dengan hati-hati.

2.3 Meningkatkan Penyampaian

• Atur time_to_live dengan tepat. Jangan gunakan 0; pertahankan default 1 hari atau perpanjang sesuai kebaruan konten, maksimal 15 hari. Untuk konten yang tidak sensitif waktu, masa simpan offline yang lebih panjang memungkinkan pengguna offline tetap menerimanya saat membuka browser kembali.

• Pilih strategi distribusi yang sesuai. Pada third_party_channel.w3push.distribution:

  • first_ospush (default): kanal sistem lebih dulu, jika tidak valid baru kanal EngageLab;
  • secondary_push: kanal EngageLab lebih dulu, jika pengguna offline baru kanal sistem; API Buat Push menyarankan opsi ini;
  • mtpush: memaksa kanal EngageLab; hanya cocok jika pengguna lama berada di situs;
  • ospush: memaksa hanya kanal sistem.

  Saat kanal vendor browser tidak stabil, Anda dapat beralih sementara ke prioritas kanal EngageLab.

• Gunakan override_msg_id dengan hati-hati. Menimpa notifikasi sebelumnya yang belum dibersihkan membuat pengguna hanya melihat yang terbaru; cocok untuk skenario pembaruan konten, tidak cocok jika Anda ingin beberapa notifikasi tetap tampil.

• Gunakan push dengan kecepatan terkontrol untuk kampanye atau volume besar. Dengan big_push_duration, sebarkan push secara merata dalam jumlah menit yang ditentukan (maksimal 1440) untuk menghindari puncak sesaat.

2.4 Meningkatkan Impresi

• Utamakan notifikasi. Untuk konten yang harus tampil di bilah notifikasi dan dihitung sebagai impresi, gunakan notification bukan message. Jika bisnis memang memerlukan pesan kustom, panggil customDisplayReport('msg_id') setelah menampilkannya di halaman dan customClickReport('msg_id') saat diklik.
• Hindari mengirim beberapa notifikasi berturut-turut ke pengguna yang sama dalam waktu singkat. Di Chrome, Edge, dan Firefox, notifikasi berikutnya menggantikan yang sebelumnya, sehingga pengguna hanya melihat yang terakhir dan hanya satu impresi yang dihitung. Gabungkan beberapa konten menjadi satu notifikasi atau beri jarak waktu pengiriman.
• Perhatikan kompatibilitas aset dan teks dengan browser. icon disarankan 192×192 dan tidak lebih dari 1 MB; ikon kustom hanya didukung Chrome dan Firefox, sedangkan Safari dan Edge memakai ikon default sistem. image disarankan 360×180 dan tidak lebih dari 1 MB; hanya didukung Chrome dan Edge, tidak didukung Firefox dan Safari. Kanal sistem membatasi panjang judul (kurang dari 20 karakter Mandarin atau 40 karakter Inggris); judul terlalu panjang dapat memengaruhi tampilan.
• Atur masa berlaku tampilan yang wajar untuk pesan in-app. Setelah masa berlaku terlewati, pesan tidak ditampilkan saat pengguna kembali ke halaman dan memicu impression_failed. Perpanjang masa berlaku untuk konten yang tidak sensitif waktu dan kendalikan ukuran gambar agar tidak gagal diunduh.
• Kirim pada jam aktif pengguna. Gunakan pengiriman cerdas di Tugas Terjadwal atau data pencocokan waktu aktif di Statistik Push untuk mengirim saat pengguna lebih mungkin membuka browser, sehingga mengurangi kedaluwarsa karena offline.
• Tafsirkan data Safari dengan benar. Kanal sistem Safari tidak dapat mengembalikan callback impresi dan klik, sehingga impresi rendah di kanal ini adalah keterbatasan statistik, bukan berarti notifikasi tidak ditampilkan. Saat menilai tingkat impresi, evaluasi Safari terpisah dari kanal lain.

Bagian 3: Pendekatan Menyeluruh untuk Meningkatkan Impresi Secara Sistematis

Perbaikan satu titik hanya menyelesaikan satu lapisan. Untuk terus meningkatkan impresi, jalankan "pertumbuhan pelanggan, jaminan penyampaian, dan pemantauan impresi" sebagai rutinitas operasional harian.

3.1 Membangun Tampilan Pemantauan per Kanal

• Setiap hari perhatikan funnel konversi push, tren tingkat pengiriman / impresi / klik, serta jumlah pengguna yang mengaktifkan / menonaktifkan notifikasi di Ikhtisar.
• Di Statistik Push, lihat tersampaikan dan impresi per browser, dengan fokus pada Chrome dan kanal EngageLab; evaluasi Safari secara terpisah.
• Terima event delivered, Impression, impression_failed, click, dan lainnya melalui API Callback lalu simpan ke basis data untuk analisis per pengguna dan per pesan yang lebih detail daripada konsol (statistik per pesan disimpan di sisi EngageLab paling lama satu bulan).
• Tetapkan baseline terpisah untuk tingkat pengiriman dan tingkat impresi: jika tingkat pengiriman turun tidak normal, periksa dulu time_to_live, strategi distribusi, dan kanal vendor; jika tingkat impresi turun tidak normal, periksa dulu jenis pesan, penimpaan oleh beberapa notifikasi, dan izin di sisi pengguna.

3.2 Daftar Tindakan per Fase

Fase integrasi (sekitar peluncuran)

• Gunakan HTTPS, konfigurasikan domain, tempatkan Service Worker di root, dan pastikan tidak ada konflik cakupan;
• Pilih "permintaan terpandu" untuk izin notifikasi, konfigurasikan teks dan interval soft prompt;
• Siapkan panduan tambah ke layar utama untuk pengguna iOS;
• Gunakan notifikasi (notification) alih-alih pesan kustom (message) sebagai cara jangkauan utama;
• Saat uji integrasi, gunakan Riwayat Push dan Kueri Data untuk memastikan status online, penyampaian, dan impresi perangkat target terhitung dengan benar.

Fase pertumbuhan (operasional harian)

• Bandingkan pertumbuhan pengguna berlangganan dan aktif setiap minggu; jika konversi langganan buruk, sesuaikan teks dan waktu pemicu soft prompt;
• Pertahankan time_to_live minimal 1 hari, gunakan secondary_push atau strategi default untuk distribution;
• Kendalikan frekuensi push ke pengguna yang sama untuk menghindari kehilangan impresi akibat penimpaan, sekaligus konfigurasikan kontrol frekuensi untuk melindungi pengalaman;
• Pilih waktu pengiriman dengan bantuan pengiriman cerdas atau data pencocokan waktu aktif;
• Bersihkan langganan yang lama tidak aktif secara berkala.

Fase kampanye (push puncak)

• Gunakan push kecepatan terkontrol untuk meratakan puncak;
• Persingkat time_to_live untuk konten sensitif waktu, dan perpanjang penyimpanan offline untuk konten yang boleh sampai belakangan;
• Gabungkan beberapa notifikasi pemasaran menjadi satu, atau kirim bertahap per segmen pengguna;
• Setelah push, tinjau tingkat pengiriman dan impresi per kanal, lalu terapkan pelajaran dari kanal bermasalah ke konfigurasi push berikutnya.

3.3 Ringkasan Satu Kalimat

Impresi = pengguna berlangganan × proporsi target valid × tingkat pengiriman × tingkat impresi. Gunakan data funnel untuk menentukan di lapisan mana kehilangan terjadi, lalu optimalkan lapisan tersebut. Untuk lapisan "impresi" itu sendiri, intinya adalah menggunakan notifikasi dan memastikan pelaporan SDK, menghindari penimpaan oleh beberapa notifikasi, serta menafsirkan data per kanal.

Dokumen Referensi

• Panduan Integrasi Web SDK
• API Web SDK
• Pengaturan Dasar
• Pengaturan Lanjutan
• API Buat Push
• API Callback
• API Statistik
• Statistik Push
• Riwayat Push
• FAQ
• Cara Menghindari Hilangnya Pelanggan Saat Migrasi Web Push