最小产品分析栈：漏斗、留存与回放的起步配置

B 方向·OPC 最佳实践（仪器维度）。indie-pricing-models 说「验证窗口 1-2 个月、转化 <5% 先改付费墙」——但没说用什么量。本篇补测量仪器。

背景与问题

solo 的产品分析最少装什么？怎么不违反 APPI（产品处理银发敏感数据）？

发现

• PostHog 免费档够用到很晚：每月 100 万事件、漏斗/留存/回放/feature flags 全包含、无限成员、免信用卡（官方定价）；免费档实际覆盖约 5,000 MAU 级产品（Solopreneur Analytics Stack 2026）；超限后按总事件计费涨得快，中等流量可能 $100+/月（Sleek indie 指南）。
• 最小配置套路（社区共识）：autocapture 一行装完 → 定义一个激活假设 → 建一个核心漏斗 → 看 5-10 条会话回放验证 → 跟踪一个留存 cohort（PostHog 漏斗文档、GrowthBook 免费工具综述、PostHog 装后指南）。
• 替代品：Plausible/Fathom（隐私优先、只做 web 分析无漏斗回放）；自托管 OpenPanel——日本 APPI 敏感数据场景下「数据不出境/自托管」有额外价值【推测：与 japan-appi-data-compliance 的最小化原则一致】。

推测

• 本产品线的分析对象特殊：老人端（LINE OA 内）无法埋点传统 web 事件——分析重心在子女端 web（漏斗：LP→注册→绑 LINE→付费）+ LINE 侧用「消息送达/点击/回复」原生统计近似替代。
• Session replay 对银发产品是双刃剑：回放里会出现老人健康/财务信息——必须开 masking（输入框遮蔽），否则自己制造 APPI 风险。

结论

可行动启发：

1. 默认栈定案：子女端 web = PostHog 免费档（autocapture + 3 个自定义事件：signup/activated/paid）；LINE 端 = Messaging API 原生统计；不动 Plausible（无漏斗需求不双装）。
2. 一个漏斗原则：只建「LP → 注册 → 绑定 LINE → 首付」一条核心漏斗，每周看一次；多于一个漏斗=没想清楚激活假设。
3. 回放必开 masking + 频次上限（每周固定看 5 条，进 opc-ai-automation-2026 的周例程）；隐私政策补一条分析工具披露（japan-appi-data-compliance 五件套联动）。
4. 事件额度监控：finance dashboard（opc-finance-dashboard）加一行「PostHog 月事件数」，接近 100 万再谈付费或裁事件——不预先优化。

待办 / 下次继续

• 首个产品上线时执行：PostHog 装 autocapture + masking 配置截图存档（SOP 化）。
  
• LINE OA 统计指标（送达/点击/回复率）导出到 finance dashboard 的方式确认。
  

关联

• 仪器层服务 indie-pricing-models（验证窗口测量）、opc-churn-retention-playbook（留存指标源）、opc-finance-dashboard（月度指标行）。