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-design3department: "strategist"4description: "Telemetry events, A/B test instrumentation, and success metrics design"5version: 16triggers:7 - "analytics"8 - "telemetry"9 - "tracking"10 - "A/B test"11 - "funnel"12 - "metric"13 - "experiment"14 - "instrumentation"15---1617# Analytics Design1819## Purpose2021Design a comprehensive measurement strategy including metrics hierarchy, event taxonomy, funnel instrumentation, and A/B test framework to ensure features can be evaluated with data.2223## Inputs2425- Feature or product area to instrument26- Business goals and key questions to answer27- Existing analytics infrastructure (tools, event patterns, naming conventions)28- Privacy requirements and data retention policies29- Target user segments for experimentation3031## Process3233### Step 1: Define Key Metrics Hierarchy3435Build a three-tier metrics structure:36- **North Star Metric:** The single metric that best captures the value delivered to users (e.g., weekly active users completing core action)37- **Leading Indicators:** Metrics that predict movement in the North Star (e.g., activation rate, feature adoption, session frequency)38- **Guardrail Metrics:** Metrics that must NOT degrade (e.g., page load time, error rate, unsubscribe rate, support ticket volume)3940For each metric, define:41- Precise definition (what counts, what doesn't)42- Data source and calculation method43- Current baseline (if known)44- Target threshold4546### Step 2: Design Event Taxonomy4748Establish a consistent naming convention:49- **Category:** Feature area (e.g., `editor`, `dashboard`, `onboarding`)50- **Action:** User action or system event (e.g., `clicked`, `viewed`, `completed`, `errored`)51- **Label:** Specific element or variant (e.g., `save_button`, `sidebar_nav`, `dark_mode`)52- **Value:** Numeric value if applicable (e.g., duration, count, score)5354Naming rules:55- Use snake_case for all event names56- Format: `category.action.label` (e.g., `editor.clicked.save_button`)57- Keep consistent across platforms (web, mobile, API)58- Version events when schema changes (`v2.editor.clicked.save_button`)5960### Step 3: Specify Event Properties6162For each trackable interaction, define:6364| Event Name | Properties | Type | Required | Description |65|------------|-----------|------|----------|-------------|66| `feature.action.label` | user_id | string | yes | Anonymous user identifier |67| | session_id | string | yes | Current session |68| | timestamp | ISO 8601 | yes | Event time |69| | [custom props] | ... | ... | Feature-specific data |7071Include:72- Common properties (present on every event)73- Feature-specific properties74- Context properties (page, referrer, device, viewport)7576### Step 4: Plan Funnel Instrumentation7778For each key user flow:79- Define funnel stages (each stage = a specific event)80- Identify drop-off measurement points between stages81- Design recovery tracking (users who drop off then return)82- Plan cohort segmentation (new vs returning, plan type, entry source)8384```85[Stage 1: View] → [Stage 2: Engage] → [Stage 3: Convert] → [Stage 4: Retain]86 100% 65% 30% 20%87 ↓ 35% drop ↓ 35% drop ↓ 10% drop88 [Exit survey?] [Tooltip help?] [Follow-up email?]89```9091### Step 5: Design A/B Test Framework9293For each planned experiment:94- **Experiment name:** Descriptive, following convention (e.g., `onboarding_v2_simplified_flow`)95- **Hypothesis:** "If we [change], then [metric] will [improve/decrease] because [reason]"96- **Variants:** Control (A) and treatment(s) (B, C...)97- **Allocation:** Percentage split per variant (typically 50/50 for two variants)98- **Sample size:** Calculate minimum detectable effect (MDE) with 80% power, 95% significance99- **Duration:** Estimated time to reach sample size based on traffic100- **Guardrails:** Metrics to monitor for negative effects during the test101102### Step 6: Define Success Criteria103104For each experiment:105- **Primary metric:** The one metric that determines success106- **Minimum detectable effect:** The smallest improvement worth shipping (e.g., +5% conversion)107- **Statistical significance threshold:** Typically p < 0.05108- **Practical significance:** Is the effect size meaningful even if statistically significant?109- **Decision framework:**110 - Significant positive result → Ship to 100%111 - Significant negative result → Revert and analyze112 - No significant result → Extend test or abandon113 - Mixed results (primary up, guardrail down) → Investigate and decide114115### Step 7: Plan Data Pipeline and Storage116117- **Collection method:** Client-side SDK, server-side events, or hybrid118- **Transport:** Real-time streaming vs batch upload119- **Storage:** Analytics warehouse, time-series database, or SaaS platform120- **Retention:** How long to keep raw events vs aggregated data121- **Access:** Who can query the data, dashboards to create122- **Privacy:** PII handling, consent tracking, GDPR/CCPA compliance123124## Output Format125126### Metrics Hierarchy127128```129North Star: [Metric Name]130 ├── Leading: [Indicator 1]131 ├── Leading: [Indicator 2]132 ├── Leading: [Indicator 3]133 ├── Guardrail: [Metric A] (must not decrease)134 └── Guardrail: [Metric B] (must stay below threshold)135```136137### Event Catalog138139| Event Name | Description | Properties | Trigger |140|------------|-------------|-----------|---------|141| `category.action.label` | ... | `{prop1, prop2, ...}` | User clicks X |142| ... | ... | ... | ... |143144### Funnel Diagram145146```147[Stage 1] ──→ [Stage 2] ──→ [Stage 3] ──→ [Stage 4]148 100% ___% ___% ___%149```150151### A/B Test Plan152153| Experiment | Hypothesis | Variants | Sample Size | Duration | Primary Metric |154|------------|-----------|----------|-------------|----------|----------------|155| ... | If..., then... | A/B | ... | ... weeks | ... |156157## Quality Checks158159- [ ] North star metric is clearly defined with calculation method160- [ ] Event taxonomy follows consistent naming convention161- [ ] All key user interactions have corresponding events162- [ ] Funnels have defined stages with drop-off measurement163- [ ] A/B tests have hypotheses, sample size calculations, and duration estimates164- [ ] Success criteria include both statistical and practical significance165- [ ] Privacy and data retention requirements addressed166- [ ] Guardrail metrics defined for each experiment167168## Evolution Notes169<!-- Observations appended after each use -->