posthog-onboarding

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PostHog CS Improvement Skill

PostHog 客户成功改进技能

Help existing PostHog customers get more value from their instance. This skill is for Customer Success, not sales — the customer already has PostHog installed, something isn't working well, and your job is to diagnose the gaps and give them a clear path forward.

Core assumption: Their current implementation is probably underinstrumented, inconsistently named, or not being used by the right people. Start from that baseline.

帮助现有PostHog客户从其实例中获取更多价值。本技能面向客户成功团队，而非销售团队——客户已安装PostHog，但部分功能运行不佳，你的工作是诊断缺口并为他们提供清晰的改进路径。

核心假设： 他们当前的实施可能存在埋点不足、命名不一致或未被正确人员使用的问题。以此为基线展开工作。

Workflow

工作流程

Research – Understand what the company builds
Current State – Ask the customer to describe their setup and pain points
Customer Profile – Synthesize into a structured profile
Ideal Schema – Design best-in-class events and properties for their business type
Insights Plan – Prescribe insights by problem + maturity (see
```
references/insights-plan.md
```
)
Improvement Plan – Prioritized, actionable recommendations
Output – Customer-facing improvement plan

Writing Style: Follow

references/writing-style.md

for all outputs. Conversational and direct — not corporate, not salesy.

调研 – 了解该公司的业务内容
当前状态 – 请客户描述他们的设置情况和痛点
客户档案 – 将信息整合为结构化档案
理想Schema – 为其业务类型设计一流的事件和属性
洞察计划 – 根据问题和成熟度制定洞察方案（详见
```
references/insights-plan.md
```
）
改进计划 – 优先级明确、可执行的建议
输出 – 面向客户的改进计划

写作风格： 所有输出需遵循

references/writing-style.md

的要求。风格要口语化、直接——避免企业腔和销售话术。

Step 1: Research

步骤1：调研

When triggered with a company name or domain, research:

What they build (product/service)
Their customers (B2B/B2C, market)
Business model (pricing, signup flow)
Tech signals (job postings, docs, stack)

Determine business type: B2B SaaS, B2C SaaS, E-commerce, Marketplace, Developer Tools, Fintech, Healthcare, Content/Media

See

references/business-types.md

for events and metrics by type.

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

他们的业务内容（产品/服务）
客户群体（B2B/B2C、目标市场）
商业模式（定价、注册流程）
技术信号（招聘信息、文档、技术栈）

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

详见

references/business-types.md

中按业务类型划分的事件和指标。

Step 2: Current State

步骤2：当前状态

The goal here is to understand what's broken, missing, or ignored — not to validate what's working. Ask questions that surface problems.

Ask 2–3 questions max per message. Skip anything already known from research or context.

此步骤的目标是了解哪些功能损坏、缺失或被忽略——而非验证哪些功能正常运行。提出能暴露问题的问题。

每条消息最多问2-3个问题。跳过从调研或上下文已获知的内容。

Must-Have

必问内容

Context	Why	Question
Primary pain point	Drives everything	"What's the #1 thing PostHog isn't giving you right now?"
Key user journeys	Core of any tracking plan	"What are the 2–3 most important flows in your product?"
Current events	Identifies gaps	"What events are you tracking today? What do you wish you were tracking?"
Who uses PostHog	Shapes recommendations	"Which teams actually open PostHog — and which ones should but don't?"
Products in use	Finds expansion areas	"Which PostHog products are you actively using vs. ignoring?"

背景信息	原因	问题
首要痛点	引导所有工作	“目前PostHog无法满足你的核心需求是什么？”
关键用户旅程	任何跟踪计划的核心	“你的产品中最重要的2-3个用户流程是什么？”
当前跟踪事件	识别缺口	“你目前正在跟踪哪些事件？你希望跟踪哪些事件？”
PostHog使用者	影响建议方向	“哪些团队实际使用PostHog——哪些团队应该使用但并未使用？”
已使用的产品	发现拓展空间	“你正在积极使用哪些PostHog产品，哪些被忽略了？”

Should-Have

可选内容

How long they've had PostHog
Whether engineers are engaged or if CS/PM are blocked waiting for instrumentation
Any previous attempts to fix the problem that didn't stick
Compliance constraints

使用PostHog的时长
工程师是否参与，或是客户成功/产品经理因等待埋点而受阻
之前尝试解决问题但未成功的任何方案
合规限制

Step 3: Customer Profile

步骤3：客户档案

markdown

undefined

markdown

undefined

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]

业务类型： [类型]
业务内容： [1-2句话描述]
客户群体： [B2B/B2C、具体群体]
收入模式： [订阅/使用量计费等]
发展阶段： [种子轮/A轮/B轮、员工数量]

PostHog Setup

PostHog设置情况

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]

使用时长： [月/年]
活跃产品： [Analytics、Replay、Flags、Experiments、Surveys等]
分析成熟度： [初级/中级/高级]
使用者： [角色]
应使用但未使用的团队： [被遗漏的角色]

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]

