Recipe：Active Users

• 官方来源：examples/recipes/active-users
• 核对日期：2026-05-22

这个示例解决什么问题

如何在 Cube 中定义：

• DAU
• WAU
• MAU
• WAU / MAU

而且不用为每种粒度单独准备物化表。

官方示例的核心做法

官方 schema/ActiveUsers.js 基于订单表抽出 user_id 与 created_at，然后定义多个 countDistinct measure，并配合 rollingWindow：

• trailing: 30 day → MAU
• trailing: 7 day → WAU
• trailing: 1 day → DAU

以及一个公式指标：

• wauToMau = weeklyActiveUsers / monthlyActiveUsers

这说明了什么

1. 活跃用户本质上是“滚动窗口去重”

这类指标不是简单的按天 group by count，而是：

在某个时间窗口内，对用户做 distinct count。

2. Cube 可以把窗口定义固化为 measure 语义

这很好，因为上层消费端不必每次重新写复杂 SQL 窗口逻辑。

3. 比值型指标也可以在语义层中定义

WAU/MAU 这种业务指标很适合做成公式 measure，而不是散落在看板公式里。

一个最小理解示例

官方查询文件会同时请求：

• monthlyActiveUsers
• weeklyActiveUsers
• dailyActiveUsers
• wauToMau

并配一个时间范围。

这类查询很适合：

• 用户增长面板
• 社区活跃度分析
• 内容平台参与度分析

迁移到你项目里的建议

适合场景

• 登录活跃用户
• 下单活跃用户
• 发帖活跃用户
• 完成关键事件的活跃用户

注意点

• 明确定义“活跃事件”来源表；
• 确保 user_id 与时间字段质量稳定；
• 去重口径要统一；
• 如果数据量很大，考虑配合时间维度预聚合策略评估性能。

和教程哪章搭配最好

• 编写第一个模型
• 预聚合

一句话总结

这个 recipe 的核心价值是：用 rolling window + distinct count，把 DAU/WAU/MAU 这类常见增长指标变成稳定可复用的语义资产。