# 衡量 Apple Messages 业务结果

使用 Bird 的[渠道指标](/docs/guides/apple-messages/analytics)衡量消息活动和处理情况。使用负责订单、预约、付款或工单的系统确认业务结果。

消息的**已发送**状态确认 Apple 网关已接受消息。表单答案或所选时间记录的是客户交互。两者都不能证明业务操作已完成。

## 报告结果前先定义结果

选择来源系统能确认的结果，例如已创建预约、已付款订单或已解决服务工单。写明时间戳、记录标识符以及满足结果要求的条件。

对于预约，请区分以下观察结果：

| 观察结果       | 证据                                   |
| -------------- | -------------------------------------- |
| 已提供时间选项 | 发出的消息记录。                       |
| 客户已选择时间 | 收到的原生回答。                       |
| 已建立预约     | 预约系统中的成功预约记录。             |
| 已发送确认     | 单独发出的确认消息。                   |
| 客户已到场     | 服务团队记录的到场信息（如果有收集）。 |

选择能回答您问题的分母。例如，预约数除以获得时间选项的客户数，与预约数除以收到的时间选择数，衡量的是不同阶段。报告结果时注明时间范围和排除项。

## 关联记录

在集成中，将工单或操作编号与 Bird 的对话和消息 ID 一同保留。对于 API 发送，按[发送消息契约](/docs/api/reference/create-amb-message)使用受支持的 `metadata` 或报告标签。报告标签不会改变权限、屏蔽或重试行为。

使用自身系统的编号，不要将客户秘密放入 URL 或消息标签。记录每个时间戳和结果来自哪个系统。对关联后的数据应用您的保留和访问规则。

## 处理重复和延迟结果

分别对 Webhook 投递和业务操作去重。同一事件的重复投递不能创建第二次预约。客户再次主动发起的请求可能代表另一项操作。

核对超时后仍不确定的操作。让延迟到达的提供商结果更新原操作，不要将其计为新的转化。如果报告所回答的问题需要包含取消和撤销，请将其纳入。

## 如实解读报告

对话关闭是客户生命周期事件，不是问题解决得分。首次响应更快不能证明答案正确。缺少设备已读回执时，不能用网关接受状态来代替已读。

必要时，按受支持的入口意图或自身工单分类比较结果。查看成功结果的同时，也检查未解决请求和失败路径。将此业务报告与 Bird 消息控制台区分开，让读者知道每个数字能证明什么。