App 推播通知設計指南：權限請求時機、頻率分眾與交易行銷分流

App 上線後，App 推播通知幾乎是每個業主都想用的工具：新品上架發一則、週年慶發一則、會員到期再發一則。發得越多，看起來越積極，但很快會發現打開率越來越低，甚至有人直接把通知關掉、把 App 刪了。

推播的問題通常不在「要不要發」，而在什麼時候請求權限、發給誰、多久發一次、點下去會到哪裡。這些事情沒有在開發階段一起設計，後續就只能靠行銷人員憑感覺發送，而 App 端也缺少分眾、深連結與成效追蹤的基礎。

這篇從通知權限的請求時機開始，說明頻率與分眾、交易通知與行銷通知的分流、深連結設計，以及上線後該觀察哪些成效，最後整理與 LINE 官方帳號的分工方式。

推播能做什麼、不適合做什麼

推播的本質是在使用者沒有打開 App 時，把他帶回來做一件具體的事。所以好的推播都有一個明確的下一步：查看出貨進度、確認預約、使用即將到期的點數、回覆一則訊息。

適合推播的內容：

• 與使用者本人的交易或帳號有關的即時狀態，例如付款成功、出貨、取件、預約提醒。
• 使用者主動訂閱的資訊，例如到貨通知、追蹤商品降價、關注主題的新內容。
• 有時效性的個人化權益，例如點數或優惠券即將到期。

不適合推播的內容：

• 沒有下一步的公告，例如「感謝您的支持」。
• 對所有人都一樣、與使用者行為無關的大量廣告。
• 需要長篇說明才看得懂的內容，推播只有一兩行的空間。

判斷原則很簡單：如果這則訊息使用者錯過了也不會有損失，那它可能不該是推播，可以放在 App 內的訊息中心或其他管道。

通知權限：請求時機決定開啟意願

iOS 需要使用者明確同意才能發送通知，較新版本的 Android 也改為需要使用者授權。系統的權限視窗通常只有一次機會，被拒絕後要使用者自己到設定裡開。因此什麼時候跳出請求，是推播設計的第一步。

不要在第一次開啟 App 就請求。使用者還不知道這個 App 能帶給他什麼，此時跳出「是否允許通知」，拒絕是很自然的反應。

在使用者能理解好處的時刻請求。例如：

• 下單完成後：「開啟通知，出貨時第一時間告訴你。」
• 設定預約後：「開啟通知，預約前一天提醒你。」
• 按下「到貨通知我」時：這個動作本身就說明了通知的用途。

先用自家說明畫面，再觸發系統視窗。許多 App 會先顯示一個自己設計的畫面，說明會收到哪些通知、頻率大概如何，使用者按「好」才跳系統視窗；按「之後再說」就先不跳，保留下次機會。

讓使用者選擇通知類型。在 App 設定頁提供分類開關，例如「訂單與帳號通知」「優惠與活動」「內容更新」。使用者可以只關掉行銷類，而不是因為不想看廣告就連出貨通知一起關掉。

交易通知與行銷通知必須分開

這是最常被忽略、影響卻最大的設計。

交易通知（也有人稱服務通知）是使用者為了完成某件事必須知道的資訊：付款結果、訂單狀態、帳號安全提醒、預約變更。這類通知使用者通常期待收到，即使頻率高也不太會反感。

行銷通知是推廣性質的內容：活動、新品、優惠。這類通知要節制，也應該讓使用者能單獨關閉。

兩者分開的理由：

1. 使用者可以分別控制，不會因為討厭廣告而錯過重要的交易訊息。
2. 發送權限可以分開管理。交易通知由系統依事件自動觸發，行銷通知由行銷人員排程發送，兩邊互不干擾，也降低誤發的風險。
3. 成效指標不同。交易通知看的是送達是否準時、是否正確；行銷通知看的是點擊與後續行為，混在一起分析會失真。

在系統設計上，這代表推播服務要能為每則通知標記類別，後台的發送介面也要區分。這部分通常與會員系統綁在一起，可參考會員與 CRM 系統開發指南。

頻率與分眾：同一則訊息不該發給所有人

把一則活動訊息發給全部會員，是最省事、也最容易造成反感的做法。分眾的目的是讓每個人收到的訊息都和自己有關。

常見的分眾依據

• 行為：最近有瀏覽某類商品、加入購物車未結帳、很久沒有打開 App。
• 狀態：新會員、會員等級、點數即將到期、訂閱即將續約。
• 偏好：使用者主動選擇的關注類別、常去的門市或地區。
• 時間：使用者過去習慣打開 App 的時段。

頻率控制的做法

• 為行銷通知設定每人每週的發送上限，由系統自動擋下超過的部分。
• 同一位使用者短時間內不要收到多則推播，必要時合併成一則。
• 夜間與清晨避免發送行銷通知，交易通知則依事件即時發送。
• 已經完成動作的人不要再提醒，例如已結帳的使用者不該再收到購物車提醒。

