From pm-data-analytics
Define and distinguish operational, vanity, and actionable metrics. Write complete metric specs with name, definition, data source, calculation formula, owner, and review cadence. Use when formalizing metrics, building a metrics dictionary, or aligning a team on how metrics are measured.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pm-data-analytics:metric-definitionThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
| Input | Required? | Example |
| Input | Required? | Example |
|---|---|---|
| Metric name(s) to define | ✅ Required | "Weekly Active Users", "Activation Rate" |
| Product / context | ✅ Required | B2B SaaS project management tool |
| Data sources available | 🟡 Recommended | PostgreSQL events table, Segment, Mixpanel |
| Team or squad that owns the metric | ⚪ Optional | Growth team, Onboarding squad |
| Current tracking / calculation method | ⚪ Optional | "We count DAU from our analytics dashboard" |
Don't have everything? Start anyway — the skill will work with what you provide and flag where richer input would improve the output.
Create precise, unambiguous metric definitions that a team can rally around. Eliminates the silent disagreements where two people say the same metric name but compute it differently.
Most metric confusion stems from one of three problems:
This skill uses a structured spec format that forces clarity on definition, formula, data source, and ownership before a metric gets into a dashboard.
You are defining metrics for $ARGUMENTS.
For each metric provided, classify it:
| Category | Definition | Examples |
|---|---|---|
| Operational / Actionable | Teams can directly influence this metric; it reflects real user behavior or business outcomes | Activation rate, feature adoption rate, trial-to-paid conversion |
| Vanity | Looks impressive but doesn't indicate health or progress; hard to act on | Total registered users, page views, social media followers |
| Leading indicator | Predicts future outcomes; moves before lagging metrics change | Users who complete onboarding → predicts retention |
| Lagging indicator | Reflects outcomes that already happened; slow to respond to changes | Annual revenue, annual churn rate |
| Health / guardrail | Monitors something you must not break; not a goal | Error rate, p99 latency, support ticket volume |
Flag any vanity metrics and explain why they're vanity — then suggest an actionable alternative.
For each metric, produce a complete spec:
## Metric: [Metric Name]
**Type**: [Operational / Vanity / Leading / Lagging / Health]
**Owner**: [Team or role responsible for moving this metric]
**Last updated**: [date]
### Definition
[One precise sentence. Avoid ambiguity. Define edge cases.]
Example of a good definition: "Percentage of new users who complete at least 3 core actions within their first 7 days after sign-up, where core actions are defined as: [action A], [action B], [action C]."
Example of a bad definition: "Users who are active."
### Formula
[Numerator] / [Denominator] × 100 (if percentage)
OR
[Precise calculation description]
**Numerator**: [precise definition]
**Denominator**: [precise definition]
**Excludes**: [what is excluded and why — e.g., internal users, test accounts]
**Time window**: [e.g., rolling 7 days, calendar month, event-based]
### Data Source
| Element | Source | Table / Collection | Field |
|---------|--------|-------------------|-------|
| [numerator element] | [database/platform] | [table] | [field] |
| [denominator element] | [database/platform] | [table] | [field] |
### Example SQL (if applicable)
```sql
-- [Metric name] calculation
SELECT
[numerator query] AS numerator,
[denominator query] AS denominator,
ROUND(100.0 * [numerator] / NULLIF([denominator], 0), 2) AS metric_value
FROM [table]
WHERE [conditions]
| Period | Value | Notes |
|---|---|---|
| Current baseline | [value] | [context] |
| 30-day target | [value] | |
| 90-day target | [value] |
[What this metric doesn't capture. What could make it misleading.]
### Step 3: Flag Vanity Metrics
For any metric classified as vanity, explicitly note:
- Why it's vanity (what useful signal it lacks)
- The actionable alternative to track instead
- Whether to stop tracking it entirely or keep it as secondary context
### Step 4: Build the Metrics Dictionary (if multiple metrics)
If defining 3+ metrics, produce a summary table:
| Metric | Type | Owner | Formula (simplified) | Cadence | Dashboard |
|--------|------|-------|---------------------|---------|-----------|
| [Metric] | [Type] | [Owner] | [Formula] | [Freq.] | [Link] |
## Notes
- A metric without a formula isn't a metric — it's a concept
- Every metric should have exactly one owner; "everyone's" metric is nobody's metric
- Counter-metrics prevent Goodhart's Law: when a metric becomes a target, optimize the counter-metric too
- Revisit definitions quarterly — product changes often silently invalidate old formulas
npx claudepluginhub tarunccet/pm-skills --plugin pm-data-analyticsDefines metrics using a standardized template covering plain English definition, formula, components, segmentation, data sources, thresholds, limitations, and drivers. Ensures clarity in analysis.
Produces complete metrics specs for product areas: names, formulas, data sources, segmentation, SQL/event tracking, thresholds. Use for KPI definition or feature instrumentation.
Produce a complete metrics definition doc — metric name, formula, data source, segmentation, SQL or event tracking spec, and what good/bad looks like. Given a product area, outputs the full metrics spec. Use when asked to "define KPIs", "metrics framework", "what should we measure", "north star metric", or "instrument this feature".