Set Up Analytics Tracking and Event Measurement

Guides setting up, improving, or auditing analytics tracking so the resulting data actually informs marketing and product decisions rather than accumulating vanity metrics. Before implementing anything it establishes business context (what decisions the data will inform, what tools already exist, the tech stack, and privacy/compliance requirements), then applies four core principles: track for decisions, not data; start from the question you need answered and work backward to the event; name things consistently (recommended object_action format - signup_completed, cta_hero_clicked - lowercase with underscores, context in properties rather than the event name); and maintain data quality over data volume. It defines a tracking-plan structure (Event Name / Category / Properties / Trigger / Notes) across four event types - pageviews, user actions, system events, and custom conversions - with standard property categories (page, user, campaign, product) and a companion event-library reference covering marketing-site, product/app, monetization, e-commerce, and B2B/SaaS event catalogs plus standard funnel sequences (signup: signup_started -> signup_step_completed -> signup_completed -> onboarding_started; purchase: pricing_viewed -> plan_selected -> checkout_started -> payment_info_entered -> purchase_completed).

For GA4 it covers data-stream setup, enabling enhanced measurement (automatic page_view, scroll, outbound_click, site_search, video_engagement, file_download tracking), using Google's predefined recommended events for richer reporting, custom-event dispatch via gtag('event', ...), marking conversions and their counting method (once-per-session versus every-event) in Admin, custom dimensions/metrics scoped to event/user/item, audience creation, DebugView/real-time debugging, and cross-domain and internal-traffic filtering for data quality. For Google Tag Manager it covers container structure (tags, triggers, variables), a [Type] - [Description] - [Detail] naming convention, the dataLayer.push() pattern (including clearing ecommerce: null before each e-commerce push to avoid stale item carryover), common tag configurations (GA4 Configuration/Event tags, a Facebook Pixel base and event tag), Preview mode debugging, workspace/version-note discipline, and gtag('consent', 'default'/'update', {...}) consent-mode integration. It also defines UTM parameter strategy (utm_source/medium/campaign/content/term, lowercase and specific naming like blog_footer_cta rather than cta1, documented centrally) and a validation checklist (correct triggers, populated properties, no duplicate events, cross-browser/mobile coverage, correct conversion recording, no PII leakage) alongside common-issue diagnosis (events not firing, wrong values, duplicates).

Privacy and compliance are treated as a first-class section, not an afterthought: cookie consent is required in the EU/UK/California, no PII belongs in analytics properties, data retention settings and user-deletion capability must be considered, and implementation should wait for consent (consent mode), anonymize IPs, collect only what's needed, and integrate with a consent-management platform. The final deliverable is a tracking-plan document (overview, events table, custom dimensions, conversions with counting method) the skill produces in a fixed markdown format.

Use it when the user wants to set up, improve, or audit analytics tracking and measurement - or mentions "set up tracking," "GA4," "Google Analytics," "conversion tracking," "event tracking," "UTM parameters," "tag manager," "GTM," or "analytics implementation." It checks for an existing product-marketing context file (.agents/product-marketing.md or the legacy product-marketing-context.md) before asking questions, and only asks about what isn't already covered. Its own limitations note: use it only when the task clearly matches this scope, verify commands, generated code, dependencies, credentials, and external service behavior before applying changes, and don't treat its examples as a substitute for environment-specific testing, security review, or user approval for destructive or costly actions.

Input is the analysis tools in use (GA4, Mixpanel, Amplitude, PostHog, Segment), the key actions to track, the decisions the data should inform, who implements it (dev or marketing), and any privacy/consent requirements. Output is a tracking-plan markdown document and, where relevant, working gtag.js or GTM dataLayer code - for example:

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

Covers GA4 and Google Tag Manager in depth (with an MCP integration listed for GA4 specifically), and names Mixpanel, Amplitude, PostHog, and Segment as alternative or complementary analytics tools with their own integration guides in a companion tools registry. Points to related skills for adjacent work: ab-testing for experiment tracking, seo-audit for organic traffic analysis, cro for conversion optimization that consumes this data, and revops for pipeline metrics, CRM tracking, and revenue attribution.

Marketers, product managers, and developers setting up or auditing analytics tracking who need a decision-driven event taxonomy, working GA4/GTM implementation code, and a privacy-compliant consent setup rather than an ad hoc pile of vanity-metric events. Sourced from the community marketingskills repository (coreyhaines31/marketingskills) under the MIT license, added 2026-07-01.