如何提高 Web Push 的推播展示數量

「推播發出去了，但展示數量遠低於預期」是 Web Push 接入方最常見的問題之一。展示數量並不是一個孤立的指標，它是訂閱、發送、送達等多個環節層層折損後的結果。本文協助您按漏斗逐層定位展示量偏低的原因，針對每類原因給出優化手段，並在最後提供一套可持續執行的綜合方案。

先統一口徑：展示在漏斗的哪一層

EngageLab 對每條推播按以下階段統計，各階段定義見 推播統計 與 統計 API：

flowchart LR
    plan["計畫目標"]
    targets["有效目標<br/>365 天內活躍過的裝置"]
    sent["發送數量<br/>伺服器成功建立發送任務"]
    delivered["送達數量<br/>實際送達至 Web 端"]
    impressions["展示數量<br/>在終端成功展示"]
    clicks["點擊數量"]

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

關於「展示」有三點必須先明確，否則很容易把統計口徑問題誤判為推播問題：

1. 展示由 SDK 上報。 回呼 API 中 Impression 狀態的定義是「Web Push 通知訊息和應用內訊息由 SDK 上報展示成功」，見 回呼 API。沒有經過 SDK 上報的展示不會計入展示數量。
2. 自訂訊息預設不計展示。 建立推播 API 中的 message（自訂訊息）不會展示在瀏覽器上，而是透傳給您的網頁；如需統計展示，需要您在網頁中呼叫 customDisplayReport 主動上報，見 Web SDK API。
3. 統計視窗為 5 天。 發送成功 5 天之後產生的送達與展示不再計入統計，也不再回呼。

因此，排查展示量低時，請先區分「展示率低」（送達了但沒展示）與「展示數低但展示率正常」（問題出在更上游的訂閱、發送、送達環節）。這兩類問題的原因和解法完全不同。

一、展示量低如何排查原因

建議按漏斗從上游到下游逐層排查，每一層先看資料、再定位原因。

1.1 訂閱池是否足夠大

展示數量的上限由訂閱使用者規模決定。如果訂閱使用者本身很少，再高的送達率與展示率也無法帶來可觀的展示數。

看哪裡：

• 使用者概況：對比「訂閱使用者」與「活躍使用者」。訂閱使用者是成功訂閱並同意接收通知的唯一使用者裝置數，若訂閱使用者遠低於活躍使用者，說明大量訪客沒有完成授權。
• 概況：查看裝置通知權限開啟率與「關閉通知使用者」數量。
• 資料查詢：抽查具體 Registration ID 的線上狀態與最後上線時間，確認訂閱是否仍然有效。

常見原因（見 FAQ 與 基礎設定）：

• 使用「直接申請」方式彈出瀏覽器原生授權框，使用者一旦點擊 Block / Don't Allow，之後無法再次申請，除非使用者自行修改瀏覽器設定。
• 站點未使用 HTTPS 或網域未在主控台設定，無法彈出原生授權提示，也無法訂閱。
• Service Worker 未放在網站根目錄，或與站點已有的 PWA Service Worker 作用域衝突，導致訂閱失敗。
• iOS 使用者未將網站加入主畫面，或授權請求不是由使用者手勢觸發。
• 使用者使用無痕模式、私密瀏覽模式或訪客模式，這些模式不支援 Web Push。
• 同一 user_str 在多個瀏覽器或裝置上訂閱時，新訂閱會取代舊訂閱，只有最後一次訂閱的裝置能收到訊息。

1.2 有效目標到發送是否有大量折損

看哪裡：

• 推播記錄：對比單條推播的有效目標數與發送數，並查看訊息詳情中的失敗原因。
• 統計 API 的推播生命週期查詢：target_invalid、sent_failed 狀態可定位具體裝置的折損階段。

常見原因：

• 有效目標口徑為「過去 365 天活躍過」，長期不活躍的訂閱不會成為有效目標。
• 進階設定 中設定了單裝置每小時 / 每天 / 每週的推播上限或可推播時間段，超出限制或不在時段內的訊息會被直接丟棄。

1.3 發送到送達是否有大量折損

這是最容易被誤判為「展示低」的一層。送達數低，展示數一定低，但此時展示率可能是正常的。

看哪裡：

• 推播記錄中單條推播的送達率；推播統計中按瀏覽器（Chrome、Safari、Firefox、Edge、EngageLab 通道等）拆分的送達資料。
• 統計 API 回傳的 sub 欄位可分別查看 notification 與 message 兩類訊息的送達與展示，engageLab_web、chrome、safari、firefox、edge 等欄位可按通道拆分。

