solo-metrics-track

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/metrics-track

Set up a metrics tracking plan for a project. Defines PostHog event funnel, KPI benchmarks, and kill/iterate/scale decision thresholds based on lean startup principles.

为项目设置指标跟踪计划。基于精益创业原则定义PostHog事件漏斗、KPI基准以及终止/迭代/扩展的决策阈值。

MCP Tools (use if available)

MCP工具（如有可用请使用）

```
kb_search(query)
```
— find PostHog methodology, analytics patterns

If MCP tools are not available, fall back to Grep + Read.

```
kb_search(query)
```
— 查找PostHog方法、分析模式

如果MCP工具不可用，回退使用Grep + Read。

Methodology Reference

方法参考

This skill implements metrics tracking based on lean startup principles:

Relative metrics vs niche benchmarks — compare against your own trajectory, not vanity averages
Kill/iterate/scale decision rules — data-driven thresholds for product decisions (see step 7 below)

此技能基于精益创业原则实现指标跟踪：

相对指标 vs 细分领域基准 — 与自身发展轨迹对比，而非虚荣的行业平均值
终止/迭代/扩展决策规则 — 基于数据的产品决策阈值（见下文第7步）

Steps

步骤

Parse project from
```
$ARGUMENTS
```
.
- Read PRD for features, ICP, monetization model.
- Read CLAUDE.md for stack (iOS/Web/both).
- If empty: ask via AskUserQuestion.
Detect platform:
- iOS app → PostHog iOS SDK events
- Web app → PostHog JS SDK events
- Both → cross-platform identity (shared user ID across platforms)
Load PostHog methodology:
- If MCP available:
```
kb_search("PostHog analytics events funnel identity")
```
- Otherwise: check project docs for existing analytics configuration
- Extract: event naming conventions, identity resolution, funnel pattern

Define event funnel based on PRD features:

Standard funnel stages (adapt per product):

Awareness → Acquisition → Activation → Revenue → Retention → Referral

Map to concrete events:

Stage	Event Name	Trigger	Properties
Awareness	`page_viewed`	Landing page visit	`source` , `utm_*`
Acquisition	`app_installed` or `signed_up`	First install/signup	`platform` , `source`
Activation	`core_action_completed`	First key action	`feature` , `duration_ms`
Revenue	`purchase_completed`	First payment	`plan` , `amount` , `currency`
Retention	`session_started`	Return visit (D1/D7/D30)	`session_number` , `days_since_install`
Referral	`invite_sent`	Shared or referred	`channel` , `referral_code`

Forced reasoning — metrics selection: Before defining KPIs, write out:
- North Star Metric: The ONE number that matters most (e.g., "weekly active users who completed core action")
- Leading indicators: What predicts the North Star? (e.g., "activation rate D1")
- Lagging indicators: What confirms success? (e.g., "MRR", "retention D30")
- Vanity metrics to AVOID: (e.g., total downloads without activation)

Set KPI benchmarks per stage:

KPI	Target	Kill Threshold	Scale Threshold	Source
Landing → Signup	3-5%	< 1%	> 8%	Industry avg
Signup → Activation	20-40%	< 10%	> 50%	Product benchmark
D1 Retention	25-40%	< 15%	> 50%	Mobile avg
D7 Retention	10-20%	< 5%	> 25%	Mobile avg
D30 Retention	5-10%	< 2%	> 15%	Mobile avg
Trial → Paid	2-5%	< 1%	> 8%	SaaS avg

Adjust based on product type (B2C vs B2B, free vs paid, mobile vs web).

Define decision rules (lean startup kill/iterate/scale):

markdown

## Decision Framework

**Review cadence:** Weekly (Fridays)

### KILL signals (any 2 = kill)
- [ ] Activation rate < {kill_threshold} after 2 weeks
- [ ] D7 retention < {kill_threshold} after 1 month
- [ ] Zero organic signups after 2 weeks of distribution
- [ ] CAC > 3x LTV estimate

### ITERATE signals
- [ ] Metrics between kill and scale thresholds
- [ ] Qualitative feedback suggests product-market fit issues
- [ ] One stage of funnel is dramatically worse than others

### SCALE signals (all 3 = scale)
- [ ] Activation rate > {scale_threshold}
- [ ] D7 retention > {scale_threshold}
- [ ] Organic growth > 10% week-over-week

