Define an instrumentation and analytics plan for a product feature or launch. Outputs event taxonomy, tracking spec, dashboard design, and analysis playbook.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
product-analytics-plan
description
Define an instrumentation and analytics plan for a product feature or launch. Outputs event taxonomy, tracking spec, dashboard design, and analysis playbook.
argument-hint
["feature type","key questions to answer","analytics stack","launch timeline"]
allowed-tools
Read, Write
Product Analytics Plan
An analytics plan defines what to measure, how to measure it, and what questions the data will answer — before the feature ships. Analytics planned after launch leaves gaps that can't be backfilled. A good analytics plan turns every feature into a learning opportunity.
Process
Define the questions. What decisions will this data inform? Work backwards from decisions to metrics.
Design the event taxonomy. What user actions need to be tracked? Naming convention.
Write the tracking spec. For each event: name, trigger, properties, and example payload.
Design the dashboard. What charts answer which questions? Mock it before building.
Write the analysis playbook. How will you interpret the data after launch? What would "success" look like?
Review with data team. Catch gaps before engineering implements.
QA the tracking. Verify events fire correctly in staging before launch.
Analytics Plan Template
@pm-name
Team Templates
2024-04-15
Segment → BigQuery → Amplitude + Looker
---
Business questions → Metrics → Events needed
| Question | Metric | Primary Event(s) |
|----------|--------|-----------------|
| Is the feature being adopted? | % teams with ≥1 template published | templateused, workflowlibrarypreviewed, templatecopied (with category prop) |
| Does using templates improve activation? | Activation rate: template users vs non-template users | templatecopied, workflow{action}` — past tense verbs
Examples: templatecopied, templateviewed
| Event | Trigger | Properties |
|-------|---------|-----------|
| templateviewed | User opens template library tab | sessionstate) |
| templateterm, resultspreviewed | User clicks a template card | templatename, category, positionlist |
| templateid, templateid |
| templateid, templatecount |
| templateid, reason (optional) |
| templatesearchedresults | Search returns 0 results | searchcopied
Fires when a user creates a copy of a team template in their workspace.
User clicks "Use this template" button in template library and copy creation succeeds.
| Property | Type | Required | Example | Notes |
|----------|------|----------|---------|-------|
| templateabc123" | UUID |
| templateteamid | string | yes | "userresults" | Where user found it: "browse", "searchinterm | string | no | "report" | If copied from search results |
| sessiondef456" | For funnel analysis |
# Analytics Plan: Team Templates Feature
**Author:**
**Feature:**
**Launch date:**
**Data stack:**
## 1. Questions This Analytics Plan Answers
_published |
| Is it delivering value? | % users using template vs building from scratch | template_
_created |
| Where do users drop off in the flow? | Funnel: discover → preview → use → publish | template_
_viewed, template_
_copied |
| What types of templates are most popular? | Copies per template, by category | template_
_copied + existing activation events |
| Are admins publishing quality templates? | Template copy → published ratio | template_
Implementation note: Fire after successful API response (POST /templates/{id}/copy returns 201).
Do NOT fire on click (before API call) — only on success.
## 4. Dashboard Design
```markdown
## Template Analytics Dashboard (Looker)
### Panel 1: Adoption Overview
- Time series: # templates published per week
- Time series: # templates copied per week
- Single stat: % teams with ≥1 template (30-day)
- Single stat: Avg copies per template
### Panel 2: Discovery Funnel
Funnel chart (Amplitude):
library_viewed → template_previewed → template_copied
Show conversion rate at each step
Segment by source (browse, search, featured)
### Panel 3: Template Performance
Table: Top 20 templates by copies in last 30 days
Columns: template_name, category, copies, publish_date, author
### Panel 4: Search Analysis
- Top 10 search terms
- Search terms with no results (template gap discovery)
- Search → copy conversion rate
### Panel 5: Impact Analysis
Comparison chart:
Users who copied a template vs users who didn't
Metrics: activation rate, day-7 retention, trial→paid conversion
5. Analysis Playbook
## What to Look For Post-Launch### Week 1 (sanity checks)- Verify events are firing (check Segment debugger)
- Verify funnel looks reasonable (no step has >100% conversion)
- Check for event spikes or gaps
### Week 2-4 (early signals)- Library viewed → template copied conversion: expect >15%
- "No results" searches: identify top missing categories
- If library viewed but not previewed: thumbnail/card design issue
- If previewed but not copied: description quality issue, or template irrelevant
### Month 1 review (success assessment)- Primary: % teams with ≥1 template published ≥ 25%?
- Primary: % users using template in first 30 days ≥ 15%?
- If adoption low: investigate via session recordings + qualitative interviews
- Compare activation: template users vs non-template users
### Segment analysis- New accounts: Are templates accelerating activation?
- Enterprise accounts: Different templates used vs SMB?
- Industry breakdown: Which industries publish most?
### Decision triggers- Template adoption <5% after 6 weeks → qualitative research before further investment
- Search no-results >30% of searches → create templates for top missing categories
- Template copies but low workflow published rate → investigate where users drop off
6. QA Checklist
## Event Tracking QA
Before launch, verify each event:
[ ] template_library_viewed fires when: tab clicked, sidebar link, onboarding prompt
[ ] template_copied fires after API success (not on click)
[ ] template_copied does NOT fire on API error
[ ] All required properties present on every event
[ ] template_id is UUID format (not null, not "undefined")
[ ] source property correctly set for each entry point
[ ] position_in_list correct (starts at 1, not 0)
Test scenarios:
[ ] Browse → preview → copy (check full funnel fires)
[ ] Search → result → copy (check search_term prop present)
[ ] Copy fails (API error) → event does NOT fire
[ ] Admin publishes → template appears in library → member copies
QA environment: use Segment's live debugger to inspect events in real-time
Sign-off: @data-analyst reviews event stream before launching to 100%
Anti-Patterns to Avoid
Anti-Pattern
Problem
Fix
Tracking everything
Data lake with no actionable insights
Start with questions; track what answers them
Event on click (before API)
Counts attempts not completions
Fire events on successful API response
Generic event names
button_clicked with no context
Specific: template_copied, not button_clicked
No properties
Can't slice the data
Every event needs context properties
No QA before launch
Gaps discovered post-launch; unbackfillable
Tracking QA in staging before every launch
Dashboard without decisions
Vanity dashboard; nobody acts on it
Each panel answers a specific decision-relevant question
Analytics plan as afterthought
Engineers implement without tracking spec
Plan written before engineering starts
10 Rules
Define questions before designing events — work backwards from decisions to data.
Events fire on API success, not on user click — measure completions, not intentions.
Every event has a precise naming convention — object_action in past tense.
Every event property is documented with type, example, and notes.
QA the tracking in staging before launch — post-launch gaps can't be backfilled.
The dashboard is mocked before it is built — agree on what you'll look at.
The analysis playbook is written before launch — define what "good" and "bad" look like.
Track "no results" in search — it's a backlog of needed features.
