Article body
正文
以一道模拟问题为例：“二季度新客 30 天复购率是多少？”同一句提问，业务负责人拿到 40%，运营同学算出 35%，数据团队给出 47.5%。这不必然说明谁算错了。三个人可能在算三件不同的事：把各月比例直接平均、把所有客户放在同一分母里，或只纳入已经走完 30 天观察期的客户。数字没有脱离定义独立存在。对 ChatBI 而言，提问能否映射到正确指标只是开始；时间边界、去重实体、分组是否互斥、关联后的行数变化，都决定了结果能不能解释和复核。
先把“复购率”写成可复算的合同
复购率的定义至少要固定五项。第一，新客以什么事件认定，例如首次支付成功，而不是注册、下单或发货。第二，首单发生在哪个入组区间。第三，复购以什么事件认定，例如首单之后发生的第二笔支付成功订单，并明确退款、取消、测试订单是否排除。第四，观察窗口从首单时刻还是自然日开始，窗口右端是否包含。第五，数据截点是什么，距离首单不足 30 天的客户如何处理。
可以用下列业务伪代码把这些选择写清楚。它用于校验口径，不是可直接执行的 HQL 或 SQL。
cohort = 去重(customer_id)，其中 first_paid_at 在入组区间内
eligible = cohort 中 first_paid_at + 30 天 <= data_cutoff_at 的客户
repeaters = eligible 中存在支付成功订单的客户，且
paid_at > first_paid_at 且 paid_at <= first_paid_at + 30 天
rate = 去重计数(repeaters.customer_id) / 去重计数(eligible.customer_id)若 eligible 集合为空，应显示观察期不足或暂无可计算结果，不能把零分母写成 0% 的复购率。这段定义刻意把“首单”与“复购订单”分开。若把首单也放进复购事件集合，任何有首单的客户都会被算成复购。若分子取了所有复购订单，而分母取了新客人数，单位也发生了变化。衡石 v6.2 的 Data Agent 文档建议将复杂、可复用的业务口径预先沉淀为指标，并在描述中写清时间口径、过滤条件与易混淆概念，而不是把关键计算留给单次对话临时拼接。Data Agent 使用指南
一组模拟数据，三种统计结果
下面的数字完全为演示而设。假定统计对象是“首次支付发生在 2025 年二季度的客户”，复购事件是首单后 30 天内的再次支付成功；数据截点为 2025 年 7 月 15 日。4 月和 5 月入组客户已经完成观察；本例另外假定，6 月的 80 位新客全部在 6 月 20 日至 30 日首次支付，因此截至截点均未走完 30 天。这个假定只服务于算例，真实数据要逐位客户判断成熟度，不能按月份整批排除。
| 首单月份 | 新客数 | 截至截点在首单后30天内复购的客户数 | 截至截点已观测比例 | 30 天观察是否完整 |
|---|---|---|---|---|
| 2025 年 4 月 | 120 | 66 | 55% | 是 |
| 2025 年 5 月 | 40 | 10 | 25% | 是 |
| 2025 年 6 月 | 80 | 20 | 25% | 否 |
把三个月的月度比例等权平均，结果是 (55% + 25% + 25%) ÷ 3 = 35%。这回答的是“典型月份的平均比例”，每个月的权重相同。把全部入组客户放入同一集合后再算，结果是 (66 + 10 + 20) ÷ (120 + 40 + 80) = 40%。这回答的是“截至截点，全部二季度新客中已有复购记录的比例”，每位客户权重相同，但 6 月客户的观察时间尚未结束。
若题目承诺的是“30 天复购率”，未完成观察的客户不能和完整观察客户混在同一个分母中。按本例对 6 月首单日期的假定，符合 eligible 条件的只有 4 月和 5 月两批： (66 + 10) ÷ (120 + 40) = 47.5%。这个数既不是把月度比例简单平均，也不是把未成熟 cohort 当作完整结果。它回答的是“截至 7 月 15 日，已完成 30 天观察的二季度新客复购率”。仪表盘、ChatBI 回答和指标描述都应把数据截点与 cohort 成熟规则呈现出来；不然读者会把 40% 误当成最终 30 天结果。
“加权”还有一个常被忽略的前提。按门店、渠道或会员等级汇总时，只有分组内客户集合互斥，才可以把各组去重客户数相加，再算总体比例。如果同一客户在两家门店都购买过，门店分母相加会重复该客户；总体复购率必须回到全局客户集合重新去重。分子同样必须来自这一个入组集合，不能把跨门店复购事件直接累加后再除以去重客户数。
先确认“人”，再确认“单”
复购率通常衡量复购客户占新客客户的比例，分子应该是发生过至少一次符合条件的复购行为的唯一客户。它不等于复购订单数，也不等于每位新客的复购次数。假设一个小 cohort 有 3 位客户：甲在窗口内复购 2 次，乙复购 1 次，丙没有复购。复购客户数为 2，客户复购率为 2 ÷ 3 = 66.7%；复购订单数为 3，除以 3 位新客应得到 1 单/人。把这个比值误写成 100% 的复购率，就把订单频次和客户比例混在了一起。
数据团队应把客户 ID 设为口径里的计数实体，并单独保留复购订单数作为诊断指标。两者一起出现时，读者可以判断“比例升高”来自更多客户开始复购，还是少数客户增加了购买次数。若业务问题关心复购频次，可以另建“人均复购订单数”；不要借用复购率这个名称。衡石文档列出了与重复、留存相关的高级计算能力，但采用哪一种计算仍取决于业务事件、时间窗口和分母的定义。高级计算函数
“指标粒度”与数据行粒度不是同一个概念
排查时常有人说“粒度不一致”，却没有说明是在说数据行，还是指标配置。订单明细表的一行可能代表一个商品行；订单表的一行代表一笔订单；客户 cohort 表的一行应代表一位客户。这是数据行粒度，决定去重和聚合要在哪个实体上发生。复购率若从订单明细直接计数，客户会随着商品行数被重复放大。
衡石产品中的“指标粒度”是另一层配置：它把业务指标的分析维度、时间轴与限定条件集中管理，供指标引用。引用后，粒度变更会同步到引用它的指标；当前文档还说明，粒度仅支持一个数据集，多表业务指标的配置不能用这一方式承载。它便利于复用配置，却不是历史口径的冻结快照，也不会自动隔离旧定义与新定义。指标管理：指标粒度
因此，一项复购指标至少要分别记录两种信息：数据计算在客户、订单还是订单明细层开始；指标配置引用了哪些维度、时间轴和限定条件。前者防止重复计数，后者让分析入口复用相同业务场景。把二者混成一句“按客户粒度算”，很难在结果变化后定位问题。
关联后的六行，不代表六位客户
一对多关联会让另一侧的数据行扩张。设 cohort 表中客户甲只有一行；客户标签表有“新会员”“高潜”两行；甲的一笔复购订单又包含 3 个商品明细。若直接把三张表按客户或订单关联，甲可展开为 2 × 3 = 6 行。此时用行数或非去重的 customer_id 计数，分子和分母都会被放大。它们恰好按同样倍数变化时，比例可能看似正常；不同筛选条件引入不同关联路径时，比例又会突然跳变。
衡石的数据模型把关联条件、关联类型、关联基数和生效机制作为关系配置的一部分。官方说明中，“多”的一侧可能引起另一侧数据膨胀，并且关联基数会影响度量的计算路径。这个机制要求建模者先确认关联键是否唯一、事实表与维表各自的行粒度，以及计算是否需要拆开；它不替代业务人员对复购客户集合的定义。数据模型管理 关联关系描述
- **入组集合：**比较关联前后的去重 customer_id 数。添加标签或商品表后人数变化时，检查关联键、过滤条件和是否应在关联前固化 cohort。
- **复购分子：**并列查看去重复购客户数与复购订单数。两者被当作同一指标时，应按 customer_id 去重，把订单次数另列。
- **关联行数：**检查每位客户关联前后的行数分布。单个客户出现多行且参与汇总时，先聚合事实表，或调整关系与计算层。
- **时间成熟度：**比较 eligible 客户数与全部新客数。近期 cohort 被当成完整窗口时，排除未成熟 cohort，或将结果标为截至截点。
让 ChatBI 给出可校验的回答
ChatBI 不应承担替团队猜定复购口径的责任。衡石的 Data Agent 文档指出，相同输入不保证得到完全相同的响应；问数效果不好时，官方 FAQ 也建议优先完善数据集、字段和指标的命名、描述、知识管理与同义词，再补提示词。Data Agent 的数据准备说明 Data Agent 与 ChatBI FAQ
把“30 天新客复购率”沉淀为指标后，建议在指标描述或数据集知识中写出：首单事件、复购事件、客户主键、窗口边界、退款处理、数据截点、未成熟 cohort 的规则，以及按门店查看时是否允许跨店客户重复。用户在 ChatBI 中追问“按门店看”时，还要明确希望看各门店独立 cohort、互斥归属后的加权结果，还是全局去重客户的归因视图。三个问题的语句接近，分母并不相同。
上线前可用一小组人工可算的数据做回归校验：先按伪代码列出 eligible 客户与 repeaters 客户，再在图表或 ChatBI 中运行相同筛选；接着加入一张一对多表，检查客户数和行数是否发生预期变化；最后移动数据截点，确认未成熟 cohort 的状态与标签同步变化。这类校验不承诺 AI 从此不会误解问题，却能把口径、模型和结果放在同一张检查单上。
**衡石观点：**复购率不是一个等待模型识别的名词，而是一份必须写明客户集合、时间窗口、观察截点和关联路径的计算合同。把合同固化为可复算指标，再让 ChatBI 在清楚的上下文中调用，团队才能解释两个答案为何不同，并决定哪一个回答当前的经营问题。