Generate PostHog implementation snippets:

For iOS (Swift):

swift

// Event tracking examples
PostHogSDK.shared.capture("core_action_completed", properties: [
    "feature": "scan_receipt",
    "duration_ms": elapsed
])

For Web (TypeScript):

typescript

// Event tracking examples
posthog.capture('signed_up', {
    source: searchParams.get('utm_source') ?? 'direct',
    plan: 'free'
})

Write metrics plan to

docs/metrics-plan.md

markdown

# Metrics Plan: {Project Name}

**Generated:** {YYYY-MM-DD}
**Platform:** {iOS / Web / Both}
**North Star:** {north star metric}

## Event Funnel

| Stage | Event | Properties |
|-------|-------|------------|
{event table from step 4}

## KPIs & Thresholds

| KPI | Target | Kill | Scale |
|-----|--------|------|-------|
{benchmark table from step 6}

## Decision Rules

{framework from step 7}

## Implementation

### PostHog Setup
- Project: {project name} (EU region)
- SDK: {posthog-ios / posthog-js}
- Identity: {anonymous → identified on signup}

### Code Snippets
{snippets from step 8}

## Dashboard Template
- Funnel: {stage1} → {stage2} → ... → {stageN}
- Retention: D1 / D7 / D30 cohort chart
- Revenue: MRR trend + trial conversion

---
*Generated by /metrics-track. Implement events, then review weekly.*

Output summary — North Star metric, key thresholds, first event to implement.

解析项目 从
```
$ARGUMENTS
```
中获取。
- 阅读PRD了解功能、理想客户画像（ICP）、盈利模式。
- 阅读CLAUDE.md了解技术栈（iOS/网页/两者兼具）。
- 如果为空：通过AskUserQuestion询问用户。
检测平台：
- iOS应用 → PostHog iOS SDK事件
- 网页应用 → PostHog JS SDK事件
- 两者兼具 → 跨平台身份标识（各平台共享用户ID）
加载PostHog方法：
- 如果MCP可用：
```
kb_search("PostHog analytics events funnel identity")
```
- 否则：检查项目文档中的现有分析配置
- 提取：事件命名规范、身份解析规则、漏斗模式

基于PRD功能定义事件漏斗：

标准漏斗阶段（可根据产品调整）：

认知 → 获取 → 激活 → 变现 → 留存 → 推荐

映射为具体事件：

阶段	事件名称	触发条件	属性
认知	`page_viewed`	访问着陆页	`source` , `utm_*`
获取	`app_installed` 或 `signed_up`	首次安装/注册	`platform` , `source`
激活	`core_action_completed`	完成首个关键操作	`feature` , `duration_ms`
变现	`purchase_completed`	首次支付	`plan` , `amount` , `currency`
留存	`session_started`	回访（D1/D7/D30）	`session_number` , `days_since_install`
推荐	`invite_sent`	分享或推荐他人	`channel` , `referral_code`

强制推理 — 指标选择： 在定义KPI之前，明确以下内容：
- 北极星指标： 最核心的唯一指标（例如：“每周完成关键操作的活跃用户数”）
- 领先指标： 哪些指标可以预测北极星指标？（例如：“D1激活率”）
- 滞后指标： 哪些指标可以验证成功？（例如：“月度经常性收入（MRR）”、“D30留存率”）
- 应避免的虚荣指标：（例如：仅统计总下载量而不考虑激活情况）

为各阶段设置KPI基准：

KPI	目标值	终止阈值	扩展阈值	来源
着陆页→注册	3-5%	< 1%	> 8%	行业平均值
注册→激活	20-40%	< 10%	> 50%	产品基准值
D1留存率	25-40%	< 15%	> 50%	移动应用平均值
D7留存率	10-20%	< 5%	> 25%	移动应用平均值
D30留存率	5-10%	< 2%	> 15%	移动应用平均值
试用→付费	2-5%	< 1%	> 8%	SaaS行业平均值

根据产品类型调整（B2C vs B2B、免费 vs 付费、移动 vs 网页）。

定义决策规则（精益创业的终止/迭代/扩展）：

markdown

## 决策框架

**评审周期：** 每周（周五）

