{"id":"analytics-strategy","name":"analytics-strategy","summary":"イベントタクソノミー、KPI階層、ダッシュボードアーキテクチャ、アトリビューションモデル、分析実装戦略などの測定フレームワークを設計します。","body":"# Analytics Strategy\n\nDesign measurement frameworks that produce decisions, not just dashboards. Stack-agnostic. Tool-agnostic.\n\nThis skill is for measurement planning. For conversion optimization, use `cro-optimization`. For SEO measurement specifically, use `seo-onpage` and adjacent SEO skills.\n\n---\n\n## When to use\n\n- Setting up analytics on a new product or site\n- Auditing existing analytics setup\n- Designing dashboards for a team or business\n- Defining KPIs and a north star metric\n- Building event taxonomies for product analytics\n- Designing attribution models for marketing\n- Translating business questions into measurement plans\n\n## When NOT to use\n\n- Conversion testing or optimization (use `cro-optimization`)\n- SEO performance measurement (use SEO skills)\n- Pure data infrastructure decisions (different domain)\n\n---\n\n## Required inputs\n\n- The business or product context (what does success look like)\n- The audience for the analytics (who needs to make what decisions)\n- The current measurement state (existing tools, tracking, gaps)\n- The questions the team needs to answer\n\n---\n\n## The framework: 4 layers\n\nA complete measurement strategy covers all four. Each layer feeds the next.\n\n### 1. North star and KPI hierarchy\n\nThe single metric that captures the most important outcome, plus the supporting metrics.\n\n**North star metric:**\n\n- One metric. Singular.\n- Captures customer-perceived value.\n- Leads to revenue, but isn't revenue itself (revenue is too far downstream).\n- Examples: weekly active users, completed jobs, revenue-generating sessions, hours of value delivered.\n\n**Underneath the north star, the KPI hierarchy:**\n\n```\nNorth star metric\n├── Acquisition KPI (how new users enter)\n├── Activation KPI (when new users get value)\n├── Engagement KPI (how often users return)\n├── Retention KPI (how many stick over time)\n└── Monetization KPI (how value translates to revenue)\n```\n\nThis is the \"AARRR\" or \"pirate metrics\" framework. It works because it covers the full lifecycle.\n\n### 2. Event taxonomy\n\nThe vocabulary the product uses to describe what users do.\n\n**Event design principles:**\n\n- **Verb + noun.** `signed_up`, `created_project`, `completed_checkout`. Past tense, snake_case.\n- **One event per discrete action.** Not \"interacted_with_modal\" - too vague. Specifically `opened_modal_X`, `closed_modal_X`, `confirmed_in_modal_X`.\n- **Properties capture context.** Each event has properties (key-value pairs) for context. `signed_up` has properties like `signup_method`, `referrer`, `plan`.\n- **Standardize property names.** `user_id` everywhere, not `userId` here and `id` there.\n- **Document everything.** A tracking plan that lives nowhere is a tracking plan no one follows.\n\n**Event coverage:**\n\n- All key user actions tracked\n- All conversion points tracked\n- All errors tracked\n- All page views tracked (with consistent properties)\n- All button clicks that matter (not all button clicks - that's noise)\n\n**Anti-patterns:**\n\n- 500+ events with no documentation\n- Inconsistent naming (`buttonClicked`, `Button Clicked`, `clicked_button`)\n- Property keys that vary across events\n- Events fired client-side that should be server-side (and vice versa)\n- PII in event properties (privacy issue and tooling issue)\n\n### 3. Dashboards and reports\n\nThe interface between data and decisions.\n\n**Dashboard design principles:**\n\n- **One audience per dashboard.** Executive dashboard != product team dashboard. Different metrics, different cadence.\n- **One question per chart.** A chart should answer one question, not three.\n- **Annotations matter.** Note launches, experiments, holidays, outages. A spike means nothing without context.\n- **Context comparisons.** \"10,000 signups this month\" - compared to what? Last month, last year, target?\n- **Lead with the action.** What does this dashboard help someone decide?\n\n**Common dashboard types:**\n\n| Dashboard | Audience | Metrics | Cadence |\n|---|---|---|---|\n| Executive | Leadership | North star, top 3 KPIs, big-picture trends | Weekly review |\n| Product | Product team | Funnel metrics, feature adoption, retention | Daily / weekly |\n| Marketing | Marketing team | Acquisition by channel, CAC, attribution | Daily / weekly |\n| Operations | Ops / on-call | Performance, errors, capacity | Real-time |\n| Custom (per team) | Specific team | Their specific KPIs | Their cadence |\n\n### 4. Attribution and segmentation\n\nHow to connect cause and effect.\n\n**Attribution models:**\n\n- **First-touch.** Credit the first interaction. Useful for awareness understanding.\n- **Last-touch.** Credit the final interaction before conversion. Default in many tools, often misleading.\n- **Linear.** Spread credit equally across touches. Avoids over-crediting any single channel.\n- **Time-decay.** Recent touches get more credit. Reasonable middle ground.\n- **Position-based.** First and last get more credit, middle touches less.\n- **Data-driven (algorithmic).** Tools like Google Analytics 4 use ML. Black box but increasingly the default.\n\nFor most businesses: pick one primary attribution model, use multiple secondary models for validation.\n\n**Segmentation principles:**\n\n- Segment by what causes different behavior, not by what's easy to track\n- Useful segments: source/channel, plan tier, geography, device, cohort (signup date)\n- Less useful: demographic guesses without behavioral validation\n\n---\n\n## The tracking plan document\n\nOutput of the analytics strategy. A living document.\n\n**Structure:**\n\n1. **Goals and KPIs.** Business objectives, north star, KPI hierarchy.\n2. **Event catalog.** Every event, with properties, when fired, why tracked.\n3. **User properties.** Persistent attributes (plan, signup_date, role).\n4. **Page taxonomy.** Page categories, page properties.\n5. **Naming conventions.** Snake_case, verb_noun, etc.\n6. **Implementation notes.** Client-side vs server-side, SDK details, sampling.\n7. **Privacy and compliance.** PII rules, consent handling, data retention.\n8. **Governance.** Who can add events, review process, change log.\n\n---\n\n## Workflow\n\n1. **Define the questions.** What does the team need to answer? Working backward from questions to metrics works better than starting from metrics.\n2. **Define the north star.** One metric. Tested against the criteria above.\n3. **Build the KPI hierarchy.** Acquisition, activation, engagement, retention, monetization.\n4. **Audit existing tracking.** What's there? What's broken? What's missing?\n5. **Design the event taxonomy.** Cover the user journey. Document everything.\n6. **Implement with care.** Test each event. Verify properties. Catch issues in staging.\n7. **Build dashboards.** One per audience. Lead with action.\n8. **Establish review cadence.** Weekly business review, monthly KPI review, quarterly strategy review.\n9. **Govern.** Who adds events, who reviews, how changes propagate.\n\n---\n\n## Failure patterns\n\n- **Tracking everything.** Noise overwhelms signal.\n- **Tracking nothing strategic.** Page views and that's it. Cannot answer real questions.\n- **No documentation.** Tracking plan lives in someone's head.\n- **Inconsistent naming.** Same concept, three names. Reports become detective work.\n- **Events fired but never reviewed.** Tracking debt accumulates.\n- **Dashboards no one looks at.** Built for vanity, not decisions.\n- **Single attribution model treated as truth.** All models lie. Some lie usefully.\n- **PII in events.** Compliance and tooling problems.\n- **Client-side only.** Critical business events should be server-side too. Ad blockers, network issues, edge cases lose client-side events.\n- **No connection to business outcomes.** Metrics exist in a silo, never connected to revenue, retention, or strategic decisions.\n\n---\n\n## Output format\n\nDefault output: a markdown tracking plan at `analytics-tracking-plan.md` plus a dashboard inventory.\n\nTracking plan structure:\n\n```markdown\n# Tracking Plan\n\n## North star metric\n[Definition, calculation, target]\n\n## KPI hierarchy\n[Each KPI with definition, calculation, owner]\n\n## Event catalog\n| Event | When fired | Properties | Owner | Status |\n|---|---|---|---|---|\n| user_signed_up | After successful signup form submit | source, plan, referrer | Marketing | Live |\n| project_created | When user clicks Create Project | project_type, template_used | Product | Live |\n| ... | | | | |\n\n## User properties\n[List with definitions]\n\n## Naming conventions\n[Rules]\n\n## Privacy and compliance\n[Rules]\n\n## Governance\n[Process]\n```\n\n---\n\n## Reference files\n\n- [`references/event-taxonomy-template.md`](references/event-taxonomy-template.md) - Starter event catalog with patterns for common product types.","author":"@rampstackco","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/rampstackco/claude-skills/tree/main/dist/pi/.agents/skills/analytics-strategy","license":"MIT","category":"growth","lang":"en","tokens":1885,"stars":0,"calls30d":2,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[{"path":"references/event-taxonomy-template.md","size":9896,"sha256":"04ab0efbc566f2ee8e33f8e2f262ba5fd7d86edc3fb23af0eaa5c85c0737d49d"}],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[{"code":"injection.bypass","kind":"injection","where":"references/event-taxonomy-template.md:384","excerpt":"without consent","message":"instructs the agent to bypass the human","severity":"warn"}],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":[]}}