常見原因（見 建立推播 API 與 FAQ）：

• time_to_live 設為 0：不保留離線訊息，僅目前線上的使用者能收到；預設值為 86400 秒（1 天），最長 15 天。
• 通道差異：EngageLab 通道需要使用者開啟您的站點頁面才能收到；系統通道（Chrome、Edge、Firefox 等）只要瀏覽器程序在作業系統中存在即可收到，瀏覽器程序完全退出則收不到；Safari 系統通道無需瀏覽器執行。
• 使用者清除了瀏覽器 Cookie / 快取，廠商通道的訂閱資訊隨之遺失；若通知權限仍為允許，使用者回到站點初始化 SDK 後會自動重新訂閱並取得新的 Registration ID，若權限已改為「詢問」或「封鎖」則不會自動重新訂閱。
• third_party_channel.w3push.distribution 下發策略與您的使用者行為不匹配，例如使用者很少停留在站點卻強制使用 mtpush（僅 EngageLab 通道）。
• 瀏覽器廠商通道不穩定，FAQ 建議此時可切換為 EngageLab 通道優先下發。

1.4 送達到展示是否有折損（展示率低）

送達數正常、展示數明顯偏低時，才是真正的「展示率」問題。

看哪裡：

• 推播記錄詳情中按平台展示的「送達數 / 展示數」及比率。
• 回呼 API 的 Impression 與 impression_failed 事件。

常見原因：

1.5 排查檢查表

排查時建議按下表順序逐項確認，先排除口徑與上游問題，再看展示本身：

二、排查到原因後如何對症優化

2.1 擴大訂閱池

• 改用引導申請（軟提示）。 在 基礎設定 的通知授權中選擇「引導申請」：先用自訂樣式向使用者說明通知價值，使用者表示意願後再觸發原生授權框，避免使用者在不了解價值的情況下直接點擊 Block 導致永久無法再申請。軟提示支援設定初次提示間隔（預設 3 天）與後續提示間隔（預設 7 天），直到使用者訂閱。
• 確保前置條件完整。 站點使用 HTTPS 並在【整合設定】-【網站網域】中設定網域（最多 100 個）；Service Worker 檔案放在網站根目錄以取得最大作用域；如站點已有 PWA Service Worker，將兩者合併或確保作用域不重疊，參考 Web SDK 整合指南 與 FAQ。
• 為 iOS 使用者提供引導。 iOS / iPadOS 16.4 及以上的 Safari 需要使用者先將網站加入主畫面並從主畫面開啟，再由使用者手勢（如點擊訂閱按鈕）觸發授權，建議在頁面上放置橫幅引導。
• 避免多裝置互相擠掉。 若您使用 user_str 標識使用者，注意同一 user_str 在多瀏覽器 / 多裝置訂閱時只有最後一次訂閱的裝置能收到訊息；如需覆蓋使用者的全部裝置，請勿在不同裝置上重複使用同一 user_str。
• 遷移時不要遺失訂閱。 從其他服務商遷移到 EngageLab 時，按 如何避免 Web 推播遷移中的訂閱使用者流失 處理舊 Service Worker，已授權使用者初始化後不會再次彈出授權框。

2.2 減少有效目標到發送的折損

• 在 進階設定 中根據業務需要設定單裝置推播上限與可推播時間段。頻控是保護使用者體驗的手段，但設定過嚴會直接丟棄訊息，請結合推播計畫評估。
• 定期透過 刪除使用者 API 清理確認不再活躍的訂閱，使有效目標數更準確地反映可觸達使用者，避免統計被無效訂閱稀釋。刪除操作不可復原，請謹慎執行。

2.3 提升送達

• 合理設定 time_to_live。 不要使用 0；保持預設 1 天或按內容時效延長，最長 15 天。對時效性不強的內容適當延長離線保存時間，可以讓離線使用者在重新開啟瀏覽器後仍能收到。

• 選擇匹配的下發策略。 在 third_party_channel.w3push.distribution 中：

  • first_ospush（預設）：優先系統通道，無效再走 EngageLab 通道；
  • secondary_push：優先 EngageLab 通道，使用者不在線再走系統通道，建立推播 API 建議使用此方式；
  • mtpush：強制 EngageLab 通道，僅適合使用者長時間停留在站點的場景；
  • ospush：強制僅系統通道。

  當瀏覽器廠商通道不穩定時，可暫時切換為 EngageLab 通道優先。

• 謹慎使用 override_msg_id。 覆蓋上一條未清除的通知會讓使用者只看到最新一條，適用於內容更新的場景，不適用於希望多條通知都展示的場景。