### 终止信号（满足任意2项=终止）
- [ ] 2周后激活率 < {终止阈值}
- [ ] 1个月后D7留存率 < {终止阈值}
- [ ] 上线分发2周后无自然注册用户
- [ ] 用户获取成本（CAC）> 预估客户终身价值（LTV）的3倍

### 迭代信号
- [ ] 指标处于终止与扩展阈值之间
- [ ] 定性反馈显示存在产品-市场匹配问题
- [ ] 漏斗中的某一阶段表现远差于其他阶段

### 扩展信号（全部满足3项=扩展）
- [ ] 激活率 > {扩展阈值}
- [ ] D7留存率 > {扩展阈值}
- [ ] 自然周增长率 > 10%

生成PostHog实现代码片段：

iOS（Swift）：

swift

// Event tracking examples
PostHogSDK.shared.capture("core_action_completed", properties: [
    "feature": "scan_receipt",
    "duration_ms": elapsed
])

网页（TypeScript）：

typescript

// Event tracking examples
posthog.capture('signed_up', {
    source: searchParams.get('utm_source') ?? 'direct',
    plan: 'free'
})

将指标计划写入

docs/metrics-plan.md

：

markdown

# 指标计划: {项目名称}

**生成时间:** {YYYY-MM-DD}
**平台:** {iOS / 网页 / 两者兼具}
**北极星指标:** {北极星指标}

## 事件漏斗

| 阶段 | 事件 | 属性 |
|-------|-------|------------|
{第4步中的事件表格}

## KPI与阈值

| KPI | 目标值 | 终止 | 扩展 |
|-----|--------|------|-------|
{第6步中的基准表格}

## 决策规则

{第7步中的框架内容}

## 实现方案

### PostHog设置
- 项目: {项目名称}（欧盟区域）
- SDK: {posthog-ios / posthog-js}
- 身份标识: 匿名 → 注册时通过用户ID标识

### 代码片段
{第8步中的代码片段}

## 仪表板模板
- 漏斗: {阶段1} → {阶段2} → ... → {阶段N}
- 留存: D1 / D7 / D30 cohort图表
- 变现: MRR趋势 + 试用转化率

---
*由/metrics-track生成。先实现事件，再每周评审。*

输出摘要 — 北极星指标、关键阈值、首个需实现的事件。

Notes

注意事项

PostHog EU hosting for privacy compliance
Use
```
$set
```
for user properties,
```
capture
```
for events
Identity: start anonymous,
```
identify()
```
on signup with user ID
Cross-platform: same PostHog project, same user ID → unified journey
Review dashboard weekly, make kill/iterate/scale decision monthly

使用PostHog欧盟托管以符合隐私合规要求
使用
```
$set
```
设置用户属性，
```
capture
```
跟踪事件
身份标识: 先以匿名身份开始，注册时调用
```
identify()
```
并传入用户ID
跨平台: 使用同一个PostHog项目、同一个用户ID → 统一用户旅程
每周评审仪表板，每月做出终止/迭代/扩展决策

Common Issues

常见问题

Wrong platform detected

平台检测错误

Cause: Project has both web and iOS indicators. Fix: Skill checks package manifests. If both exist, it generates cross-platform identity setup. Verify the detected platform in the output.

原因: 项目同时包含网页和iOS相关标识。 解决方法: 技能会检查包清单。如果两者都存在，将生成跨平台身份标识设置。请在输出中验证检测到的平台。

KPI thresholds too aggressive

KPI阈值过于激进

Cause: Default thresholds are industry averages. Fix: Adjust thresholds in

docs/metrics-plan.md

based on your niche. B2B typically has lower volume but higher conversion.

原因: 默认阈值为行业平均值。 解决方法: 根据你的细分领域调整

docs/metrics-plan.md

中的阈值。B2B通常用户量较低但转化率更高。

PostHog SDK not in project

项目中未安装PostHog SDK

Cause: Metrics plan generated but SDK not installed. Fix: This skill generates the PLAN only. Install PostHog SDK separately:

pnpm add posthog-js

(web) or add

posthog-ios

via SPM (iOS).

原因: 已生成指标计划但未安装SDK。 解决方法: 此技能仅生成计划。请单独安装PostHog SDK：网页端使用

pnpm add posthog-js

，iOS端通过SPM添加

posthog-ios

。