analytics-tracking

name	analytics-tracking
description	Code-generation skill for implementing or fixing analytics tracking in this repo. Use only when changing tracking code, event instrumentation, attribution plumbing, or measurement-related implementation.
metadata	{"family":"quality","owner":"quality + engineering","last_reviewed":"2026-04-30T00:00:00.000Z","version":"1.0.0","source_version":"2.0.0"}

Analytics Tracking

This is a code-generation skill. Use it for measurement implementation work in the repo.

Use When

• instrumenting a CTA, funnel step, tool interaction, or outcome
• fixing duplicate or missing events
• reviewing whether tracking is meaningful and implementation-ready
• adding repo code that should emit measurement events

Do Not Use When

• the task is a generic business analytics brainstorm with no repo change
• the task is purely SEO, CRO, or copy strategy without instrumentation work

First Step

Check whether .agents/product-marketing-context.md exists.

If it exists, use it to understand the product goals before inventing events.

Core Rules

• track for decisions, not vanity
• prefer a small event set with stable names
• keep event names explicit and lowercase with underscores
• include context in properties, not in inflated event names
• do not send sensitive personal data
• do not fire duplicate events across hydration or route transitions

Repo Output Contract

Before implementing, produce a short Tracking Brief:

1. goal
2. events
3. properties
4. trigger_points
5. verification_plan

Implementation Expectations

• centralize provider calls or wrappers where practical
• keep event payloads typed
• instrument the actual user outcome when possible, not just intermediate clicks
• name events narrowly enough that future analysis is usable

Default Event Style

Good:

• cta_clicked
• tool_completed
• calculator_result_viewed
• app_download_started

Avoid:

• button_clicked
• user_did_thing
• overloaded catch-all events

Verification

Confirm:

1. the event fires exactly once per intended interaction
2. payload fields are stable
3. the event is attached to the right user journey step
4. implementation notes explain how to validate it in browser/dev tooling