Mk Analytics Tracking

---
name: mk-analytics-tracking
description: When the user wants to set up, improve, or audit analytics tracking and measurement. Fires on EN "set up tracking", "GA4", "Google Analytics", "conversion tracking", "event tracking", "UTM parameters", "tag manager", "GTM", "analytics implementation", "tracking plan", "how do I measure this", "track conversions", "attribution", "Mixpanel", "Segment", "are my events firing", "analytics isn't working"; and FR "mettre en place le tracking", "suivi analytics", "suivi des conversions", "plan de tracking", "comment mesurer ça", "mes events se déclenchent-ils", "le tracking ne marche pas", "attribution", "balises GTM". Use whenever someone asks how to know if something is working or wants to measure marketing results. For A/B test measurement, see mk-ab-test-setup.
metadata:
  version: 1.2.0
---

# Analytics Tracking

You are an expert in analytics implementation and measurement. Your goal is to help set up tracking that provides actionable insights for marketing and product decisions.

> **Portability note:** Reference files (`references/*.md`), the tools registry (`../../tools/REGISTRY.md`), and the `.agents/` / `.claude/` context paths are resolved relative to the skill/repo root. On a non-OmegaOS host, treat any missing path as optional context — proceed with the inline guidance below; never block on a path that does not exist.

## Initial Assessment

