DAU WAU MAU怎么看：活跃口径、黏性比率与虚高排查

DAU、WAU、MAU到底在计算什么

更稳妥的通用定义是：在指定时间窗口内，至少触发一次有效活跃事件的去重统计主体数量。

这一定义包含三个必须先确定的变量：

• 有效活跃事件：用户需要完成什么行为，才会进入活跃用户集合。
• 去重统计主体：按登录账号、匿名浏览器、设备、安装实例，还是身份合并后的用户档案计算。
• 时间窗口：采用业务时区内的自然日、自然周、自然月，还是滚动1天、7天、30天。

在三项口径保持一致时，可以写成以下计算方式：

DAU：某个业务自然日内，触发至少一个有效活跃事件的去重用户数。

WAU：截至观察日的连续7个统计日内，触发至少一个有效活跃事件的去重用户数。若使用自然周，应在指标名称或口径说明中明确标注。

MAU：截至观察日的连续30个统计日内，触发至少一个有效活跃事件的去重用户数。若报表按自然月统计，也应与滚动30天MAU区分。

自然月MAU适合月度经营复盘，滚动30天MAU更适合连续观察趋势。两者都可以使用，但不能在同一趋势图中无说明地切换。

DAU、WAU、MAU通常满足DAU不大于WAU、WAU不大于MAU，但这一关系只在活跃条件、身份规则、观察终点和统计范围一致时成立。若DAU按登录账号计算、MAU按设备计算，大小关系便失去检查意义。

活跃口径应该怎样写成可执行规则

“当天使用过产品”不是可以交付给研发和数据团队的指标定义。一个可执行口径必须能够落到事件名称、属性条件、身份字段和排除规则。

企业可以将活跃分成两个层级：

基础访问活跃

基础访问活跃用于观察产品覆盖规模，可以由前台启动、有效页面浏览或互动会话触发。它适合回答“有多少统计主体在这个周期内进入或使用了产品”，但不能直接表示用户完成了核心任务。

核心价值活跃

核心价值活跃需要结合产品用途定义。例如内容产品可使用有效内容消费事件，协作产品可使用创建、编辑或提交事件，学习产品可使用完成学习任务，工具产品可使用执行核心功能。

核心价值事件不是越多越好。若把页面曝光、推送到达、后台保活、定时心跳、异常重试等事件全部列入活跃条件，DAU可能上涨，但业务含义会变弱。

Google Analytics 4对“活跃用户”有自己的产品定义，包括互动会话以及特定首次访问、互动时长或用户互动条件；其“总用户数”则统计指定范围内触发任意事件的唯一用户。该定义适用于GA4报表，不能直接写成所有企业都应采用的行业标准。可参阅Google Analytics用户指标说明。

Amplitude文档中的一种产品规则，是把指定时间范围内记录至少一个事件的用户视为活跃用户。若没有进一步筛选事件，“任意事件”可能包括不能代表主动使用价值的事件。因此，平台默认值可以作为初始观察口径，正式经营指标仍应经过业务评审。可参阅Amplitude活跃用户与用户分群说明。

Firebase Authentication中的DAU、MAU主要出现在认证使用和计费语境，例如按24小时内登录的唯一用户或计费周期内使用账号的用户计算。认证活跃不等于产品功能活跃，不能把登录用户数直接当作内容消费、协作或交易活跃。相关规则见Firebase Authentication官方文档。

在编写口径卡时，至少应记录以下内容：指标名称、指标版本、业务目的、有效活跃事件、排除事件、统计主体、身份优先级、业务时区、窗口类型、迟到数据截止时间和负责人。

底层事件如何触发、生成字段和完成上报，可以结合SDK数据采集与事件埋点进一步核对。活跃指标只是结果，事件字典和身份规则才决定结果能否复现。

DAU/MAU等黏性比率能说明什么

DAU/MAU表示日窗口内的活跃用户占月窗口活跃用户的比例。它回答的是：一批进入月活集合的用户，有多大比例也出现在某一个日窗口中。

DAU/WAU可以观察周活用户在单日出现的频率，WAU/MAU可以观察月活用户是否分布在多个周次。Google Analytics将DAU/MAU、DAU/WAU和WAU/MAU用于用户黏度观察，并将其解释为不同时间窗口内活跃用户之间的比率。该解释依赖GA4自身的活跃定义和滚动窗口规则，详情可查看Google Analytics用户黏度说明。