頻率上限要多少才合理，沒有放諸四海的標準，取決於產品性質與使用者期待。比較實際的做法是從保守的上限開始，觀察關閉通知與解除安裝的變化再調整。

深連結：點下去要到對的地方

推播最浪費的情況，是使用者點了「你關注的商品降價了」，結果被帶到 App 首頁，還要自己再找一次。深連結（Deep Link）讓推播點開後直接進入特定畫面，例如商品頁、訂單詳情、優惠券頁。

設計深連結時要注意：

• 每種推播都要對應明確的目標畫面。規劃推播類型時就把目標頁一起列出來。
• 處理未登入狀態：使用者點開時若已登出，先登入再導回原本的目標頁，而不是登入後停在首頁。
• 處理內容已失效：活動已結束、商品已下架時，要顯示說明並提供替代選項，不能出現空白或錯誤畫面。
• App 未安裝或版本過舊：若同一個連結也會用在簡訊、Email 或社群貼文，要決定未安裝時導向網頁還是商店頁。
• 帶上追蹤參數：讓分析工具知道使用者是從哪一則推播進來的。

深連結需要 App 端與後端一起設計，最好在需求階段就列入，可以參考軟體需求怎麼寫整理目標畫面清單。

推播設計規劃表：開發前就填好

以下是一份可以直接拿來用的規劃表骨架，建議每一種推播都填一列，交給開發團隊與行銷團隊一起確認：

欄位	填寫內容
通知名稱	例：出貨通知、購物車提醒、點數到期
類別	交易／行銷／內容
觸發方式	系統事件自動觸發，或人工排程
對象條件	誰會收到、誰要排除
頻率限制	是否計入行銷上限、同一人多久內不重複
文案骨架	標題與內文，標出會帶入的個人化欄位
點擊目標	深連結到哪個畫面，內容失效時怎麼處理
成效指標	要觀察的主要數據

填完這張表，開發團隊就知道要做哪些觸發事件、哪些分眾欄位、哪些深連結；行銷團隊也有了發送規則，不必每次臨時討論。

成效觀察：看的不只是打開率

推播上線後，常見的錯誤是只看單則推播的點擊，卻忽略它對整體使用者關係的影響。建議觀察以下幾個面向：

• 送達與點擊：每則推播實際送達多少裝置、有多少人點開。
• 點擊後的行為：點進去的人有沒有完成目標動作，例如結帳、使用優惠券、完成預約。
• 權限開啟狀況：整體使用者中開啟通知的比例是否穩定，在哪個請求時機開啟的人最多。
• 負面訊號：發送後關閉通知、解除安裝的情況有沒有上升，這是頻率過高的警訊。
• 各類別比較：交易通知與行銷通知分開看，不要混在一起算平均。

要追蹤點擊後的行為，App 與網站的分析設定要事先埋好事件，追蹤方式可參考GA4 設定指南的事件規劃概念。分析結果要回饋到分眾條件與頻率上限的調整，形成持續改善的循環。

與 LINE 官方帳號怎麼分工

很多業者同時經營 App 與 LINE 官方帳號，最怕的是同一則活動在兩邊各發一次，讓同一位顧客收到兩次。建議依情境分工：

• App 推播：與帳號、交易綁定的通知；需要點進 App 內特定畫面操作的訊息；已下載 App 的活躍使用者。
• LINE 官方帳號：還沒下載 App 或很少打開 App 的顧客；需要用圖文或對話互動的內容；廣泛觸及的活動訊息。

如果會員資料能把 App 帳號與 LINE 好友對應起來，就可以設定「已經用 App 收到的人，LINE 不再重複發」。LINE 端的經營方式可以參考LINE 官方帳號行銷指南。

推播做得好不好，關鍵在開發階段有沒有把分類、分眾、深連結與追蹤的基礎打好；等到上線後才補，往往要改動 App 與後台兩邊。如果你正在規劃新 App，或現有 App 的推播只能「全部人發一樣的」，可以和 NETVANA 聊聊你的推播需求，我們會從通知類型盤點、權限流程到後台發送介面一起規劃。軟體服務一律採詢問報價制，服務內容請見軟體服務介紹。

延伸閱讀：推播要搭配 LINE 經營，先看LINE 官方帳號行銷指南；分眾需要會員資料基礎，讀會員與 CRM 系統開發指南；準備送審時權限說明怎麼寫，看App 上架檢查清單；推播成效要接上分析工具，參考GA4 設定指南；上線後的功能怎麼排優先序，看上線後的產品路線圖；想知道推播到底有沒有帶來行動，可以看App 數據埋點與事件追蹤指南；推播權限最好在新手引導中適時請求，可以看App 新手引導設計。