• 大促或大批量推播使用定速推播。 透過 big_push_duration 將推播在指定分鐘數內均勻下發（最大 1440 分鐘），避免瞬時峰值。

2.4 提升展示

• 優先使用通知訊息。 需要在通知欄展示並統計展示數的內容，請使用 notification 而非 message；若業務確實需要自訂訊息，在網頁展示後呼叫 customDisplayReport('msg_id') 上報展示，點擊時呼叫 customClickReport('msg_id')。
• 避免短時間內向同一使用者連續推播多條通知。 在 Chrome、Edge、Firefox 上後一條會取代前一條，使用者最終只看到最後一條，展示數也只計入一條。將多條內容合併為一條，或拉開發送間隔。
• 注意素材與文案的瀏覽器相容性。 icon 建議 192×192、不超過 1M，僅 Chrome、Firefox 支援自訂，Safari 與 Edge 使用系統預設圖示；image 建議 360×180、不超過 1M，僅 Chrome、Edge 支援，Firefox 與 Safari 不支援。系統通道對標題長度有限制（中文少於 20 字、英文少於 40 字元），超長可能影響展示效果。
• 為應用內訊息設定合理的展示有效期。 超過展示有效期後使用者再進入頁面不會展示，並觸發 impression_failed。時效性不強的內容適當延長有效期，並控制圖片體積以避免圖片下載失敗。
• 在使用者活躍時段推播。 使用 定時任務 的智慧投遞或結合推播統計中的活躍時間匹配資料，在使用者更可能開啟瀏覽器的時段下發，減少離線過期。
• 正確解讀 Safari 資料。 Safari 系統通道無法取得展示與點擊回呼，該通道展示數偏低屬於統計能力限制，不代表通知未展示；評估展示率時建議將 Safari 與其他通道分開看。

三、綜合方案：系統性提高展示數量

單點優化只能解決某一層的問題，要持續提高展示數量，建議把「訂閱增長、送達保障、展示監控」作為一套日常機制來營運。

3.1 建立分通道的監控視圖

• 每日關注 概況 中的推播轉化漏斗與送達率、展示率、點擊率趨勢，以及通知權限開啟 / 關閉使用者數。
• 在 推播統計 中按瀏覽器拆分查看送達與展示，重點關注 Chrome 與 EngageLab 通道；Safari 單獨評估。
• 透過 回呼 API 接收 delivered、Impression、impression_failed、click 等事件並落庫，可以按使用者、按訊息做比主控台更細粒度的分析（單條訊息統計在 EngageLab 側最多保留一個月）。
• 為送達率與展示率分別設定基線：送達率異常下降優先排查 time_to_live、下發策略與廠商通道；展示率異常下降優先排查訊息類型、多條覆蓋與使用者端權限。

3.2 分階段行動清單

接入期（上線前後）

• 使用 HTTPS，設定網域，Service Worker 放根目錄並確認無作用域衝突；
• 通知授權選擇「引導申請」，設定軟提示文案與間隔；
• 為 iOS 使用者準備加入主畫面的引導；
• 以通知訊息（notification）而非自訂訊息（message）作為主要觸達方式；
• 聯調時用推播記錄與資料查詢確認目標裝置的線上狀態、送達與展示都能正常計數。

增長期（日常營運）

• 每週對比訂閱使用者與活躍使用者增長，訂閱轉化不佳時調整軟提示文案與觸發時機；
• time_to_live 保持 1 天以上，distribution 使用 secondary_push 或預設策略；
• 控制向同一使用者的推播頻率，避免覆蓋導致的展示損失，同時設定頻控保護體驗；
• 借助智慧投遞或活躍時間匹配資料選擇發送時段；
• 定期清理長期不活躍訂閱。

大促期（高峰推播）

• 使用定速推播平滑峰值；
• 對時效性強的內容適當縮短 time_to_live，對可延後觸達的內容延長離線保存；
• 多條行銷通知合併為一條，或按使用者分批錯峰發送；
• 推播後按通道復盤送達率與展示率，將異常通道的經驗回填到下次推播設定。

3.3 一句話總結

展示數量 = 訂閱使用者 × 有效目標比例 × 送達率 × 展示率。先用漏斗資料判斷折損發生在哪一層，再針對該層優化；對「展示」這一層本身，核心是使用通知訊息並確保 SDK 上報、避免多條覆蓋、分通道解讀資料。

參考文件

• Web SDK 整合指南
• Web SDK API
• 基礎設定
• 進階設定
• 建立推播 API
• 回呼 API
• 統計 API
• 推播統計
• 推播記錄
• FAQ
• 如何避免 Web 推播遷移中的訂閱使用者流失