Analytics
Design or fix analytics implementation—events, conversions, UTM, GA4/GTM—so solo builders can tell if marketing and product changes actually work.
Overview
Analytics is an agent skill most often used in Grow (also Launch and Validate) that sets up, improves, and audits analytics tracking so solo builders can measure conversions and marketing results.
Install
npx skills add https://github.com/coreyhaines31/marketingskills --skill analyticsWhat is this skill?
- Starts from business context: decisions, key conversions, current stack, and compliance constraints
- Reads `.agents/product-marketing.md` (or legacy paths) before re-asking positioning questions
- Covers GA4, GTM, conversion and event tracking, UTM discipline, and multi-tool stacks (Mixpanel, Segment)
- Separates implementation auditing ("are my events firing") from experiment measurement (points to ab-testing skill)
- Applies core measurement principles before recommending tags or event schemas
- Skill metadata version 2.0.0
- Initial assessment covers business context, current state, and technical context before implementation
Adoption & trust: 15.7k installs on skills.sh; 32.4k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You shipped pages and campaigns but cannot confidently answer whether events fire, conversions count, or channels deserve spend.
Who is it for?
Founders wiring GA4/GTM or product analytics for the first time or debugging broken attribution on a live SaaS or marketing site.
Skip if: Pure A/B test design and readouts—use the ab-testing skill instead—and not for teams without any defined key conversions yet.
When should I use this skill?
User mentions set up tracking, GA4, GTM, conversion/event tracking, UTM, attribution, Mixpanel, Segment, or asks how to measure if marketing is working.
What do I get? / Deliverables
You leave with a clearer tracking plan, tool-aligned implementation steps, and measurement that ties back to conversions—ready to validate with QA and iterate funnels.
- Tracking plan with events, properties, and conversion definitions
- Implementation and audit checklist aligned to the chosen stack
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Grow is the canonical shelf because the skill optimizes ongoing measurement and decision-quality after you have something to track. Analytics subphase matches tracking plans, event taxonomy, attribution, and tool implementation called out in triggers.
Where it fits
Audit whether signup and upgrade events fire correctly in GA4 after a pricing change.
Standardize UTM parameters before running multi-channel launch campaigns.
Define primary conversion and supporting events before scaling traffic to a waitlist page.
Map lifecycle milestones to Mixpanel or Segment for retention decisions.
How it compares
Skill-guided tracking plan and implementation, not a hosted analytics product or MCP connector by itself.
Common Questions / FAQ
Who is analytics for?
Solo builders and small teams who own their web or app stack and need GA4, GTM, or product analytics implemented with marketing-relevant events.
When should I use analytics?
In Grow to audit funnels and lifecycle metrics; at Launch when adding campaign UTMs and conversion pixels; in Validate when defining what success means before you scale spend.
Is analytics safe to install?
It may guide tag and API changes that touch production tracking; review GTM/container edits and PII policies, and check the Security Audits panel on this Prism page before install.
Workflow Chain
Requires first: product marketing
SKILL.md
READMESKILL.md - Analytics
# 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. ## Initial Assessment **Check for product marketing context first:** If `.agents/product-marketing.md` exists (or `.claude/product-marketing.md`, or the legacy `product-marketing-context.md` filename, 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 --- ## 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 ###