Design an analytics instrumentation plan — define key events, properties, naming conventions, and produce a tracking spec document that engineers can implement. Use when setting up analytics for a new product, redesigning a tracking schema, or onboarding engineers to instrumentation work.
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 |
|---|---|---|
| Product / feature to instrument | ✅ Required | Onboarding flow for a B2B SaaS tool |
| Key user actions to track | ✅ Required | Sign-up, profile complete, first project created |
| Analytics platform | 🟡 Recommended | Posthog, Segment, Mixpanel, Amplitude |
| Existing event taxonomy (if any) | 🟡 Recommended | Current event naming conventions or schema |
| Business questions to answer | ⚪ Optional | "Where do users drop off in onboarding?" |
Don't have everything? Start anyway — the skill will work with what you provide and flag where richer input would improve the output.
Create a complete, engineer-ready analytics tracking specification that defines which events to instrument, what properties to capture, how to name them, and what business questions each event answers.
Analytics instrumentation is a PM responsibility that's often done reactively — you add events when you realize you can't answer a question. This skill flips the approach: define the questions you need to answer before building, then design the tracking schema to answer them.
Key principle: Track intent, not just action. signup_completed tells you a user signed up. onboarding_step_skipped with a step_name property tells you where they gave up. The difference is in properties.
You are designing an event tracking plan for $ARGUMENTS.
Before defining events, list 5-7 questions the tracking plan must be able to answer:
These questions drive which events and properties matter.
Organize events into logical groups:
Event naming convention: Use [noun]_[verb] in snake_case (e.g., user_signed_up, project_created, feature_clicked). Be consistent — choose either past tense or present tense and stick to it.
For each event:
| Event Name | Trigger | When It Fires | Business Question Answered |
|---|---|---|---|
[event_name] | [user action] | [precise moment] | [which question from Step 1] |
For each event, define the properties to capture:
Event: [event_name]
Description: [what this event represents]
Trigger: [exactly when it fires]
Properties:
- [property_name] (type: string/number/boolean/array) — [description, example value]
- [property_name] (type: ...) — [description]
Example payload:
{
"event": "[event_name]",
"timestamp": "[ISO 8601]",
"[property_name]": "[example_value]",
...
}
List properties that should be captured on every event automatically:
| Property | Type | Description | Example |
|---|---|---|---|
user_id | string | Unique user identifier | usr_abc123 |
session_id | string | Session identifier | ses_xyz789 |
platform | string | Web, iOS, Android | web |
app_version | string | Product version | 2.4.1 |
| [add product-specific globals] |
Specify how users move through identity states:
anonymous_id (device/browser-level)user_id after sign-up or log-in## Event Tracking Spec: [Product / Feature]
**Version**: 1.0
**Date**: [today]
**Analytics platform**: [tool]
**Owner**: [PM name]
**Engineer contact**: [TBD]
---
### Naming Conventions
- Events: [noun]_[verb] in snake_case, past tense
- Properties: snake_case, descriptive
- Boolean properties: prefixed with `is_` or `has_`
### Global Properties (on every event)
[Table from Step 4]
### Event Catalogue
#### [Group 1: e.g., Authentication]
[Event specs from Step 3]
#### [Group 2: e.g., Onboarding]
[Event specs]
#### [Group 3: e.g., Core Feature Usage]
[Event specs]
### Business Questions → Events Mapping
| Business Question | Events to Query | Key Property |
|-----------------|----------------|-------------|
| [Question] | [event_1, event_2] | [property] |
### Implementation Notes for Engineers
- Capture events on the server side where possible to prevent ad blockers
- Include `[property]` on every event for [specific reason]
- Do NOT capture PII in event properties — use anonymized IDs only
- [Platform-specific notes]
### Validation Checklist
- [ ] All events fire at correct trigger points
- [ ] No PII captured in event properties
- [ ] Events visible in analytics platform within 5 minutes
- [ ] Global properties attached to all events
- [ ] Identity alias event fires on sign-up