Firebase Cloud Messaging报告接收量超发送量，与BigQuery数据不符原因咨询

这确实是个有点反直觉的现象，结合你提到的「控制台报告接收量>发送量，但BigQuery里接收量<发送量」的矛盾点，我梳理了几个最可能的原因：

1. 统计口径的核心差异（最常见） #

FCM控制台和BigQuery的统计维度往往不一样，这是导致数据矛盾的头号原因：

• 控制台的「发送量」：很多时候统计的是API调用请求数，而不是实际发送到设备的消息数。比如你一次调用FCM API给1000个设备发消息，控制台会把这次请求记为「发送量1」，但实际发送的消息数是1000条。
• 控制台的「接收量」：统计的是设备成功接收的消息次数（对应1000条里的实际送达数，比如950条），这时候950自然远大于1的发送量。
• BigQuery的数据：则是按单条消息维度统计——MESSAGE_SENT事件对应每个设备的发送记录（这里就是1000条），MESSAGE_RECEIVED对应实际接收的950条，所以会出现接收量低于发送量的情况，这才是真实的单消息维度统计结果。

2. 时间窗口与跨周期统计 #

另一个常见原因是统计时间窗口的对齐问题：

• 控制台可能把「消息发送时间」作为统计维度，比如你在Day1发送的消息，有些设备因为离线在Day2才接收，控制台会把这次接收算到Day1的接收量里；
• 而BigQuery通常按「事件发生时间」统计，也就是设备实际接收的时间（Day2），这会导致Day1的控制台接收量包含了延迟接收的消息，看起来超过当天的发送量，而BigQuery里Day1的接收量则是真实的当天接收数，低于发送量。

3. 重试机制的计数差异 #

FCM会自动重试发送失败的消息（比如设备离线后上线）：

• 控制台的接收量可能会把重试请求的成功次数纳入统计（虽然FCM不会重复送达同一条消息，但控制台可能将重试动作的成功也算作接收量），而发送量只统计初始发送请求数，导致接收量虚高；
• 而BigQuery里的MESSAGE_RECEIVED事件只会记录设备实际接收的那一次，所以接收量会更准确，低于发送量。

4. 数据延迟与临时统计偏差 #

FCM控制台的报告数据可能存在延迟同步或者临时的统计修正：

• 刚发送消息后，发送量会先被统计出来，而接收量是逐步更新的，有时候会出现短期的接收量超过发送量的情况，但等数据完全同步后会恢复正常；
• 而BigQuery的数据通常是更实时、更准确的事件日志，不会有这种临时偏差。

建议的排查步骤 #

• 先核对控制台和BigQuery的统计定义：查看控制台报告的说明，确认「发送量」是请求数还是消息数；在BigQuery里统计MESSAGE_SENT和MESSAGE_RECEIVED的数量，对比控制台数据；
• 检查时间窗口的一致性：确认两者都是使用UTC时间还是本地时间，统计周期是否完全匹配（比如都是按自然日）；
• 在BigQuery里通过message_id分组，查看每个消息的发送和接收情况，确认是否有重复发送或异常接收的情况。

内容的提问来源于stack exchange，提问作者Ivan Ustyugov