送達率答緊嘅係錯嘅問題
送達回執描述嘅係網絡對一個訊息報告咗咩。業務真正問嘅問題唔一樣:用戶喺仍然停留喺流程入面嗰陣,有冇完成驗證?呢兩個數字可以朝相反方向移動,而只有第二個先係一個結果。
以下模型圍繞結果同解釋結果嘅分佈嚟建立,故意冇包含任何目標值。每一個值得告警嘅門檻,都應該來自項目自己最近嘅歷史,按路由、按目的地分開——一個市場 、一個供應商嘅驗證流程,冇辦法同另一個直接比較。
結果指標
驗證完成率。 喺發出咗驗證碼嘅驗證 session 之中,成功驗證嘅比例。呢個係頭條數字。落任何結論之前先要分段睇。
首次嘗試完成率同重發行為。 驗證喺冇重發嘅情況下完成嘅頻率,同每個 session 重發次數嘅分佈。某條路由或目的地重發率上升,通常喺完成率下跌之前就出現,因為用戶會為遲到嘅訊息補償,直到佢哋放棄為止。
重複發碼。 有超過一個驗證碼被發出而且仍然有效嘅 session,同用戶輸入咗已被取代嘅驗證碼嘅 session。呢兩種都係自招嘅失敗,亦都可以喺程式碼度修正。
過期同亂序驗證碼。 用過期驗證碼嘗試驗證,或者較早發出嘅驗證碼喺較後嘅之後先到。呢啲數字高,講緊嘅係延遲,唔係用戶問題。
用戶重試循環。 用戶反覆要求驗證碼但一直冇完成、最終放棄嘅 session。呢個群體正正就係支援工單嘅來源。
延遲分佈
三個時間 段,以分佈形式報告而唔係平均值,因為失敗通常藏喺尾巴度:
- 發出到接受——由你嘅服務決定發出驗證碼,到供應商接受咗份提交。呢個係你自己嘅系統加供應商嘅接收。
- 提交到最終狀態——由接受到路由給出最終狀態。呢個涉及供應商、目的地網絡同營運商。
- 發出到驗證——由發出到一次成功嘅驗證嘗試。呢個包含咗人嘅因素,亦係決定你嘅過期時間是否合理嘅時間段。
將第三個分佈同你設定嘅過期時間比較。過期時間應該係由呢個分佈同你嘅安全政策共同決定,而唔係抄返一個預設值——同樣嘅推理亦定義咗過咗就唔再幫到用戶嘅有用時限。
定位問題嘅細分維度
聚合數字會隱藏失敗;以上每個指標都需要能夠按以下維度切分:
- 供應商同路由
- 國家,同有得知情況下嘅營運商
- 發送方身分同範本
- 裝置平台同應用程式版本
- 流量類別同流程(登入、註冊、找回、付款批核)
- 一日入面嘅時段
有兩個比較值得持續留意:
- 送達同驗證之間嘅落差,按路由分開。一條報告送達強勁但驗證疲弱嘅路由,可能係送達得太遲、送達咗用戶唔信任嘅內容,或者報告嘅狀態根本反映唔到現實。
- 應用程式錯誤,喺驗證端點度要同用戶錯誤分開。一個驗證邏輯漏洞,喺聚合數字入面睇落好似個送達問題。
標準失敗原因
供應商錯誤碼並唔一致,所以將佢哋對應一次去自己一套詞彙,按邊個可以採取行動分組:
| 組別 | 例子 | 負責方 |
|---|---|---|
| 應用程式 | 目的地格式錯誤、範本缺失、端點錯誤 | 你嘅工程團隊 |
| 政策 | 達到速率限制、目的地被抑制、發送方未喺該市場註冊 | 你嘅營運團隊 |
| 供應商 | 路由拒絕、被限速、提交錯誤、冇最終狀態返回 | 供應商管理 |
| 目的地網絡 | 被過濾、發送方被封鎖、網絡拒絕 | 供應商加營運商升級 |
| 收件人 | 接觸唔到、用戶不存在、手機狀態問題 | 逐一訊息無法採取行動 |
| 未知 | 喺時限內冇返回狀態 | 當成數據質素問題調查 |
連同標準狀態一齊保留供應商原始狀態同代碼。冇呢個,轉供應商改變嘅只係你嘅報表,唔係你嘅可靠度。
成本同濫用
- 每次成功驗 證嘅成本,而唔係每個訊息嘅成本。一條較平但重發多、完成率低嘅路由,實際上更貴。
- 詐騙同濫用訊號:按號碼、帳戶、網絡計嘅要求速率;集中喺不尋常或高成本目的地嘅情況;從未帶到驗證嘅要求。呢啲既影響開支,亦影響其他所有指標嘅準確性。
唔記低驗證碼本身,亦能夠關聯各項紀錄
五種紀錄類型需要拼合:驗證 session、驗證碼發出、每次訊息嘗試、每次狀態更新,同驗證結果。一個關聯識別碼——喺你嘅服務決定發出嗰刻生成,貫穿之後每一項紀錄,喺應用程式同訊息傳送兩邊都存低——就係令呢個拼合成為可能嘅嘢。
驗證碼本身永遠唔屬於呢條軌跡。只儲存驗證一個提交驗證碼所需要嘅資料,如果要將一次嘗試連返去某個具體驗證碼,就用一個不可逆嘅發出參考。普通應用程式日誌、分析工具同支援畫面,永遠都唔應該包含驗證碼嘅值。
量度結構
auth_session: session_id, user_ref, journey, started_at, outcome, outcome_at
otp_issuance: issuance_id, session_id, correlation_id, issued_at, expires_at,
attempt_index, superseded_by, channel_policy
message_attempt: attempt_id, correlation_id, issuance_id, provider, route,
sender_id, country, operator, submitted_at, accepted_at,
provider_message_ref, client_reference
message_status: attempt_id, canonical_status, canonical_reason, raw_status,
raw_code, status_at, is_final
verification: verification_id, session_id, issuance_id, attempted_at, result,
failure_kind, device_platform, app_version
呢篇文章入面嘅每一個指標都可以由呢五張表推導出嚟。當中冇一個包含驗證碼嘅值。
診斷表
| 觀察 | 可能原因 | 第一步檢查 |
|---|---|---|
| 送達報告強勁,某條路由驗證率下跌 | 該路由送達遲或內容唔被信任 | 該路由嘅提交到最終狀態分佈,同發出到驗證分佈 |
| 重發率上升,完成率持平 | 訊息遲到但仍喺窗口內 | 按營運商睇提交到最終狀態嘅尾部 |
| 重發率上升、完成率下跌,只限某一國家 | 該市場過濾或註冊問題 | 目的地網絡組別嘅標準原因;發送方註冊狀態 |
| 過期驗證碼嘗試上升 | 過期時間短過真實用戶行為,或延遲增加 | 發出到驗證分佈對比設定嘅過期時間 |
| 被取代驗證碼嘗試上升 | 每個 session 有多過一個有效驗證碼 | 按 session 睇發出紀錄;喺 session 層面去重 |
| 驗證碼有效、及時但驗證仍失敗 | 應用程式或驗證邏輯缺陷 | 按應用程式版本拆分驗證端點嘅失敗類型 |
| 某條路由缺少最終狀態 | 供應商狀態報告有缺口 | 按供應商計算冇最終狀態嘅嘗試比例;向供應商提出 |
| 每次驗證成本上升,流量持平 | 重發增加或濫用 | 每次完成驗證嘅要求數;按號碼同網絡計嘅速率 |
告警
按項目自己嘅基線,喺該路由同目的地度,對照一個夠長、足以排除該流量正常波動嘅時間窗口去告警。每個告警都要指名負責人同行動:升級畀供應商、轉換路由、暫停活動,或者開一個應用程式缺陷。冇附加行動嘅告警,兩星期內就會被忽略。
相關嘅送達機制見A2P SMS 送達實戰指南。