張志豪
更新：2026-06-27
推播通常是指 App、網站或系統在使用者沒有主動開啟 App 或網站時，顯示在手機、電腦或瀏覽器通知區的即時提醒。常見例子包括訂單狀態更新、物流提醒、活動通知、內容更新、帳戶安全提醒和會員優惠。
Push notification 常見中文說法包含推播通知、推播訊息和推播提醒，也有人稱為「推送通知」。對企業來說，重點不是名稱差異，而是如何在使用者授權後，透過 App 或網站通知傳遞真正有用的訊息。
什麼是推播通知？
推播通知
推播通知是由 App、網站或企業系統主動送到使用者裝置上的簡短提醒，即使使用者當下沒有開啟 App 或停留在網站頁面，也能在通知區看到訊息。
推播通知可以用在 App，也可以用在網站。App 推播通常出現在手機鎖定畫面或通知中心；網頁推播則透過瀏覽器通知顯示在電腦或手機上。只要使用者已安裝 App、允許 App 通知，或同意網站透過瀏覽器發送通知，企業就可以在符合條件時發送推播。
也因此，推播通知不是「只要發送就一定會被看到」的管道。使用者需要先允許通知，裝置、App 或瀏覽器也要能正常接收；如果使用者關閉通知、封鎖網站通知或解除安裝 App，企業就需要搭配其他聯繫管道，例如簡訊、電子郵件、站內訊息或通訊平台訊息。
常見的推播通知包括購物平台的訂單與物流提醒、銀行 App 的帳戶異動通知、媒體網站的新聞快訊、SaaS 產品的新功能提醒，以及電商活動或會員優惠通知。
對企業來說，可以先把推播通知分成兩類：一類是使用者需要及時知道的通知，例如付款、物流、帳戶安全或預約提醒；另一類是希望使用者回來互動的通知，例如內容更新、活動提醒、會員優惠，或喚回長時間未互動的使用者。前者重視準確與及時，後者更需要控制頻率、分眾和內容相關性。
推播通知是如何運作的？
推播通知的核心是「主動傳送」。使用者先允許接收通知，企業再透過 App、網站或推播通知服務設定發送對象、內容和觸發條件。當條件成立時，系統就會把通知送到使用者的裝置或瀏覽器。
以 App 推播來說，通知通常會透過行動作業系統和推播管道送達裝置；以網頁推播來說，通知會透過網站、瀏覽器授權和 Web Push 相關機制送達。web.dev 的 推播通知總覽，以及 MDN 的 Web Notifications API 說明，都可以作為理解基礎概念的延伸參考。實務上，重點不是記住每個技術名詞，而是理解：推播需要使用者授權、系統或瀏覽器支援，以及企業端設定正確的發送對象與觸發條件。
對非技術團隊來說，可以先把流程理解為：企業設定通知規則，推播服務依照使用者授權、標籤、行為、地區、裝置或事件，把正確訊息送到正確的人。例如下單成功後發送交易提醒、物流狀態變更時發送更新、活動開始前發送提醒，或使用者長時間未回訪時發送喚回通知。
推播通知有哪幾種類型？
從企業常見使用情境來看，推播通知主要可以分為App（應用程式）推播通知和網頁推播通知。兩者都能主動觸達使用者，但差異不只是發送位置不同，還包含使用者是否已安裝 App、是否已授權通知、企業是否需要較深的會員經營，以及網站訪客是否也需要被召回。
除了 App 推播與網頁推播，有些重要通知也可能需要搭配簡訊、電子郵件或通訊平台訊息作為補充。下圖不是把這些管道列為推播類型，而是協助判斷不同訊息管道如何搭配使用。
-
1
App 推播通知
App 推播通知是發送給已安裝 App 並允許通知的使用者。它適合用於會員經營、交易提醒、App 活躍召回、個人化推薦和帳戶安全通知；如果企業已經有穩定的 App 使用者基礎，也更容易依照用戶行為與會員狀態做分眾。 -
2
網頁推播通知
網頁推播通知是由網站透過瀏覽器送出的通知。使用者不一定需要安裝 App，也不一定要留下手機號碼或電子郵件，但通常需要先造訪網站並同意接收通知。它適合用於內容更新、活動提醒、網站訪客召回和電商促銷；需要注意的是，實際效果會受到瀏覽器、裝置和通知授權狀態影響。
| 比較項目 | App 推播 | 網頁推播 |
|---|---|---|
| 接收前提 | 使用者已安裝 App，並允許 App 通知。 | 使用者造訪網站，並允許瀏覽器通知。 |
| 適合對象 | 已經註冊、登入或持續使用 App 的會員與活躍用戶。 | 尚未下載 App、但已造訪網站並願意接收通知的訪客。 |
| 適合情境 | 交易提醒、帳戶安全、會員經營、App 活躍召回、個人化推薦。 | 內容更新、活動提醒、網站訪客召回、電商促銷、文章或新聞快訊。 |
| 導入與維護 | 通常需要 App、SDK 或推播管道設定，後續也要管理不同系統與版本。 | 通常從網站和瀏覽器授權開始，導入門檻相對較低，但仍需要管理訂閱、發送與成效追蹤。 |
| 互動與資料 | 較適合結合 App 內行為、會員狀態與深層連結，引導使用者回到特定功能或頁面。 | 較適合把網站訪客帶回指定頁面，例如活動頁、文章頁、商品頁或購物車。 |
| 主要限制 | 需要使用者先安裝 App 並保持通知授權；若解除安裝或關閉通知，就無法繼續觸達。 | 會受到瀏覽器、裝置、通知授權狀態和使用者清除瀏覽資料影響，部分系統或瀏覽器也可能有額外限制。 |
簡單判斷：如果您的核心使用者已經在 App 內完成註冊、登入或交易，App 推播通常更適合承接會員經營與重要提醒；如果您的主要流量來自網站，或還沒有足夠理由要求使用者下載 App，網頁推播會是較輕量的召回方式。若 App 和網站都在經營，重點不是兩邊都發，而是依照使用者所在管道、授權狀態和活躍階段分層，避免同一位使用者重複收到相同訊息。
推播通知適合發送哪些內容？
推播通知適合承載時效性強、與使用者狀態相關、能引導下一步行動的訊息。企業在決定是否發送前，可以先確認三件事：使用者現在是否需要知道、這則通知是否和他的訂單、帳戶、偏好或行為有關、點擊後是否有清楚的下一步。如果只是為了增加曝光，通常不適合用推播打擾使用者。
依照目的來看，常見推播內容可以分為交易與狀態提醒、互動與回訪提醒、促銷活動、內容更新、個人化推薦和意見回饋等類型。
需要注意的是，同一則訊息不一定適合同時發到 App 和網站。交易提醒、帳戶安全、預約提醒等高關聯通知，通常更重視即時送達；促銷、內容更新和活動提醒，則需要根據使用者所在管道、授權狀態和活躍階段來判斷，避免重複打擾。
| 內容類型 | 常見範例 | 主要目的 |
|---|---|---|
| 交易、狀態與安全提醒 | 訂單確認、付款成功、物流更新、預約提醒、登入異常、帳戶安全通知。 | 讓使用者即時知道重要狀態，降低查詢成本與不確定感；這類通知應優先確保準確和及時。 |
| 互動與回訪提醒 | 歡迎訊息、新手任務提醒、未完成註冊、試用流程提醒、長時間未回訪提醒。 | 引導使用者完成下一步操作，幫助新用戶理解產品價值，或喚回一段時間未互動的用戶。 |
| 促銷與活動通知 | 限時優惠、會員活動、新品上架、降價提醒、補貨通知、購物車未結帳提醒。 | 在合適時機提醒使用者回到 App 或網站，但需要控制頻率，避免讓促銷通知變成干擾。 |
| 內容更新 | 文章更新、影音內容上線、課程提醒、新聞快訊、產品公告。 | 把使用者可能感興趣的新內容送到通知區，適合媒體、內容平台、教育產品和 SaaS 產品使用。 |
| 個人化推薦 | 依照瀏覽紀錄、收藏、購買紀錄、地區或偏好推薦商品與內容。 | 提高通知相關性，避免所有人收到同一則訊息；但推薦依據應與使用者行為或偏好有明確關聯。 |
| 意見回饋與調查 | 滿意度調查、服務評價、使用體驗回饋。 | 收集使用者意見，協助產品、服務和行銷活動優化。 |
如果要把這些場景寫成實際推播文案，建議保持短、清楚、相關：標題先說明發生什麼事，正文補充和使用者有什麼關係，點擊後應直接前往對應的訂單、活動、商品、文章或功能頁。交易、安全和物流類通知應優先準確；促銷和回訪類通知則更需要分眾、控制頻率，避免讓使用者因為干擾而關閉通知。
如果您想延伸了解不同通知與訊息類型，可以參考以下內容：
推播通知能為企業帶來什麼幫助？
推播通知的價值在於，它可以在使用者還沒有主動回到 App 或網站時，提醒他注意與自己相關的資訊。對企業來說，推播通知常用於提升回訪、減少流程中斷、推動轉換，以及觀察不同訊息對使用者行為的影響。
- 即時提醒重要狀態：例如付款、物流、預約、帳戶安全等資訊，使用者通常希望越快知道越好。
- 提升 App 或網站回訪：當使用者一段時間沒有回來時，可以透過內容更新、任務提醒或優惠通知引導回訪。
- 推動下一步轉換：例如購物車提醒、活動倒數、會員優惠或試用流程提醒，都可以引導使用者完成下一步。
- 優化分眾與訊息策略：透過送達、開啟、點擊、轉換等數據，企業可以比較不同受眾、內容和發送時間的效果。
不過，推播通知也需要控制頻率與相關性。如果通知過多、內容和使用者無關，反而可能造成關閉通知、解除安裝 App 或降低品牌好感。
如何發送推播通知？
發送推播通知前，先確認要使用 App 推播、網頁推播，或兩者並行。App 推播適合已安裝 App 並允許通知的使用者；網頁推播適合已造訪網站並同意瀏覽器通知的訪客。確認發送管道後，企業需要先完成通知授權與基礎設定，再設定受眾、通知內容、觸發條件和成效追蹤。
對非技術團隊來說，可以把「發送推播」分成兩層：技術層負責讓 App 或網站具備接收通知的能力；營運層負責決定誰會收到、什麼時候收到、點擊後去哪裡，以及如何追蹤效果。本文重點放在營運與選型判斷，不展開 APNs、FCM 或 Web Push API 的接入細節。
-
1
確認要使用 App 推播、網頁推播或兩者並行
如果您已有 App 使用者，App 推播通常更適合會員經營和交易提醒；如果您主要經營網站訪客，網頁推播可以作為回訪提醒和內容更新管道。若 App 和網站並行，需要依照使用者所在管道、授權狀態和活躍階段分層，避免同一位使用者重複收到相同訊息。 -
2
取得使用者通知授權
在使用者理解 App 或網站價值後，再引導開啟通知，通常比一進站或一開 App 就要求授權更自然。授權文案也應說明使用者會收到哪些類型的通知。 -
3
依照使用者狀態分群
可依照新使用者、活躍使用者、長時間未互動的使用者、購買行為、瀏覽偏好、地區、裝置或會員等級分群，避免所有人收到同一則通知。 -
4
撰寫清楚且有下一步的通知內容
推播通知通常篇幅較短，應讓使用者快速知道「發生什麼事」「和我有什麼關係」「點擊後會去哪裡」。如果是促銷或活動通知，也要避免過度誇張或與實際落地頁不一致。 -
5
設定發送時間、排程或自動觸發條件
有些通知適合即時發送，例如付款成功或帳戶安全提醒；有些通知適合排程，例如活動開始前提醒；也有些通知適合依照使用者行為自動觸發，例如未完成註冊、購物車未結帳或長時間未回訪。 -
6
追蹤送達、點擊與轉換成效
發送後需要觀察通知送達、開啟、點擊、轉換、取消授權等指標。如果點擊低、取消授權上升，通常代表內容相關性、發送時機或頻率需要調整，不應只靠增加發送量解決。
什麼情況需要推播通知服務？
如果只是少量通知，企業可能可以先從 App 或網站現有工具開始。但當您需要同時管理 App Push、Web Push、分眾、排程、自動觸發和成效追蹤時，使用推播通知服務會更容易維持穩定性與可管理性。
- 需要同時管理 App 和網站通知：避免不同管道各自操作，造成訊息重複或數據分散。
- 需要根據用戶行為自動觸發：例如註冊未完成、購物車未結帳、活動即將開始、用戶長時間未回訪。
- 需要更細的受眾分群：依照標籤、裝置、地區、活躍狀態或事件資料發送不同內容。
- 需要追蹤完整成效：除了發送數量，也要看送達、點擊、轉換和後續行為。
選擇推播通知服務時，不必只看是否能「發送」。更應確認它是否支援您需要的發送管道、是否能做分眾與自動觸發、是否能設定點擊後的落地頁或深層連結、是否能查看送達與點擊數據，以及是否能和既有會員、訂單或行為資料串接。
EngageLab 提供 AppPush（App 推播） 與 WebPush（網頁推播） 能力，協助企業管理跨平台推播通知、受眾分群、排程發送與成效追蹤。對需要同時經營 App 和網站使用者的團隊來說，可以把推播通知作為用戶觸達與回訪經營的一部分。
推播通知常見問題
推播是什麼意思？
推播通常指 push notification，也就是 App、網站或系統在使用者未主動打開頁面時，主動顯示在手機、電腦或瀏覽器通知區的提醒。它通常需要使用者先允許接收，常見形式包括 App 推播、網頁推播、推播訊息和推播提醒。
推播通知和簡訊有什麼不同？
推播通知通常依賴 App 或瀏覽器授權，適合經營已經和 App / 網站互動的使用者；簡訊則透過手機門號發送，較常用於驗證碼、交易通知，或需要更確實送達的訊息。推播通常不按簡訊則數計費，但仍可能有平台、開發或流量成本。兩者可以搭配使用：如果訊息需要引導使用者回到 App 或網站，推播較適合；如果訊息和帳戶安全、交易確認或驗證流程高度相關，且不確定使用者是否已授權推播，簡訊可以作為補充或備援管道。若想進一步比較兩者差異，可以參考 推播通知與簡訊行銷比較。
沒有 App 也可以發送推播通知嗎？
可以。如果企業主要經營網站，可以使用網頁推播通知，在使用者同意瀏覽器通知後，發送內容更新、活動提醒、購物車提醒或回訪通知。不過，網頁推播仍會受到瀏覽器、裝置、通知授權狀態和使用者清除瀏覽資料影響，因此不適合把它視為一定送達的通知管道。LINE 官方帳號、簡訊和電子郵件也能作為其他訊息管道，但不屬於 App 推播或網頁推播；選擇時應依照使用者所在管道、訊息重要性和授權狀態判斷。
