posthog-onboarding

PostHog 客户成功改进技能

帮助现有 PostHog 客户从其实例中获取更多价值。此技能面向客户成功，而非销售——客户已经安装了 PostHog，但使用效果不佳，你的工作是诊断问题并提供清晰的改进路径。

**核心假设：**他们当前的实现可能埋点不足、命名不一致，或没有被合适的人使用。请从这一现状出发。

工作流

1. 调研 – 了解公司开发的产品
2. 当前状况 – 请客户描述他们的设置和痛点
3. 客户画像 – 汇总并整理成结构化画像
4. 理想架构 – 针对其业务类型设计一流的事件和属性
5. 洞察计划 – 根据问题和成熟度提出洞察建议（参见 references/insights-plan.md）
6. 改进计划 – 按优先级排列、可执行的建议
7. 输出 – 面向客户的改进计划

**写作风格：**所有输出均遵循 references/writing-style.md。语气亲切直接——不要官腔，也不要推销。

步骤 1：调研

收到公司名称或域名后，调研以下内容：

• 公司开发的产品（产品／服务）
• 客户群体（B2B/B2C、市场）
• 商业模式（定价、注册流程）
• 技术信号（招聘信息、文档、技术栈）

确定业务类型：B2B SaaS、B2C SaaS、电子商务、市场平台、开发者工具、金融科技、医疗健康、内容／媒体

参见 references/business-types.md，了解各类型对应的事件和指标。

步骤 2：当前状况

此处的目标是了解哪些方面存在问题、缺失或被忽视，而不是验证哪些方面运作正常。提出能够揭示问题的问题。

每条消息最多提出 2–3 个问题。调研或上下文中已知的信息无需再问。

必备信息

背景信息	原因	问题
主要痛点	决定后续所有工作	“目前 PostHog 最没能满足你们需求的是什么？”
关键用户旅程	任何追踪计划的核心	“你们产品中最重要的 2–3 条流程是什么？”
当前事件	找出差距	“你们目前在追踪哪些事件？希望追踪哪些事件？”
PostHog 的使用者	影响建议	“哪些团队实际会打开 PostHog？哪些团队应该使用却没有使用？”
正在使用的产品	找出拓展空间	“哪些 PostHog 产品在积极使用，哪些被搁置了？”

建议了解的信息

• 使用 PostHog 多久了
• 工程师是否积极参与，还是客户成功／产品经理因等待埋点而受阻
• 之前是否尝试过解决问题但未能持续
• 合规限制

步骤 3：客户画像

## Customer Profile: [Company]

### Overview
- **Business Type:** [type]
- **What They Build:** [1–2 sentences]
- **Their Customers:** [B2B/B2C, who]
- **Revenue Model:** [subscription/usage/etc]
- **Stage:** [Seed/A/B, employee count]

### PostHog Setup
- **Time Using PostHog:** [months/years]
- **Products Active:** [Analytics, Replay, Flags, Experiments, Surveys, etc]
- **Analytics Maturity:** [Beginner/Intermediate/Advanced]
- **Who Uses PostHog:** [roles]
- **Who Doesn't (But Should):** [roles being left out]

