Analytics Instrumentation Planner

Purpose

Design product analytics instrumentation: what to track, how events are named, which properties to capture, and how metrics connect to product goals.

Input: Product flows, north-star metric (optional), key hypotheses, platform constraints (web/mobile/API)
Output: Analytics Tracking Plan with event catalog, property schemas, funnels, and dashboard wireframes
Examples: See examples.md for worked input/output.

Workflow

Step 1: Align metrics to goals

If north-star undefined, run north-star-metric-advisor first or propose candidates.

Step 2: Map user journeys to funnels

For each critical journey:

Entry → Key actions → Success state → Retention signal

Example (AI assistant):

Sign up → First prompt → Successful response → Return within 7d

Document drop-off questions each funnel step should answer.

Step 3: Design event taxonomy

Naming convention: object_action in snake_case (e.g., prompt_submitted, rag_query_completed).

Rules:

• One event per user-visible action (not per API call unless debugging)
• No PII in event names or property keys
• Hash or bucket sensitive values

Step 4: Define property schema

Global context on every event:

Per-event properties documented with type, allowed values, and nullability.

Step 5: AI-specific instrumentation

Align with ai-evaluation-builder online metrics where possible.

Step 6: Dashboard and experiment specs

For A/B tests: primary metric, guardrails, minimum detectable effect, runtime estimate.

Step 7: Validate

Run Validation checklist.

Decision Rules

Validation

• North star and input metrics linked to events
• ≥1 funnel with steps and success definition
• Event catalog ≥10 events with naming convention doc
• Global context properties defined
• No PII in event/property design
• AI-specific signals included for AI products
• Dashboard wireframe with ≥3 charts
• Implementation notes (SDK, server-side vs client)

Anti-patterns

• Track everything — unusable warehouse, privacy risk.
• Vague events — button_clicked without object context.
• Metric without owner — dashboard nobody reads.
• Client-only revenue events — trust server-side for billing.
• Prompt logging by default — compliance incident waiting to happen.

Best Practices

• Version the tracking plan in repo (analytics/tracking-plan.md).
• Use Segment/Amplitude/Mixpanel taxonomy import where supported.
• Pair events with acceptance-criteria-generator for measurable stories.
• Review event volume and cost quarterly.
• Run tracking plan review before each major release.

Output Structure

# Analytics Tracking Plan: [Product]

## Goals
| Metric | Definition | Target |
|--------|------------|--------|

## Funnels
### [Journey name]
[Steps + questions]

## Event Catalog
| Event | Trigger | Properties |
|-------|---------|------------|

## Global Properties
[Schema table]

## AI Events
[If applicable]

## Dashboards
[Wireframe descriptions]

## Privacy & Consent
[Rules]

## Implementation Checklist
[ ] SDK init [ ] Server events [ ] QA validation

Next Skills