當客戶開始忽略你嘅訊息或者大批退訂,問題好少喺內容,多數係喺數量。呢份指南講清楚頻率封頂點運作、執行喺邊度發生,同埋喺多過一個系統一齊發送嘅時候,點樣喺 SMS、Push、Email、WhatsApp 等渠道配置。
先講清楚一點：頻率封頂係一個由你自己決定、自己擁有嘅內部客戶體驗同管治控制,唔係法律控制。法律要求同營運商或平台規則——consent、退訂處理、發送時段、內容限制、分類規則——係另一條線,要按計劃、按司法轄區 、按渠道逐一核實。封頂做唔到呢啲要求,滿足咗呢啲要求都唔代表唔需要封頂。
咩係頻率封頂
頻率封頂係一種基於規則嘅控制,限制單一客戶喺指定時段內可以收到嘅訊息數量,適用於 SMS、Push、Email、In-app、WhatsApp、RCS 同 Voice。可以當佢係收件人層級嘅「音量掣」。
封頂設一個上限——例如每星期唔多過三個 push,或者一日內所有渠道加埋唔多過五條訊息。一旦到頂,原本合資格嘅額外訊息就會被抑制,直到窗口重置。
一個常見誤解係將 capping 同 rate limiting 混為一談,兩者唔同：rate limiting 控制系統層面嘅發送速度,capping 控制到達單一個人嘅訊息數量,一個關乎吞吐,一個關乎收件人體驗。
配置方式可以係：全局封頂——同時喺所有渠道生效,唔理邊個 campaign 觸發;渠道封頂——只喺單一渠道生效,例如 SMS 每星期兩條,同 email 量無關;混合封頂——兩者並行,客戶去到 SMS 上限之後仍然收到 email,但兩個渠道各自都唔超標。
一個實用起步方案係用全局封頂做安全網,再喺上面疊加渠道級封頂,咁樣既有總量上限,又可以逐渠道調校。
平台點樣執行封頂
執行機制同配置本身一樣重要。大部分平台喺準備發送或者判斷資格階段,即訊息交俾下游供應商之前,就會做封頂檢查。典型流程：
- 活動根據分群同觸發邏輯篩選客戶。
- 平台用客戶嘅訊息歷史對比已設定嘅閾值。
- 超出閾值,訊息被抑制,跳過該客戶。
- 抑制會被記錄,但好多平台喺預設儀表板唔會突出顯示。
- 時間窗口重置之後,客戶再次符合條件。
跨渠道執行通常係出問題嘅地方。Email 平台嘅封頂睇唔到 SMS 供應商發咗咩,冇統一嘅訊息歷史同共享執行層,分渠道嘅封頂無法防止組合過度打擾：同一日兩封 email、三條 SMS,每個渠道都喺限內,但加埋遠超你會批准嘅水平。
要令跨渠道封頂真正生效,需要兩樣嘢：一個所有發送系統都認得嘅共享客戶識別碼,同一份所有系統喺發送前都會查嘅訊息歷史。缺咗任何一樣,渠道級封頂會守到,但總量守唔到。常見做法係加一層,喺路由去任何渠道或供應商之前,先保存呢份歷史同套用封頂邏輯。
策略比較
| 封頂類型 | 適合 | 取捨 |
|---|---|---|
| 全局固定封頂 | 高量級多渠道計劃 | 工具偏粗,可能抑制高價值訊息 |
| 渠道固定封頂 | 渠道角色清晰嘅計劃 | 要逐渠道調校;可能有跨渠道漏洞 |
| 動態互動式封頂 | 有行為數據嘅成熟計劃 | 需要更多基礎設施同持續校準 |
固定封頂容易實施同稽核,例如「每個客戶每星期所有渠道加埋唔多過五條」講得清、驗得到。缺點係一個成日打開每條訊息嘅高互動客戶,同幾個月冇互動嘅客戶,會頂住同一個上限。
基於互動信號嘅動態封頂正正解決呢個問題：持續開啟同點擊嘅客戶可以收多啲而唔覺被轟炸,顯示疏離嘅客戶會喺退訂之前先被收緊。代價係校準工作永遠做唔完。
無論用邊種,都要按類別（事務性、促銷性、觸發式行為訊息）標記訊息,只喺可以接受被抑制嘅類別套用封頂。一條可以靜靜掉咗 OTP 或者付款確認嘅音量規則,係漏洞,唔係政策。
設定頻率封頂嘅實踐建議
目標係保護客戶體驗,但唔會不必要咁抑制本來受歡迎嘅訊息。
由數據開始：拉出退訂率、垃圾投訴率同各渠道嘅互動下滑曲線,呢啲會話俾你聽而家嘅發送量已經喺邊度造成摩擦。
頻率封頂同 suppression、退訂互補,但運作方式唔同——封頂係暫時嘅,限制一個時間窗口然後重置;suppression 或退訂係永久或者長期排除。主動用好封頂,可以令較少客戶去到完全退訂嗰步。將封頂當第一道防線,suppression 留做最後手段。
幾個跨渠道、跨規模都適用嘅做法：按客戶生命周期階段分段封頂,新訂閱者通常對量更敏感,onboarding 期可以收緊啲;至少每季檢視一次封頂,受眾行為、campaign 組合會變,半年前啱嘅設定可能而家太緊或太鬆;用對照組先測試調整,再大規模推行;跨部門協調——市場、CRM、產品往往各自向同一批客戶發 campaign,冇共享封頂管治,每個團隊自己覺得「合理」嘅量加埋就會變得不合理。
用多供應商 SMS 路由嘅團隊,封頂執行要覆蓋所有供應商路由發出嘅訊息,唔止其中一個供應商——呢係多供應商架構常見缺口,需要刻意設計去補。
Flowstates 點樣支援封頂執行
喺 SMS、RCS、WhatsApp、電郵同語音之間一致咁執行封頂,基建問題同配置問題一樣重要。Flowstates 營運介乎你 campaign 平台同承載流量嘅路由之間嘅訊息層,提供一個地方追蹤跨渠道訊息歷史,喺訊息去到網絡之前套用封頂邏輯。
呢一點唔理路由嚟自邊度都成立：我哋供應嘅渠道同路由、你自己嘅供應商合約由我哋操作（BYOV）,或者兩者混合。喺閘道設定嘅封頂,無論最終邊條路由承載訊息都會生效。分開喺唔同系統跑促銷計劃、OTP 流程同 CRM campaign 嘅團隊,可以唔使重建呢啲系統就套用同一套聯絡頻率政策。
兩件經常搞錯嘅事
報表。 封頂抑制一條訊息時,客戶記錄有被處理但冇實際發出。好多平台預設報表唔會顯示呢啲抑制,令 campaign 發送數同送達數對唔上,冇人解釋到落差。將 suppression 當成一等公民結果去記錄,並附上原因,否則下次事故覆盤你就會不斷靠估。
範圍。 封頂唔可以取代 consent 管理、退訂處理或者發送時段規則。呢啲義務視乎你嘅司法轄區、渠道同你發送所依循嘅營運商或平台條款,要按每個計劃逐一核實,唔可以由一個封頂設定推斷出嚟。