以下为“活动前（3/01–3/07）访客→注册→下单→支付”漏斗与“活动后（3/08–3/14）各步骤转化率（含渠道拆分）”的对比可视化方案与分析框架。内容包含口径定义、指标计算、图表设计、实现要点与统计标注，确保数据可比、输出清晰并可直接落地。
一、分析目标与对比框架
- 总体目标：评估活动上线后（3/08–3/14）相对活动前（3/01–3/07）在各漏斗步骤的转化改善情况，定位贡献最大的步骤与渠道，并区分由“流量变化”与“转化率变化”带来的支付增长。
- 对比维度：
- 时间：活动前 vs 活动后
- 漏斗步骤：访客→注册→下单→支付（穿越式漏斗）
- 渠道：建议标准化为自然、付费搜索、社媒、联盟、展示/信息流、直达、其他（可与业务现有归因映射一致）
- 输出对象：产品与运营（洞察）、渠道负责人（归因与优化）、数据团队（复核口径）
二、数据口径与计算
1) 事件与去重
- 用户粒度：user_id（未登录阶段可用 device_id+cookie 合并；强建议做跨端合并）
- 事件定义：
- 访客：有效会话开启（排除爬虫与异常流量；如 ≥1 PV 且停留≥N秒）
- 注册：完成账号创建
- 下单：创建订单
- 支付：订单支付成功
- 时间窗：UTC 或业务时区统一；事件归属按事件发生日
2) 渠道归因与会话归并
- 归因规则建议：last non-direct click，回溯窗口7天（与投放团队确认）
- 渠道标准化：使用渠道映射表将 utm/campaign/source/medium 归一
3) 指标与公式
- 步骤转化率（穿越式，建议为主口径）
- CR_step(s→t, period, channel) = distinct_users_t(s→t) / distinct_users_s
- 例如 CR_vis→reg = 注册人数 / 访客人数（同一时间窗内）
- 总体支付转化率：CR_total = 支付人数 / 访客人数
- 流失率：Drop_step = 1 − CR_step
- 环比提升：Lift = (CR_post − CR_pre) / CR_pre
- 贡献拆解（将支付人数变化拆为流量与率的贡献）
- 设 V 为访客，R 为总体转化率（访客→支付），c 为渠道
- ΔPay_total = Σc (V_post,c × R_post,c − V_pre,c × R_pre,c)
- 流量贡献：Σc (ΔV_c × R_pre,c)
- 率的贡献：Σc (V_post,c × ΔR_c)
- 交互项（可归并到率的贡献或单独展示）：Σc (ΔV_c × ΔR_c)
4) 统计稳健性与显著性
- 样本阈值：每步骤、每渠道 n ≥ 200 决定是否展示显著性；低于阈值灰显或聚合为“其他”
- 置信区间：Wilson 区间近似步骤转化率 95% CI
- 显著性检验：两比例 z 检验（pre vs post）；显著用标记符显示（如 ●）
三、可视化设计与布局
A. 总览层（汇总，无渠道）
- 图1：镜像漏斗（Mirror Funnel）
- 左侧：活动前；右侧：活动后。步骤从上到下：访客→注册→下单→支付
- 编码：条宽=人数；右侧同量级轴对齐；标注每步 CR_step 与 Drop_step
- 辅助：在每步中间显示差值条（细）或旁注 Lift%
- 图2：哑铃图（Dumbbell）或坡度图（Slopegraph）对比各步骤转化率
- 横轴=转化率；每步一行，左端为活动前、右端为活动后
- 编码：颜色表示提升/下降（绿色/红色），标注Lift%与显著性符号
B. 渠道层（含拆分）
- 图3：分面漏斗（Small Multiples Funnel）
- 每个渠道一个小漏斗，显示活动前、后两套轮廓（重叠或镜像）
- 用统一量纲轴；在支付端标注该渠道对支付的净贡献ΔPay_c
- 图4：热力矩阵（Heatmap）
- 行=渠道，列=步骤（访客→注册、注册→下单、下单→支付、总体）
- 单元值=Lift%（或后期值−前期值的百分点差）
- 色标：绿色提升、红色下降；右侧显示显著性圆点
- 图5：贡献瀑布图（Waterfall）
- 展示支付人数变化的拆解：基线=活动前支付人数
- 加项1：流量贡献；加项2：转化率贡献；加项3：交互项（可合并）
- 下钻到渠道维度的小瀑布（交互展开）
C. 趋势与稳定性（可选）
- 图6：日粒度趋势线（3/01–3/14）
- 访客、注册、下单、支付人数与 CR_step 的日线
- 活动开始日加竖线标注，便于观察结构性拐点与周末效应
四、交互与信息层级
- 顶部筛选：日期、渠道分组、设备、地域、新老客
- 悬浮提示：展示样本量 n、CR、CI、p 值、基线对比
- 切换：绝对值 vs 归一化（例如按每1,000访客标准化）以利对比
- 异常提示：当样本不足或显著性不达标时自动标记
五、实现要点（示例）
1) 数据结构（聚合后示例字段）
- period ∈ {pre, post}
- channel ∈ {organic, paid_search, social, affiliate, display, direct, other}
- step_counts: visitors, registrations, orders, payments
- derived: cr_vis_reg, cr_reg_ord, cr_ord_pay, cr_total, n, ci_low, ci_high
2) SQL 模板（以 events 表为例）
- 假设 events(user_id, event_time, step, channel_norm)
- step ∈ {visit, register, order, pay}
WITH base AS (
SELECT
user_id,
DATE(event_time) AS dt,
CASE WHEN event_time BETWEEN '2025-03-01' AND '2025-03-07 23:59:59' THEN 'pre'
WHEN event_time BETWEEN '2025-03-08' AND '2025-03-14 23:59:59' THEN 'post' END AS period,
channel_norm AS channel,
MAX(CASE WHEN step='visit' THEN 1 END) OVER (PARTITION BY user_id, channel,
CASE WHEN event_time BETWEEN '2025-03-01' AND '2025-03-07 23:59:59' THEN 'pre'
WHEN event_time BETWEEN '2025-03-08' AND '2025-03-14 23:59:59' THEN 'post' END) AS has_visit,
MAX(CASE WHEN step='register' THEN 1 END) OVER (...) AS has_register,
MAX(CASE WHEN step='order' THEN 1 END) OVER (...) AS has_order,
MAX(CASE WHEN step='pay' THEN 1 END) OVER (...) AS has_pay
FROM events
WHERE event_time BETWEEN '2025-03-01' AND '2025-03-14 23:59:59'
)
, agg AS (
SELECT period, channel,
COUNT(DISTINCT CASE WHEN has_visit=1 THEN user_id END) AS visitors,
COUNT(DISTINCT CASE WHEN has_register=1 THEN user_id END) AS registrations,
COUNT(DISTINCT CASE WHEN has_order=1 THEN user_id END) AS orders,
COUNT(DISTINCT CASE WHEN has_pay=1 THEN user_id END) AS payments
FROM base
WHERE period IN ('pre','post')
GROUP BY period, channel
)
SELECT *,
registrations*1.0/NULLIF(visitors,0) AS cr_vis_reg,
orders*1.0/NULLIF(registrations,0) AS cr_reg_ord,
payments*1.0/NULLIF(orders,0) AS cr_ord_pay,
payments*1.0/NULLIF(visitors,0) AS cr_total
FROM agg;
说明：
- 若需严格“穿越式”，推荐以“上一环节用户集合”为基，或使用事件序列判断先后顺序（避免跨天正逆序）。
- 置信区间与显著性可在 BI 层按二项分布近似计算。
3) ECharts 配置片段示例（哑铃图：步骤转化率前后对比）
option = {
dataset: [{source: data}], // data: [{step:'访客→注册', pre:0.25, post:0.33, significant:true}, ...]
xAxis: { type: 'value', min:0, max:1, axisLabel:{ formatter: v => (v*100).toFixed(0)+'%' } },
yAxis: { type: 'category', inverse:true, axisLabel:{ formatter: v => v } },
tooltip: { trigger:'axis', formatter: p => { const d=p[0].data; return `${d.step}<br/>前: ${(d.pre*100).toFixed(1)}%<br/>后: ${(d.post*100).toFixed(1)}%<br/>提升: ${((d.post-d.pre)/d.pre*100).toFixed(1)}%${d.significant?' ●':''}` } },
series: [
{ type:'line', symbol:'circle', symbolSize:8, data: data.map(d=>[d.pre, d.step]), lineStyle:{ color:'#ccc' } },
{ type:'line', symbol:'circle', symbolSize:8, data: data.map(d=>[d.post, d.step]), lineStyle:{ color:'#ccc' } },
{ type:'custom',
renderItem: (p, api) => {
const y = api.coord([0, api.value(2)])[1];
const x1 = api.coord([api.value(0), 0])[0];
const x2 = api.coord([api.value(1), 0])[0];
return { type:'line', shape:{ x1, y1:y, x2, y2:y }, style:{ stroke: api.value(1)>=api.value(0)?'#2e7d32':'#c62828', lineWidth:3 } };
},
encode: { x:[ 'pre', 'post' ], y:'step' },
data: data.map((d,i)=>({ value:[d.pre, d.post, d.step] }))
}
]
};
4) 可读性与配色
- 颜色：活动后提升用绿色，下降用红色；活动前中性灰；相同类别在各图保持一致
- 数值标注：百分号统一小数位（建议1位）；数值与差值并列显示，避免反复切换
六、对比分析输出要点（使用上述可视化）
- 定位瓶颈步骤：在坡度图中查找下降或提升最小的步骤，结合置信区间判断是否显著
- 识别渠道差异：热力矩阵观察“高提升”渠道与“下降”渠道，优先关注注册→下单和下单→支付两个高杠杆步骤
- 贡献拆解：瀑布图量化总支付增长中，来自流量侧与转化率侧的占比；若率的贡献更大，说明活动素材/权益更有效；若主要由流量驱动，需复核质量与成本
- 异常检查：日趋势中若出现单日剧烈波动，复核投放突增、系统异常或跟踪丢失
七、质量与风险控制
- 统一归因窗口与跨平台去重，避免期前期后口径漂移
- 剔除返挡流量与异常（爬虫、同 IP 高频触发、支付回滚）
- 样本量不足的渠道合并展示，避免误读
- 避免类目激增导致分面拥挤，渠道数>8时采用下钻或TOP-N+其他
八、需要的数据补充清单
- 渠道映射表与归因规则（窗口期、直达处理）
- 事件日志字段定义与去重逻辑（跨端ID策略）
- 活动权益及站内改动清单（用于解释步骤间改善）
- 成本数据（如需进一步做ROI与付费渠道质量分析）
如提供原始聚合数据（按 period×channel×step 的人数与转化率），可基于上述方案输出具体图表与结论，并给出显著性标注与贡献拆解结果。
