Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
tracking-plan
description
Master analytics tracking plan for PLG and B2B SaaS — unified event taxonomy, pixel strategy (1P and 3P tagging), marketing attribution architecture, CDP implementation (Segment, Rudderstack), product analytics (Amplitude, Mixpanel, PostHog), CRM tracking (HubSpot, Salesforce), and analytics infrastructure design. Use when building a complete tracking plan, designing analytics architecture, implementing product analytics, or aligning marketing and product tracking. Triggers on: "tracking plan", "analytics plan", "event tracking architecture", "pixel strategy", "analytics for PLG", "SaaS analytics".
license
MIT
compatibility
Claude Code, Jesse, Codex, Hermes, Windsurf, OpenCode, Gemini CLI, Copilot, Zed, VS Code, Goose
metadata
{"version":"1.0.0","author":"LeadMagic","category":"analytics","tags":["tracking-plan","analytics","event-tracking","pixels","attribution","cdp","plg","product-analytics"],"related_skills":["event-analytics","gtm-metrics","campaign-analytics","1p-tagging-pixels","attribution","a-b-testing","cs-analytics-dashboards"],"frameworks":["Segment — Customer Data Platform (CDP) and Tracking Plan spec","Amplitude — Product analytics and behavioral cohorts","PostHog — Open-source product analytics","Mixpanel — Event-based analytics","Google Analytics 4 (GA4) — Web analytics and conversions","Elena Verna (Reforge/Amplitude) — PLG analytics models","Brian Balfour (Reforge) — Growth models and tracking","OpenView — PLG benchmarks and metrics","Avo — Tracking plan governance and code generation"]}
Analytics Tracking Plan
Overview
Most companies have tracking — they just don't have a plan. Events fire into
the void. Pixels fire twice (or never). Marketing attributes credit to the
wrong channel. Product doesn't know what marketing tracks. Nobody trusts the
data. The mistake: adding tracking ad-hoc without a unified plan. This skill
covers the complete analytics tracking architecture for PLG and B2B SaaS:
event taxonomy, pixel strategy, attribution architecture, CDP implementation,
and the analytics stack that makes it all work together.
Authoritative Foundations
Segment — Customer Data Platform (CDP) and Tracking Plan spec — Customer Data Platform (CDP) and Tracking Plan spec
Amplitude — Product analytics and behavioral cohorts — Product analytics and behavioral cohorts
What it is: A single source of truth for every event, property, and
destination in your analytics infrastructure. Every developer, marketer,
and analyst references the same document.
The Tracking Plan template (Google Sheets / Notion / Avo):
TRACKING PLAN — [Company]
SHEET 1: EVENT CATALOG
| Event Name | Category | Trigger | Properties | Destinations | Owner | Status |
|---|---|---|---|---|---|---|
| Signed Up | Account | POST /auth/signup | plan, source, referrer, utm_* | Segment→GA4,Amplitude,HubSpot | Eng | Live |
| Feature Used | Usage | Client-side click | feature_name, context | Segment→Amplitude | Product | Live |
| ... | | | | | | |
SHEET 2: PROPERTY CATALOG
| Property Name | Type | Example Values | Events Using | Description |
|---|---|---|---|---|---|
| plan | string | starter, growth, enterprise | Signed Up, Upgraded, Downgraded | Customer's subscription plan |
| source | string | google_ads, linkedin, referral | Signed Up | Acquisition channel |
| ... | | | | |
SHEET 3: DESTINATIONS
| Destination | Purpose | Events Routed | Owner |
|---|---|---|---|
| Amplitude | Product analytics — retention, funnels, cohorts | All usage + account events | Product |
| GA4 | Web analytics — traffic, conversions, ad attribution | Page views, signups, conversions | Marketing |
| HubSpot | CRM — lead scoring, lifecycle stages | Account events, email events | RevOps |
| Intercom | Event-triggered messaging | All usage + milestone events | CS |
| Data Warehouse | BI — cross-functional reporting | All events | Data |
SHEET 4: IDENTITIES
| Identity Type | How It's Set | When | Example |
|---|---|---|---|
| anonymous_id | Auto-generated (cookie/localStorage) | First visit | uuid |
| user_id | Backend generates on signup | After authentication | user_abc123 |
| group_id | Workspace/account ID | After login (B2B) | ws_xyz789 |
| email | identify() call | After signup/login | user@company.com |
SHEET 5: UTM / ATTRIBUTION
| Parameter | Required | Example | Purpose |
|---|---|---|---|
| utm_source | Yes | google, linkedin, newsletter | Acquisition source |
| utm_medium | Yes | cpc, organic, email, social | Channel type |
| utm_campaign | Yes | q1_launch, black_friday | Campaign name |
| utm_content | Optional | variant_a, cta_hero | Creative variant |
| utm_term | Optional | cold+email+tool | Keyword (paid search) |
| referrer | Auto | document.referrer | Referring URL |
| landing_page | Auto | window.location.pathname | First page visited |
| gclid | Auto | Google Ads auto-tagging | Google Click ID |
| fbclid | Auto | Facebook auto-tagging | Facebook Click ID |
Phase 2: Event Taxonomy for PLG and SaaS
Build the event taxonomy in references/event-taxonomy.md when the task needs the full PLG/SaaS event library. In SKILL.md, capture only the chosen event groups, naming rules, owners, and QA gates.
Phase 3: Pixel Strategy (1P and 3P Tagging)
The progressive pixel architecture:
TIER 1: FIRST-PARTY (Essential — always on)
└─ CDP (Segment/Rudderstack) — server-side SDK
No ad blockers can block server-side events.
Critical events (signup, payment, subscription) go server-side.
TIER 2: FIRST-PARTY (Product — always on)
└─ CDP (Segment/Rudderstack) — client-side SDK
Behavioral events. Some ad-blocker loss (~15-30%).
Acceptable for product analytics (you don't need 100% of
behavioral events — you need enough to see patterns).
TIER 3: MARKETING PIXELS (Conditional — consent required)
└─ GA4 (Google Analytics)
└─ Google Ads Conversion Tracking
└─ LinkedIn Insight Tag
└─ Meta (Facebook) Pixel
└─ Twitter/X Pixel
└─ Reddit Pixel
└─ Quora Pixel
└─ Microsoft (Bing) Ads UET
TIER 4: RETARGETING (Conditional — consent required)
└─ Google Ads Remarketing
└─ LinkedIn Matched Audiences
└─ Meta Custom Audiences
└─ AdRoll / Criteo (if using)
Pixel implementation hierarchy:
Server-side (via CDP) — PRIMARY:
Segment/Rudderstack → Google Ads (enhanced conversions)
Segment/Rudderstack → Meta CAPI (Conversions API)
Segment/Rudderstack → LinkedIn CAPI
These are ad-blocker resistant and privacy-safe.
Client-side (via GTM) — SECONDARY:
Google Tag Manager (GTM) loads marketing pixels
Consent management (Cookiebot/OneTrust) gates all marketing pixels
GTM fires only when user has consented to marketing cookies
Server-side GTM (sGTM) — ADVANCED:
GTM server-side container proxies all pixel requests
Your server → sGTM → marketing platforms
First-party domain for tracking (e.g., analytics.yourdomain.com)
This is the gold standard for privacy-safe, ad-blocker-resistant tracking
Pixel audit checklist:
□ Every pixel has a purpose (no "we might use this someday" pixels)
□ Consent management gates all marketing pixels
□ Pixels fire ONCE (no duplicate firing from GTM + CDP)
□ Server-side tracking for critical conversion events
□ All pixels documented: what fires when, what data it sends
□ Regular audit: remove unused pixels (they slow down the page)
□ GDPR: marketing pixels only fire with consent
□ CCPA: "Do Not Sell" respected — data sharing pixels disabled
Phase 4: Attribution Architecture
Multi-touch attribution model:
FIRST-Touch: Which channel introduced them?
→ UTM params captured at first visit. Stored in cookie + user profile.
LAST-Touch: Which channel closed them?
→ UTM params at conversion. Overwrites first-touch for "last-click" view.
MULTI-Touch: Which channels touched them along the way?
→ Track every touchpoint: ad click, email click, organic visit, referral.
→ Model: linear (equal credit), time-decay (recent = more credit),
U-shaped (first + last = most credit), W-shaped (first + MQL + SQL + close).
SELF-REPORTED: "How did you hear about us?"
→ Form field on signup/demo. Most reliable single data point.
→ Categorize responses: Search, Social, Referral, Podcast, Event, Other.
Attribution data flow:
TOUCHPOINT CAPTURE:
1. First visit → capture UTM + referrer → store in first-touch cookie
2. Subsequent visits → append to visit log (timestamp, source, medium)
3. Signup/Conversion → capture UTM + referrer → store in user profile
4. CRM → Sales tags opportunity source (can override self-reported)
ATTRIBUTION REPORTING:
- HubSpot/Salesforce: Original Source, Latest Source, Source Drill-Down
- GA4: Traffic Acquisition, User Acquisition reports
- BI Tool (Metabase/Looker/Mode): Custom multi-touch models
- Attribution tool (Dreamdata/HockeyStack/Attribution): B2B journey mapping
Phase 5: CDP Implementation
Use references/cdp-implementation.md for the full Segment/RudderStack/mParticle/warehouse routing patterns. In the main response, summarize chosen destination routing, identity policy, suppression rules, and QA checks.
CDP implemented (server-side for critical events, client-side for behavioral)
All marketing pixels consent-gated (no pre-ticked boxes)
Server-side tracking for signup, payment, subscription changes
UTM parameters captured and persisted to user profile
Attribution model documented (first-touch + last-touch + multi-touch)
PLG funnel measured at every stage transition
Event dictionary maintained — no undocumented events
PII audit complete — no personal data in event properties
Monthly tracking plan review on calendar
Quality Check
Before delivering, verify:
Output matches the user's stated request
Named frameworks or sources are reflected in the recommendation
The deliverable is specific enough for an agent to execute
Any assumptions, risks, or dependencies are explicit
No unsupported claims, invented facts, or private/internal references are included
Common Pitfalls
Tracking without a plan. Events fire into the void. No one knows what
"button_clicked_3" means. The data is worthless. Fix: Tracking plan
document FIRST. Implementation second. Every event has a name, purpose,
properties, destinations, and owner.
Client-side only. Ad blockers block 15-30% of client-side tracking.
Critical events (signup, payment, subscription) are lost. Fix: Server-side
tracking for revenue-critical events. CDP server-side SDK.
Duplicate events. Segment fires "Signed Up." GTM also fires "SignUp."
GA4 shows 2x signups. Nobody knows which number is real. Fix: One source
of truth per event. Audit for duplicates. GTM ONLY handles marketing pixels,
not core events.
Marketing and product tracking disconnected. Marketing sees signups.
Product sees activation. Nobody connects the two — can't answer "which
marketing channel produces the most activated users?" Fix: Same event
taxonomy. Same user_id. CDP routes to both marketing and product tools.
No attribution on signup. UTM params captured on visit but lost on
signup. "Where did this customer come from?" = shrug. Fix: Capture UTM
params on first visit. Persist to user profile on signup. Always.
PII in event properties.email: "john@company.com" tracked in every
event. This is a privacy violation and a security risk. Fix: Use user_id.
Store PII in your database, not your event pipeline. Only identify() call
carries user traits — regular track() calls do not.
Execution Artifacts
references/framework-notes.md — named frameworks, citation anchors, and operating assumptions
templates/output-template.md — copy-paste deliverable structure for the user
scripts/check-output.py — local checklist validator for required sections
This skill includes lightweight artifacts the agent can load on demand:
Use the artifacts when the user asks for an implementation-ready deliverable, a repeatable workflow, or a quality check rather than generic advice.
