analytics-strategy

# Analytics Strategy

Design measurement frameworks that produce decisions, not just dashboards. Stack-agnostic. Tool-agnostic.

This skill is for measurement planning. For conversion optimization, use `cro-optimization`. For SEO measurement specifically, use `seo-onpage` and adjacent SEO skills.

---

## When to use

- Setting up analytics on a new product or site
- Auditing existing analytics setup
- Designing dashboards for a team or business
- Defining KPIs and a north star metric
- Building event taxonomies for product analytics
- Designing attribution models for marketing
- Translating business questions into measurement plans

## When NOT to use

- Conversion testing or optimization (use `cro-optimization`)
- SEO performance measurement (use SEO skills)
- Pure data infrastructure decisions (different domain)

---

## Required inputs

- The business or product context (what does success look like)
- The audience for the analytics (who needs to make what decisions)
- The current measurement state (existing tools, tracking, gaps)
- The questions the team needs to answer

---

## The framework: 4 layers

A complete measurement strategy covers all four. Each layer feeds the next.

### 1. North star and KPI hierarchy

The single metric that captures the most important outcome, plus the supporting metrics.

**North star metric:**

- One metric. Singular.
- Captures customer-perceived value.
- Leads to revenue, but isn't revenue itself (revenue is too far downstream).
- Examples: weekly active users, completed jobs, revenue-generating sessions, hours of value delivered.

**Underneath the north star, the KPI hierarchy:**

```
North star metric
├── Acquisition KPI (how new users enter)
├── Activation KPI (when new users get value)
├── Engagement KPI (how often users return)
├── Retention KPI (how many stick over time)
└── Monetization KPI (how value translates to revenue)
```

This is the "AARRR" or "pirate metrics" framework. It works because it covers the full lifecycle.

### 2. Event taxonomy

The vocabulary the product uses to describe what users do.

**Event design principles:**

- **Verb + noun.** `signed_up`, `created_project`, `completed_checkout`. Past tense, snake_case.
- **One event per discrete action.** Not "interacted_with_modal" - too vague. Specifically `opened_modal_X`, `closed_modal_X`, `confirmed_in_modal_X`.
- **Properties capture context.** Each event has properties (key-value pairs) for context. `signed_up` has properties like `signup_method`, `referrer`, `plan`.
- **Standardize property names.** `user_id` everywhere, not `userId` here and `id` there.
- **Document everything.** A tracking plan that lives nowhere is a tracking plan no one follows.

**Event coverage:**

- All key user actions tracked
- All conversion points tracked
- All errors tracked
- All page views tracked (with consistent properties)
- All button clicks that matter (not all button clicks - that's noise)

**Anti-patterns:**

- 500+ events with no documentation
- Inconsistent naming (`buttonClicked`, `Button Clicked`, `clicked_button`)
- Property keys that vary across events
- Events fired client-side that should be server-side (and vice versa)
- PII in event properties (privacy issue and tooling issue)

### 3. Dashboards and reports

The interface between data and decisions.

**Dashboard design principles:**

- **One audience per dashboard.** Executive dashboard != product team dashboard. Different metrics, different cadence.
- **One question per chart.** A chart should answer one question, not three.
- **Annotations matter.** Note launches, experiments, holidays, outages. A spike means nothing without context.
- **Context comparisons.** "10,000 signups this month" - compared to what? Last month, last year, target?
- **Lead with the action.** What does this dashboard help someone decide?

**Common dashboard types:**

| Dashboard | Audience | Metrics | Cadence |
|---|---|---|---|
| Executive | Leadership | North star, top 3 KPIs, big-picture trends | Weekly review |
| Product | Product team | Funnel metrics, feature adoption, retention | Daily / weekly |
| Marketing | Marketing team | Acquisition by channel, CAC, attribution | Daily / weekly |
| Operations | Ops / on-call | Performance, errors, capacity | Real-time |
| Custom (per team) | Specific team | Their specific KPIs | Their cadence |

### 4. Attribution and segmentation

How to connect cause and effect.

**Attribution models:**

- **First-touch.** Credit the first interaction. Useful for awareness understanding.
- **Last-touch.** Credit the final interaction before conversion. Default in many tools, often misleading.
- **Linear.** Spread credit equally across touches. Avoids over-crediting any single channel.
- **Time-decay.** Recent touches get more credit. Reasonable middle ground.
- **Position-based.** First and last get more credit, middle touches less.
- **Data-driven (algorithmic).** Tools like Google Analytics 4 use ML. Black box but increasingly the default.

For most businesses: pick one primary attribution model, use multiple secondary models for validation.

**Segmentation principles:**

- Segment by what causes different behavior, not by what's easy to track
- Useful segments: source/channel, plan tier, geography, device, cohort (signup date)
- Less useful: demographic guesses without behavioral validation

---

## The tracking plan document

Output of the analytics strategy. A living document.

**Structure:**

1. **Goals and KPIs.** Business objectives, north star, KPI hierarchy.
2. **Event catalog.** Every event, with properties, when fired, why tracked.
3. **User properties.** Persistent attributes (plan, signup_date, role).
4. **Page taxonomy.** Page categories, page properties.
5. **Naming conventions.** Snake_case, verb_noun, etc.
6. **Implementation notes.** Client-side vs server-side, SDK details, sampling.
7. **Privacy and compliance.** PII rules, consent handling, data retention.
8. **Governance.** Who can add events, re