| name | event-tracking-plan |
| description | Create or audit an event tracking plan for product, growth, and analytics workflows. Use when a team needs a source-of-truth taxonomy, instrumentation plan, and data governance rules. |
| argument-hint | ["product-or-feature"] |
Event Tracking Plan
Use this skill to design, repair, or review a product analytics tracking plan.
What this skill must produce
Always produce:
- Tracking objective
- Critical event
- North Star tie-in
- Core funnel
- Event taxonomy
- Property taxonomy
- Identity model
- Client vs server instrumentation map
- Data quality / governance checks
- Implementation backlog
Inputs to gather
If available, extract:
- Product name
- Core user journey
- Target conversion / activation event
- Existing event names
- Current analytics stack
- User/account model
- Main reporting questions
- Planned experiments / funnels
- Regions / privacy constraints
- Existing dashboards / warehouse / CDP
If these are missing, infer a reasonable first pass and label assumptions.
Working rules
- Treat the tracking plan as the source of truth.
- Prefer human-readable event names.
- Use an object-action naming convention unless the repo already uses a different standard.
- Include event purpose, owner, source, and destination.
- Track only data that is necessary and useful.
- Distinguish clearly between event properties, user properties, and organization properties.
- Explicitly mark whether each event is client-side or server-side.
- Design for analysis and activation.
Step-by-step method
Step 1: define the business questions
List the 5-10 most important questions the team wants the data to answer.
Examples:
- What drives activation?
- Where do users drop in onboarding?
- Which behaviors correlate with retention?
- What qualifies an account as product-qualified?
- Which experiments require new events?
Step 2: define the critical event
Choose the user action that most closely represents the core value exchange in the product.
State:
- why this is the critical event
- what should count as an active user
- what should not count as active usage
Step 3: map the core funnel
Define the critical path funnel from first touch to activation / conversion.
For each stage specify:
- stage name
- target event
- key failure mode
- key diagnostic event
Step 4: design the event taxonomy
For every required event include:
- canonical event name
- plain-English purpose
- when it fires
- trigger source
- actor
- destinations
- owner
Step 5: design properties
For each event list required properties with:
- property name
- type
- example value
- why it is needed
- whether required or optional
Then separately list:
- user properties
- org/account properties
Step 6: define instrumentation ownership
For each event specify whether it is:
- client-side
- server-side
- both
- derived / warehouse modeled
Step 7: define governance rules
Specify:
- naming rules
- deprecation rules
- duplicate event checks
- required documentation fields
- QA checklist
- audit cadence
Step 8: create implementation order
Prioritize events into:
- P0 must-have
- P1 next
- P2 later
Required outputs
Tracking objective
Summarize the job of this tracking plan in 2-4 sentences.
Critical event
- Event:
- Why it matters:
- Active user definition:
- Non-active noise to exclude:
North Star tie-in
Explain how the critical event and funnel relate to the team’s North Star or primary KPI.
Core funnel
| Stage | Target event | Why it matters | Common drop-off cause |
|---|
Event taxonomy
| Event name | Purpose | Fires when | Source | Owner | Priority |
|---|
Event properties
| Event | Property | Type | Example | Required? | Why needed |
|---|
User properties
| Property | Type | Example | Why needed |
|---|
Account / org properties
| Property | Type | Example | Why needed |
|---|
Identity model
State clearly:
- anonymous ID
- user ID
- account / org ID
- merge behavior
- multi-org behavior
- device/session considerations
Client vs server instrumentation map
Data quality / governance checks
- Naming convention:
- Required docs:
- QA process:
- Audit cadence:
- Deprecation process:
- PII guidance:
- Common failure patterns to watch:
Implementation backlog
Additional rules
When auditing an existing taxonomy, explicitly call out:
- duplicates
- ambiguous names
- events without business purpose
- missing properties
- events that cannot support the desired funnels or experiments
- active-user definitions that are too shallow
- places where account-level context is missing
If the product is B2B SaaS, strongly prefer including org/account properties and account-level events where relevant.
