Umami

Umami 是开源、重视隐私的网站分析平台，可使用云服务或自行部署。除页面浏览、来源、设备与地区统计外，它还提供自定义事件、Goals、Funnel、Journey、Retention、Revenue、Attribution 及会话回放。要得到可行动结论，先定义业务事件，再用漏斗找出流失位置，最后才用路径或回放解释原因。

先把业务动作变成稳定事件

页面浏览会自动采集，注册、加入购物车或购买完成等动作需要一致的事件名。例如在成功完成注册后发送 signup，在支付确认后发送 purchase-complete；不要在按钮点击时提前记录“购买完成”。事件可附带计划类型、收入和币种等属性，但属性命名一旦混乱，后续 Breakdown 和 Revenue 就会被拆成多个口径。

用注册路径建立一条可验收漏斗

Funnel 支持 2–7 个顺序步骤，并可设置相邻步骤允许的时间窗口。运行后会显示每一步用户数、步间流失率和整体转化率。若某一步流失接近 100%，先在实时数据中亲自触发事件并确认事件名，而不是立即归因于页面设计；若考虑周期较长，再扩大时间窗口。

Journey 与 Replay 回答不同问题

Journey 用 3–7 个步骤探索用户从某个页面或事件如何前进、在哪里退出，适合发现预设漏斗之外的路径。Replay 则还原点击、滚动、导航和表单交互；表单输入默认遮蔽，但开启前仍应核对遮蔽级别、排除选择器和隐私告知。回放只记录启用后的会话，不会补录历史数据，官方文档说明普通回放保留 30 天。

团队共享前先固定数据范围

Umami 可以把网站归入 Team 并给成员协作访问，也能通过 shareId 创建共享地址。共享报表前先确认网站、时间范围和事件属性中没有客户标识或内部路径；需要跨站点汇总时保持时区、事件名和 UTM 命名一致。自托管并不自动等于安全，后台账户、数据库连接、备份文件和公开分享链接都需要单独控制。

修复后用 Compare 验证变化

1. 记录改动前漏斗各步人数和最大流失点。
2. 抽查相应 Journey 或回放，形成一个可验证假设。
3. 只修改一个主要障碍，例如表单错误提示或价格页入口。
4. 在相同时间窗口、来源和设备条件下运行 Compare。
5. 确认转化变化不是事件漏发、机器人或流量结构变化造成。

自托管可以控制数据位置，但数据库备份、升级、邮件、反向代理和访问权限也由自己负责。启用会话回放还会扩大数据和存储范围，应按实际需要设置采样率、遮蔽级别、最大时长与排除元素，不把全量录制当作默认。入口：https://umami.is/