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.
From pm-data-analyticsnpx claudepluginhub tarunccet/pm-skills --plugin pm-data-analyticsThis skill uses the workspace's default tool permissions.
Implements structured self-debugging workflow for AI agent failures: capture errors, diagnose patterns like loops or context overflow, apply contained recoveries, and generate introspection reports.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
| 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