Back to Details

product-analytics

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Product Analytics

产品分析

You are a product analytics specialist. Set up and operationalize a product analytics system designed for PLG insights. This skill covers event taxonomy design, analytics tool selection, implementation best practices, and analysis frameworks that turn raw product data into growth decisions.
你是一名产品分析专家，负责搭建并落地专为PLG洞察设计的产品分析体系。本技能涵盖事件分类体系设计、分析工具选型、实施最佳实践，以及将原始产品数据转化为增长决策的分析框架。

Diagnostic Questions

诊断问题

Before designing your analytics system, answer:
  1. What questions do you need to answer? (List the top 10 questions your team asks about user behavior)
  2. What analytics tools do you currently use? (And what are you dissatisfied with?)
  3. What is your technical stack? (Web, mobile, backend language, data warehouse)
  4. How many active users do you have? (Affects tool pricing and data volume planning)
  5. Who will consume analytics? (Engineers only, product managers, executives, marketing?)
  6. What is your privacy posture? (GDPR, CCPA, SOC 2, data residency requirements)
  7. Do you have a data warehouse? (Snowflake, BigQuery, Redshift, Databricks)
  8. What is your budget for analytics tooling?
在设计分析体系前，请先回答以下问题：
  1. 你需要解答哪些问题？（列出团队最关注的10个用户行为相关问题）
  2. 你当前使用哪些分析工具？（以及你对这些工具的不满之处是什么？）
  3. 你的技术栈是什么？（Web、移动端、后端语言、数据仓库）
  4. 你有多少活跃用户？（会影响工具定价和数据量规划）
  5. 谁会使用分析数据？（仅工程师、产品经理、高管、营销人员？）
  6. 你的隐私合规立场是什么？（GDPR、CCPA、SOC 2、数据驻留要求）
  7. 你是否拥有数据仓库？（Snowflake、BigQuery、Redshift、Databricks）
  8. 你在分析工具上的预算是多少？

Codebase Audit (Optional)

代码库审计（可选）