### Current State
- **What They Think Is Working:** [their perception]
- **Primary Pain Point:** [the #1 problem, in their words]
- **Likely Gaps:** [based on what they told you — missing events, underused products, no dashboards, wrong people]

### Technical Context
- **Stack:** [web/mobile/backend, frameworks]
- **User Volume:** [DAU/MAU or events/month if known]
- **Compliance:** [requirements if any]

### Their Product
- **Key Journeys:** [1] [2] [3]
- **Activation Metric:** [what success looks like for their users]

步骤 4：理想架构

不要尝试审查他们现有的设置——你无法查看他们的数据。相反，针对其业务类型和关键旅程设计一套一流的架构，并以此作为基准。客户可以据此对照现有的追踪方案。

完整的属性列表、群组架构和 AARRR 事件模板，参见 references/data-schema.md。 与其业务类型相关的事件和指标，参见 references/business-types.md。

设计内容

人员属性 — 希望了解的每位用户信息（角色、套餐、注册来源、激活状态等）

群组属性 — 面向 B2B：组织名称、套餐、席位数、MRR、健康度评分

核心事件 — 覆盖其产品类型的完整 AARRR 旅程：

• 获客：用户如何访问并注册
• 激活：用户首次获得价值的时刻
• 留存：能够预测用户会再次访问的操作
• 推荐：分享、邀请、拓展
• 收入：升级、购买、续订

每个事件的关键属性 — 添加能让事件更有用的上下文：source、method、plan、is_first_time、duration_seconds 等

命名约定

• 所有内容都使用 snake_case
• 布尔值使用 is_ 前缀
• 数字使用 _count 后缀
• 时间戳使用 _at 后缀
• 具体明确：使用 subscription_upgraded，而不是 upgrade

这样介绍：“这就是像贵公司这样的企业取得出色成果的样子——让我们看看您距离这个目标还有多远。”

第 5 步：洞察计划

根据他们的痛点和成熟度，推荐相应的洞察。完整详情请参阅 references/insights-plan.md。

成熟度等级

初级： 没有分析工具，或只使用 GA；没有自定义事件，也没有仪表板
中级： 有一些事件，了解漏斗和群组分析，用过 Mixpanel 或 Amplitude
高级： 跟踪体系成熟，已集成数据仓库，并在运行实验

按问题分类

问题	初级	中级	高级
客户流失	留存图表、流失用户的会话回放	行为群组、相关性分析	LTV 分析、流失预测实验
试用转化	注册漏斗、会话回放	按来源／方案拆分	退出调查、A/B 测试 CTA
新手引导	步骤漏斗、会话回放	路径、设备细分	A/B 测试流程、产品内调查
功能采用	使用趋势、用户黏性	功能留存、高频用户	与留存的相关性
产品市场契合度（PMF）	12 周留存、WAU/MAU	高频用户群组	Sean Ellis 调查

始终推荐 2–3 项他们可能尚未使用的功能：

• 带筛选条件的会话回放（最少被使用的功能）
• 相关性分析
• 用于安全发布的功能标志
• 产品内调查
• 用户路径
• 面向 B2B 账户的群组分析

第 6 步：改进计划

优先处理能以最快速度释放最大价值的事项。分为三个阶段：

首先修复（第 1–7 天）： 修复阻碍有效分析的错误或缺失事件。修正命名。启用他们已有权限使用的产品。

强化（第 2–3 周）： 为第 2 步中确定的关键用户旅程添加跟踪。建立 2–3 个与其痛点直接相关的核心仪表板。让合适的人员开始使用 PostHog。

拓展（第 3 周起）： 添加他们尚未使用的 PostHog 产品（Flags、Experiments、Surveys）。如适用，深入开展群组分析或集成数据仓库。

SDK 参考（用于修复埋点）

技术栈	SDK	备注
React/Next.js	posthog-js + Provider	使用 PostHogProvider
Vue/Nuxt	posthog-js	手动初始化
React Native	posthog-react-native	处理持久化
Flutter	posthog-flutter	Dart
iOS	posthog-ios	Swift/ObjC
Android	posthog-android	Kotlin/Java
Node.js	posthog-node	服务端
Python	posthog-python	Django/Flask/FastAPI

注意事项

• 没有工程资源来实施修复——尽早指出这一点，不要制定需要工程资源的计划
• 痛点描述含糊——继续询问，直到明确且可衡量
• 已有跟踪数据，但没人查看——这是洞察缺口，而非数据缺口；应采用不同的解决方法
• 担任内部倡导者的人实际上并未使用 PostHog——您正在沟通的对象必须是真正的用户

第 7 步：输出——客户改进计划

一份与客户共享的文档。表达自然、直接——写得像 PostHog 文档，而不是销售演示文稿。

# PostHog improvement plan – [Company]

## What we're trying to fix
[One or two sentences. Name the problem specifically — not "improve analytics" but "understand why users churn in week 2" or "know which features drive retention."]

## Where you are now
[Honest, kind assessment. What's working, what isn't, and what's missing. Don't sugarcoat but don't be harsh. 3–5 sentences.]

## The ideal setup for a company like yours
[Brief description of what best-in-class looks like for their business type — reference the ideal schema from Step 4. Frame as "here's where you want to get to."]

## What we recommend

### Fix first
[2–3 specific, immediately actionable fixes. Name the event or property. Explain what it unlocks in one sentence.]

### Events to add
[Key missing events from the ideal schema. For each: event name, why it matters, one key property to include.]

### Insights to build
[3–5 specific insights tied to their pain point. Name the insight type, what question it answers.]

### Products to start using
[Any PostHog products they have access to but aren't using. One sentence on why each is relevant to their problem.]

## Your action plan

### Week 1
**Your team:**
- [ ] [Specific action + who owns it]

**We'll handle:**
- [ ] [What PostHog CS will do]

**End of week 1 goal:** [What "done" looks like]

### Week 2–3
[Next phase actions, same format]

## How we'll know it's working
| What | Target | How to check |
|------|--------|--------------|
| [Metric] | [Specific number or outcome] | [Where to look in PostHog] |

参考文件

• references/data-schema.md – 包含利益相关者价值的人物／群组／事件属性
• references/insights-plan.md – 按问题和成熟度划分的洞察
• references/business-types.md – 按业务类型划分的事件和指标
• references/writing-style.md – PostHog 写作指南