技术栈： [Web/移动/后端、框架]
用户规模： [日活/月活或已知的月事件量]
合规要求： [如有相关要求]

Their Product

产品信息

Key Journeys: [1] [2] [3]
Activation Metric: [what success looks like for their users]

undefined

关键用户旅程： [1] [2] [3]
激活指标： [用户成功的判定标准]

undefined

Step 4: Ideal Schema

步骤4：理想Schema

Don't try to audit what they have — you don't have visibility into their data. Instead, design the best-in-class schema for their business type and key journeys, then use it as a benchmark. The customer can map their current tracking against it.

See

references/data-schema.md

for full property lists, group schemas, and AARRR event templates. See

references/business-types.md

for events and metrics specific to their business type.

不要尝试审计他们现有数据——你无法查看其数据详情。相反，为他们的业务类型和关键用户旅程设计一流的Schema，以此作为基准。客户可将其当前跟踪情况与此基准对比。

详见

references/data-schema.md

获取完整的属性列表、群组Schema和AARRR事件模板。详见

references/business-types.md

获取针对其业务类型的事件和指标。

What to design

设计内容

Person properties — what you'd want to know about every user (role, plan, signup source, activation status, etc.)

Group properties — for B2B: org name, plan, seat count, MRR, health score

Core events — cover the full AARRR journey for their product type:

Acquisition: how users arrive and sign up
Activation: the moment they first get value
Retention: the actions that predict they'll come back
Referral: sharing, inviting, expanding
Revenue: upgrade, purchase, renewal

Key properties on each event — include context that makes the event useful:

source

method

plan

is_first_time

duration_seconds

, etc.

用户属性 —— 你需要了解的每个用户的信息（角色、套餐、注册来源、激活状态等）

群组属性 —— 针对B2B客户：组织名称、套餐、席位数量、月度经常性收入（MRR）、健康评分

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

获取（Acquisition）：用户如何到达并注册
激活（Activation）：用户首次获得价值的时刻
留存（Retention）：预示用户将返回的行为
推荐（Referral）：分享、邀请、拓展
收入（Revenue）：升级、购买、续费

每个事件的关键属性 —— 包含使事件更具价值的上下文信息：

source

、

method

、

plan

、

is_first_time

、

duration_seconds

等

Naming conventions

命名规范

```
snake_case
```
for everything
```
is_
```
prefix for booleans
```
_count
```
suffix for numbers
```
_at
```
suffix for timestamps
Be specific:
```
subscription_upgraded
```
not
```
upgrade
```

Present this as: "Here's what great looks like for a company like yours — let's figure out how close you are."

所有名称使用
```
snake_case
```
格式
布尔值以
```
is_
```
为前缀
数值以
```
_count
```
为后缀
时间戳以
```
_at
```
为后缀
命名要具体：例如使用
```
subscription_upgraded
```
而非
```
upgrade
```

表述方式：“这是与你同类型公司的最佳实践——我们来看看你的当前情况距离这个标准有多远。”

Step 5: Insights Plan

步骤5：洞察计划

Prescribe insights based on their pain point and maturity. See

references/insights-plan.md

for full detail.

根据客户的痛点和成熟度制定洞察方案。详见

references/insights-plan.md

获取详细内容。

Maturity Levels

成熟度等级

Beginner: No analytics or just GA, no custom events, no dashboards Intermediate: Some events, knows funnels/cohorts, has used Mixpanel or Amplitude Advanced: Mature tracking, warehouse integration, running experiments

初级： 无分析能力或仅使用GA，无自定义事件，无仪表盘 中级： 有部分事件，了解漏斗/群组分析，曾使用Mixpanel或Amplitude 高级： 成熟的跟踪体系，数据仓库集成，正在运行实验

By Problem

按问题分类

Problem	Beginner	Intermediate	Advanced
Churn	Retention chart, replays of churned users	Behavioral cohorts, correlation analysis	LTV analysis, churn prediction experiments
Trial conversion	Signup funnel, replays	Breakdown by source/plan	Exit surveys, A/B test CTAs
Onboarding	Step funnel, replays	Paths, device breakdown	A/B test flows, in-product surveys
Feature adoption	Usage trends, stickiness	Feature retention, power users	Correlation with retention
PMF	12-week retention, WAU/MAU	Power user cohorts	Sean Ellis survey

Always suggest 2–3 capabilities they're probably not using:

Session Replay with filters (most underused)
Correlation analysis
Feature flags for safe rollouts
In-product surveys
User paths
Group analytics for B2B accounts

问题	初级	中级	高级
用户流失	留存图表、流失用户的会话重放	行为群组分析、相关性分析	用户生命周期价值（LTV）分析、流失预测实验
试用转化	注册漏斗、会话重放	按来源/套餐细分	退出调查、CTA按钮A/B测试
新用户引导	步骤漏斗、会话重放	用户路径、设备细分	引导流程A/B测试、产品内调查
功能采用	使用趋势、粘性分析	功能留存、核心用户分析	与留存的相关性分析
产品市场契合度（PMF）	12周留存率、周活/月活比	核心用户群组	Sean Ellis调查

