# Event Tracking Plan

> 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.

- Skill: `45ck/event-tracking-plan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add 45ck/event-tracking-plan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/45ck/event-tracking-plan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: 45ck (https://skillmd.com/u/45ck)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/45ck/event-tracking-plan

---


# Event Tracking Plan

Use this skill to design, repair, or review a product analytics tracking plan.

## What this skill must produce

Always produce:

1. **Tracking objective**
2. **Critical event**
3. **North Star tie-in**
4. **Core funnel**
5. **Event taxonomy**
6. **Property taxonomy**
7. **Identity model**
8. **Client vs server instrumentation map**
9. **Data quality / governance checks**
10. **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
| Event | Client | Server | Notes |
|---|---|---|---|

### Data quality / governance checks
- Naming convention:
- Required docs:
- QA process:
- Audit cadence:
- Deprecation process:
- PII guidance:
- Common failure patterns to watch:

### Implementation backlog
| Priority | Task | Owner | Why now |
|---|---|---|---|

## 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.