Event Tracking And Instrumentation

Why this skill matters for Product Analysts

Event tracking and instrumentation turn user actions into trustworthy data. As a Product Analyst, you depend on clean, consistent events to answer core questions like: What features drive activation? Where do users drop off? Which cohorts retain or churn? Strong instrumentation unlocks reliable funnels, experiments, growth analyses, and product strategy.

Who this is for

• Product Analysts who interpret behavioral data and partner with PMs/Engineers.
• Data/Business Analysts transitioning into product analytics.
• PMs who need to specify analytics requirements precisely.

Prerequisites

• Basic SQL (SELECT, WHERE, GROUP BY, JOIN, COUNT DISTINCT).
• Familiarity with product metrics: activation, retention, conversion.
• Comfort reading JSON payloads and basic event schemas.

Learning path

1. Define event naming and taxonomy
   • Choose a consistent naming style (e.g., verb_noun: "added_to_cart").
   • Decide required vs optional properties per event.
   • Definition of Done: a written taxonomy with examples and rules.
2. Design event properties
   • Include identifiers, context (source, platform), and business parameters.
   • Normalize types (strings, numbers, booleans, enums) and units (currency, time).
   • Definition of Done: property schema with clear types and allowed values.
3. Create a tracking plan
   • Map events to user journeys and product goals.
   • Specify trigger, properties, identity, and ownership for each event.
   • Definition of Done: a versioned tracking plan document shared with engineering.
4. Set up user identity resolution
   • Define how anonymous and authenticated users are tied (anonymousId to userId).
   • Plan for cross-device and workspace/account contexts.
   • Definition of Done: documented identity rules and merge logic.
5. Ensure client–server event consistency
   • Decide which events fire client-side vs server-side and how to deduplicate.
   • Align timestamps, session logic, and idempotency keys.
   • Definition of Done: a consistency policy with examples.
6. Instrumentation QA
   • Validate payloads in dev/stage, then in production.
   • Check naming, properties, types, and identity are as specified.
   • Definition of Done: QA checklist completed with screenshots or logs.
7. Detect missing and broken events
   • Set up volume baselines and anomaly checks.
   • Build coverage tests for required properties and schemas.
   • Definition of Done: monitoring queries or dashboards plus alert thresholds.
8. Document and maintain
   • Keep a changelog and deprecation policy.
   • Publish a usage guide for analysts and PMs.
   • Definition of Done: documentation accessible to the product team.

Worked examples

{
  "event": "added_to_cart",
  "userId": "u_12345",            // null if anonymous; then use anonymousId
  "anonymousId": null,
  "timestamp": "2025-01-10T12:34:56.789Z",
  "properties": {
    "product_id": "sku_987",
    "product_name": "Trail Shoes XT",
    "category": "footwear",
    "price": 89.99,                 // in USD
    "currency": "USD",
    "quantity": 1,
    "referrer": "search",
    "campaign": "spring_launch",   // optional
    "platform": "web",             // web|ios|android
    "experiment": {
      "exp_key": "cart_btn_color",
      "variant": "green"
    }
  },
  "context": {
    "page": {"url": "https://example.com/product/sku_987"},
    "user_agent": "...",
    "ip": "203.0.113.10"
  }
}

// Before sign-up
{
  "event": "viewed_product",
  "userId": null,
  "anonymousId": "anon_abc123",
  "timestamp": "2025-01-10T10:00:00Z"
}

// On sign-up (identify)
{
  "event": "identify",
  "userId": "u_12345",
  "anonymousId": "anon_abc123",
  "traits": {"email": "user@example.com"},
  "timestamp": "2025-01-10T10:05:00Z"
}

// After sign-up
{
  "event": "added_to_cart",
  "userId": "u_12345",
  "anonymousId": null,
  "timestamp": "2025-01-10T10:06:00Z"
}

-- Daily counts by platform
SELECT
  DATE_TRUNC('day', timestamp) AS d,
  properties:platform::string AS platform,
  COUNT(*) AS events
FROM events
WHERE event = 'added_to_cart'
  AND timestamp >= CURRENT_DATE - INTERVAL '14 days'
GROUP BY 1, 2
ORDER BY 1, 2;

-- Property coverage for required keys
SELECT
  COUNT_IF(properties:product_id IS NULL) AS missing_product_id,
  COUNT_IF(properties:price IS NULL) AS missing_price,
  COUNT(*) AS total
FROM events
WHERE event = 'added_to_cart'
  AND timestamp >= CURRENT_DATE - INTERVAL '7 days';

// Client
{
  "event": "completed_purchase",
  "userId": "u_12345",
  "properties": {"order_id": "o_555", "total": 129.00},
  "context": {"source": "client"},
  "messageId": "uuid-client-o_555"
}

// Server (source of truth)
{
  "event": "completed_purchase",
  "userId": "u_12345",
  "properties": {"order_id": "o_555", "total": 129.00},
  "context": {"source": "server"},
  "messageId": "uuid-server-o_555"
}

Drills and exercises

• List 10 core events for your product’s activation funnel. Write names using your taxonomy.
• For each event, specify 3–5 required properties with types and allowed values.
• Draft a one-page identity resolution policy: anonymous, logged-in, workspace/account contexts.
• Create SQL to monitor daily counts and property coverage for two key events.
• Run a QA of a recent release: capture payload screenshots/logs and note any mismatches.

Common mistakes and debugging tips

Mini project: Instrument an activation funnel

1. Pick a 3–5 step funnel (e.g., sign_up → completed_onboarding → used_core_feature).
2. Write the tracking plan: event names, triggers, required properties, identity rules, source (client/server), owners.
3. Define QA steps and acceptance checks.
4. Implement a monitoring query for volumes and property coverage per step.
5. Run a post-release validation and produce a one-page report with findings and fixes.

Practical projects

• Design and ship a feature-specific tracking spec (search, share, or payments) with QA evidence.
• Create a data health dashboard: event volumes, null property rates, and platform splits.
• Refactor legacy events: deprecate, alias, and migrate dashboards to the new taxonomy.

Subskills

• Event Naming And Taxonomy — Build a clear, consistent naming system and style guide.
• Event Properties Design — Choose required/optional fields, types, units, and enums that support analysis.
• Tracking Plan Creation — Specify trigger, payload, identity, and ownership for each event.
• User Identity Resolution — Merge anonymous and authenticated activity correctly across devices.
• Client Server Event Consistency — Prevent double counts; define authoritative sources and idempotency keys.
• Instrumentation QA — Validate payloads in stage/prod with a repeatable checklist.
• Detecting Missing And Broken Events — Monitor volumes, nulls, and schema drift to catch issues early.
• Analytics Documentation — Keep a versioned, searchable record of events and changes.

Next steps

• Complete the drills, then attempt the skill exam below. Anyone can take it for free; sign in to save progress.
• Apply the mini project to a real feature. Share your tracking plan and QA outcomes with your team.
• Move on to deeper analysis topics like experimentation and retention once your instrumentation is stable.