Analytics

---
name: analytics
description: Marketing measurement methodology — tracking plans, event taxonomy and naming, funnel models, attribution models, UTM conventions, dashboards and reporting cadence, and reading the numbers. Use when the user says "set up tracking", "GA4", "conversion tracking", "event tracking", "tracking plan", "UTM parameters", "GTM", "tag manager", "which channel gets credit", "our numbers don't match", "are my events firing", "how do I measure this", or asks how to know whether something is working.
allowed-tools: Read, Write, Glob, Grep
---

# Analytics — Marketing Measurement

> Most analytics setups collect everything and answer nothing. This skill starts from the decision, works backwards to the event, and stops there.

## When this skill activates

**Implicit:** "set up tracking for X", "what should we measure", "our conversion numbers don't match the database", "which channel should get credit", "build a tracking plan", "what UTMs should we use", "why is this event firing twice".
**Explicit:** "Use the analytics skill to [task]."
**Routed from:** `/mk:campaign` (Phase 9 — Measure; skill listed in the command's skill set), `/mk:growth referral` (referral tracking design), and the `campaign-manager` agent when it closes the measure → optimize loop.

## Scope

Covers:
- Tracking plans — the event/property/trigger table that a dev team can implement from.
- Event taxonomy and naming conventions (object_action), property standards, PII exclusion.
- Funnel modelling — step sequences, per-step drop-off, where to instrument.
- Attribution models — what each model over- and under-credits, and when to switch.
- UTM conventions and campaign taxonomy.
- Dashboards + reporting cadence — which number is looked at daily, weekly, quarterly.
- Interpreting the numbers: discrepancies between tools, consent/adblock gaps, duplicate events.
- Instrumentation design for GA4 + GTM (what to fire, with what parameters) — see `references/`.

Does NOT cover:
- Conversion-rate diagnosis and fixes → [[cro]] (this skill supplies the data CRO acts on).
- Ad-platform reporting and bid decisions → [[ads]].
- Organic search performance analysis → [[seo-audit]], ranking drift → [[seo-drift]].
- Launch-metric goal setting → [[launch]].
- Statistical A/B test design and significance calls — **no ClauKit skill owns this.** This skill can define the events an experiment needs; it will not declare a winner. Flag the gap rather than improvising a stats verdict.

**Boundary with the data-access skills.** This skill owns *methodology* — what to measure, how to model it, how to read it. It does not fetch data:
- `skills/automation/mcp-ga4/` — GA4 reads through `mcp__ga4__*` tools, with manual CSV-export fallback.
- `skills/automation/mcp-gsc/` — Search Console reads through `mcp__gsc__*` tools, same fallback.
- [[seo-google]] — direct REST against Google's own APIs (PSI/CrUX, GSC, Indexing API, GA4 Data API) when the MCP wrappers don't expose what's needed.

Rule: this skill decides *which* report to pull and what the result means; those skills pull it. Don't duplicate their auth, tool-call, or export instructions here.

## Core principles

1. **Track for decisions, not data.** Every event must map to a decision someone will actually make. If no decision changes, don't instrument it.
2. **Start from the question.** What do you need to know → what action follows → what event proves it. Work backwards, never forwards from "what can we capture".
3. **Name things once.** Conventions get set before the first event ships; renaming after the fact splits history.
4. **Clean data beats more data.** Validate, monitor, and prune. A trusted small set outperforms a large unaudited one.

## Tracking plan framework

The deliverable is a table a developer can implement without asking follow-ups:

| Event name | Description | Properties | Trigger | Decision it informs |
|---|---|---|---|---|
| `signup_completed` | User finishes signup | `method`, `plan`, `source` | Success page / API 201 | Channel budget allocation |

Event types to cover:

| Type | Examples |
|---|---|
| Pageviews | Automatic, enriched with content metadata |
| User actions | CTA clicks, form submits, feature usage |
| System events | Signup completed, purchase, subscription changed |
| Custom conversions | Goal completions, funnel-stage transitions |

Full event lists by business type (marketing site, product, monetization, e-commerce, B2B/SaaS): `references/event-library.md`.

## Event naming

Format: **object_action**, lowercase, underscores.

```
signup_completed
cta_hero_clicked
form_submitted
checkout_payment_completed
```

- Be specific — `cta_hero_clicked` beats `button_clicked`.
- Context belongs in properties, not in the event name (don't create `cta_hero_clicked_pricing`).
- No spaces, no special characters, no camelCase mixed with snake_case.
- Document every naming decision; the plan is the contract.

## Essential events

**Marketing site**

| Event | Properties |
|---|---|
| `cta_clicked` | `button_text`, `cta_location`, `page` |
| `form_submitted` | `form_name`, `form_location` |
| `signup_completed` | `method`, `plan`, `source` |
| `demo_requested` | `company_size`, `industry` |

**Product / app**

| Event | Properties |
|---|---|
| `onboarding_step_completed` | `step_number`, `step_name` |
| `first_key_action_completed` | `action_type` |
| `feature_used` | `feature_name`, `feature_category` |
| `purchase_completed` | `plan`, `value`, `currency`, `transaction_id` |
| `subscription_cancelled` | `plan`, `reason`, `tenure` |

## Event properties

| Category | Properties |
|---|---|
| Page | `page_title`, `page_location`, `page_referrer` |
| User | `user_id`, `user_type`, `account_id`, `plan_type` |
| Campaign | `source`, `medium`, `campaign`, `content`, `term` |
| Product | `product_id`, `product_name`, `category`, `price`, `quantity` |

Rules: consistent names across events; don't re-send what the platform already collects automatically; **never put PII in a property** (no emails, names, phone numbers, raw addresses — use opaque IDs).

## Funnel modelling

A funnel is an ordered event sequence plus the drop-off between each pair. Instrument every step, not just the endpoints — an endpoint-only funnel tells you that you lost people, not where.

**Signup funnel:** `signup_started` → `signup_step_completed` (per step) → `signup_completed` → `onboarding_started` → `first_key_action_completed`

**Purchase funnel:** `pricing_viewed` → `plan_selected` → `checkout_started` → `payment_info_entered` → `purchase_completed`

**E-commerce funnel:** `product_viewed` → `product_added_to_cart` → `cart_viewed` → `checkout_started` → `shipping_info_entered` → `payment_info_entered` → `purchase_completed`

Reading it:
- **Step conversion rate** = step N+1 count ÷ step N count. Rank steps by absolute users lost, not by rate — a 40% drop late in a thin funnel may cost fewer users than a 10% drop at the top.
- **Segment before concluding.** A flat overall rate often hides one device, one channel, or one plan tier collapsing.
- The largest absolute-loss step is the handoff to [[cro]].

## Attribution models

Attribution assigns conversion credit across the touchpoints that preceded it. No model is correct; each is a different question.

| Model | Credit | Over-credits | Use when |
|---|---|---|---|
| Last click / last non-direct | 100% to final touch | Bottom-funnel, branded search, retargeting | Short cycles; a baseline everyone understands |
| First click | 100% to first touch | Top-funnel discovery channels | Judging awareness spend |
| Linear | Split evenly | Long, noisy paths | Long B2B cycles with many assisting touches |
| Time decay | Weighted toward recent | Closing channels | Cycles where recency genuinely drives the close |
| Position-based (40/20/40) | First + last emphasized | Discovery and closing, ignores the middle | You care about "who found them, who closed them" |
| Data-driven (platform) | Modelled from observed paths | Whatever the platform can see | Enough conversion volume; accept it's a black box |

Practical rules:
- **Pick one model as the reporting default** and state it on every dashboard. Switching models mid-quarter creates fake trends.
- **Compare two models to find assist value** — a channel that looks weak on last-click and strong on first-click is a discovery channel; don't cut it on last-click alone.
- Platform-reported conversions (ad platforms self-attributing) will exceed analytics-reported conversions. That's a definitional gap, not a bug — see below.
- Click-based attribution cannot see dark social, word of mouth, or offline. Where those matter, pair the model with a self-reported-attribution field ("how did you hear about us?") on the signup form and reconcile directionally.

## UTM strategy

| Parameter | Purpose | Example |
|---|---|---|
| `utm_source` | Specific origin | `google`, `linkedin`, `newsletter` |
| `utm_medium` | Channel class | `cpc`, `paid-social`, `email`, `organic-social` |
| `utm_campaign` | Campaign identifier | `spring_sale_2026` |
| `utm_content` | Variant/placement | `hero_cta`, `footer_banner` |
| `utm_term` | Paid search keyword | `running+shoes` |

- Lowercase everything — `Google` and `google` become two rows forever.
- Pick underscores *or* hyphens and never mix.
- Specific but short: `blog_footer_cta`, not `cta1`.
- Keep a single UTM registry file so two people don't invent two spellings of the same campaign.
- Never UTM-tag internal links — it restarts the session and destroys the original source.

## Dashboards and cadence

Build three tiers; one metric owner each. If a number has no owner and no decision attached, cut it.

| Tier | Cadence | Contents | Question answered |
|---|---|---|---|
| Health | Daily / on-alert | Traffic, conversions, error rate, spend pacing | Is anything broken right now? |
| Performance | Weekly | Channel × conversions, funnel step rates, CAC, cost per conversion | What do we change this week? |
| Strategic | Monthly / quarterly | Cohort retention, LTV:CAC, channel mix trend, attribution-model comparison | Is the mix still right? |

Rules: annotate every dashboard with the attribution model and date range; log releases and campaign launches as annotations so spikes are explainable later; compare like-for-like windows (28-day, not "this month vs last month" with unequal weekday counts).

## Validation and debugging

Validation checklist before a tracking plan is called done:

- [ ] Events fire on the intended trigger, once.
- [ ] Property values populate (no `undefined`, no `(not set)`).
- [ ] No duplicate events (double containers, double-bound listeners).
- [ ] Works on mobile and in at least two browsers.
- [ ] Conversions register with the intended counting method.
- [ ] No PII in any property.

| Symptom | Check first |
|---|---|
| Event not firing | Trigger condition; container actually loaded; consent state blocking it |
| Wrong or empty values | Property path; data-layer shape; push happening after the tag reads it |
| Duplicate events | Two containers; trigger matching twice; SPA route change firing again |
| Analytics < platform/database | Consent denials, ad blockers, client-side loss, session-timeout and lookback-window definitions differing |
| Analytics ≠ ad platform | Self-attribution + view-through windows on the platform side vs click-based last-touch in analytics |

When two tools disagree, reconcile **definitions first, implementation second**: same date range, same timezone, same conversion definition, same attribution window. Most "broken tracking" is a definition mismatch.

## Privacy and consent

- Cookie consent is required in the EU/UK and under several other regimes — collect it before analytics storage is granted.
- Consent mode (or equivalent conditional loading) means a real, measurable share of traffic is modelled or missing. Report the consent rate alongside the numbers, never silently.
- No PII in event properties, ever. Use hashed or opaque IDs.
- Set data retention deliberately and support user-deletion requests.
- Only collect what a decision needs — the smallest defensible dataset is also the cheapest to keep compliant.

## Key concepts

- **Track for decisions** — an event with no downstream decision is cost without value.
- **Object_action naming** — one convention, set before implementation, never renamed in place.
- **Step drop-off** — the funnel's value is between the steps, not at the ends.
- **Model choice, not model truth** — attribution answers a question you chose; state which one.
- **Definition mismatch** — most tool-to-tool discrepancies are date/timezone/window/definition differences, not bugs.
- **Consent gap** — the modelled/missing share of traffic that must be quoted with every consent-affected number.

## Output

- `plans/marketing/<campaign>/analytics-plan.md` — tracking plan (event table, properties, conversions, custom dimensions).
- `plans/marketing/<campaign>/measurement-report.md` — funnel + channel readout with the attribution model stated.
- `plans/marketing/<campaign>/utm-registry.md` — campaign UTM taxonomy.
- Inline recommendations for quick checks.

Tracking-plan document skeleton:

```markdown
# <Site/Product> Tracking Plan
Tools: <GA4, GTM, ...> · Attribution default: <model> · Updated: <YYMMDD>

## Events
| Event | Description | Properties | Trigger | Decision |

## Custom dimensions
| Name | Scope | Parameter |

## Conversions
| Conversion | Event | Counting |
```

## Cross-references

- `references/event-library.md` — full event taxonomy by business type + funnel sequences
- `references/ga4-implementation.md` — GA4 configuration, custom events, conversions, dimensions, audiences, debugging
- `references/gtm-implementation.md` — GTM container structure, data-layer patterns, tag configs, consent mode
- `plans/marketing-context.md` — required hub (ICP, positioning, goals)
- `.claude/workflows/marketing-rules.md` — quality gates
- `.claude/workflows/automation-rules.md` — MCP usage policy, PII redaction
- `skills/automation/mcp-ga4/SKILL.md`, `skills/automation/mcp-gsc/SKILL.md` — data access (GA4 / GSC)
- [[seo-google]] — direct Google API access when the MCP wrappers fall short
- [[cro]] — acts on the drop-off this skill locates
- `.claude/skills/marketing/README.md` — full kit overview

## Provenance

Imported from `coreyhaines31/marketingskills` (MIT, © 2025 Corey Haines) and adapted for KitForge: KitForge frontmatter, `/mk:` routing, `plans/marketing/` outputs, explicit boundary against the `mcp-ga4`/`mcp-gsc`/`seo-google` data-access skills; funnel-reading, attribution-model, and dashboard-cadence sections added because ClauKit has no separate `attribution` skill; upstream `ab-testing`, `revops`, and tools-registry references dropped (no ClauKit equivalent).