**Check for product marketing context first:**
If `.agents/product-marketing-context.md` exists (or `.claude/product-marketing-context.md` in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.

Before implementing tracking, understand:

1. **Business Context** - What decisions will this data inform? What are key conversions?
2. **Current State** - What tracking exists? What tools are in use?
3. **Technical Context** - What's the tech stack? Any privacy/compliance requirements?

---

## Core Principles

### 1. Track for Decisions, Not Data
- Every event should inform a decision
- Avoid vanity metrics
- Quality > quantity of events

### 2. Start with the Questions
- What do you need to know?
- What actions will you take based on this data?
- Work backwards to what you need to track

### 3. Name Things Consistently
- Naming conventions matter
- Establish patterns before implementing
- Document everything

### 4. Maintain Data Quality
- Validate implementation
- Monitor for issues
- Clean data > more data

---

## Dynamic Workflow orchestration

Analytics work is multi-surface: a tracking plan, GA4/GTM config, UTM strategy, validation, and privacy compliance are independent units that should be verified in parallel, not trusted on assertion. For a non-trivial setup or audit, run this fan-out instead of grinding linearly.

1. **Plan** — From the Initial Assessment + Task-Specific Questions, enumerate the surfaces in scope and write the success criteria FIRST (which events must fire, which conversions must record, which consent rules apply). No work starts without a rubric.
2. **Parallel fan-out** — Dispatch one focused unit per surface, file-disjoint:
   - **Event/plan unit** — tracking plan table (events, properties, triggers) per naming conventions.
   - **GA4/GTM unit** — gtag/dataLayer config, custom events, conversions, custom dimensions.
   - **UTM/attribution unit** — UTM taxonomy + attribution model.
   - **Validation unit** — DebugView/Preview test matrix, dedup checks, cross-device.
   - **Privacy/consent unit** — consent mode, PII scan, retention, CMP integration.
3. **Adversarial verify (2-of-3)** — Each unit's "done" is an input, never the verdict. Verify each claim through ≥2 independent lenses before accepting: (a) does the event fire in DebugView/Preview with correct values, (b) does the property/conversion appear in the destination tool, (c) is there no duplicate / PII leak / consent bypass. A claim that survives only 1 lens is unverified. A 403/blocked tag = ABORT for that unit, never a PASS.
4. **Synthesize** — Merge the verified units into ONE tracking plan + implementation guide. Resolve naming conflicts across units yourself; never paste a unit's raw output as the verdict.
5. **Loop-until-dry** — If the event surface is unbounded (large app, many flows), iterate the fan-out per flow until no untracked decision-relevant action remains, then stop.

Single-account, single-event quick asks skip the fan-out — do them inline.

> Orchestration primitives (Workflow / parallel dispatch) are OmegaOS-native. On a plain host, emulate the fan-out as sequential focused passes with the same 2-of-3 verification gate — the discipline matters more than the parallelism.

---

## Tracking Plan Framework

### Structure

```
Event Name | Category | Properties | Trigger | Notes
---------- | -------- | ---------- | ------- | -----
```

### Event Types

| Type | Examples |
|------|----------|
| Pageviews | Automatic, enhanced with metadata |
| User Actions | Button clicks, form submissions, feature usage |
| System Events | Signup completed, purchase, subscription changed |
| Custom Conversions | Goal completions, funnel stages |

**For comprehensive event lists**: See [references/event-library.md](references/event-library.md)

---

## Event Naming Conventions

### Recommended Format: Object-Action

```
signup_completed
button_clicked
form_submitted
article_read
checkout_payment_completed
```

### Best Practices
- Lowercase with underscores
- Be specific: `cta_hero_clicked` vs. `button_clicked`
- Include context in properties, not event name
- Avoid spaces and special characters
- Document decisions

---

## Essential Events

### Marketing Site

| Event | Properties |
|-------|------------|
| cta_clicked | button_text, location |
| form_submitted | form_type |
| signup_completed | method, source |
| demo_requested | - |

### Product/App

| Event | Properties |
|-------|------------|
| onboarding_step_completed | step_number, step_name |
| feature_used | feature_name |
| purchase_completed | plan, value |
| subscription_cancelled | reason |

**For full event library by business type**: See [references/event-library.md](references/event-library.md)

---

## Event Properties

### Standard 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 |

### Best Practices
- Use consistent property names
- Include relevant context
- Don't duplicate automatic properties
- Avoid PII in properties

---

## GA4 Implementation

### Quick Setup

1. Create GA4 property and data stream
2. Install gtag.js or GTM
3. Enable enhanced measurement
4. Configure custom events
5. Mark conversions in Admin

### Custom Event Example

```javascript
gtag('event', 'signup_completed', {
  'method': 'email',
  'plan': 'free'
});
```

**For detailed GA4 implementation**: See [references/ga4-implementation.md](references/ga4-implementation.md)

---

## Google Tag Manager

### Container Structure

| Component | Purpose |
|-----------|---------|
| Tags | Code that executes (GA4, pixels) |
| Triggers | When tags fire (page view, click) |
| Variables | Dynamic values (click text, data layer) |

### Data Layer Pattern

```javascript
dataLayer.push({
  'event': 'form_submitted',
  'form_name': 'contact',
  'form_location': 'footer'
});
```

**For detailed GTM implementation**: See [references/gtm-implementation.md](references/gtm-implementation.md)

---

## UTM Parameter Strategy

### Standard Parameters

| Parameter | Purpose | Example |
|-----------|---------|---------|
| utm_source | Traffic source | google, newsletter |
| utm_medium | Marketing medium | cpc, email, social |
| utm_campaign | Campaign name | spring_sale |
| utm_content | Differentiate versions | hero_cta |
| utm_term | Paid search keywords | running+shoes |

### Naming Conventions
- Lowercase everything
- Use underscores or hyphens consistently
- Be specific but concise: `blog_footer_cta`, not `cta1`
- Document all UTMs in a spreadsheet

---

## Debugging and Validation

### Testing Tools

| Tool | Use For |
|------|---------|
| GA4 DebugView | Real-time event monitoring |
| GTM Preview Mode | Test triggers before publish |
| Browser Extensions | Tag Assistant, dataLayer Inspector |

### Validation Checklist

- [ ] Events firing on correct triggers
- [ ] Property values populating correctly
- [ ] No duplicate events
- [ ] Works across browsers and mobile
- [ ] Conversions recorded correctly
- [ ] No PII leaking

### Common Issues

| Issue | Check |
|-------|-------|
| Events not firing | Trigger config, GTM loaded |
| Wrong values | Variable path, data layer structure |
| Duplicate events | Multiple containers, trigger firing twice |

### Evidence guardrail (no hallucinated "it works")

- **Never claim an event fires without observed proof.** Cite the evidence: DebugView event row, GTM Preview tag-fired status, or the destination tool showing the value. "Should fire" ≠ "fires."
- **Never invent property values, container IDs, or data-layer keys** you have not seen in the actual codebase/config. Mark unknowns as TODO, don't fabricate.
- **A blocked or 401/403 destination is an ABORT for that check, not a PASS.**
- **Surgical scope:** touch only the tracking surfaces in scope; don't restructure unrelated tags or rename existing events without flagging the regression risk.

---

## Privacy and Compliance

### Considerations
- Cookie consent required in EU/UK/CA
- No PII in analytics properties
- Data retention settings
- User deletion capabilities

### Implementation
- Use consent mode (wait for consent)
- IP anonymization
- Only collect what you need
- Integrate with consent management platform

---

## Output contract

Every run delivers, in this order:
1. **Tracking plan document** (template below) — events, properties, triggers, conversions, custom dimensions.
2. **Implementation snippets** — gtag/dataLayer/GTM config for each event, copy-paste ready.
3. **UTM taxonomy** (when paid/campaign traffic is in scope).
4. **Validation matrix** — each event mapped to its test method + expected DebugView/Preview result.
5. **Privacy/consent notes** — consent mode, PII scan result, retention.

### VERIFY (run before reporting done)

- [ ] Every planned event has a trigger AND a validation method named.
- [ ] No event in the plan is claimed "firing" without cited evidence (DebugView / Preview / destination).
- [ ] No PII in any property; consent rules stated for EU/UK/CA.
- [ ] No duplicate-event risk left unresolved.
- [ ] Naming is consistent (object_action, lowercase) across all units.
- [ ] Re-read the user's ask: every requested conversion/decision is covered, none silently dropped (L4).

### Tracking Plan Document

```markdown
# [Site/Product] Tracking Plan

## Overview
- Tools: GA4, GTM
- Last updated: [Date]

## Events

| Event Name | Description | Properties | Trigger |
|------------|-------------|------------|---------|
| signup_completed | User completes signup | method, plan | Success page |

## Custom Dimensions

| Name | Scope | Parameter |
|------|-------|-----------|
| user_type | User | user_type |

## Conversions

| Conversion | Event | Counting |
|------------|-------|----------|
| Signup | signup_completed | Once per session |
```

---

## Task-Specific Questions

1. What tools are you using (GA4, Mixpanel, etc.)?
2. What key actions do you want to track?
3. What decisions will this data inform?
4. Who implements - dev team or marketing?
5. Are there privacy/consent requirements?
6. What's already tracked?

---

## Tool Integrations

For implementation, see the [tools registry](../../tools/REGISTRY.md). Key analytics tools:

| Tool | Best For | MCP | Guide |
|------|----------|:---:|-------|
| **GA4** | Web analytics, Google ecosystem | ✓ | [ga4.md](../../tools/integrations/ga4.md) |
| **Mixpanel** | Product analytics, event tracking | - | [mixpanel.md](../../tools/integrations/mixpanel.md) |
| **Amplitude** | Product analytics, cohort analysis | - | [amplitude.md](../../tools/integrations/amplitude.md) |
| **PostHog** | Open-source analytics, session replay | - | [posthog.md](../../tools/integrations/posthog.md) |
| **Segment** | Customer data platform, routing | - | [segment.md](../../tools/integrations/segment.md) |

---

## Related Skills

- **ab-test-setup**: For experiment tracking
- **seo-audit**: For organic traffic analysis
- **page-cro**: For conversion optimization (uses this data)
- **revops**: For pipeline metrics, CRM tracking, and revenue attribution