查看LookWorldPro今日群发量，优先打开实时仪表盘与当天发送日志；按渠道（短信/邮件/推送/站内信）与活动拆分，分别统计发送请求、被平台接收与最终回执（送达/失败/退回），再用时间序列和唯一消息ID交叉校验异常点，注意时区与重试策略带来的延迟。
先把概念讲清楚：群发量到底包括什么？
有时候大家把“群发量”当成一个数字，其实这是好几类数据的集合。把它想像成一个流水线：你往机器里丢入“发送请求”，系统接收并分发到不同通道（像邮件网关、短信供应商、推送服务），最终会有各种回执（送达、失败、退回、黑名单拒收等）。所以要看“群发量”，要分别看每一段流水线上的计数。
关键计数项（必须分开看）
- 发送请求数（Requested）：应用端发起的请求总数，等于你发给LookWorldPro的“要发送多少条”。
- 接收/受理数（Accepted）：平台成功接收并入队列的消息数（可能被队列限流后滞后发送）。
- 下发数（Dispatched/Delivered to provider）：平台已经发给第三方通道（短信网关、邮件服务器等）的次数。
- 回执数（Delivery Receipts）：来自第三方的最终状态，如送达、失败、退订、黑名单等。
- 成功率/失败率：常用比值指标，用来判断链路健康。
- 打开/点击/互动：仅对邮件/应用内消息有意义，衡量效果而非纯量。
如何一步步查今天的群发量（实操流程）
下面我按从最直观到最底层的顺序写，像自己在现场查故障时会做的那样：
1) 看实时仪表盘（第一步，也是最常用）
大部分系统都会有一个“今日统计”或实时仪表盘，展示请求数、send rate、成功率等。仪表盘的优点是直观、及时；缺点是可能有采样或延迟（尤其是第三方回执）。所以仪表盘看完后，必要时要往下钻。
2) 按渠道和活动拆分（关键）
把总量按渠道（短信/邮件/推送/站内信）拆开，再按campaign或模板拆分。很多时候“总量正常，但某渠道崩了”是常见问题。按国家/时区/语言再细分，可以迅速定位是否是地域或运营策略问题。
3) 看发送日志和消息队列
在后台日志里，你能看到每条消息的生命周期：请求时间、队列入队时间、下发时间、第三方回执时间与状态。若系统使用消息中间件（Kafka/RabbitMQ/Redis Streams），也要看队列长度、消费速率和重试次数。
4) 比较三方数据
做三个地方的数据比对：应用请求（A）、平台下发给提供商（B）、第三方回执（C）。理想关系是 A ≥ B ≥ C（视不同语义而定）。常见不一致来源包括延迟回执、丢弃、重复请求、去重策略等。
5) 使用API或SQL直接查询（最可靠）
如果你能运行查询，直接用SQL或内部API按当天时间窗口做精确计数。这比仪表盘更准确（前提是数据仓库延迟可控）。下面会给出示例SQL和API思路。
示例：你可以运行的查询和API检查
这里的例子是通用模板（表名、字段按你们系统改）。用这些能快速得到“今日群发量”的各个分项。
示例SQL（伪代码）：
SELECT
SUM(CASE WHEN created_at::date = CURRENT_DATE THEN 1 ELSE 0 END) AS requested_today,
SUM(CASE WHEN accepted_at::date = CURRENT_DATE THEN 1 ELSE 0 END) AS accepted_today,
SUM(CASE WHEN dispatched_at::date = CURRENT_DATE THEN 1 ELSE 0 END) AS dispatched_today,
SUM(CASE WHEN receipt_status = ‘DELIVERED’ AND receipt_time::date = CURRENT_DATE THEN 1 ELSE 0 END) AS delivered_today
FROM messages
WHERE created_at >= CURRENT_DATE AND created_at < CURRENT_DATE + INTERVAL '1 day';
示例API校验流程：
- 调用 /api/v1/messages/stats?date=YYYY-MM-DD 获取聚合数。
- 调用 /api/v1/messages?date=YYYY-MM-DD&channel=sms&limit=1000 获取具体记录抽样。
- 对抽样记录比对外部供应商的回执（通过供应商报表或Webhook）。
重要字段对照表（便于沟通）
| 字段 | 含义 | 示例 |
| request_id | 系统内唯一请求ID，用于串联整条消息生命周期 | abc123-20250316-0001 |
| created_at | 客户端发起发送请求的时间（UTC） | 2026-03-16T08:12:03Z |
| accepted_at | 平台成功受理并入队时间 | 2026-03-16T08:12:04Z |
| dispatched_at | 已下发到第三方通道时间 | 2026-03-16T08:12:06Z |
| receipt_status / receipt_time | 第三方回执状态与时间（DELIVERED/FAILED/BOUNCED/REJECTED） | DELIVERED / 2026-03-16T08:13:10Z |
不同通道的注意点（别混为一谈）
- 短信（SMS）：第三方回执通常比较快，但不同运营商回执格式不同。高并发时供应商可能会限流并延迟回执。
- 邮件（SMTP/ESMTP）：投递到目标邮件服务器并不等于用户“看到邮件”。退信（bounce）与延迟（deferred）会在回执中体现，可能滞后数小时。
- 推送（APNs/FCM）：通常认为“送达到平台”就很接近终端，但设备离线或token失效会导致无法最终送达，回执语义也不同。
- 站内信/应用消息：通常由你们自己存储并发推，不依赖外部回执，但要注意写入成功和展示统计。
常见差异与排查思路（实战派）
- 差异1：请求多，但回执少 —> 检查队列积压、供应商限流、重试策略、以及是否有黑名单/屏蔽。
- 差异2：回执晚到 —> 看时间序列，是否发生批量回执（批处理），是否时区/夏令时导致显示错位。
- 差异3：重复计数 —> 使用唯一request_id与幂等key进行去重，再校验日志里是否有重复提交。
- 差异4：地域性失败 —> 按国家/运营商分布统计，排查供应商地区中断或交付限制。
监控与告警建议（让“今天”的数据事半功倍）
- 设置实时SLA阈值：如每分钟发送失败率超过2%触发告警；队列积压超过N条或消费速率下降触发告警。
- 时间序列监控：按分钟粒度监控请求、被接受、下发与回执数，便于快速定位突发事件。
- 对各通道分别设置阈值（短信/邮件/推送）——因为各自正常失败率不同。
- 保留7-30天的详细日志，便于事后追踪与合规审计。
今日快速核对清单（操作步骤，照着做）
- 打开实时仪表盘，记录：请求数、被接收数、回执数（各渠道）
- 按campaign和通道导出当天的详细记录（或抽样）
- 比对第三方回执（Webhook或供应商报表）
- 检查队列长度与消费速率，查看是否有积压或重试风暴
- 若发现异常，按request_id追溯日志链路，确认是平台问题、网络问题，还是供应商问题
小技巧与经验（那些容易被忽略的点）
- 时区问题：存储时间尽量统一用UTC，展示时再转换；汇报“今日”时要明确是哪个时区的“今日”。
- 延迟回执：对邮件类和某些短信供应商，最终回执可能滞后一段时间，别急着下结论。
- 抽样比对：当总量巨大时，抽样比对比全量慢但更快定位问题（先抽1000条做交叉核验）。
- 去重与幂等：保证客户端重试采用幂等key，避免重复发送带来虚高群发量。
如果看到“数字异常”，先别慌，按这三个问题问自己：
- 是仪表盘延迟还是数据库延迟？（看数据仓库ETL窗口）
- 异常是全渠道还是单个通道？（按渠道拆解）
- 是否刚刚调整过重试/去重/节流策略？（排查配置变更）
好了，这些步骤和注意事项几乎涵盖了现场查“今日群发量”时会碰到的大部分情形。你可以把仪表盘当作第一眼的“体温计”，但最后的数据诊断还是得靠日志、队列和第三方回执三者对齐——这是核心理念，也是少犯错的办法。顺便说一句，如果你需要我把上面的SQL或API模板根据你们数据库与字段名改写一次，告诉我表名字段就行，我可以继续帮你把查询改得能直接跑。