较高的DAU/MAU通常表示月活用户在日窗口中出现得更频繁，但它不是严格意义上的留存率。留存率通常需要先确定一批在同一时期进入或完成某一行为的用户，再观察这批用户在后续时间是否返回。DAU/MAU没有固定同一批用户作为分母，因此不能替代Cohort留存分析。

DAU/MAU也不能单独证明用户满意度、收入增长或长期价值提高。以下情况都可能让比率上升：

• 产品通过强提醒或强制任务提高打开频率。
• 后台事件、推送到达或自动曝光被纳入活跃口径。
• 大量低价值、高频操作被当作核心活跃行为。
• 月活下降速度快于日活，使比率被动上升。
• 用户身份合并或过滤规则发生变化。

不同产品的自然使用周期也不同。即时通信、内容消费和游戏产品通常更适合持续观察DAU；企业协作、教育和工具类产品可能更关注WAU；旅游、招聘、汽车服务等低频产品可能更适合观察MAU、任务完成率和复访周期。这里是分析选择，不是跨行业评价标准。

“DAU/MAU乘以30等于每月平均活跃天数”也需要限定条件。准确关系应是：30天内每日DAU之和，除以同一窗口内的MAU；也可以表达为30乘以该窗口的平均DAU，再除以MAU。不能只取某一个偶然日期的DAU乘以30，便称为准确的月均活跃天数。

若需要把活跃指标与漏斗、路径、留存和用户分层结合，应转到用户行为分析的完整方法中继续验证，避免让一个黏性比率承担所有业务解释。

DAU突然上涨，怎样判断是不是虚高

指标虚高不是“数字看起来太大”，而是实际计入的用户集合超过了既定业务口径应包含的范围。判断虚高需要证据链，不能只根据经验或业务直觉下结论。

1. 确认指标版本。检查异常日期前后是否调整过活跃事件、用户ID、时区、过滤规则、数据源或报表配置。
2. 拆分事件结构。查看新增活跃主要来自启动、页面浏览、核心业务事件，还是推送到达、后台心跳、自动曝光等非主动行为。
3. 拆分身份类型。比较登录用户、匿名用户、新生成匿名ID、设备ID和安装实例ID的变化。
4. 检查应用版本与环境。判断增长是否集中在某个App版本、开发环境、测试账号、内部员工或自动化测试流量。
5. 检查上报与重试。确认离线补发、缓存重试和批量上报是否生成了新的匿名标识或不稳定的事件ID。
6. 核对时间规则。排查UTC与业务时区混用、自然日与滚动24小时混用、迟到事件集中回补等问题。
7. 用原始事件重算。按照明确的事件白名单、身份规则和时间窗口重新计算，并与报表结果比较。

客户端事件重复上报不一定会直接抬高活跃用户数。只要同一个人的用户ID稳定，重复事件通常仍会被用户级去重。但若重试过程生成了新的匿名ID、设备ID或安装实例ID，一个人就可能被识别成多个活跃用户。

登录状态切换也是常见风险点。用户登录后没有把匿名行为关联到登录账号，可能导致同一人同时以匿名用户和登录用户出现；用户退出后仍保留上一账号的user_id，则可能把后续行为错误归属给原账号。

Google Analytics官方文档说明，User-ID可用于连接同一登录用户在不同会话、设备和平台中的行为，并要求用户退出登录时将User-ID清除。该规则适用于GA4接入，但它说明了一个通用问题：登录、退出和匿名转登录必须有明确的身份状态转换。参阅Google Analytics User-ID接入说明。

Amplitude的身份文档同样显示，设备ID、用户ID和平台内部用户标识之间的合并方式会影响活跃用户计数；身份未正确关联时，同一用户可能被重复计算。该实现属于Amplitude产品规则，但可以作为身份治理风险的说明。参阅Amplitude唯一用户识别说明。

当日数据和近期数据还可能受到处理延迟影响。Google Analytics说明，部分数据处理可能需要24至48小时，迟到数据也可能继续改变历史报表。因此，实时DAU与次日报表不同，不能直接认定SDK丢数或平台虚报。具体见Google Analytics数据新鲜度说明。

用一张矩阵固定活跃口径和虚高证据

下面的“活跃指标口径与虚高排查矩阵”可以作为数据评审、埋点验收和异常复盘的共同模板。表中的字段属于本文建议，不是某个平台的默认配置。

唯一用户数也不一定始终采用绝对精确计数。Google Analytics Data API文档说明，Active Users等唯一计数可能使用HyperLogLog++近似算法，报表还可能受到抽样、数据阈值、查询维度和Reporting Identity影响。该处理方式属于Google Analytics，不能据此推断所有分析系统都采用同一种算法。参阅Google Analytics报表数据预期说明。

