等待验证码的用户会将排队、送达、阅读和输入体验为一个整体延迟。在判断注册缓慢是消息送达问题还是更广泛的验证流程问题之前，先将这些区间分开。
应该收集哪些时间戳？
通过 webhook 订阅收集 Verify 生命周期事件，存储其载荷中的时间戳。
事件载荷 标识了以下阶段：
| 事件 | 时间戳 | 记录内容 |
|---|---|---|
verify.verification.created | created_at | 验证已创建 |
verify.attempt.sent | sent_at | Bird 将验证码交给了一个渠道 |
verify.attempt.delivered | delivered_at | 渠道报告已送达 |
verify.attempt.undelivered | failed_at | 该验证码尝试失败 |
verify.verification.verified | verified_at | 接收方提交了正确的验证码 |
verify.verification.failed | failed_at | 投递计划未能送达验证码 |
将事件类型与每个时间戳一起保存。两个 failed_at 字段描述不同的范围：一个是单次尝试，另一个是验证的投递计划。
使用 webhook-id 对送达事件去重，它标识一个事件并在重试中保持不变。排序事件时使用载荷的 timestamp，因为送达顺序可能变化。
哪个时间区间能回答我的问题？
使用 sent 到 delivered 获取报告送达时间。使用 created 到 verified 获取完成验证时间。
| 区间 | 包含内容 |
|---|---|
created_at 到 sent_at | 渠道接受验证码之前的时间，可能包含更早的渠道失败 |
sent_at 到 delivered_at | 渠道接受后的处理时间以及报告的送达区间 |
created_at 到 verified_at | 完整的等待时间，包括阅读和输入验证码 |
sent 时间戳并不总是表示运营商提交。对于 SMS，Bird 的渠道在下游 SMS 管道将其提交给运营商之前就已接受该尝试。
送达报告是参考性的。运营商和邮箱服务商在确认内容和报告速度上各有不同。
在相同渠道和市场上做纵向比较。国家之间的差异可能反映的是报告惯例，而非送达速度。
verified 事件确认验证码已被接收和使用。其时间区间衡量的是完成过程，而非仅消息送达。
验证码重发时如何配对事件？
按 verification_id、渠道和接收方地址对事件分组。排除仍然不明确的配对。
Verify 的公共事件不包含尝试标识符。重新发送或渠道切换会在同一验证标识符下创建另一次尝试。
sent 事件和对应的 delivered 事件具有不同的 webhook-id 值。该请求头用于事件去重，不能将一次尝试的各阶段关联起来。
时间戳顺序可以区分简单序列。向同一地址同一渠道的重复发送可能重叠。仅凭排序无法证明哪个送达对应哪次发送。
将这些样本标记为不明确，而非为其指定精确的尝试延迟。验证的 created 到 verified 区间仍是一个独立的度量。
不可用或受限的渠道可能在没有 sent 事件的情况下失败。计算 sent 到 delivered 区间前，要求存在 sent_at。
为什么我的数据与仪表盘不同？
仪表盘可能衡量的是不同的时间区间，也可能包含与你的事件报告不同的尝试。
仪表盘衡量的是符合条件的已计费、已送达尝试从创建到完结的时间。它将修正后的送达超时排除在延迟样本之外，因为这些完结时间不属于实测送达。
其报告窗口使用计费时间。基于发送时间的事件报告因此可能包含不同的尝试集合。
存储的延迟反映的是读取计费时的送达状态。后续的送达更新可能不会改变该样本。
当没有符合条件的样本时，百分位数为 null。保留这一区分，不要显示零，因为零意味着即时送达。
在调查差异之前，先比较相同的报告窗口。当你的应用需要自定义时间区间和分组时，使用 webhook 事件。
如何报告缓慢和丢失的验证码？
将时间报告与未送达的尝试和未完成的验证一起呈现。
仅包含已送达尝试的延迟报告会遗漏验证码从未到达的用户。在时间摘要旁保留这些失败记录。
verify.verification.failed 事件涵盖已耗尽的投递计划。验证码过期和错误码尝试次数耗尽不会触发该事件，因此它不是完整的未转化计数。
在你的应用中跟踪验证创建和成功完成。将未完结的会话单独保留，而非为其分配一个虚构的送达时长。
按渠道和接收方市场拆分尝试。当有报告时，carrier 和 mcc_mnc 标识处理网络。对于 email、WhatsApp 和 Telegram，两者均为 null。
渠道故障转移可以解释用户收到验证码较晚的原因。在将整个延迟视为单个渠道的送达时间之前，先检查尝试序列。
简而言之
选择你需要的时间区间。
报告送达时间和完成验证时间回答的是不同问题。完成时间包含阅读和输入验证码的过程。
谨慎配对尝试。
事件标识的是验证而非每次尝试。在同一渠道上重复发送可能导致配对不明确。
在延迟报告旁保留失败记录。
仅统计成功送达会忽略从未收到的验证码。将未送达和未完成的验证单独报告。
比较同类流量。
送达报告因渠道和市场而异。在比较百分位数之前，先记录你的时间区间和采样规则。