Help us improve
Share bugs, ideas, or general feedback.
From pm-data-analytics
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.
npx claudepluginhub tarunccet/pm-skills --plugin pm-data-analyticsHow this skill is triggered — by the user, by Claude, or both
Slash command
/pm-data-analytics:event-tracking-planThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
| Input | Required? | Example |
Instrumentation plan — design event taxonomy, property schema, and tracking plan for analytics tools. Use when asked to "what should we track", "instrumentation plan", "set up analytics events", "analytics event schema", "tracking plan", or "instrument this feature".
Designs event taxonomies, property schemas, and tracking plans for analytics instrumentation. Scans for tools like PostHog/Mixpanel, maps user journeys, and prioritizes P0 events before coding.
Designs opinionated target tracking plan for product telemetry from product model, current audit, and best practices. Outputs .telemetry/tracking-plan.yaml and delta.md. Use for creating or redesigning analytics instrumentation.
Share bugs, ideas, or general feedback.
| 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