若企业采购分析产品或建设自有指标平台，应确认系统能否公开用户去重方式、支持原始事件导出、记录指标版本，并允许按同一口径复算。报表“能够显示DAU”只是基础能力，能否解释数字如何形成才决定它是否适合经营决策。

实施验收不能只检查报表有没有数字

活跃指标上线前，应通过可复现的测试验证事件、身份、时间和过滤规则。至少需要完成以下检查：

• 使用若干脱敏测试账号，核对客户端触发、接收端记录和报表计数是否一致。
• 测试游客访问、登录、退出、再次登录和跨设备登录的身份转换。
• 在业务日界线前后触发事件，检查时区和自然日归属。
• 模拟断网、缓存和重试，确认事件不会因新建匿名ID而增加用户数。
• 确认开发、测试、预发布和生产环境可以隔离。
• 确认内部员工、测试账号、自动化脚本和异常流量具有排除机制。
• 对比界面报表、API结果和数仓查询使用的日期、筛选条件与身份规则。
• 记录数据冻结时间，明确迟到数据是否触发历史重算。

口径变更也必须版本化。只要有效活跃事件、身份合并、业务时区、窗口或过滤规则发生变化，就应记录生效日期、修改原因、旧口径和新口径，并判断是否需要重算历史数据。否则，趋势图中的变化可能来自业务，也可能只是计算规则变化。

当活跃用户进一步用于近7日活跃、近30日沉默或生命周期分层时，还要明确标签更新时间、数据截止时间和互斥规则。相关设计可以结合标签体系与用户画像建模检查，但不应在身份口径尚未稳定时直接生成用户标签。

合规边界与适用范围

DAU、WAU、MAU通常以聚合数字展示，但底层可能包含用户ID、匿名ID、设备标识、事件时间和行为属性。只要这些信息能够单独或结合其他信息识别自然人，就可能进入个人信息处理范围。报表是汇总数据，不代表底层采集自动脱离合规要求。

在企业自有业务场景中采集活跃数据，应具有明确、合理的处理目的，与业务目的直接相关，并控制在最小必要范围。在依法需要用户同意或授权的场景，应完成透明告知和合法授权，同时采取数据脱敏、权限控制、访问日志、保存期限管理和适当安全措施。

《中华人民共和国个人信息保护法》要求个人信息处理具有明确合理目的、与处理目的直接相关，并采取对个人权益影响最小的方式；处理前还应依法告知处理目的、方式、信息种类和保存期限等内容。可参阅《中华人民共和国个人信息保护法》公开文本。

《常见类型移动互联网应用程序必要个人信息范围规定》明确，App运营者不得因为用户不同意提供非必要个人信息，就拒绝其使用基本功能服务。具体业务属于哪一种App类型、哪些信息属于必要信息，需要结合实际功能逐项判断。可参阅常见类型App必要个人信息范围规定。

不得为了提高跨端识别率，默认采集与活跃分析目的没有直接关系的通讯录、精确位置或其他高风险信息。匿名ID也不能被简单描述为“一定不是个人信息”；去标识化与匿名化并不等同，是否仍可识别需要结合实际技术和关联能力判断。

网站自身对信息处理、用户权益和联系渠道的说明，可通过隐私政策与信息保护说明查看。涉及敏感个人信息、未成年人、跨境传输、第三方SDK共享或大规模用户画像时，应由内部法务、个人信息保护负责人、安全和研发团队共同复核。

适用范围与最后核实日期

本文适用于企业自有网站、App、H5、小程序和SaaS产品中的活跃用户指标设计、埋点验收和数据异常排查。它不提供跨行业统一的DAU/MAU优秀值，也不把活跃频率直接解释为留存、满意度、收入或长期价值。

文中涉及Google Analytics、Firebase和Amplitude的内容均为特定产品规则，不是行业统一标准。Google User-ID文档记录的更新时间为2026年6月3日，Google Analytics报表数据预期文档记录的更新时间为2026年4月23日，Firebase Authentication页面记录的更新时间为2026年7月3日。相关动态资料在已核实笔记中的访问日期为2026年7月28日，正式发布前仍应再次查看官方页面。

开始排查DAU、WAU、MAU前，应先准备现行事件字典、活跃事件白名单、身份转换规则、业务时区、异常日期和原始事件查询结果。只有这些条件能够对齐，团队才有基础判断报表变化究竟来自真实使用、运营活动、口径调整还是数据链路异常。