流量類別有互不相容嘅要求
用一個發送方身分同一條路由嘅論點係簡單:一次註冊、一次整合、一張帳單。反對嘅論點係共用呢條路由嘅各類別,有唔同嘅時限、唔同嘅同意基礎、唔同嘅內容審查同唔同嘅成功定義。
一旦佢哋共用一條路由,一個排程活動嘅排隊行為就會套用喺一個驗證碼度,而由推廣文案觸發嘅內容審查就會套用喺承載嗰個驗證碼嘅發送方身分度。呢 兩個效果喺整體送達百分比入面完全睇唔出。
值得明確分開嘅有五個類別:
- 驗證 —— 用戶正主動等緊嘅驗證碼或連結。只有喺佢哋仍然停留喺流程入面嘅時段先有用。
- 服務 —— 訂單、付款、預約、帳戶狀態。預期之內,同某個業務事件掛勾。
- 推廣 —— 營銷。需要同意基礎,喺好多市場受制於內容規則同時段限制。
- 支援 —— 對話式,通常雙向,需要回覆路徑同真人負責人。
- 緊急營運 —— 中斷、安全、詐騙警示。罕見,後果重大,無人確認就要升級。
佢哋之間必須不同嘅地方
發送方身分同註冊
已註冊嘅發送方身分承載申報用途,喺部分市場仲有已批核嘅範本。美國嘅 10DLC 註冊經 The Campaign Registry 進行,包括申報用途,呢啲細節會影響流量嘅處理方式;具體細則由登記機構同營運商制定,要為特定活動同供應商確認。喺驗證同推廣內容之間共用一個身分,即係一個類別嘅內容決定會落到另一個類別度。
同意同抑制
推廣流量取決於同意紀錄同一個被遵守嘅 opt-out。驗證同服務訊息通常建基於唔同嘅法律依據,抑制規則唔可以靜靜噉封鎖用戶要求嘅驗證碼。呢個要求按類別分開嘅抑制語義:營銷 opt-out 唔係全局封鎖,而全局封鎖仍然一定要被遵守。
隊列優先次序同吞吐分配
畀每個類別自己嘅隊列同明確優先次序,喺路由上都有自己嘅吞吐分配。冇按類別分配,一次大型排程發送就會吃走條路由上其他嘢嘅容量。
路由政策
如果供應商支援,就按類別分開路由身分,最好為驗證同推廣流量分開供應商,令故障域、限速行為同合約互相獨立。值得明確講明嘅一條規則:推廣流量永遠唔會 failover 到驗證路由度。
重試同時限政策
每個類別都需要一個有用時限——過咗呢一點送達就唔再幫到人——同一個停止條件,而唔係無限重試。驗證時限短,由用戶所處嘅流程決定;服務通知嘅時限由業務事件決定;推廣時限由活動窗口同靜默時段決定。
內容同範本治理
驗證同服務內容應該做成範本、經審查、有版本紀錄,連發送方身分、範本 ID 同批核狀態一併記錄。推廣內容經常改變,需要一條唔會影響另一個類別所依賴嘅範本嘅審查路徑。
監測基線
按每個項目自己最近嘅基線,分路由同目的地去告警,而唔係一個通用數字。有用嘅訊號因類別而異:驗證睇最終狀態嘅延遲分佈同驗證結果;推廣睇限速同拒絕原因、投訴或 opt-out 率;支援睇回應時間同未回覆嘅入站訊息;緊急流量睇確認情況。
事故回應
按類別定義邊個會被通知、第一個行動係咩、「已解決」嘅定義係咩。驗證路由劣化同一個緩慢嘅活動,唔應該以同一種方式送到同一個人度。
隔離矩陣
| 維度 | 驗證 | 服務 | 推廣 | 支援 | 緊急營運 |
|---|---|---|---|---|---|
| 發送方身分 | 專用,已註冊 | 專用或同服務共用 | 專用,為營銷用途註冊 | 具雙向能力 | 專用或服務身分 |
| 路由 | 專用,以延遲優先 | 專用,或只喺分配被強制執行時同驗證共用 | 獨立路由,最好獨立供應商 | 支援入站嘅路由 | 專用,有獨立 fallback |
| 隊列優先次序 | 最高 | 高 | 最低,按排程 | 互動式 | 優先插隊 |
| 同意基礎 | 由用戶要求 | 業務事件 | 已紀錄同 意,opt-out 被遵守 | 現有對話 | 合理營運需要 |
| 抑制 | 只有全局封鎖 | 只有全局封鎖 | 營銷 opt-out 加全局 | 對話狀態 | 只有全局封鎖 |
| 時限 | 由即時流程決定 | 由業務事件決定 | 活動窗口、靜默時段 | 按 session | 即時,無人確認就升級 |
| 重試 | 有上限,同一 session 唔重複發碼 | 有上限,按狀態去重 | 有上限,遵守靜默時段 | 人手驅動 | 有上限,之後轉用其他渠道並升級 |
| Failover 目標 | 另一供應商嘅驗證路由 | 服務路由 | 永遠唔到驗證路由 | 支援入站嘅路由 | 獨立路徑 |
| 告警 | 延遲分佈同驗證結果 | 按路由嘅最終狀態組合 | 限速、拒絕、opt-out | 未回覆嘅入站訊息 | 確認情況 |
遷移清單
由共用設定轉去分開類別,按一個唔會造成中斷嘅次序:
- 為現有流量分類。喺應用邊界為每次發送標上類別再改動其他嘢,再對照真實流量確認標籤。
- 記錄每個項目同路由現時嘅基線,方便事後評估變更效果。
- 按市場註冊新嘅發送方身分並等待確認,將前置時間當成第三方依賴處理。
- 為每個類別配置獨立路由身分同吞吐分配。
- 落實按類別嘅隊列、優先次序、時限同停止條件。
- 落實按類別嘅抑制語義,並驗證營銷 opt-out 唔會封鎖被要求嘅驗證碼。
- 先搬風險最低嘅類別,通常係推廣,並對照已記錄嘅基線觀察。
- 搬服務流量,最後先搬驗證,保留舊路由做熱備 fallback。
- 按類別分開告警,有指定負責人同明確行動。
- 搬完之後重新建立基線,並移除混合類別嘅 fallback 路徑,以免被靜靜噉用返。
Flowstates 銷售同營運訊息路由,支援客戶保留自己嘅供應商合約,亦支援混合安排。以上嘅隔離喺每種情況下都係同一份工作:改變嘅只係邊個持有供應合約,唔係邊個要負責執行呢個隔離。