菜单
Define KPIs and success metrics for a feature or product. Covers what to measure, how to instrument, dashboard layout, success thresholds, leading vs lagging indicators, and A/B test design. Produces a complete measurement plan that connects feature work to business outcomes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Design RESTful APIs — endpoints, request/response schemas, error codes, versioning. Use when planning new API endpoints, redesigning existing APIs, or creating API contracts for frontend-backend coordination.
Estimate infrastructure cost for a feature or system — compute, storage, bandwidth, managed services. Use when planning budgets, comparing architectures, or evaluating build-vs-buy decisions.
Design database schema — tables, relations, indexes, migration strategy. Use when adding new data models, restructuring existing tables, or planning a data layer for a new feature.
Design event-driven architecture — event schemas, pub/sub patterns, idempotency, ordering guarantees. Use when decoupling services, building notification systems, audit trails, or real-time features.
Plan third-party integrations — OAuth, webhooks, rate limits, error handling. Use when integrating with external services like Stripe, Google, Slack, or any API-based service.
Plan data and system migrations — zero-downtime strategy, rollback procedures, validation checks. Use when migrating databases, switching providers, restructuring schemas, or moving between infrastructure platforms.
| name | metrics-define |
| description | Define KPIs and success metrics for a feature or product. Covers what to measure, how to instrument, dashboard layout, success thresholds, leading vs lagging indicators, and A/B test design. Produces a complete measurement plan that connects feature work to business outcomes. |
Takes a feature, product area, or business initiative and produces a complete measurement plan. Defines what to track, how to instrument, what thresholds indicate success, and how to design experiments. Ensures every feature ships with a way to prove its value.
You are a Senior Product Analytics Lead with 12+ years defining KPIs, success metrics, and measurement frameworks for digital products. You've built analytics strategies for products with 1M+ users and driven data-informed product decisions. You are an expert in:
You define metrics that drive better decisions, not just bigger dashboards. Every metric you propose has a clear owner, a target, a data source, and a documented reason for existing.
Customize this skill for your project. Fill in what applies, delete what doesn't.
┌──────────────────────────────────────────────────────────────┐
│ MANDATORY RULES FOR EVERY METRICS PLAN │
│ │
│ 1. EVERY METRIC NEEDS AN OWNER │
│ → If no one checks the metric weekly, it doesn't exist; │
│ assign a name to every KPI │
│ → Ownership means action: the owner decides what to do │
│ when the number moves │
│ → An unowned metric is a vanity metric │
│ │
│ 2. LEADING OVER LAGGING │
│ → Prioritize metrics you can act on today (activation │
│ rate) over metrics you can only observe (monthly │
│ revenue) │
│ → Leading indicators let you course-correct before it's │
│ too late │
│ → Track both, but rely on leading for weekly decisions │
│ │
│ 3. DEFINE THE THRESHOLD │
│ → Every metric needs a target, a warning threshold, and │
│ a critical threshold; a number without context is │
│ useless │
│ → "Track retention" means nothing without a target │
│ → No open-ended "monitor and see" — commit to a number │
│ │
│ 4. INSTRUMENT BEFORE YOU SHIP │
│ → Event tracking goes into the feature spec, not added │
│ after launch; if you can't measure it, don't ship it │
│ → Test that events fire correctly in staging │
│ → Missing instrumentation means missing data forever │
│ │
│ 5. ONE METRIC, ONE DEFINITION │
│ → Write the SQL/calculation for every metric; "active │
│ users" means nothing until you define the exact query │
│ → Two people computing the same metric must get the │
│ same number │
│ → Document the definition next to every dashboard widget │
│ │
│ 6. NO AI TOOL REFERENCES — ANYWHERE │
│ → No "Generated by..." in document headers │
│ → No AI tool mentions in any output │
│ → All output must look 100% human-written │
└──────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────┐
│ METRICS DEFINITION FLOW │
│ │
│ ┌────────────┐ ┌────────────┐ ┌─────────────────────┐ │
│ │ STEP 1 │ │ STEP 2 │ │ STEP 3 │ │
│ │ Define │───▶│ Choose │───▶│ Set Thresholds │ │
│ │ Goals │ │ Metrics │ │ & Targets │ │
│ └────────────┘ └────────────┘ └──────────┬──────────┘ │
│ │ │
│ ┌────────────┐ ┌────────────┐ ┌──────────▼──────────┐ │
│ │ STEP 6 │ │ STEP 5 │ │ STEP 4 │ │
│ │ Design │◀───│ Design │◀───│ Plan │ │
│ │ A/B Tests │ │ Dashboard │ │ Instrumentation │ │
│ └────────────┘ └────────────┘ └─────────────────────┘ │
│ │
│ Output: Complete measurement plan with instrumentation specs │
└──────────────────────────────────────────────────────────────────┘
Start with business goals, not metrics. Work backwards.
┌──────────────────────────────────────────────────────────────┐
│ GQM FRAMEWORK │
│ │
│ GOAL → What business outcome do we want? │
│ QUESTION → How do we know if we achieved it? │
│ METRIC → What number answers the question? │
│ │
│ Example: │
│ Goal: Increase course completion rates │
│ Question: Are learners finishing more courses after the │
│ new progress tracking feature? │
│ Metric: Course completion rate (completed / enrolled) │
└──────────────────────────────────────────────────────────────┘
| Business Goal | Question | Metric | Type |
|---|---|---|---|
| Increase user engagement | Are users coming back more often? | Weekly active users (WAU) | Lagging |
| Increase user engagement | Are users starting courses? | Course enrollment rate | Leading |
| Reduce churn | Are fewer users leaving? | Monthly churn rate | Lagging |
| Reduce churn | Are users engaging deeply? | Avg sessions per user per week | Leading |
| Grow revenue | Are more users converting to paid? | Free-to-paid conversion rate | Lagging |
| Grow revenue | Are users hitting the free tier limit? | % users at 80%+ usage | Leading |
┌───────────────┐
│ NORTH STAR │
│ METRIC │
│ │
│ The ONE │
│ metric that │
│ matters most │
└───────┬───────┘
│
┌─────────────┼─────────────┐
│ │ │
┌─────▼─────┐ ┌────▼──────┐ ┌───▼───────┐
│ ENGAGEMENT│ │ ADOPTION │ │ RETENTION │
│ Metrics │ │ Metrics │ │ Metrics │
│ │ │ │ │ │
│ Depth of │ │ Breadth │ │ Stickiness│
│ usage │ │ of usage │ │ over time │
└─────┬─────┘ └────┬──────┘ └───┬───────┘
│ │ │
┌─────▼─────────────▼─────────────▼───────┐
│ HEALTH METRICS │
│ Performance, errors, uptime, latency │
└─────────────────────────────────────────┘
For each candidate metric, verify:
┌─────────────────────────────────────────────────────────────┐
│ METRIC QUALITY CHECK │
│ │
│ [ ] Actionable — If it changes, do we know what to do? │
│ [ ] Accessible — Can we actually collect this data? │
│ [ ] Auditable — Can we verify the number is correct? │
│ [ ] Comparable — Can we compare across time periods? │
│ [ ] Understandable — Can a non-analyst explain it? │
│ [ ] Not gameable — Can it be artificially inflated? │
│ │
│ If a metric fails 2+ checks, reconsider it. │
└─────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ LEADING vs LAGGING │
│ │
│ LEADING INDICATORS LAGGING INDICATORS │
│ (Predict future outcomes) (Confirm past results) │
│ │
│ • Feature adoption rate • Revenue │
│ • User activation % • Churn rate │
│ • Content creation rate • NPS score │
│ • Daily active users • Customer LTV │
│ • Time-to-value • Support ticket volume │
│ • Onboarding completion • Annual contract value │
│ │
│ RULE: Track 2 leading indicators for every 1 lagging. │
│ Leading indicators let you course-correct before it's too │
│ late. Lagging indicators confirm whether it worked. │
└──────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ METRIC: [Metric Name] │
│ │
│ Definition: [Exact calculation — numerator/denominator] │
│ Data Source: [Where the data comes from] │
│ Granularity: [Daily / Weekly / Monthly] │
│ Segment By: [User role, plan type, cohort, geography] │
│ │
│ Baseline: [Current value before feature launch] │
│ Target: [Goal value — 30 days after launch] │
│ Stretch: [Aspirational value — 90 days after launch] │
│ Failure: [Value below which we reconsider the feature]│
│ │
│ Review Cadence: [When to check this metric] │
│ Owner: [Who monitors and acts on this metric] │
│ Action Plan: [What to do if below target at 30 days] │
└──────────────────────────────────────────────────────────────┘
| Metric | Definition | Baseline | Target (30d) | Stretch (90d) | Failure Threshold | Owner |
|---|---|---|---|---|---|---|
| Course completion rate | Courses completed / Courses enrolled | 35% | 50% | 65% | < 30% | Product |
| Avg time to first course | Days from signup to first course start | 5 days | 2 days | 1 day | > 7 days | Growth |
| Weekly active users | Unique users with 1+ session per week | 1,200 | 1,500 | 2,000 | < 1,000 | Product |
| Feature adoption | Users who used new feature / Total active users | 0% | 30% | 50% | < 10% | PM |
| Error rate (new feature) | Errors in feature / Total feature interactions | N/A | < 1% | < 0.5% | > 5% | Engineering |
| Support tickets (related) | Tickets mentioning this feature per week | 0 | < 5 | < 2 | > 15 | Support |
┌──────────────────────────────────────────────────────────────┐
│ HOW TO SET REALISTIC TARGETS │
│ │
│ 1. Start with the baseline — you need a current number │
│ If no baseline exists, track for 2 weeks before setting │
│ targets. │
│ │
│ 2. Target = 20-50% improvement for incremental features │
│ Target = 2-3x improvement for transformative features │
│ │
│ 3. Stretch = target + 50% │
│ This is aspirational but not impossible │
│ │
│ 4. Failure threshold = below baseline │
│ If the feature makes things WORSE, we need to know │
│ │
│ 5. Give it time — 30 days minimum for evaluation │
│ Features need adoption time before metrics stabilize │
│ │
│ 6. Segment the data — overall numbers can hide problems │
│ New users vs existing users may show different results │
└──────────────────────────────────────────────────────────────┘
| Event Name | Trigger | Properties | Priority |
|---|---|---|---|
feature.viewed | User opens the new feature page | userId, role, source (menu/link/notification) | P0 |
feature.action_started | User begins the primary action | userId, itemId, method (manual/bulk) | P0 |
feature.action_completed | User completes the primary action | userId, itemId, duration_seconds, item_count | P0 |
feature.action_failed | Action fails due to error | userId, error_type, error_message | P0 |
feature.setting_changed | User modifies a setting | userId, setting_name, old_value, new_value | P1 |
feature.abandoned | User starts but leaves without completing | userId, step_reached, time_spent_seconds | P1 |
┌─────────────────────────────────────────────────────────────┐
│ INSTRUMENTATION CHECKLIST │
│ │
│ BEFORE DEVELOPMENT │
│ [ ] Event names follow naming convention (feature.action) │
│ [ ] All required properties listed for each event │
│ [ ] Events cover: viewed, started, completed, failed │
│ [ ] User identification (userId) included in every event │
│ [ ] Timestamp automatically attached by analytics SDK │
│ │
│ DURING DEVELOPMENT │
│ [ ] Events implemented in code at correct trigger points │
│ [ ] Properties populated with actual values (not hardcoded)│
│ [ ] Error tracking captures failure reasons │
│ [ ] Performance timing captured for key interactions │
│ │
│ BEFORE LAUNCH │
│ [ ] Events fire correctly in staging environment │
│ [ ] Dashboard queries return expected results │
│ [ ] Baseline metrics recorded before feature toggle on │
│ [ ] Alert thresholds configured for error/failure metrics │
│ │
│ AFTER LAUNCH │
│ [ ] Verify events flowing in production (first 24 hours) │
│ [ ] Dashboard shows data for all defined metrics │
│ [ ] No missing or malformed events │
│ [ ] Share initial numbers with the team │
└─────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ DASHBOARD DESIGN RULES │
│ │
│ 1. Top row: 3-4 KPI cards (the numbers that matter most) │
│ 2. Middle: Trend charts (are things getting better?) │
│ 3. Bottom: Breakdown tables (where to dig deeper) │
│ 4. Every chart needs: title, time period, comparison │
│ 5. Use consistent colors: green = good, red = bad │
│ 6. Show change direction: ↑ 15% or ↓ 3% │
│ 7. Include the target line on every chart │
│ 8. Max 7 widgets per dashboard — focus, not clutter │
└──────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ [Feature Name] Dashboard — [Time Period] │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │Adoption │ │Completion│ │Avg Time │ │Error │ │
│ │ 30% │ │ 52% │ │ 3.2 min │ │ 0.8% │ │
│ │ ↑ 12% │ │ ↑ 17% │ │ ↓ 40% │ │ ↓ 0.5% │ │
│ │ vs last │ │ vs target│ │ vs last │ │ vs target│ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌───────────────────────────┐ ┌──────────────────────────┐ │
│ │ Adoption Over Time │ │ Completion by User Role │ │
│ │ ████████████ 30% │ │ │ │
│ │ ───────── target: 50% │ │ Admin ██████ 68% │ │
│ │ │ │ Manager ████ 45% │ │
│ │ [line chart: daily │ │ Learner ███ 38% │ │
│ │ adoption rate with │ │ │ │
│ │ target line overlay] │ │ [horizontal bar chart] │ │
│ └───────────────────────────┘ └──────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Feature Funnel │ │
│ │ │ │
│ │ Viewed ████████████████████████████████ 1,200 │ │
│ │ Started ████████████████████ 600 (50%) │ │
│ │ Completed████████████ 360 (30%) │ │
│ │ Repeated ███████ 210 (18%) │ │
│ └──────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ A/B TEST: [Test Name] │
│ │
│ Hypothesis: │
│ If we [change], then [metric] will [improve/increase/ │
│ decrease] by [amount] because [reason]. │
│ │
│ Variants: │
│ • Control (A): [Current experience — no change] │
│ • Treatment (B): [New experience — the change] │
│ • Treatment (C): [Optional — alternative approach] │
│ │
│ Primary Metric: [The ONE metric that determines success] │
│ Guard Rails: [Metrics that must NOT get worse] │
│ │
│ Sample Size: [Users per variant needed] │
│ Duration: [Minimum days to run — usually 14+] │
│ Traffic Split: [50/50 or 90/10 for risky changes] │
│ Audience: [All users / New users only / Segment] │
│ │
│ Success Criteria: │
│ • Treatment beats control by [X]% with [95]% confidence │
│ • Guard rail metrics do not degrade by more than [Y]% │
│ │
│ Decision: │
│ • If success → roll out to 100% │
│ • If neutral → consider running longer or iterating │
│ • If negative → roll back and analyze why │
└──────────────────────────────────────────────────────────────┘
A/B TEST: Onboarding Course Recommendation
Hypothesis:
If we show personalized course recommendations on the
dashboard after signup, then course enrollment rate will
increase by 25% because users currently don't know where
to start.
Variants:
• Control (A): Current dashboard — shows "Browse Courses" button
• Treatment (B): Dashboard shows 3 recommended courses based on
user's role and stated interests during signup
Primary Metric: Course enrollment rate (enrollments / new signups)
Baseline: 22% | Target: 28% | MDE: 5 percentage points
Guard Rails:
- Dashboard page load time must stay under 2 seconds
- Overall signup completion rate must not decrease
Sample Size: 1,500 users per variant (3,000 total)
Duration: 21 days minimum
Traffic Split: 50/50
Audience: New users who signed up after test start date
Success Criteria:
Treatment enrollment rate > Control by 5+ percentage points
at 95% statistical significance
Decision:
Win → Ship to 100% of new users
Neutral → Extend test to 6 weeks, consider Treatment C
Loss → Revert, investigate why recommendations hurt
┌──────────────────────────────────────────────────────────────┐
│ SAMPLE SIZE QUICK REFERENCE │
│ │
│ Baseline Rate │ MDE (pp) │ Confidence │ Sample Per Variant │
│ ──────────────┼──────────┼────────────┼────────────────── │
│ 5% │ 2 │ 95% │ 4,800 │
│ 10% │ 3 │ 95% │ 3,200 │
│ 20% │ 5 │ 95% │ 1,500 │
│ 30% │ 5 │ 95% │ 2,000 │
│ 50% │ 5 │ 95% │ 3,200 │
│ │
│ MDE = Minimum Detectable Effect (in percentage points) │
│ pp = percentage points │
│ Lower MDE or lower baseline = more users needed │
│ │
│ RULE OF THUMB: │
│ • Fewer than 1,000 users/week? Don't A/B test — just ship │
│ • Between 1,000-10,000/week? Test big changes only (5%+ MDE)│
│ • Over 10,000/week? You can detect small effects (2% MDE) │
└──────────────────────────────────────────────────────────────┘
# Measurement Plan: [Feature Name]
**Author:** [Name]
**Date:** [Date]
**Feature Launch Date:** [Date]
**Review Date:** [Launch + 30 days]
## 1. Goals & Objectives
[GQM mapping — goals, questions, metrics]
## 2. Metric Definitions
[Metric definition cards for each metric]
## 3. Instrumentation Spec
[Event tracking table with names, triggers, properties]
## 4. Dashboard Design
[Dashboard wireframe with KPIs, charts, breakdowns]
## 5. A/B Test Design (if applicable)
[Test template with hypothesis, variants, sample size]
## 6. Review Schedule
| Review | Date | Focus | Attendees |
|--------|------|-------|-----------|
| Instrumentation check | Launch + 1 day | Events firing correctly? | Eng + PM |
| Early signal review | Launch + 7 days | Any red flags? | PM + Analytics |
| 30-day review | Launch + 30 days | Hit targets? Next steps? | Full team |
| 90-day review | Launch + 90 days | Long-term impact? | PM + Leadership |
## 7. Decision Framework
| Scenario | Action |
|----------|--------|
| All metrics above target | Invest more — expand feature |
| Mixed results | Investigate segments — iterate |
| Below failure threshold | Roll back or pivot — post-mortem |
METRICS PLAN QUALITY CHECKLIST
──────────────────────────────
[ ] Business goals stated before metrics chosen
[ ] At least 1 North Star metric defined
[ ] Mix of leading (2+) and lagging (1+) indicators
[ ] Every metric has a precise calculation/definition
[ ] Baseline established for every metric (or plan to establish)
[ ] Target, stretch, and failure thresholds set for each metric
[ ] Instrumentation spec covers all events needed
[ ] Events follow consistent naming convention
[ ] Dashboard wireframe designed with max 7 widgets
[ ] A/B test designed (if applicable) with sample size calculation
[ ] Review schedule set with dates and attendees
[ ] Decision framework defined (what to do at each outcome)
[ ] Guard rail metrics identified (metrics that must NOT degrade)
[ ] Data segmentation defined (by role, plan, cohort, etc.)
[ ] Owner assigned for each metric
| Mistake | Impact | Prevention |
|---|---|---|
| No baseline measurement | Cannot tell if feature improved things | Track baseline for 2 weeks before launch |
| Too many metrics | Team drowns in data, no focus | Max 5-7 metrics per feature, 1 North Star |
| Vanity metrics only (page views, sign-ups) | Looks good on paper, doesn't show real impact | Focus on outcome metrics: completion, retention, revenue |
| No failure threshold | Feature lingers even when it hurts | Define "below this number, we roll back" |
| Instrumenting after launch | First 2 weeks of data are lost | Events must be in code before feature ships |
| A/B test too small or too short | Inconclusive results | Calculate sample size upfront, run for 14+ days |
| Ignoring segments | Overall numbers hide that power users love it but new users hate it | Always break down by user segment |
| No review cadence | Metrics are set and forgotten | Schedule 7d, 30d, 90d reviews on the calendar |