始终建议2-3个他们可能未使用的功能：

带筛选条件的Session Replay（最未被充分利用的功能）
相关性分析
用于安全发布的Feature Flags
产品内调查
用户路径
针对B2B客户的群组分析

Step 6: Improvement Plan

步骤6：改进计划

Prioritize by what unblocks the most value fastest. Frame as three phases:

Fix first (Days 1–7): Broken or missing events that are blocking any meaningful analysis. Naming fixes. Enabling products they already have access to.

Strengthen (Week 2–3): Add tracking for key journeys identified in Step 2. Build 2–3 core dashboards tied directly to their pain point. Get the right people in PostHog.

Expand (Week 3+): Add PostHog products they're not using (Flags, Experiments, Surveys). Deepen with group analytics or warehouse if relevant.

按“最快解锁最大价值”的优先级排序。分为三个阶段：

优先修复（第1-7天）： 阻碍有意义分析的损坏或缺失事件。命名规范修复。启用已有权限但未使用的产品。

强化阶段（第2-3周）： 为步骤2中识别的关键用户旅程添加跟踪。构建2-3个与核心痛点直接相关的核心仪表盘。让正确的人员开始使用PostHog。

拓展阶段（第3周后）： 添加未使用的PostHog产品（Flags、Experiments、Surveys）。如有需要，深化群组分析或数据仓库集成。

SDK reference (for instrumentation fixes)

SDK参考（用于埋点修复）

Stack	SDK	Notes
React/Next.js	`posthog-js` + Provider	Use `PostHogProvider`
Vue/Nuxt	`posthog-js`	Manual init
React Native	`posthog-react-native`	Handles persistence
Flutter	`posthog-flutter`	Dart
iOS	`posthog-ios`	Swift/ObjC
Android	`posthog-android`	Kotlin/Java
Node.js	`posthog-node`	Server-side
Python	`posthog-python`	Django/Flask/FastAPI

技术栈	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

Watch-outs

注意事项

No engineering bandwidth to implement fixes — flag this early, don't build a plan that requires it
Pain point is vague — keep asking until it's specific and measurable
Tracking exists but no one looks at it — this is an insights gap, not a data gap; solve differently
The champion isn't actually using PostHog — whoever you're talking to needs to be a real user

无工程师带宽实施修复——尽早标记此问题，不要制定需要工程师参与的计划
痛点模糊——持续追问直到问题具体且可衡量
已有跟踪但无人查看——这是洞察缺口，而非数据缺口；需采用不同解决方案
对接人并非PostHog实际使用者——你沟通的对象必须是真正的用户

Step 7: Output — Customer Improvement Plan

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

One document, shared with the customer. Conversational and direct — written like a PostHog doc, not a sales deck.

markdown

undefined

一份共享给客户的文档。风格口语化、直接——采用PostHog文档的风格，而非销售演示文稿。

markdown

undefined

PostHog improvement plan – [Company]

PostHog改进计划 – [公司名称]

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."]

[1-2句话。明确指出具体问题——不是“改进分析”，而是“了解用户为何在第2周流失”或“明确哪些功能驱动用户留存”。]

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.]

[诚实、友好的评估。哪些部分有效，哪些无效，哪些缺失。不要粉饰但也不要过于尖锐。3-5句话。]

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."]

[简要描述同类型公司的最佳实践——参考步骤4中的理想Schema。表述为“这是你需要达到的目标”。]

What we recommend

我们的建议

Fix first

优先修复

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

[2-3个具体、可立即执行的修复措施。明确事件或属性名称。用一句话说明其能解锁的价值。]

Events to add

需要添加的事件

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

[理想Schema中缺失的关键事件。每个事件需包含：事件名称、重要性、需包含的一个关键属性。]

Insights to build

需要构建的洞察

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

[3-5个与核心痛点相关的具体洞察。明确洞察类型、能解答的问题。]

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.]

[已有权限但未使用的PostHog产品。用一句话说明每个产品与当前问题的相关性。]

Your action plan

你的行动计划

Week 1

第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]

你的团队：

[具体行动 + 负责人]

我们将负责：

[PostHog客户成功团队的工作内容]

第1周目标： [“完成”的判定标准]

Week 2–3

第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]

undefined

指标	目标	查看位置
[指标名称]	[具体数值或结果]	[PostHog中的查看路径]

undefined

Reference Files

参考文件

```
references/data-schema.md
```
– Person/group/event properties with stakeholder value
```
references/insights-plan.md
```
– Insights by problem and maturity
```
references/business-types.md
```
– Events and metrics by business type
```
references/writing-style.md
```
– PostHog writing guidelines

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