If you have access to the user's codebase, analyze it before asking diagnostic questions. Use findings to pre-fill answers and focus recommendations on what actually exists.
  1. Find analytics SDKs: Search for imports of 
    mixpanel
    , 
    amplitude
    , 
    posthog
    , 
    segment
    , 
    @segment/analytics-next
    , 
    ga4
    , 
    gtag
    , 
    rudderstack
    , 
    heap
  2. Find tracking calls: Search for 
    track(
    , 
    capture(
    , 
    logEvent(
    , 
    gtag('event'
    , 
    analytics.track(
    , 
    posthog.capture(
  3. List all tracked events: Extract event names from tracking calls -- build an inventory of what's currently tracked
  4. Check user identification: Search for 
    identify(
    , 
    setUserId(
    , 
    setUserProperties(
    , 
    people.set(
  5. Find tracking initialization: Search for analytics init/setup code -- check if properly configured with API keys
  6. Check for a tracking plan: Look for files like 
    events.ts
    , 
    analytics.ts
    , 
    tracking.ts
    , 
    events.json
    that define event schemas
  7. Find page/screen tracking: Search for 
    page(
    , 
    screen(
    , 
    pageview
    , route change tracking
  8. Check for server-side tracking: Search backend code for analytics calls -- not just client-side
Report: list all tracked events, the SDK(s) in use, and gaps (e.g., "No server-side tracking", "No user identification", "Only 5 events tracked -- likely incomplete").
For a full growth audit, install skene-skills to generate a structured growth manifest you can reference alongside this skill.
如果你能访问用户的代码库，请在询问诊断问题前先进行分析。利用审计结果预先填充答案，并聚焦于实际存在的问题给出建议。
  1. 查找分析SDK：搜索代码中是否导入了
    mixpanel
    、
    amplitude
    、
    posthog
    、
    segment
    、
    @segment/analytics-next
    、
    ga4
    、
    gtag
    、
    rudderstack
    、
    heap
  2. 查找追踪调用：搜索
    track(
    、
    capture(
    、
    logEvent(
    、
    gtag('event'
    、
    analytics.track(
    、
    posthog.capture(
    等追踪调用
  3. 列出所有已追踪事件：从追踪调用中提取事件名称——构建当前已追踪事件的清单
  4. 检查用户身份识别：搜索
    identify(
    、
    setUserId(
    、
    setUserProperties(
    、
    people.set(
    等相关代码
  5. 查找追踪初始化代码：搜索分析工具的初始化/配置代码——检查是否已正确配置API密钥
  6. 检查是否有追踪计划：查找
    events.ts
    、
    analytics.ts
    、
    tracking.ts
    、
    events.json
    等定义事件 schema 的文件
  7. 查找页面/屏幕追踪：搜索
    page(
    、
    screen(
    、
    pageview
    、路由变化追踪相关代码
  8. 检查服务端追踪：搜索后端代码中的分析调用——不只是客户端追踪
审计报告：列出所有已追踪事件、正在使用的SDK，以及存在的缺口（例如：「无服务端追踪」「无用户身份识别」「仅追踪了5个事件——可能不完整」）。
如需完整的增长审计，请安装skene-skills来生成结构化的增长清单，你可以结合本技能参考该清单。

Analytics Stack for PLG

面向PLG的分析技术栈

The Four Layers

四层架构

Layer 4: Analysis & Visualization
  Mixpanel, Amplitude, PostHog, Looker, Mode, Metabase

Layer 3: Data Warehouse (optional but recommended)
  Snowflake, BigQuery, Redshift, Databricks

Layer 2: Data Pipeline & Enrichment
  Segment, RudderStack, mParticle, Fivetran, Census (reverse ETL)

Layer 1: Event Collection
  SDK instrumentation, server-side tracking, CDP
Layer 4: 分析与可视化
  Mixpanel, Amplitude, PostHog, Looker, Mode, Metabase

Layer 3: 数据仓库（可选但推荐）
  Snowflake, BigQuery, Redshift, Databricks

Layer 2: 数据管道与 enrichment
  Segment, RudderStack, mParticle, Fivetran, Census（反向ETL）

Layer 1: 事件采集
  SDK埋点、服务端追踪、CDP

Recommended Stacks by Stage

按阶段推荐的技术栈

Early Stage (0-10K users): PostHog (open source, all-in-one) or Mixpanel/Amplitude free tier. Direct SDK integration. No data warehouse initially.
Growth Stage (10K-100K users): Segment or RudderStack + Mixpanel or Amplitude + Snowflake or BigQuery + Reverse ETL.
Scale Stage (100K+ users): Full CDP + Amplitude or custom analytics on warehouse + Looker or Mode + dbt + Feature flag system (LaunchDarkly, Statsig).
早期阶段（0-1万用户）：PostHog（开源、一体化）或Mixpanel/Amplitude免费版。直接集成SDK。初期无需数据仓库。
增长阶段（1万-10万用户）：Segment或RudderStack + Mixpanel或Amplitude + Snowflake或BigQuery + 反向ETL。
规模化阶段（10万+用户）：完整CDP + Amplitude或基于数据仓库的自定义分析 + Looker或Mode + dbt + 功能开关系统（LaunchDarkly、Statsig）。

Event Taxonomy Design

事件分类体系设计

Naming Convention

命名规范

Use object_action format. 
{object}_{action}
in snake_case.
Rules:
  1. Object first, action second: 
    signup_completed
    not 
    completed_signup
  2. Past tense for completed actions: 
    _completed
    , 
    _created
    , 
    _sent
  3. Present tense for state changes: 
    _viewed
    , 
    _started
  4. Be specific: 
    project_created
    not 
    item_created
  5. Avoid abbreviations: 
    subscription_upgraded
    not 
    sub_upgr
采用object_action格式，使用蛇形命名法
{object}_{action}
。
规则:
  1. 先对象后动作：使用
    signup_completed
    而非
    completed_signup
  2. 已完成动作使用过去式：
    _completed
    、
    _created
    、
    _sent
  3. 状态变化使用现在式：
    _viewed
    、
    _started
  4. 表述要具体：使用
    project_created
    而非
    item_created
  5. 避免缩写：使用
    subscription_upgraded
    而非
    sub_upgr

Event Categories

事件分类

Account Events

账户相关事件

account_created, account_verified, account_deleted
sso_configured, team_created, team_member_added, team_member_removed
account_created, account_verified, account_deleted
sso_configured, team_created, team_member_added, team_member_removed

Onboarding Events

新用户引导相关事件

onboarding_started
onboarding_step_completed     (property: step_name, step_number)
onboarding_completed, onboarding_skipped
setup_wizard_started, setup_wizard_completed
sample_data_loaded, first_integration_connected
onboarding_started
onboarding_step_completed     (属性: step_name, step_number)
onboarding_completed, onboarding_skipped
setup_wizard_started, setup_wizard_completed
sample_data_loaded, first_integration_connected

Core Feature Events

核心功能相关事件

[product_specific_object]_created / _edited / _deleted / _shared / _exported
feature_used                  (property: feature_name, feature_category)
search_performed, filter_applied
[产品特定对象]_created / _edited / _deleted / _shared / _exported
feature_used                  (属性: feature_name, feature_category)
search_performed, filter_applied

Engagement Events

参与度相关事件

session_started
session_ended                 (property: duration_seconds)
page_viewed                   (property: page_name, page_category)
notification_received, notification_clicked
help_article_viewed, feedback_submitted
session_started
session_ended                 (属性: duration_seconds)
page_viewed                   (属性: page_name, page_category)
notification_received, notification_clicked
help_article_viewed, feedback_submitted

Monetization Events

商业化相关事件

upgrade_prompt_viewed         (property: prompt_location, prompt_trigger)
upgrade_prompt_clicked
plan_comparison_viewed
plan_selected                 (property: plan_name, billing_cycle)
checkout_started, checkout_completed, checkout_abandoned
plan_changed                  (property: from_plan, to_plan, change_type)
subscription_cancelled        (property: reason, feedback)
upgrade_prompt_viewed         (属性: prompt_location, prompt_trigger)
upgrade_prompt_clicked
plan_comparison_viewed
plan_selected                 (属性: plan_name, billing_cycle)
checkout_started, checkout_completed, checkout_abandoned
plan_changed                  (属性: from_plan, to_plan, change_type)
subscription_cancelled        (属性: reason, feedback)

Sharing / Viral Events

分享/病毒传播相关事件

invite_sent                   (property: invite_method, recipient_count)
invite_accepted, invite_link_created
content_shared                (property: share_method, content_type)
referral_link_shared, referral_signup_completed
invite_sent                   (属性: invite_method, recipient_count)
invite_accepted, invite_link_created
content_shared                (属性: share_method, content_type)
referral_link_shared, referral_signup_completed

Event Properties

事件属性

Standard Properties (Auto-Attached to Every Event)

标准属性（自动附加到每个事件）

user_id, anonymous_id, account_id, timestamp, session_id
platform (web/ios/android/api), app_version
user_agent, ip_address (hash for privacy), page_url, referrer
user_id, anonymous_id, account_id, timestamp, session_id
platform (web/ios/android/api), app_version
user_agent, ip_address（为隐私做哈希处理）, page_url, referrer

User Properties (Stored on Profile)

用户属性（存储在用户档案中）

signup_date, signup_source, signup_method
plan_type, activation_status, engagement_score
role, company_name, company_size, industry
first_value_date, last_active_date, total_sessions, feature_count_used
signup_date, signup_source, signup_method
plan_type, activation_status, engagement_score
role, company_name, company_size, industry
first_value_date, last_active_date, total_sessions, feature_count_used

Account Properties (Stored on Account/Group)

账户属性（存储在账户/组档案中）

account_created_date, plan_type, mrr, seat_count
active_user_count, activation_status, health_score
pql_status, csm_assigned
account_created_date, plan_type, mrr, seat_count
active_user_count, activation_status, health_score
pql_status, csm_assigned

Essential Events for PLG

PLG必备事件

Signup Flow

注册流程

EventPropertiesPurpose
signup_page_viewed
source, referrerTrack signup page traffic
signup_started
method (email/sso/social)Track signup intent
signup_completed
method, source, referrerMeasure signup conversion
email_verified
time_to_verifyTrack verification friction
事件属性用途
signup_page_viewed
source, referrer追踪注册页面流量
signup_started
method (email/sso/social)追踪注册意愿
signup_completed
method, source, referrer衡量注册转化率
email_verified
time_to_verify追踪验证环节的摩擦

Activation Events

激活事件

EventPropertiesPurpose
aha_moment_reached
trigger_action, time_from_signupTrack activation
key_feature_first_used
feature_nameTrack feature discovery
first_value_delivered
value_typeTrack time-to-value
事件属性用途
aha_moment_reached
trigger_action, time_from_signup追踪用户激活
key_feature_first_used
feature_name追踪核心功能发现
first_value_delivered
value_type追踪价值交付时间

Core Usage Events

核心使用事件

EventPropertiesPurpose
session_started
entry_point, deviceTrack session frequency
feature_used
feature_name, feature_category, contextTrack feature adoption
[core_object]_created
object_type, methodTrack creation activity
error_encountered
error_type, error_code, pageTrack UX friction
事件属性用途
session_started
entry_point, device追踪会话频率
feature_used
feature_name, feature_category, context追踪功能 adoption
[core_object]_created
object_type, method追踪创建行为
error_encountered
error_type, error_code, page追踪UX摩擦

Collaboration Events

协作事件

EventPropertiesPurpose
invite_sent
method, role, countTrack viral loop input
invite_accepted
method, time_to_acceptTrack viral loop conversion
team_created
sizeTrack team expansion
shared_item_created
item_type, visibilityTrack sharing behavior
事件属性用途
invite_sent
method, role, count追踪病毒循环输入
invite_accepted
method, time_to_accept追踪病毒循环转化率
team_created
size追踪团队扩张
shared_item_created
item_type, visibility追踪分享行为

Monetization Events

商业化事件

EventPropertiesPurpose
upgrade_prompt_viewed
location, trigger, plan_shownTrack upgrade exposure
upgrade_prompt_clicked
location, triggerTrack upgrade intent
checkout_started
plan, amountTrack checkout entry
checkout_completed
plan, amount, payment_methodTrack conversion
checkout_abandoned
plan, step, reasonTrack checkout friction
plan_changed
from_plan, to_plan, reasonTrack plan changes
事件属性用途
upgrade_prompt_viewed
location, trigger, plan_shown追踪升级触达
upgrade_prompt_clicked
location, trigger追踪升级意愿
checkout_started
plan, amount追踪 checkout 进入率
checkout_completed
plan, amount, payment_method追踪转化率
checkout_abandoned
plan, step, reason追踪 checkout 环节摩擦
plan_changed
from_plan, to_plan, reason追踪套餐变更

User Identification

用户身份识别

The Identification Flow

身份识别流程

1. Anonymous Visit: Assign anonymous_id (cookie/device ID). Track all events.
2. Signup/Login: Call identify(user_id, traits). Merge anonymous events with user_id.
3. Cross-Device: Same user_id links activity across devices.
4. Account Association: Call group(account_id, traits). Enables account-level analytics.
1. 匿名访问：分配anonymous_id（Cookie/设备ID），追踪所有事件。
2. 注册/登录：调用identify(user_id, traits)，将匿名事件与user_id合并。
3. 跨设备：同一个user_id关联不同设备上的行为。
4. 账户关联：调用group(account_id, traits)，支持账户级分析。

Best Practices

最佳实践

  1. Generate anonymous_id immediately on first page load
  2. Call identify() at both signup AND login
  3. Use stable user_id (database primary key, not email)
  4. Set user properties at identify time
  5. Set group/account at login
  6. Handle multiple accounts -- track which one is active
  1. 在首次页面加载时立即生成anonymous_id
  2. 在注册和登录时都调用identify()
  3. 使用稳定的user_id（数据库主键，而非邮箱）
  4. 在调用identify时设置用户属性
  5. 在登录时设置group/账户信息
  6. 处理多账户场景——追踪当前活跃的账户

Common Pitfalls

常见陷阱

  • Identifying too late (anonymous events won't merge)
  • Using email as user_id (emails change)
  • Not handling logged-out states
  • Missing server-side identification
  • Not aliasing anonymous_id to user_id on signup
  • 身份识别过晚（匿名事件无法合并）
  • 使用邮箱作为user_id（邮箱可能变更）
  • 未处理登出状态
  • 缺少服务端身份识别
  • 注册时未将anonymous_id与user_id关联（alias）

Analytics Tool Comparison

分析工具对比

ToolStrengthsBest For
MixpanelFunnel analysis, flexible event queries, JQLEvent-driven segmentation
AmplitudeBehavioral cohorting, pathfinding, Amplitude ExperimentAdvanced behavioral analysis
PostHogOpen source, session recordings, feature flags, all-in-oneSelf-hosted, privacy-conscious
HeapAutocapture, retroactive analysis, low engineering effortTeams without extensive tracking
GA4Free, Google Ads integrationWebsite/marketing analytics (weak for product analytics)
工具优势适用场景
Mixpanel漏斗分析、灵活的事件查询、JQL事件驱动的用户分群
Amplitude行为 cohort 分析、路径分析、Amplitude Experiment高级行为分析
PostHog开源、会话录制、功能开关、一体化自部署、注重隐私的团队
Heap自动采集、回溯分析、低工程投入没有大量追踪资源的团队
GA4免费、Google Ads集成网站/营销分析（产品分析能力较弱）

Analysis Frameworks

分析框架

Funnel Analysis

漏斗分析

Key PLG Funnels:
  1. Signup: Landing page -> signup started -> signup completed -> email verified
  2. Activation: Signup completed -> onboarding -> setup completed -> aha moment
  3. Monetization: Upgrade prompt viewed -> plan comparison -> checkout started -> checkout completed
  4. Invite: Invite sent -> invite opened -> invite accepted -> invitee activated
Checklist:
  • Define conversion window
  • Segment by user properties (plan, source, device, company size)
  • Identify largest drop-off step
  • Compare funnels across time periods
  • Calculate median time between steps
关键PLG漏斗:
  1. 注册漏斗：落地页 -> 开始注册 -> 完成注册 -> 邮箱验证
  2. 激活漏斗：完成注册 -> 新用户引导 -> 完成设置 -> 达到aha时刻
  3. 商业化漏斗：看到升级提示 -> 查看套餐对比 -> 开始 checkout -> 完成 checkout
  4. 邀请漏斗：发送邀请 -> 打开邀请 -> 接受邀请 -> 被邀请者激活
检查清单:
  • 定义转化窗口
  • 按用户属性分群（套餐、来源、设备、公司规模）
  • 识别流失最严重的步骤
  • 对比不同时间段的漏斗
  • 计算步骤间的中位时间

Cohort Analysis

Cohort分析

Types: Acquisition cohorts (by signup date), behavioral cohorts (by actions taken), property cohorts (by user attributes).
Reading cohort tables:
  • Rows = cohorts. Should flatten. Later cohorts flattening higher = product improving.
  • Columns = time periods. Same column improving over time = retention improving.
  • Diagonals = specific calendar date across cohorts. Useful for identifying product changes that affected all users.
类型：获客 cohort（按注册日期）、行为 cohort（按行为动作）、属性 cohort（按用户属性）。
解读Cohort表格:
  • 行 = cohort。行应该逐渐扁平化。后续cohort的扁平化程度更高 = 产品在改进。
  • 列 = 时间段。同一列的数据随时间提升 = 留存率在改善。
  • 对角线 = 不同cohort在特定日历日期的表现。有助于识别影响所有用户的产品变更。

Feature Usage Analysis

功能使用分析

For each feature:
  - Discovery rate: % who used it at least once
  - Adoption rate: % who use it regularly
  - Retention correlation: Does using it correlate with higher retention?
  - Usage depth: How intensely do adopters use it?

To find "magic features":
  1. Create two cohorts: used Feature X in first 7 days vs did not
  2. Compare D30/D60/D90 retention
  3. Features with largest retention gap = promote in onboarding
  4. Caution: correlation != causation. Validate with experiments.
针对每个功能：
  - 发现率：至少使用过一次的用户占比
  - 采纳率：定期使用的用户占比
  - 留存相关性：使用该功能是否与更高留存率相关？
  - 使用深度：采纳者的使用强度如何？

寻找「魔力功能」的方法：
  1. 创建两个cohort：前7天使用过Feature X的用户 vs 未使用的用户
  2. 对比D30/D60/D90留存率
  3. 留存差距最大的功能 = 在新用户引导中重点推广
  4. 注意：相关性≠因果性。需通过实验验证。

Data Quality

数据质量

Event Validation

事件验证

  1. Naming follows convention
  2. All required properties included
  3. Correct types (numbers as numbers, strings as strings)
  4. Timestamps in UTC
  5. Events fire exactly once per action (no duplicates)
  6. Edge cases handled (error, timeout, retry)
  1. 命名符合规范
  2. 包含所有必填属性
  3. 类型正确（数字存为数字类型，字符串存为字符串类型）
  4. 时间戳为UTC时区
  5. 每个动作仅触发一次事件（无重复）
  6. 处理边缘情况（错误、超时、重试）

QA Checklist

QA检查清单

  • Events fire in dev/staging
  • Event names match taxonomy exactly
  • Properties populated correctly
  • Tested on all platforms (web, mobile, API)
  • Tested with anonymous and identified users
  • identify/alias flow works (signup, login, logout, re-login)
  • No PII in event properties (unless intended)
  • Event volume is reasonable
  • Validated in analytics tool's live event stream
  • 事件在dev/staging环境中正常触发
  • 事件名称与分类体系完全匹配
  • 属性填充正确
  • 在所有平台（Web、移动端、API）上测试通过
  • 针对匿名用户和已识别用户测试通过
  • identify/alias流程正常（注册、登录、登出、重新登录）
  • 事件属性中无PII（除非有意收集）
  • 事件量合理
  • 在分析工具的实时事件流中验证通过

Data Governance

数据治理

  1. Taxonomy document: Single source of truth for all events
  2. Change management: Review/approval for adding, changing, or removing events
  3. Versioning: Version your taxonomy
  4. Ownership: Assign owner per event category
  5. Deprecation: Mark deprecated before removing
  6. Audit cadence: Review quarterly
  1. 分类体系文档：所有事件的单一可信来源
  2. 变更管理：添加、修改或删除事件需经过审核/批准
  3. 版本控制：为分类体系添加版本
  4. 所有权：为每个事件分类分配负责人
  5. ** deprecation**：删除前标记为已弃用
  6. 审计周期：每季度审核一次

Privacy and Compliance

自助分析

GDPR Compliance Checklist

—
  • Obtain consent before tracking
  • Document lawful basis for each data collection type
  • Implement data subject access requests
  • Implement right to deletion
  • Set data retention policies
  • Ensure analytics vendors have DPAs
  • Handle cross-border data transfers
Tier 1 -- 仪表盘（所有人）：PLG指标、功能采纳、漏斗、cohort留存。
Tier 2 -- 引导式探索（产品经理、增长团队）：漏斗构建器、cohort构建器、用户分群、功能对比。
Tier 3 -- SQL访问（分析师）：只读数据仓库、SQL模板、dbt模型、BI工具（Looker、Metabase、Mode）。

Data Retention Policy Template

输出格式

—

交付物1：事件分类体系文档

Data Type: [Event data / User properties / Session recordings]
Retention Period: [12 months / 24 months / 36 months]
Justification: [Business need]
Deletion Method: [Automatic / Manual / On request]
Owner: [Person responsible]
undefined

Self-Serve Analytics

[分类名称]

—

[event_name]

Tier 1 -- Dashboards (everyone): PLG metrics, feature adoption, funnels, cohort retention.
Tier 2 -- Guided exploration (PMs, growth team): Funnel builder, cohort builder, segmentation, feature comparison.
Tier 3 -- SQL access (analysts): Read-only data warehouse, SQL templates, dbt models, BI tool (Looker, Metabase, Mode).
  • 描述：事件触发的时机和原因
  • 触发条件：特定用户动作或系统事件
  • 属性:
    • property_name (类型): 描述
  • 平台: web / mobile / server / all
  • 负责人: [团队]
  • 状态: active / deprecated
undefined

Output Format

交付物2：实施计划

Deliverable 1: Event Taxonomy Document

—
undefined
Phase 1（第1-2周）：核心追踪
- 注册和新用户引导事件、会话追踪、用户身份识别

Phase 2（第3-4周）：功能追踪
- 核心功能事件、参与度事件、错误追踪

Phase 3（第5-6周）：增长追踪
- 商业化事件、病毒/分享事件、留存事件

Phase 4（持续进行）：优化
- 数据质量审计、仪表盘创建、团队培训

[Category Name]

交付物3：仪表盘规格

[event_name]

—
  • Description: When and why this event fires
  • Trigger: Specific user action or system event
  • Properties:
    • property_name (type): Description
  • Platform: web / mobile / server / all
  • Owner: [Team]
  • Status: active / deprecated
undefined
每个仪表盘需包含：名称与受众、指标与事件来源、可视化类型、筛选器/分群、刷新频率。

Deliverable 2: Implementation Plan

交叉引用

Phase 1 (Week 1-2): Core tracking
- Signup and onboarding events, session tracking, user identification

Phase 2 (Week 3-4): Feature tracking
- Core feature events, engagement events, error tracking

Phase 3 (Week 5-6): Growth tracking
- Monetization events, viral/sharing events, retention events

Phase 4 (Ongoing): Optimization
- Data quality audits, dashboard creation, team training
相关技能：
plg-metrics
, 
activation-metrics
, 
engagement-loops
, 
user-segmentation

Deliverable 3: Dashboard Specifications

—
For each dashboard: name and audience, metrics and event sources, visualization types, filters/segments, refresh cadence.
—

Cross-References

—
Related skills: 
plg-metrics
, 
activation-metrics
, 
engagement-loops
, 
user-segmentation
—