specwright/templates/skills/dev-team/po/data-analysis/SKILL.md
# Data Analysis Skill > Template for Product Owner user metrics analysis and product analytics > Created: 2026-01-09 > Version: 1.0.0 ## Skill Name **data-analysis** - Expert product analytics, user metrics interpretation, and data-driven decision making ## Purpose Enable Product Owners to analyze user behavior, interpret product metrics, validate hypotheses, and make informed prioritization decisions based on quantitative and qualitative data. ## When to Activate Activate this skill when:
npx skillsauth add michsindlinger/specwright specwright/templates/skills/dev-team/po/data-analysisInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Template for Product Owner user metrics analysis and product analytics Created: 2026-01-09 Version: 1.0.0
data-analysis - Expert product analytics, user metrics interpretation, and data-driven decision making
Enable Product Owners to analyze user behavior, interpret product metrics, validate hypotheses, and make informed prioritization decisions based on quantitative and qualitative data.
Activate this skill when:
// Example event structure
{
event: "feature_used",
user_id: "user_123",
timestamp: "2026-01-09T14:30:00Z",
properties: {
feature_name: "export_csv",
context: "dashboard",
duration_ms: 1200
}
}
button_clicked, not btn_click, ButtonClick)Track groups of users over time:
Week 0: 1000 users signed up
Week 1: 650 users returned (65% retention)
Week 2: 520 users returned (52% retention)
Week 4: 400 users returned (40% retention)
Insights:
Track step-by-step user progression:
Homepage Visit: 10,000 users (100%)
↓
Signup Page: 3,000 users (30%)
↓
Form Submission: 1,500 users (15%)
↓
Email Confirmation: 1,200 users (12%)
↓
Onboarding Complete: 900 users (9%)
Insights:
Compare behavior across user groups:
Free Plan Users:
- Avg session: 5 min
- Feature usage: 40%
- Retention: 30%
Paid Plan Users:
- Avg session: 15 min
- Feature usage: 85%
- Retention: 75%
Insights:
Compare variants to validate hypotheses:
Variant A (Control): 1000 users, 10% conversion
Variant B (New CTA): 1000 users, 14% conversion
Statistical Significance: p < 0.05 ✓
Best Practices:
We believe that [change/feature]
For [user segment]
Will result in [expected outcome]
We will know we're right when we see [measurable signal]
Hypothesis 1:
Hypothesis 2:
Validation Process:
Common analytics platforms:
[MCP_TOOLS]
<!-- Populated during skill creation based on: 1. User's installed MCP servers 2. User's selection for this skill Recommended for this skill (examples): - postgres - Query analytics data from production database - fetch - Retrieve metrics dashboards and reports - filesystem - Manage data analysis artifacts and reports Note: Skills work without MCP servers, but functionality may be limited -->Before making data-driven decisions:
# Product Metrics Dashboard: [Product Name]
> Last Updated: [DATE]
> Data Period: [Date Range]
> Reporting Frequency: Weekly | Monthly
## Executive Summary
[2-3 sentence overview of current product health]
## Key Metrics
### Acquisition
- **Total Signups**: [Number] ([% change] vs. last period)
- **Signup Conversion Rate**: [%] ([% change])
- **Top Traffic Sources**:
1. [Source]: [%]
2. [Source]: [%]
3. [Source]: [%]
### Activation
- **Onboarding Completion Rate**: [%] ([% change])
- **Time to First Value**: [Avg time] ([% change])
- **Feature Adoption (First Week)**: [%] ([% change])
### Retention
- **DAU**: [Number] ([% change])
- **WAU**: [Number] ([% change])
- **MAU**: [Number] ([% change])
- **30-Day Retention**: [%] ([% change])
- **Churn Rate**: [%] ([% change])
### Revenue
- **MRR**: $[Amount] ([% change])
- **ARPU**: $[Amount] ([% change])
- **LTV**: $[Amount]
- **CAC**: $[Amount]
- **LTV:CAC Ratio**: [Ratio]
### Quality
- **Error Rate**: [%] ([% change])
- **Avg Page Load Time**: [Seconds] ([% change])
- **NPS Score**: [Score] ([% change])
## Cohort Analysis
| Signup Week | Week 0 | Week 1 | Week 2 | Week 4 | Week 8 |
|-------------|--------|--------|--------|--------|--------|
| 2025-12-02 | 100% | 68% | 54% | 42% | 38% |
| 2025-12-09 | 100% | 70% | 56% | 44% | - |
| 2025-12-16 | 100% | 72% | 58% | - | - |
| 2025-12-23 | 100% | 65% | - | - | - |
**Insight**: [Interpretation of cohort trends]
## Feature Usage
| Feature | % of Active Users | Avg Uses per User | Trend |
|---------|-------------------|-------------------|-------|
| [Feature 1] | [%] | [Number] | ↑ ↓ → |
| [Feature 2] | [%] | [Number] | ↑ ↓ → |
| [Feature 3] | [%] | [Number] | ↑ ↓ → |
**Insight**: [Key takeaways on feature adoption]
## Conversion Funnels
### Signup Funnel
1. Homepage → Signup Page: [%]
2. Signup Page → Form Submit: [%]
3. Form Submit → Email Confirm: [%]
4. Email Confirm → Onboarding: [%]
**Overall Conversion**: [%]
**Biggest Drop-off**: [Step] ([%] drop)
### Purchase Funnel
1. Free User → Trial Start: [%]
2. Trial Start → Trial Engaged: [%]
3. Trial Engaged → Purchase: [%]
**Overall Conversion**: [%]
**Biggest Drop-off**: [Step] ([%] drop)
## User Segments
| Segment | % of Users | Avg Session | Feature Usage | Retention |
|---------|------------|-------------|---------------|-----------|
| Power Users | [%] | [Time] | [%] | [%] |
| Regular Users | [%] | [Time] | [%] | [%] |
| At-Risk Users | [%] | [Time] | [%] | [%] |
**Insight**: [Segment-specific observations]
## Key Insights
1. **[Insight Title]**: [Description and implication]
2. **[Insight Title]**: [Description and implication]
3. **[Insight Title]**: [Description and implication]
## Recommended Actions
| Priority | Action | Expected Impact | Owner | Status |
|----------|--------|-----------------|-------|--------|
| High | [Action] | [Impact] | [Name] | [Status] |
| Medium | [Action] | [Impact] | [Name] | [Status] |
## Experiments in Progress
| Experiment | Hypothesis | Status | Early Results |
|------------|------------|--------|---------------|
| [Name] | [Hypothesis] | Running | [Update] |
SELECT
DATE(logged_in_at) as date,
COUNT(DISTINCT user_id) as dau
FROM user_sessions
WHERE logged_in_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY DATE(logged_in_at)
ORDER BY date DESC;
SELECT
COUNT(DISTINCT user_id) as total_users,
COUNT(DISTINCT CASE WHEN feature_used THEN user_id END) as users_with_feature,
ROUND(100.0 * COUNT(DISTINCT CASE WHEN feature_used THEN user_id END) / COUNT(DISTINCT user_id), 2) as adoption_rate
FROM users
LEFT JOIN feature_events ON users.id = feature_events.user_id
WHERE users.created_at >= CURRENT_DATE - INTERVAL '30 days';
WITH cohorts AS (
SELECT
user_id,
DATE_TRUNC('week', created_at) as cohort_week
FROM users
),
activity AS (
SELECT
user_id,
DATE_TRUNC('week', logged_in_at) as activity_week
FROM user_sessions
)
SELECT
c.cohort_week,
DATE_DIFF('week', c.cohort_week, a.activity_week) as weeks_since_signup,
COUNT(DISTINCT c.user_id) as cohort_size,
COUNT(DISTINCT a.user_id) as active_users,
ROUND(100.0 * COUNT(DISTINCT a.user_id) / COUNT(DISTINCT c.user_id), 2) as retention_rate
FROM cohorts c
LEFT JOIN activity a ON c.user_id = a.user_id
GROUP BY c.cohort_week, weeks_since_signup
ORDER BY c.cohort_week, weeks_since_signup;
SELECT
COUNT(DISTINCT user_id) as total_visitors,
COUNT(DISTINCT CASE WHEN signed_up THEN user_id END) as signups,
COUNT(DISTINCT CASE WHEN onboarded THEN user_id END) as completed_onboarding,
COUNT(DISTINCT CASE WHEN upgraded THEN user_id END) as paid_users,
ROUND(100.0 * COUNT(DISTINCT CASE WHEN signed_up THEN user_id END) / COUNT(DISTINCT user_id), 2) as signup_rate,
ROUND(100.0 * COUNT(DISTINCT CASE WHEN onboarded THEN user_id END) / COUNT(DISTINCT CASE WHEN signed_up THEN user_id END), 2) as onboarding_rate,
ROUND(100.0 * COUNT(DISTINCT CASE WHEN upgraded THEN user_id END) / COUNT(DISTINCT CASE WHEN signed_up THEN user_id END), 2) as conversion_rate
FROM user_journey
WHERE visited_at >= CURRENT_DATE - INTERVAL '30 days';
Problem: Tracking metrics that look good but don't inform decisions Example: Total signups without considering retention or activation Solution: Focus on actionable metrics tied to business outcomes
Problem: Collecting endless data without making decisions Solution: Set decision deadlines, use "good enough" data
Problem: Declaring A/B test winner with insufficient data Solution: Use proper sample size calculators, validate p-values
Problem: Assuming correlation implies causation Example: "Users who use Feature X have higher retention" → doesn't mean Feature X causes retention Solution: Consider confounding factors, run experiments
Problem: Selecting date ranges or segments that support desired conclusion Solution: Define analysis parameters before looking at data
Problem: Relying solely on numbers without user feedback Solution: Combine quantitative metrics with user interviews, surveys, support tickets
Document data-driven decisions:
specwright/product/architecture-decision.md
Include:
Reference metrics in specs:
.specwright/specs/YYYY-MM-DD-feature-name/spec.md
Include:
Update roadmap based on data:
.specwright/product/roadmap.md
Adjust priorities when data reveals:
Track data analysis effectiveness through:
Remember: Data tells stories, but you must interpret them wisely. Combine quantitative metrics with qualitative insights. Question your assumptions. Test your hypotheses. And always ask "so what?" – what action does this data inform?
tools
Session Handoff: Erstellt eine vollständige Zusammenfassung der aktuellen Session für einen sauberen Kontextwechsel. NUR bei explizitem Aufruf (/session-handoff). NICHT automatisch auslösen. Geeignet wenn der User die Session resetten will, den Kontext aufräumen will, oder bei ~120k Tokens angelangt ist.
development
Pre-Mortem Risk Analysis: Strukturierte Prospective-Hindsight-Übung um launch-blocking Risiken vor Commitment aufzudecken. Team stellt sich vor, das Produkt sei 14 Tage nach Launch gefloppt, und arbeitet rückwärts. Klassifiziert Risiken in Tigers (echt), Paper Tigers (hypothetisch), Elephants (unausgesprochen). Nutze diesen Skill vor Build-Commitment, bei zu hoher Stakeholder-Confidence, vor Major-Releases, oder wenn das Team vage Sorgen nicht artikulieren kann. Trigger: /pre-mortem, 'pre-mortem', 'risk analysis', 'was könnte schiefgehen', 'risiken vor launch'.
testing
Six-Sigma Atomicity Validator for create-spec stories
tools
UX pattern definition guidance for navigation, user flows, interactions, and accessibility