Tracking Plan Creation

Why this matters

A clear tracking plan is the contract between Product, Engineering, and Analytics. It ensures everyone knows exactly what to track, where, and why—so you can answer real product questions without re-instrumenting every sprint.

• Real tasks you will face:
  • Define events and properties for a new feature launch.
  • Align naming conventions across iOS, Android, and Web.
  • Specify identity strategy (user_id vs device_id) and privacy rules.
  • Create QA steps so implemented events match the plan.
  • Version and communicate changes to the plan.

Concept explained simply

Think of the tracking plan as a checklist for your product's behaviors. For each user action or system event, it documents: what to call it, when it fires, which properties to send, who owns it, and how it will be used in analysis.

Mental model

• Map: It shows where data originates in the product.
• Contract: It prevents ambiguity between teams.
• Schema: It enforces consistency so downstream dashboards do not break.

Anatomy of a good tracking plan

• Event name: Lowercase, snake_case, verb_noun style (e.g., sign_up_submit).
• Description: Why the event exists and the exact trigger.
• Platform/Location: Web, iOS, Android; the screen or component.
• Trigger conditions: Precise logic (e.g., fires on successful API 200 for /signup).
• Properties: Key-value pairs with type, allowed values, and examples.
• Identity: Which identifiers must be present (user_id, device_id, session_id).
• Privacy classification: PII/Non-PII; hashing/anonymization rules.
• Ownership: Product area and responsible team/analyst.
• Success metric linkage: Which KPIs this event supports (e.g., activation).
• Sample payload: Example JSON to align on structure.
• Status & version: Proposed, Implemented, QA passed; version and change notes.

{
  "event": "sign_up_success",
  "description": "User completes the sign-up flow and account is created.",
  "platform": ["web", "ios", "android"],
  "location": "auth/signup",
  "trigger": "Account creation returns 200",
  "properties": [
    {"name": "method", "type": "string", "allowed": ["email", "google", "apple"], "required": true},
    {"name": "referrer", "type": "string", "example": "campaign_spring2025", "required": false}
  ],
  "identity": {"user_id": "required after creation", "device_id": "optional", "session_id": "recommended"},
  "privacy": {"pii": false},
  "owner": "Growth - Activation",
  "kpi": ["activation_rate"],
  "status": "proposed",
  "version": "1.0.0"
}

Worked examples

Example 1: Sign-up flow

• sign_up_start – fires when the signup form becomes visible.
• sign_up_submit – fires when user presses submit.
• sign_up_success – fires on successful account creation.

{
  "event": "sign_up_submit",
  "properties": {
    "method": "email",
    "form_variant": "A",
    "errors_count": 0
  },
  "user_id": null,
  "device_id": "d_823...",
  "session_id": "s_101..."
}

Example 2: E-commerce add to cart

• add_to_cart – user adds an item to cart.
• view_cart – user opens the cart screen.
• remove_from_cart – user removes an item.

{
  "event": "add_to_cart",
  "properties": {
    "product_id": "SKU-9912",
    "price": 39.99,
    "currency": "USD",
    "quantity": 1,
    "placement": "product_detail"
  },
  "user_id": "u_45...",
  "session_id": "s_88..."
}

Example 3: Feature adoption (dark launch)

• feature_exposed – user sees the new feature toggle.
• feature_used – user performs the primary action at least once.
• feature_value – user completes the value moment (e.g., shares a file).

{
  "event": "feature_used",
  "properties": {
    "feature_key": "quick_share",
    "entry_point": "home_banner",
    "variant": "B"
  },
  "user_id": "u_93...",
  "session_id": "s_12..."
}

Step-by-step: Create a robust tracking plan

1. List key user journeys: activation, conversion, retention, and risk points.
2. Draft events per journey with clear triggers and outcomes.
3. Define properties that explain the context (who/what/where).
4. Apply naming conventions: lowercase_snake_case; consistent property keys.
5. Decide identity and session strategy; avoid mixing anonymous and logged-in states without fields to distinguish.
6. Classify privacy and mark required hashing/anonymization.
7. Add sample payloads so engineers can implement without guessing.
8. Version the plan (1.0.0) and mark status for each event.
9. QA before launch: confirm events fire once, have required properties, and match sample payload formats.
10. Publish and socialize: share with engineering and stakeholders; keep a changelog.

Governance, privacy, and QA

• PII checklist:
  • Avoid raw emails/phone numbers where not essential; if required, hash.
  • Do not log secrets, tokens, or full addresses.
  • Limit free-text fields; prefer enumerations.
• QA checklist:
  • Event fires exactly once per trigger.
  • All required properties present and typed correctly.
  • Identity fields populated as designed.
  • Payload size stays within SDK limits.
  • Cross-platform parity (Web/iOS/Android).

Common mistakes and self-check

• Inconsistent naming across platforms. Self-check: Compare event lists by platform and align.
• Logging UI clicks without business meaning. Self-check: Every event links to a KPI or decision.
• Missing required properties. Self-check: Validate against the plan before merging.
• Over-collecting PII. Self-check: Mark each property as PII or not and challenge necessity.
• No versioning. Self-check: Add version and changelog entries for any change.

Practice exercises

Note: Exercises and the Quick Test are available to everyone. Log in to save your progress.

1. Draft a tracking plan for a "Newsletter Subscribe" modal.
   • List events (open, submit, success) with triggers.
   • Define 3–5 properties per event.
   • Add sample payloads and privacy flags.
2. Normalize inconsistent event names and properties.
   • Fix casing, convert to snake_case, and standardize property keys.
   • Write a one-line rationale for each change.

• Quick checklist before you consider an exercise complete:
  • Names follow snake_case and verb_noun pattern.
  • Each event has a clear trigger and required properties.
  • Identity strategy is explicit.
  • Privacy classification is defined.
  • Sample payloads match property definitions.

Practical projects

• Instrument a small onboarding funnel (3–5 events) in a mock app and run a QA session checklist.
• Create a governance doc: naming rules, identity strategy, and change process (one page).
• Version an existing plan from 1.0.0 to 1.1.0 and write a changelog with breaking vs non-breaking changes.

Who this is for, prerequisites, and learning path

Test yourself

Take the Quick Test below to check your understanding. Everyone can take it; log in to save results.

Next steps

• Run a 30-minute review of your draft plan with Engineering to de-risk ambiguities.
• Pilot the plan on one platform first, then propagate to others.
• Schedule a monthly instrumentation audit to keep the plan healthy.

Mini challenge

Your PM wants to measure "feature delight" for a new share flow. Propose 3 events with properties that would let you calculate exposure, usage, and value delivered. Add identity and privacy notes. Keep it to 8 lines total.