统计企业微信研发通知的效果，需要把“到达率”和“处理反馈”拆成两条独立的指标链：到达率看研发平台发出的消息有多少在企业微信侧确认送达，处理反馈看已送达的消息有多少在约定时限内产生了可识别的处理动作。两条链的分母不同、数据来源不同，统计前要先统一消息ID、接收人ID和时间戳口径，再处理重复推送、分母为零和跨天归属问题。
要点总览（TL;DR）
- 到达率与处理反馈是两条独立指标链：到达率以研发平台发出消息数为分母、企业微信侧确认送达数为分子；处理反馈率以确认送达数为分母、以约定时限内产生可识别处理动作的消息数为分子。
- 统计前先统一口径：以消息ID+接收人ID为对齐主键，时间戳统一时区并精确到秒；回执缺失记为未确认送达，不推断为已读。
- 重复推送按消息ID去重，重试次数单独计入重复推送数；分母为零时输出“无样本”而非0%；跨天归属以发送时间为准。
- 异常情况单独计数：发送失败、重复推送、延迟超阈值、无接收人消息，这些计数往往比比率更早暴露集成配置或账号映射问题。
- 比率只描述可观测结果：不同应用与消息类型的比率不可直接横向比较，回执能力受限时到达率只能作为下界估计并标注证据强度。
评估目标：先明确要回答哪两个问题
研发通知的统计经常被合并成一个“触达率”或“响应率”，结果既说不清消息是否送到人，也说不清送到后有没有被处理。更可用的做法是把评估目标拆成两个独立问题，各自设定判定标准。
第一个问题是到达：在指定时间窗内，研发平台针对某类研发事件发出的通知，有多少条在企业微信侧获得了确认送达的反馈。评估对象是“消息—接收人”这一组合，判定标准是存在可核验的送达回执。第二个问题是处理反馈：在确认送达的消息中，有多少条在约定时限内出现了可识别的处理动作，例如点击查看详情、在消息内确认、进入关联工单，或对应工作项发生状态流转。评估对象同样是“消息—接收人”，判定标准是处理动作的发生时间落在时限之内。
评估目标可以写成可验收的句子，例如：“统计2026年3月某应用发出的构建失败通知，以发送时间为准归入自然日，到达率按日计算，处理反馈率以送达后4小时为时限计算，输出按消息类型分组的日粒度结果。”这样的表述明确了对象、时间窗和判定标准，换一个人取数也能复算出同一结果。
需要提前说明的是，这两类指标只描述可观测结果。到达率高说明消息送到的比例高，处理反馈率高说明送达后被处理的比例高，二者都不能单独证明通知机制改善了研发协作。评估结论应停留在“观测到什么”，因果归因需要额外的对照设计，不在本次统计范围内。
指标与范围：到达率、处理反馈与异常三类指标
指标定义要落到公式、分子、分母、单位和分组维度上，形成一张可以逐项复算的定义表。下表给出建议的指标清单。
| 指标名 | 公式 | 分子 | 分母 | 单位 | 分组维度 |
|---|---|---|---|---|---|
| 到达率 | 确认送达消息数 ÷ 发出消息数 × 100% | 企业微信侧确认送达的消息数 | 研发平台发出的消息数 | 百分比 | 应用、消息类型、时间窗 |
| 处理反馈率 | 时限内处理消息数 ÷ 确认送达消息数 × 100% | 约定时限内产生可识别处理动作的消息数 | 确认送达的消息数 | 百分比 | 应用、消息类型、时限档位 |
| 发送失败数 | 计数 | 发送状态为失败的消息数 | — | 条 | 应用、失败原因 |
| 重复推送数 | 计数 | 同一消息ID的重复发送次数 | — | 次 | 应用、消息类型 |
| 延迟超阈值数 | 计数 | 送达时间减发送时间超过阈值的消息数 | — | 条 | 应用、阈值档位 |
| 无接收人消息数 | 计数 | 接收人为空或解析失败的消息数 | — | 条 | 应用 |
“可识别处理动作”需要在统计前写死清单，避免口径漂移。常见动作包括：点击消息进入详情页、在消息卡片上执行确认或忽略、由消息跳转创建或更新工单、关联工作项状态从待处理变为处理中或已完成。每个动作要能通过消息ID回填到具体消息，否则只能算旁证，不能计入分子。
统计范围要一并界定：纳入哪些应用（例如构建、发布、缺陷、值班告警），纳入哪些消息类型（文本卡片、图文、模板消息等），时间窗按发送时间还是处理时间切分，是否包含测试环境消息和机器人自动消息。测试消息和机器人消息通常单独分组或排除，具体取舍应在指标说明中写明，保证前后期口径一致。
数据口径与证据：消息ID、接收人ID和时间戳怎么对齐
两侧数据要对齐，前提是研发平台侧和企业微信侧都能提供可关联的字段。研发平台侧一般可以拿到消息ID、所属应用、消息类型、发送时间、接收人标识和发送状态；企业微信侧可获取的送达类、已读类回执字段，以及接口在具体版本中开放的范围，需要按实际部署版本核实，本文不给出确定的字段名。
对齐主键建议使用“消息ID + 接收人ID”。消息ID标识一条通知，接收人ID标识这条通知的投递对象，两者组合才能区分群发消息中不同人的送达与处理情况。接收人ID在两侧的形态可能不同，需要先通过账号映射表转换到同一标识体系，映射失败的消息计入无接收人消息数，不进入比率分母。
| 字段类别 | 研发平台侧 | 企业微信侧 | 对齐要求 |
|---|---|---|---|
| 消息标识 | 消息ID、应用、消息类型 | 可回传的消息标识 | 以消息ID为主键关联 |
| 接收人 | 接收人ID、账号映射 | 接收人标识 | 映射到统一人员ID |
| 时间 | 发送时间 | 送达时间、处理动作时间 | 统一时区与精度到秒 |
| 状态 | 发送状态 | 送达回执、已读或点击类回执 | 按实际可获取范围标注 |
缺失值处理要保守：回执缺失记为“未确认送达”，不推断为已读，也不推断为未读。若企业微信侧只提供部分回执能力，到达率只能作为下界估计，报告中应标注证据强度，例如“到达率不低于X%，因部分消息类型无回执”。时间戳统一到同一时区并精确到秒，避免跨系统时差造成延迟超阈值误判。
在研发平台侧，通知发送记录与工作项状态流转往往分散在不同模块。ONES 提供 API 接口用于与企业系统集成和数据打通，并支持一键对接企业微信，可作为研发平台侧通知记录与工作项状态数据的来源之一；具体可获取的字段和回执范围需按实际版本核实。账号目录同步与登录集成属于身份集成范畴，与本文的通知统计口径分开处理。
计算步骤：从原始日志到两张指标表
计算流程可以固定为六步，每步产出可检查的中间结果，便于复核。
- 取数：从研发平台导出指定时间窗内的通知发送记录，从企业微信侧导出可获取的送达与处理回执，保留原始字段和时间戳。
- 清洗去重：按消息ID去重，同一消息ID的多次重试只保留一条进入分母，重试次数单独计入重复推送数。
- 对齐：以消息ID + 接收人ID关联两侧记录，映射失败或无接收人的消息单独计数，不进入比率计算。
- 标记：为每条消息标记是否确认送达、是否在时限内产生可识别处理动作，处理动作按发生时间回填到对应消息。
- 聚合：按应用、消息类型、时间窗分组，统计分子分母和异常计数。
- 计算比率：到达率与处理反馈率分别计算，分母为零时输出“无样本”，不输出0%。
跨天归属以发送时间为准：一条消息在23:50发出、次日0:10被处理，仍归入发送当日，处理动作按实际发生时间判断是否在时限内。这样处理可以避免同一批消息被拆到两天、导致两天的比率都失真。若业务上更关心处理发生日，可以另出一张按处理时间归集的表，但两张表不能混用同一分母。
分母为零和样本过少要区别对待。某应用某消息类型当天没有发出消息，到达率输出“无样本”；发出3条、送达2条，比率可以计算，但应在结果旁标注样本量，避免用极小样本的比率做横向比较。聚合结果建议同时保留分子分母原始数，比率只是派生值。
例子：一周研发通知的到达与处理反馈计算
以下数值为演示用，不代表任何产品实测。假设某应用一周内发出研发通知，按消息类型分组后的原始数据如下。
| 消息类型 | 发出数 | 确认送达数 | 时限内处理数 | 发送失败数 | 重复推送数 |
|---|---|---|---|---|---|
| 构建失败通知 | 200 | 190 | 152 | 6 | 12 |
| 发布审批提醒 | 80 | 78 | 70 | 1 | 3 |
| 缺陷指派通知 | 120 | 110 | 66 | 4 | 8 |
| 值班交接提醒 | 0 | 0 | 0 | 0 | 0 |
代入公式：构建失败通知到达率 = 190 ÷ 200 × 100% = 95.0%，处理反馈率 = 152 ÷ 190 × 100% ≈ 80.0%；发布审批提醒到达率 = 78 ÷ 80 × 100% = 97.5%，处理反馈率 = 70 ÷ 78 × 100% ≈ 89.7%；缺陷指派通知到达率 = 110 ÷ 120 × 100% ≈ 91.7%，处理反馈率 = 66 ÷ 110 × 100% = 60.0%。值班交接提醒当周无发出消息，两项比率均输出“无样本”，不写0%。
异常计数单独呈现：当周发送失败11条、重复推送23次。重复推送按消息ID去重后未重复计入分母，因此到达率不受重试次数放大影响。若把重复推送直接计入发出数，构建失败通知的到达率会被稀释到约89.6%，与真实投递情况不符，这也是去重规则必须写进指标说明的原因。
处理动作的证据来源要能回填到消息。以缺陷指派通知为例，处理反馈率明显低于其他类型，可能因为部分接收人通过工作项列表直接处理而未点击消息。此时应检查处理动作清单是否覆盖了“工作项状态流转”这类间接动作，再决定是否调整口径，而不是直接判定通知效果差。
解读与限制：比率能说明什么、不能说明什么
到达率回答的是投递链路是否通畅，处理反馈率回答的是送达之后是否有人采取动作，两者不能互相替代。到达率接近100%而处理反馈率偏低，说明问题更可能出在消息内容、时限设定或处理入口，而不是通道；到达率本身偏低，则应先排查接收人映射、应用权限和发送失败原因。
不同应用、不同消息类型的比率不可直接横向比较。构建失败通知面向当班开发者，缺陷指派通知面向缺陷负责人，职责和响应预期不同，60%与80%的差异未必代表效果优劣。比较应在同应用、同消息类型、同时间窗、同时限档位下进行，跨组比较只能作为线索。
回执能力受限时，到达率只能给出下界估计。若某类消息在企业微信侧无法获取送达回执，这部分消息应标注为“未确认送达”并说明证据强度，报告中写“到达率不低于X%”，而不是把缺失当作失败。同理，处理动作若只能通过点击类回执识别，未点击但通过其他入口处理的记录不会被计入，处理反馈率会偏低。
解读时建议同时看三类信息：比率、异常计数和趋势。单周比率受样本量和事件波动影响大，连续多周的走势比单点数值更能说明问题；发送失败、重复推送、延迟超阈值和无接收人消息的计数，往往比比率更早暴露集成配置或账号映射的问题。比率是观测工具，不宜直接作为个人或团队的绩效结论。
常见问题
企业微信侧拿不到送达回执，到达率还能统计吗？
可以统计，但结果只能作为下界估计。做法是把无法获取回执的消息类型单独标注为“未确认送达”，在报告中写成“到达率不低于X%”，并说明哪些消息类型缺少回执证据。这类消息不进入分子，但仍保留在分母中，因此算出的比率偏低，不能当作真实投递失败率使用。若后续企业微信侧开放了对应回执能力，再按同一口径重算，前后结果才可比。
一条通知被重试推送多次，到达率和处理反馈率会受影响吗？
会影响，所以去重规则要写进指标说明。按消息ID去重后，同一消息ID只保留一条进入分母，重试次数单独计入重复推送数。如果不做去重，把每次重试都算作一条发出消息，到达率会被稀释，处理反馈率的分母也会被放大。去重后重试成功送达的消息仍计入分子，这样比率反映的是消息维度的投递情况，而不是发送次数的比例。
处理动作只统计点击消息，会不会漏掉通过工作项直接处理的记录？
会漏。处理动作清单如果只覆盖点击类回执，接收人从工作项列表直接更新状态、在工单系统里处理等间接动作就不会被计入，处理反馈率会系统性偏低。建议在统计前把“关联工作项状态流转”“由消息跳转创建或更新工单”等动作纳入清单，并确认这些动作能通过消息ID回填到具体消息。无法回填的动作只能作为旁证，不能计入分子，此时应在报告中说明口径覆盖范围。
某天某类通知没有发出消息，比率应该写0%还是留空？
应输出“无样本”，不写0%。分母为零时比率没有数学意义，写成0%会被误读为“全部未送达”。同理，发出消息很少时比率可以计算，但要在结果旁标注样本量，避免用极小样本做横向比较。聚合表建议同时保留分子和分母原始数，比率只作为派生值呈现，方便复核和后续重算。
统计结果偏低时，应该先排查通道还是先调整通知内容？
先看到达率再决定方向。到达率明显偏低时，优先排查接收人账号映射、应用可见范围和发送失败原因，这些属于投递链路问题；到达率正常而处理反馈率偏低时，再检查消息内容是否清晰、处理时限是否合理、处理入口是否顺手。两类问题混在一起调整，很难判断改善来自哪里。建议同时观察发送失败、重复推送、延迟超阈值等异常计数的趋势，它们通常比比率更早暴露配置问题。
