冇一個放諸四海皆準嘅渠道次序
大部分 fallback 設計由一條梯級開始——先試呢個渠道,再試嗰個——然後先發現呢條梯級對一半嘅使用情境都係錯嘅。次序係一個輸出,唔係一個輸入。
真正嘅輸入係業務目標同有用時限。其他一切都由呢兩樣推導出嚟。
政策實際上評估緊咩
對每個收件人、每個訊息,喺每次嘗試之前:
- 目標。 需要發生咩事:驗證碼被輸入、一個動作被完成、一個事實被記錄、一個回覆被收到。呢個決定咩算成功,亦即決定幾時要停。
- 有用時限。 過咗呢一點送達就唔再幫到人。用戶正等緊嘅驗證碼,同一份明日先要送嘅送貨通知,時限完全唔同,一條超過時限嘅鏈只係浪費開支。
- 同意同偏好。 收件人對呢個渠道同呢個內容有冇同意基礎,佢哋有冇表達過偏好。已表達嘅偏好凌駕於成本之上。
- 已驗證嘅目的地。 呢個地址或號碼喺呢個渠道係咪已驗證同最新,而唔係由另一份紀錄假設出嚟。
- 渠道可用性同市場支援。 呢個渠道喺該市場、對該收件人係咪可用,你嘅發送方喺當地係咪已註冊或已核准使用。可用性因市場、裝置同營運商而異,而且會變。
- 緊急程度同敏感度。 部分內容唔應該送去一個通知內容會顯示喺鎖屏、或者對話紀錄可能被分享嘅渠道。
- 成本。 相關,但受目標約束。真正重要嘅係每個完成結果嘅成本,而唔係每個訊息嘅成本。
- 訊號可靠度。 呢個渠道 會唔會返回一個你可以據以行動嘅訊號,呢個訊號有幾含糊。
可信同唔可信嘅訊號
一個 fallback 決定,只同佢所回應嘅訊號一樣好。
| 訊號 | 支持嘅結論 | 唔支持嘅結論 |
|---|---|---|
| 提交時被拒絕 | 快速失敗,試下一個合資格渠道 | 對收件人任何推斷 |
| 該渠道嘅最終失敗狀態 | 有合理信心訊息未送達 | 稍後重試會唔會成功 |
| 送達確認 | 渠道報告已到達裝置 | 有冇人睇過 |
| 讀取指示(如有提供) | 訊息喺該裝置被打開過 | 注意力、理解或意圖,而且收件人可能已關閉呢個功能 |
| 喺時限內冇任何狀態 | 含糊,唔係失敗 | 唔可以假設任何一個方向係安全 |
| 收件人動作(已驗證、已撳、已回覆、已付款) | 成功;停止呢條鏈 | —— |
有兩個後果。冇訊號唔等於失敗,所以一條將沉默當成失敗嘅鏈會重複發送訊息。而讀取指示唔等於注意力,所以一條要求讀取指示先肯停嘅鏈,會向已經行動咗嘅人過度發送。
一個流程,一個身分
呢條鏈需要一個單一嘅流程或關聯識別碼,喺應用程式決定溝通嗰刻建立,貫穿每次渠道嘗試、每次 callback 同結果紀錄。冇呢個,跨渠道去重、歸因同每個結果嘅成本全部都係估估吓。
依賴呢個識別碼嘅規則:
- 合資格性喺每次嘗試之前重新評估,而唔係喺一開始評估一次就算。同意、驗證同渠道可用性喺嘗試之間可能改變,底層業務狀態亦一樣。
- 幂等性同去重在流程層面套用,唔係按渠道。 每次嘗試由應用程式生成一個 key,喺提交之前存低,再加一條規則:另一次嘗試仍處於非最終狀態時,新嘗試唔可以開始,除非佢嘅時限已過。
- 嘗試狀態同最終狀態係分開嘅。 每次嘗試有自己嘅生命週期;流程只有一個結果。
- 停止條件優先。 如果目標已達成,或者來源業務狀態改變咗(訂單被取消、發票已付、session 已結束、驗證碼已被驗證),即使仍有嘗試未完成,呢條鏈都要停。
- 遲到同亂序嘅 callback 屬於預期之內。 一個送達確認可以喺 fallback 已經發出之後先到。要記錄低,唔好畀佢重開一個已完成嘅流程,但要計入歸因分析。
順序定並行
順序係預設做法:佢尊重收件人,亦令歸因保持乾淨。並行嘅合理情況係:漏咗一個訊息嘅後果明顯超過重複發送嘅代價——安全、詐騙或者中斷通知——或者時限太短,順序鏈根本完成唔到。要按每個流程分別決定,寫低嚟,並喺報表入面清晰顯示,因為並行發送會誇大觸及數字,亦會扭曲渠道比較。
對於用戶等緊嘅驗證碼,約束係時限本身,而唔係一條講邊啲渠道准用嘅規則:只要一個渠道嘅訊號 同延遲喺呢個窗口內可靠,就可以係候選,而要避免嘅失敗係為同一個 session 重複發碼。
決策表
| 流程 | 目標同時限 | 排序邏輯 | 停止條件 |
|---|---|---|---|
| 驗證碼 | 喺仍生效嘅 session 入面輸入驗證碼 | 該市場最快、訊號最可靠、目的地已驗證嘅渠道;只有喺時限順序做唔到先並行 | 驗證成功、session 結束、時限已過。永遠唔為同一 session 發第二個碼 |
| 送貨或預約通知 | 收件人喺事件之前得知 | 先用偏好渠道,再用下一個合資格、訊號可靠嘅,並按事件時間錯開 | 收件人確認、事件已發生或已取消 |
| 付款要求 | 喺到期日前完成付款 | 有同意基礎同身分信心嘅渠道;升級到支援回覆同真人聯絡嘅渠道 | 已收款、達成方案、帳戶狀態改變 |
| 支援跟進 | 收到回覆 | 對話開始嘅渠道,再試收件人用過嘅渠道 | 收到回覆、工單關閉 |
| 推廣 | 已同意嘅互動 | 最平嘅已同意渠道;唔跨渠道重複同一個優惠 | Opt-out、頻率上限、活動窗口結束 |
| 緊急營運 | 收到確認 | 於合資格渠道並行,再升級到人手 | 已確認,或升級路徑已完成 |
狀態機
journey(id) states: PLANNED -> ATTEMPTING -> COMPLETED | STOPPED | EXHAUSTED
on plan:
resolve objective, deadline, stop conditions
build ordered candidate list (eligibility evaluated per candidate)
on attempt(candidate):
if now > deadline -> EXHAUSTED
if stop condition met -> STOPPED
re-evaluate eligibility(candidate) -> if ineligible, next candidate
create attempt(attempt_key stored before submission)
submit; attempt state: SUBMITTED
attempt outcomes:
rejected / final failure -> next candidate immediately
delivered, objective not yet met -> wait until this attempt's own
deadline, then next candidate
no status by attempt deadline -> AMBIGUOUS; advancing is a decision
to accept possible duplication
recipient action -> journey COMPLETED, cancel pending
on late callback:
record against attempt; update attribution; never re-open a terminal journey
on source state change:
re-evaluate stop conditions immediately, regardless of pending attempts
AMBIGUOUS 呢一段,係大部分設計靜靜噉出錯嘅地方。喺冇狀態嘅情況下要唔要繼續行落去,係一個按流程決定嘅政策問題,對於任何重複發送會造成傷害嘅情況——第二個驗證碼、第二次付款要求——答案通常係等或者停,而唔係再發一次。
歸因同成本
將結果歸因到流程,並記錄結果發生嗰刻邊次嘗試仍在進行。然後報告:
- 按流程類型嘅結果,同鏈入面每個位置觸及嘅比例。
- 整條鏈嘅每個完成結果成本,而唔係按渠道計算。
- 重複率:超過一次嘗試都送達咗嘅流程。
- 含糊率:以冇最終狀態告終嘅嘗試。
- 停止條件有效性:後續嘗試被正確取消嘅流程。
如果一條鏈嘅第二同第三個位置承載咗大部分結果,咁就係話第一個位置對嗰個群體嚟講係錯嘅。
供應模式喺邊度適用
Flowstates 銷售同營運跨渠道嘅訊息路由,支援客戶保留自己嘅供應商合約(BYOV),亦支援混合安排。鏈嘅邏輯——合資格性、去重、時限、停止條件同歸因——喺每種情況下都係同一份工作,而佢應該同定義目標嘅業務狀態放埋一齊。