用途
该技能用于回答“为什么用户在某漏斗中转化或流失”这类问题。它通过对比两组人群——完成漏斗最后一步（成功）与未完成（失败）——来寻找与转化或流失相关的事件和用户属性。
主要能力
- 对每个候选事件或属性值构建列联表，计算优势比（odds ratio）。
- 优势比大于 1 表示该信号与转化相关，小于 1 表示与流失相关，偏离 1 越远相关性越强。
- 支持事件相关性分析和用户属性相关性分析两种模式。
- 可报告最显著的转化信号和流失信号及其计数。
- 可通过 query-funnel-actors 或按事件/属性过滤漏斗来查看信号背后的人群。
使用方式
工作流程如下：
- 获取漏斗定义：步骤事件、日期范围和转化窗口。若用户指定已保存的洞察，用 insight-get 读取；用 read-data-schema 确认步骤事件。
- 用 query-funnel 运行漏斗，记录总进入人数和转化人数。SQL 中的总数须在同一范围内，否则先修正步骤过滤条件。
- 用 execute-sql 运行事件相关性查询或属性相关性查询。
- 报告最显著的转化信号和流失信号及计数。
事件相关性查询使用 windowFunnel 识别漏斗步骤，统计从进入到转化（或转化窗口关闭）之间的事件，排除漏斗步骤事件本身。属性相关性查询则按用户属性分组统计。查询中包含 +1 先验以抑制小样本噪声，并过滤掉少于 25 人或少于 2% 进入者的信号。若两组规模相差超过 10 倍，比值可靠性下降，需告知用户。若成功或失败总数为 0，则无可比较内容。全员发送的噪声事件（如 $pageview、$pageleave、$feature_flag_called）可能淹没有用信号，可排除。对于基于组的漏斗，需将 person_id 替换为 $group_N，属性替换为组属性，并在漏斗步骤 WHERE 条件中添加 AND $group_N != ''。
适用场景
适用于需要诊断漏斗转化或流失原因的分析场景，例如产品转化优化、用户行为归因等。
限制
- 相关性不等于因果性，需向用户说明，并建议通过实验验证强信号。
- 小样本或组间规模悬殊时结果不稳定。
- 依赖 PostHog 环境及相应查询工具。
- 更多步骤时，查询仅保留第一步和最后一步事件，中间步骤被忽略，可能导致区间起点早于实际转化尝试的入口。