Odoo 企业版 Cohort 为什么不是“一张留存热力图”：retention/churn、timeline 方向与 drilldown 主链路讲透

Cohort 视图乍看像一张带颜色的表：首列是某批用户/记录，后面是第 1 周、第 2 周、第 3 周的留存率或流失率。但企业版的关键并不在“画出颜色块”，而在把一组统计口径稳定地变成可点击、可 drilldown 的交互模型。

主要参考：

• enterprise/web_cohort/models/models.py
• enterprise/web_cohort/static/src/cohort_model.js
• enterprise/web_cohort/static/src/cohort_controller.js
• enterprise/web_cohort/static/src/cohort_renderer.js

一、前端显示的每个 cell，后端都已经算好了含义

get_cohort_data() 返回的不是简单二维数组，而是每个 cell 对应的：

• value
• percentage
• domain
• period
• retention / churn 口径下的衍生值

这意味着前端不是自己在浏览器里“再算一遍留存率”，而是接住后端已经解释好的 cohort 数据，再负责展示与交互。

二、retention 与 churn 不只是换个标题，而是口径翻转

源码里同一个基础数据，会根据 mode 决定展示留存还是流失。前端切换模式后，用户看到的不只是颜色方向变化，而是整个百分比定义被反转。

这很重要，因为若你在自定义里只改标题、不改 cell 解释，图表就会看起来“能用”，但业务含义完全错了。

三、timeline 的 forward / backward 是 Cohort 难点之一

Cohort 不是只看“从起始批次向后看 16 格”。在 backward 模式下，系统会对初始值和窗口外数据做专门处理，确保回溯视角下的比例仍然成立。

很多人第一次做类似视图时，只会写 forward 版本，结果 backward 一开就全乱。官方把这部分复杂度放在后端模型里，前端只负责忠实消费它。

四、drilldown 的关键在于 cell 自带 domain

每个 cell 都带 domain，这使得前端点击某一格时，不需要重新“猜这格代表什么记录”，而是直接拿 domain 去打开明细。

这是一种很典型的 Odoo 视图设计哲学：统计视图不只负责看，还要能回到底层记录。没有 domain，这张热力图就只是图片；有了 domain，它才是交互式分析工具。

五、实战里最该注意的地方

1. 不要在前端重复定义业务口径

Cohort 的口径计算已经很重，特别是 backward 和 churn。最稳的是复用后端输出，不要自己在 JS 再算一遍。

2. interval 与格式化不是纯展示问题

day/week/month/quarter/year 不只是标题格式不同，时间窗口切分方式也不同。前端若只改 label，不尊重后端 period 与 domain，会把 drilldown 弄错。

3. 可点击性来自 domain，不来自 cell 位置

不要用“第 N 行第 M 列”去推测含义。真正可信的是 cell 自带的 domain 与 period。

六、结论

Cohort 视图的前端价值，不在于把颜色渲染得多漂亮，而在于它把 retention/churn、forward/backward 和 cell drilldown 组合成了一套分析闭环。

所以它不是静态热力图，而是一张能回到业务事实的交互式时间分析视图。