Marketer pack
Claude Skill
Analytics Tracking Planner
Designs a tracking plan that answers real decisions — events, naming, conversions — instead of collecting vanity data.
What it does
Builds or audits analytics tracking (GA4, GTM, product analytics) starting from the decisions you need to make, then works back to the minimal set of events, a consistent naming convention, and clear conversion definitions. Built so the data is trustworthy and acted on — not a pile of misfiring, inconsistently-named events nobody believes.
When to use
- ✓Setting up tracking on a new site or app
- ✓You can't tell whether something is actually working
- ✓Events are messy, inconsistent, or no longer trusted
When not to use
- ✗Deep data-warehouse / data-engineering modeling beyond marketing tracking
- ✗A/B test measurement specifically (that's a different skill)
Install
Download the .zip, then unzip into your Claude skills folder.
mkdir -p ~/.claude/skills
unzip ~/Downloads/analytics-tracking-planner.zip -d ~/.claude/skills/
# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.SKILL.md
SKILL.md
---
name: analytics-tracking-planner
description: Use when setting up, auditing, or improving analytics tracking. Triggers on "set up tracking", "GA4", "GTM", "tracking plan", "event tracking", "conversion tracking", "how do I measure this", "are my events firing".
---
# Analytics Tracking Planner
Track for decisions, not for data. Every event should map to a decision someone will actually make; if no decision depends on it, it's a vanity metric and it's noise. A small, trustworthy event set beats an exhaustive one nobody believes.
## Start from the questions
Work backward: what do you need to know, what will you do differently based on the answer, and only then — what's the minimal event that tells you. "What's our activation rate, and what do we change if it's low?" defines the events; a list of events in search of a question does not.
## Name things consistently — before implementing
Set the naming convention first (object-action like `signup_completed`, consistent casing, defined properties) and document it. Inconsistent naming (`Signup`, `sign_up`, `completed-signup`) is the most common reason a dataset becomes untrustworthy and un-joinable.
## Define conversions explicitly
Name the handful of events that are conversions and what each one means. Ambiguous conversions make every downstream report (attribution, funnels, ROAS) argue with itself.
## Data quality
- One source of truth per metric; don't measure the same thing three ways
- Test that events actually fire (and fire once) before trusting a report
- Prune events that inform no decision — fewer, trusted events beat many doubtful ones
## Audit mode
For an existing setup: list every event, mark each keep / rename / kill against the decision it informs, flag duplicates and misfires, and propose the consistent taxonomy to migrate to.
## Anti-patterns
- Tracking everything "just in case" and trusting none of it
- Inconsistent event/property naming
- Vanity events tied to no decision
- Shipping tracking without QA that events fire correctly
- Multiple conflicting definitions of the same conversion
Example prompts
Once installed, try these prompts in Claude:
- Design a GA4 + GTM tracking plan for our SaaS — signup, activation, upgrade. Give me the event taxonomy and naming.
- Our analytics is full of events nobody trusts. Audit it and tell me what to keep, rename, or kill.