要看LookWorldPro今日群发量，最快的办法是登录后台的“Campaign/群发”报表，选中今天的时段并设置正确时区，查看关键指标（发送、投递、拒收、打开、点击）和分批记录，然后导出CSV或用API拉取当天数据做交叉核验。如果UI与API出现差异，优先排查批处理延迟、重试队列、子账号汇总与Webhook回调时延等因素。下面按步骤把所有细节、验证方法和排查要点讲清楚，帮你把数字读准。
先弄清你想要的“群发量”具体指什么
很多人一上来就看“发送数”，其实发送数只是一部分。要把今天的群发量读准，先区分这些常见概念：
- Queued / Scheduled（排队/计划发送）：已经安排但还没发出的邮件/消息。
- Sent（已发送）：平台已把消息提交到下游发送队列或已下发到外部SMTP/API提供商。
- Delivered（已投递/接受）：对方服务器接收并返回了成功响应。
- Bounced（退信/拒收）：被目标服务器拒绝（硬退、软退需区分）。
- Opened / Clicked（打开/点击）：终端用户行为，常用于效果而非“群发量”。
为什么要区分？
因为“群发量”会随着你选的指标不同而差别很大。想知道当天到底向外发送了多少请求，就看Sent；想知道有多少实际到达目标方，就看Delivered。
具体操作步骤（UI）——一步步在后台看清今天数据
实操里，先从UI入手最直观：
- 1. 登录并确认账号/子账号：如果你有主账号和多个子账号，确认看的是哪个账号或是否需要合并视图。
- 2. 进入Campaign/群发或Report/报表页：LookWorldPro通常把群发统计放在活动报表或发送报表里。
- 3. 选择时间范围为“今日”或自定义起止时间：注意时区选择（平台默认时区可能是UTC），切换到你本地时区以免少看或多看。
- 4. 选择指标列：Sent, Delivered, Bounced, Open, Click：如果你只看发送请求数量，选Sent；要看效果同时看Open/Click。
- 5. 查看分批（batch）或任务ID：大批量发送通常分批执行，展开批次可以看到每次提交数量与时间。
- 6. 导出CSV或直接点击“导出”：把当天数据导出，方便本地核对或留档。
用API拉取和交叉验证——更可靠的方式
UI实时性与聚合逻辑可能不同，API数据通常更“原始”。推荐用API做二次核对。
- 取得API Key并确认权限：确保Key有读取报表与事件日志的权限。
- 调用活动/发送记录接口：带上起止时间戳（最好用UTC），筛选status字段。
- 聚合计算：按status计数（如 status == sent => +1），也要按batch_id或message_id去重，避免重复计数。
- 对比导出CSV：把API拉的数据和UI导出的CSV做左连接，比较sent、delivered字段的总和差异。
示例思路（伪代码）
下面这段伪代码只是思路，不依赖具体SDK：
- 调用GET /api/v1/messages?start=2026-06-17T00:00:00Z&end=2026-06-17T23:59:59Z
- 去重：unique_ids = set(message.id for message in response)
- 统计：sent = count(status == ‘sent’), delivered = count(status == ‘delivered’)
关键字段与指标解释（表格版）
| 字段 | 含义 | 何时用 |
| queued/scheduled | 计划待发的数量 | 查看未来任务或延迟发送情况 |
| sent | 已提交到发送通道（发送请求数） | 统计请求量的首选 |
| delivered | 目标端确认接收（投递成功） | 衡量实际到达目标的数量 |
| bounced | 被拒收的量（软/硬退） | 排查质量与名单问题 |
| open / click | 终端用户互动 | 衡量内容效果而非发送量 |
常见差异与排查顺序（为什么UI和API会不一致）
当你发现UI上“今日发送10000”，而API显示“9800”或“10250”，先不要慌，按下面顺序排查：
- 时区误差：UI可能按本地时区显示，API默认UTC。统一为UTC再比较。
- 批处理延迟：平台可能把日志异步写入，UI显示的是缓存或定时聚合结果。
- 去重策略不同：API拉原始事件，UI在展示时可能合并了重复message_id。
- 子账号/主账号合并：UI可能默认展示主账号汇总，API请求如果没有指定scope只返回单账号。
- 重试和队列：失败后自动重试会产生成功与失败两条记录，统计口径要一致（以message_id为准）。
- Webhook未送达：如果你通过Webhook记录回执，网络问题会造成回调丢失，导致本地统计少记录。
- 导出延迟：CSV导出有时候是批量生成，生成时间会滞后。
实操校验清单（按顺序做）
- 确认你看的是同一账号/子账号/租户。
- 统一时间：把UI和API都转到UTC或目标时区。
- 导出UI CSV并保存原文件名与时间戳。
- 用API拉取原始事件，不做去重先比总量再比去重后数量。
- 按batch_id逐批对账，找出差异最大的几批。
- 检查失败重试、重传日志、Webhook回调成功率。
- 如有第三方发送通道（SMTP、SMS厂商），查询供应商日志。
写给工程师的补充：SQL与数据处理示例
如果你能直接查询仓库或ClickHouse/Redshift表，下面的SQL思路可以用来统计当日的“sent”和“delivered”。
示例SQL（伪）：
| SELECT | COUNT(DISTINCT message_id) AS unique_messages_sent, |
| SUM(CASE WHEN status = ‘delivered’ THEN 1 ELSE 0 END) AS delivered_count | |
| FROM | message_events |
| WHERE | timestamp >= ‘2026-06-17 00:00:00’ AND timestamp <= ‘2026-06-17 23:59:59’ AND tenant_id = ‘your_tenant’ |
实时监控与自动告警建议
如果你每天都要看，很值得做自动化：
- 建立每日定时任务，通过API拉取并保存当天数据快照（CSV/数据库）。
- 设置阈值告警：当Sent相比上一日下降/上升超过阈值，或者Delivered率异常时触发告警。
- 把Webhook失败率、回调延迟也纳入告警。
- 保留原始事件至少7天，便于追溯（合规允许的情况下）。
合规、隐私与数据保留要注意的点
群发量统计牵涉名单与行为数据，注意：
- 不要在未经同意的情况下导出包含敏感个人信息的CSV。
- 遵守GDPR/CCPA等隐私法规：删除请求可能影响历史统计。
- 在做跨区域对账时，注意数据主权与传输加密。
一些容易忽视但关键的细节
- 分段发送（Throttling）：有些大批量会被分段；UI可能只统计“计划量”，实际发送是分段完成。
- 黑名单/屏蔽：如果名单中被屏蔽的地址先被过滤掉，sent数会低于原始目标数。
- 重复ID处理：某些重试机制会复用message_id或生成新id，要注意统计口径。
- API分页：拉记录时一定要处理分页，丢页会导致计数偏小。
快速排错场景举例（实战）
场景一：UI显示今天sent=12000，但API只返回11800。
- 检查时区：UI在UTC+8而API在UTC —— 同步时区后一致。
- 检查分页：API默认每页1000，遗漏了部分页导致少计。
- 检查去重：UI合并重试，API计了重复message，或相反。
场景二：delivered率比平时低很多。
- 检查bounce类别：是否硬退激增说明名单质量问题。
- 检查供应商：第三方通道是否限速或黑名单导致拒收。
- 查看内容：是否触发目标邮件服务器的反垃圾策略。
工具与自动化建议清单（便于持续观察）
- 每天定时导出：UI CSV + API快照，保存为归档。
- 建一个小脚本：对比当天UI与API的sent与delivered，自动报警差异超过1%（阈值可调）。
- 使用Webhook作为实时补丁：实时记录deliver/bounce事件，减少依赖批量导出延迟。
- 把重要报表接入内部监控看板（如Grafana）以便长期趋势分析。
对非工程团队的实用小贴士
不是每个人都想看日志，给产品/运营同学的简单方法：
- 先从UI报表看Sent和Delivered的汇总数。
- 如果看起来“漏了”，联系技术同学索要当天的CSV快照或API导出。
- 记录：今天什么时候发的，哪个活动，预计多少人。这样技术同学能迅速定位。
- 用“分批ID”或“活动ID”沟通问题，避免笼统描述。
好吧，就先说到这里，按上面那些步骤去查一遍，通常能把数字对齐；要是还有差异，再往下挖日志、供应商和回调链路就能找到根因。