Analytics Design
Purpose
Design a comprehensive measurement strategy including metrics hierarchy, event taxonomy, funnel instrumentation, and A/B test framework to ensure features can be evaluated with data.
Inputs
- Feature or product area to instrument
- Business goals and key questions to answer
- Existing analytics infrastructure (tools, event patterns, naming conventions)
- Privacy requirements and data retention policies
- Target user segments for experimentation
Process
Step 1: Define Key Metrics Hierarchy
Build a three-tier metrics structure:
- North Star Metric: The single metric that best captures the value delivered to users (e.g., weekly active users completing core action)
- Leading Indicators: Metrics that predict movement in the North Star (e.g., activation rate, feature adoption, session frequency)
- Guardrail Metrics: Metrics that must NOT degrade (e.g., page load time, error rate, unsubscribe rate, support ticket volume)
For each metric, define:
- Precise definition (what counts, what doesn't)
- Data source and calculation method
- Current baseline (if known)
- Target threshold
Step 2: Design Event Taxonomy
Establish a consistent naming convention:
- Category: Feature area (e.g.,
editor, dashboard, onboarding)
- Action: User action or system event (e.g.,
clicked, viewed, completed, errored)
- Label: Specific element or variant (e.g.,
save_button, sidebar_nav, dark_mode)
- Value: Numeric value if applicable (e.g., duration, count, score)
Naming rules:
- Use snake_case for all event names
- Format:
category.action.label (e.g., editor.clicked.save_button)
- Keep consistent across platforms (web, mobile, API)
- Version events when schema changes (
v2.editor.clicked.save_button)
Step 3: Specify Event Properties
For each trackable interaction, define:
| Event Name |
Properties |
Type |
Required |
Description |
feature.action.label |
user_id |
string |
yes |
Anonymous user identifier |
|
session_id |
string |
yes |
Current session |
|
timestamp |
ISO 8601 |
yes |
Event time |
|
[custom props] |
... |
... |
Feature-specific data |
Include:
- Common properties (present on every event)
- Feature-specific properties
- Context properties (page, referrer, device, viewport)
Step 4: Plan Funnel Instrumentation
For each key user flow:
- Define funnel stages (each stage = a specific event)
- Identify drop-off measurement points between stages
- Design recovery tracking (users who drop off then return)
- Plan cohort segmentation (new vs returning, plan type, entry source)
[Stage 1: View] → [Stage 2: Engage] → [Stage 3: Convert] → [Stage 4: Retain]
100% 65% 30% 20%
↓ 35% drop ↓ 35% drop ↓ 10% drop
[Exit survey?] [Tooltip help?] [Follow-up email?]
Step 5: Design A/B Test Framework
For each planned experiment:
- Experiment name: Descriptive, following convention (e.g.,
onboarding_v2_simplified_flow)
- Hypothesis: "If we [change], then [metric] will [improve/decrease] because [reason]"
- Variants: Control (A) and treatment(s) (B, C...)
- Allocation: Percentage split per variant (typically 50/50 for two variants)
- Sample size: Calculate minimum detectable effect (MDE) with 80% power, 95% significance
- Duration: Estimated time to reach sample size based on traffic
- Guardrails: Metrics to monitor for negative effects during the test
Step 6: Define Success Criteria
For each experiment:
- Primary metric: The one metric that determines success
- Minimum detectable effect: The smallest improvement worth shipping (e.g., +5% conversion)
- Statistical significance threshold: Typically p < 0.05
- Practical significance: Is the effect size meaningful even if statistically significant?
- Decision framework:
- Significant positive result → Ship to 100%
- Significant negative result → Revert and analyze
- No significant result → Extend test or abandon
- Mixed results (primary up, guardrail down) → Investigate and decide
Step 7: Plan Data Pipeline and Storage
- Collection method: Client-side SDK, server-side events, or hybrid
- Transport: Real-time streaming vs batch upload
- Storage: Analytics warehouse, time-series database, or SaaS platform
- Retention: How long to keep raw events vs aggregated data
- Access: Who can query the data, dashboards to create
- Privacy: PII handling, consent tracking, GDPR/CCPA compliance
Output Format
Metrics Hierarchy
North Star: [Metric Name]
├── Leading: [Indicator 1]
├── Leading: [Indicator 2]
├── Leading: [Indicator 3]
├── Guardrail: [Metric A] (must not decrease)
└── Guardrail: [Metric B] (must stay below threshold)
Event Catalog
| Event Name |
Description |
Properties |
Trigger |
category.action.label |
... |
{prop1, prop2, ...} |
User clicks X |
| ... |
... |
... |
... |
Funnel Diagram
[Stage 1] ──→ [Stage 2] ──→ [Stage 3] ──→ [Stage 4]
100% ___% ___% ___%
A/B Test Plan
| Experiment |
Hypothesis |
Variants |
Sample Size |
Duration |
Primary Metric |
| ... |
If..., then... |
A/B |
... |
... weeks |
... |
Quality Checks
Evolution Notes
1---2name: analytics-design3description: Telemetry events, A/B test instrumentation, and success metrics design4---56# Analytics Design78## Purpose910Design a comprehensive measurement strategy including metrics hierarchy, event taxonomy, funnel instrumentation, and A/B test framework to ensure features can be evaluated with data.1112## Inputs1314- Feature or product area to instrument15- Business goals and key questions to answer16- Existing analytics infrastructure (tools, event patterns, naming conventions)17- Privacy requirements and data retention policies18- Target user segments for experimentation1920## Process2122### Step 1: Define Key Metrics Hierarchy2324Build a three-tier metrics structure:25- **North Star Metric:** The single metric that best captures the value delivered to users (e.g., weekly active users completing core action)26- **Leading Indicators:** Metrics that predict movement in the North Star (e.g., activation rate, feature adoption, session frequency)27- **Guardrail Metrics:** Metrics that must NOT degrade (e.g., page load time, error rate, unsubscribe rate, support ticket volume)2829For each metric, define:30- Precise definition (what counts, what doesn't)31- Data source and calculation method32- Current baseline (if known)33- Target threshold3435### Step 2: Design Event Taxonomy3637Establish a consistent naming convention:38- **Category:** Feature area (e.g., `editor`, `dashboard`, `onboarding`)39- **Action:** User action or system event (e.g., `clicked`, `viewed`, `completed`, `errored`)40- **Label:** Specific element or variant (e.g., `save_button`, `sidebar_nav`, `dark_mode`)41- **Value:** Numeric value if applicable (e.g., duration, count, score)4243Naming rules:44- Use snake_case for all event names45- Format: `category.action.label` (e.g., `editor.clicked.save_button`)46- Keep consistent across platforms (web, mobile, API)47- Version events when schema changes (`v2.editor.clicked.save_button`)4849### Step 3: Specify Event Properties5051For each trackable interaction, define:5253| Event Name | Properties | Type | Required | Description |54|------------|-----------|------|----------|-------------|55| `feature.action.label` | user_id | string | yes | Anonymous user identifier |56| | session_id | string | yes | Current session |57| | timestamp | ISO 8601 | yes | Event time |58| | [custom props] | ... | ... | Feature-specific data |5960Include:61- Common properties (present on every event)62- Feature-specific properties63- Context properties (page, referrer, device, viewport)6465### Step 4: Plan Funnel Instrumentation6667For each key user flow:68- Define funnel stages (each stage = a specific event)69- Identify drop-off measurement points between stages70- Design recovery tracking (users who drop off then return)71- Plan cohort segmentation (new vs returning, plan type, entry source)7273```74[Stage 1: View] → [Stage 2: Engage] → [Stage 3: Convert] → [Stage 4: Retain]75 100% 65% 30% 20%76 ↓ 35% drop ↓ 35% drop ↓ 10% drop77 [Exit survey?] [Tooltip help?] [Follow-up email?]78```7980### Step 5: Design A/B Test Framework8182For each planned experiment:83- **Experiment name:** Descriptive, following convention (e.g., `onboarding_v2_simplified_flow`)84- **Hypothesis:** "If we [change], then [metric] will [improve/decrease] because [reason]"85- **Variants:** Control (A) and treatment(s) (B, C...)86- **Allocation:** Percentage split per variant (typically 50/50 for two variants)87- **Sample size:** Calculate minimum detectable effect (MDE) with 80% power, 95% significance88- **Duration:** Estimated time to reach sample size based on traffic89- **Guardrails:** Metrics to monitor for negative effects during the test9091### Step 6: Define Success Criteria9293For each experiment:94- **Primary metric:** The one metric that determines success95- **Minimum detectable effect:** The smallest improvement worth shipping (e.g., +5% conversion)96- **Statistical significance threshold:** Typically p < 0.0597- **Practical significance:** Is the effect size meaningful even if statistically significant?98- **Decision framework:**99 - Significant positive result → Ship to 100%100 - Significant negative result → Revert and analyze101 - No significant result → Extend test or abandon102 - Mixed results (primary up, guardrail down) → Investigate and decide103104### Step 7: Plan Data Pipeline and Storage105106- **Collection method:** Client-side SDK, server-side events, or hybrid107- **Transport:** Real-time streaming vs batch upload108- **Storage:** Analytics warehouse, time-series database, or SaaS platform109- **Retention:** How long to keep raw events vs aggregated data110- **Access:** Who can query the data, dashboards to create111- **Privacy:** PII handling, consent tracking, GDPR/CCPA compliance112113## Output Format114115### Metrics Hierarchy116117```118North Star: [Metric Name]119 ├── Leading: [Indicator 1]120 ├── Leading: [Indicator 2]121 ├── Leading: [Indicator 3]122 ├── Guardrail: [Metric A] (must not decrease)123 └── Guardrail: [Metric B] (must stay below threshold)124```125126### Event Catalog127128| Event Name | Description | Properties | Trigger |129|------------|-------------|-----------|---------|130| `category.action.label` | ... | `{prop1, prop2, ...}` | User clicks X |131| ... | ... | ... | ... |132133### Funnel Diagram134135```136[Stage 1] ──→ [Stage 2] ──→ [Stage 3] ──→ [Stage 4]137 100% ___% ___% ___%138```139140### A/B Test Plan141142| Experiment | Hypothesis | Variants | Sample Size | Duration | Primary Metric |143|------------|-----------|----------|-------------|----------|----------------|144| ... | If..., then... | A/B | ... | ... weeks | ... |145146## Quality Checks147148- [ ] North star metric is clearly defined with calculation method149- [ ] Event taxonomy follows consistent naming convention150- [ ] All key user interactions have corresponding events151- [ ] Funnels have defined stages with drop-off measurement152- [ ] A/B tests have hypotheses, sample size calculations, and duration estimates153- [ ] Success criteria include both statistical and practical significance154- [ ] Privacy and data retention requirements addressed155- [ ] Guardrail metrics defined for each experiment156157## Evolution Notes158<!-- Observations appended after each use -->