analytics
When the user wants to set up, improve, or audit analytics tracking and measurement. Also use when the user mentions "set up tracking," "GA4," "Google Analytics," "conversion tracking," "event tracking," "UTM parameters," "tag manager," "GTM," "analytics implementation," "tracking...
- License 许可
- MIT
- 最近更新
- 2026-10-22
- Stars
- ★ 1
- Forks
- 0
01 前言 Front Matter
- name
- analytics
- risk
- unknown
- source
- https://github.com/coreyhaines31/marketingskills/tree/main/skills/analytics
- license
- MIT
- date_added
- 1782864000000
- description
- When the user wants to set up, improve, or audit analytics tracking and measurement. Also use when the user mentions "set up tracking," "GA4," "Google Analytics," "conversion tracking," "event tracking," "UTM parameters," "tag manager," "GTM," "analytics implementation," "tracking...
- source_repo
- coreyhaines31/marketingskills
- source_type
- community
- license_source
- https://github.com/coreyhaines31/marketingskills/blob/main/LICENSE
02 资源文件 4
- 参考文档evals/evals.json6.2 KB
- 参考文档references/event-library.md8.5 KB
- 参考文档references/ga4-implementation.md6.2 KB
- 参考文档references/gtm-implementation.md7.4 KB
03 SKILL.md 正文
Analytics Tracking
When to Use
Use this skill when you need when the user wants to set up, improve, or audit analytics tracking and measurement. Also use when the user mentions "set up tracking," "GA4," "Google Analytics," "conversion tracking," "event tracking," "UTM parameters," "tag manager," "GTM," "analytics implementation," "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:
- Business Context - What decisions will this data inform? What are key conversions?
- Current State - What tracking exists? What tools are in use?
- 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
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_clickedvs.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
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
- Create GA4 property and data stream
- Install gtag.js or GTM
- Enable enhanced measurement
- Configure custom events
- Mark conversions in Admin
Custom Event Example
gtag('event', 'signup_completed', {
'method': 'email',
'plan': 'free'
});
For detailed GA4 implementation: See 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
dataLayer.push({
'event': 'form_submitted',
'form_name': 'contact',
'form_location': 'footer'
});
For detailed GTM implementation: See 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, notcta1 - 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 |
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 Format
Tracking Plan Document
# [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
- What tools are you using (GA4, Mixpanel, etc.)?
- What key actions do you want to track?
- What decisions will this data inform?
- Who implements - dev team or marketing?
- Are there privacy/consent requirements?
- What's already tracked?
Tool Integrations
For implementation, see the tools registry. Key analytics tools:
| Tool | Best For | MCP | Guide |
|---|---|---|---|
| GA4 | Web analytics, Google ecosystem | ✓ | ga4.md |
| Mixpanel | Product analytics, event tracking | - | mixpanel.md |
| Amplitude | Product analytics, cohort analysis | - | amplitude.md |
| PostHog | Open-source analytics, session replay | - | posthog.md |
| Segment | Customer data platform, routing | - | segment.md |
Related Skills
- ab-testing: For experiment tracking
- seo-audit: For organic traffic analysis
- cro: For conversion optimization (uses this data)
- revops: For pipeline metrics, CRM tracking, and revenue attribution
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
04 同仓库更多 Skills
testing-best-practices
Laravel test design and review. Use when selecting coverage, naming or structuring tests, choosing assertions or test data, isolating dependencies, testing HTTP or security boundaries, improving suite performance, or reviewing test value. Use framework guidance or search-docs for Pest and PHPUnit syntax.
tailwindcss-development
Always invoke when the user's message includes 'tailwind' in any form. Also invoke for: building responsive grid layouts (multi-column card grids, product grids), flex/grid page structures (dashboards with sidebars, fixed topbars, mobile-toggle navs), styling UI components (cards, tables, navbars, pricing sections, forms, inputs, badges), adding dark mode variants, fixing spacing or typography, and Tailwind v3/v4 work. The core use case: writing or fixing Tailwind utility classes in HTML templates (Blade, JSX, Vue). Skip for backend PHP logic, database queries, API routes, JavaScript with no HTML/CSS component, CSS file audits, build tool configuration, and vanilla CSS.
laravel-best-practices
Apply this skill whenever writing, reviewing, or refactoring Laravel PHP code. This includes creating or modifying controllers, models, migrations, form requests, policies, jobs, scheduled commands, service classes, and Eloquent queries. Triggers for N+1 and query performance issues, caching strategies, authorization and security patterns, validation, error handling, queue and job configuration, route definitions, and architectural decisions. Also use for Laravel code reviews and refactoring existing Laravel code to follow best practices. Covers any task involving Laravel backend PHP code patterns.
infer-conventions
Use this skill to analyze how a Laravel application is actually written and record its conventions as shared rules. Trigger when the user wants to detect, infer, document, or standardize project conventions or coding style, set up or grow `.ai/rules`, resolve mixed or conflicting patterns (e.g. "are we using Form Requests or inline validation?"), or onboard agents and teammates to "how we do things here". Covers: a systematic sweep of ~49 Laravel convention dimensions (validation, models, architecture, testing, frontend, database, console), open-ended house-pattern discovery, conflict reporting, and recording rules scoped to the right paths via the Boost `record-rule` MCP tool. Only run this skill when the user explicitly asks for it; never start a sweep as part of another task. Do not use for one-off code review, enforcing formatting a linter already handles, or editing `.ai/rules` files by hand.
inertia-react-development
Develops Inertia.js v2 React client-side applications. Activates when creating React pages, forms, or navigation; using <Link>, <Form>, useForm, or router; working with deferred props, prefetching, or polling; or when user mentions React with Inertia, React pages, React forms, or React navigation.
deploying-to-cloud
Deploys and manages Laravel applications on Laravel Cloud using the `cloud` CLI. Use when the user wants to deploy an app, ship to Cloud, create or manage applications, environments, databases, caches, object storage, queues, domains, instances, background processes, secrets, compute, scheduled tasks, or Laravel Cloud infrastructure; or check billing, usage, or spend. Triggers on deployment, shipping, Cloud management, environment setup, database provisioning, billing or usage queries, the `cloud` CLI, and Laravel Cloud deployment troubleshooting.