Skilllibrary analytics-instrumentation
install
source · Clone the upstream repo
git clone https://github.com/merceralex397-collab/skilllibrary
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/merceralex397-collab/skilllibrary "$T" && mkdir -p ~/.claude/skills && cp -r "$T/08-web-frontend-and-design/analytics-instrumentation" ~/.claude/skills/merceralex397-collab-skilllibrary-analytics-instrumentation && rm -rf "$T"
manifest:
08-web-frontend-and-design/analytics-instrumentation/SKILL.mdsource content
Purpose
Instrument product analytics with consistent event naming, type-safe wrappers, and funnel tracking using GA4, Segment, or PostHog.
When to use this skill
- adding analytics tracking to a web app (page views, custom events, conversions)
- defining event naming conventions or a tracking plan
- instrumenting funnels or feature usage metrics
- wrapping analytics calls in React hooks for reuse
Do not use this skill when
- the task is E2E testing — prefer
testing-web - the task is SEO metadata — prefer
seo-structured-data - the task is backend logging/monitoring — different patterns
Procedure
- Identify provider — check for GA4 (
), Segment (gtag.js
), PostHog, or custom data layer.analytics.js - Define naming convention — use
pattern inobject_action
:snake_case
,signup_completed
.item_added_to_cart - Create analytics wrapper — thin abstraction over provider for portability. Type the event names and properties.
- Implement tracking — add calls at user action points. Keep tracking code separate from business logic.
- Verify events — use GA4 DebugView, Segment Debugger, or Network tab to confirm events fire with correct properties.
- Document tracking plan — maintain a living doc mapping events to user actions and properties.
Event naming rules
Pattern: <noun>_<past_tense_verb> signup_completed, product_viewed, item_added_to_cart, search_performed Bad: click, pageView123, btnSubmit, homepage Rules: - snake_case (GA4) or Title Case (Segment) — be consistent - Context in properties, not name — item_added_to_cart + {category: "shoes"} - No PII in event properties — no emails, no passwords
React analytics hook
import { useCallback } from 'react'; function trackEvent(name: string, props?: Record<string, unknown>) { window.gtag?.('event', name, props); window.analytics?.track(name, props); } export function useTrackEvent() { return useCallback((name: string, props?: Record<string, unknown>) => { trackEvent(name, props); }, []); } // Usage function SignupButton() { const track = useTrackEvent(); return ( <button onClick={() => { track('signup_button_clicked', { location: 'hero' }); }}> Sign Up </button> ); }
Funnel tracking
Signup Funnel: 1. signup_page_viewed 2. signup_form_started (first field interaction) 3. signup_form_submitted 4. email_verified 5. onboarding_completed Each step includes: funnel_name, step_number, timestamp (auto by provider)
Decision rules
- Track user actions, not implementation events — "signup_completed" not "POST /api/signup succeeded".
- Keep properties flat — avoid nested objects; most analytics tools cannot handle them.
- Separate tracking from business logic — use hooks, middleware, or event listeners.
- Instrument progressively — start with critical funnel events, add engagement events later.
- Verify before shipping — use debug tools to confirm events fire with correct properties.
References
- https://developers.google.com/analytics/devguides/collection/ga4
- https://segment.com/docs/connections/sources/catalog/libraries/website/javascript/
Related skills
— metadata alongside analyticsseo-structured-data
— typed analytics hooksreact-typescript
— analytics impact on performancefrontend-performance