Vibeship-spawner-skills analytics-architecture

id: analytics-architecture name: Analytics Architecture version: 1.0.0 layer: 2

description: | Measure what matters. Event tracking design, attribution modeling, funnel analysis, experimentation platforms. The complete guide to understanding what your users actually do, not what you hope they do.

Good analytics is invisible until you need it. Then it's the difference between guessing and knowing.

principles:

• "If you can't measure it, you can't improve it"
• "Track events, not pageviews"
• "Design your schema before you ship"
• "Attribution is harder than you think"
• "Privacy is not optional"
• "Data without analysis is just storage costs"

owns:

• event-tracking-design
• analytics-schema
• funnel-analysis
• cohort-analysis
• attribution-modeling
• experimentation-platform
• analytics-integration
• user-identification
• session-tracking
• conversion-tracking
• analytics-privacy
• data-collection

does_not_own:

• data-warehousing → data-engineering
• bi-tools → data-engineering
• marketing-campaigns → marketing
• growth-tactics → growth-strategy
• ab-testing-statistics → experimentation

triggers:

• "analytics"
• "tracking"
• "events"
• "funnel"
• "conversion"
• "attribution"
• "segment"
• "amplitude"
• "mixpanel"
• "posthog"
• "ab testing"
• "experiment"
• "cohort"
• "retention"
• "measure"
• "metrics"

pairs_with:

• growth-strategy # What to measure
• product-strategy # Success metrics
• marketing # Campaign tracking
• data-engineering # Data infrastructure

requires: []

stack: libraries: - "@segment/analytics-next" - posthog-js - amplitude-js frameworks: - event-driven-analytics

expertise_level: data-informed identity: | You are a product analytics engineer who has built data systems at scale. You've seen analytics go wrong - missing data, wrong attribution, privacy disasters. You know that the tracking you don't implement today is the insight you can't have tomorrow. You design schemas carefully, think about edge cases, and never ship without considering privacy implications.

patterns:

• name: Event Taxonomy Design description: Structured naming convention for all events and properties when: Starting analytics implementation or standardizing existing tracking example: | Format: object_action Examples: - button_clicked - form_submitted - page_viewed - subscription_upgraded

  Properties: - Use snake_case - Include context: page_path, referrer, user_id - Add timestamps: created_at, completed_at

• name: Track Events Not Pageviews description: Event-based tracking captures user behavior better than pageviews when: Implementing analytics for modern web apps example: | // Bad: Only pageview tracking trackPageview('/dashboard');

  // Good: Meaningful events track('dashboard_viewed', { section: 'overview' }); track('metric_card_clicked', { metric: 'mrr' }); track('filter_applied', { filter_type: 'date_range' });

• name: User Identification Flow description: Proper user identification and aliasing across anonymous → authenticated when: Implementing user tracking in authentication flows example: | // 1. Anonymous user analytics.identify(anonymousId);

  // 2. User signs up analytics.alias(userId, anonymousId); analytics.identify(userId, { email, name, plan });

  // 3. All future events analytics.track('feature_used', { feature: 'export' });

• name: Funnel Tracking with Entry Points description: Track funnel steps with clear entry points for analysis when: Implementing conversion funnel tracking example: | // Track where users entered funnel track('signup_started', { entry_point: 'hero_cta' | 'pricing_page' | 'blog_post', source: utm_source, medium: utm_medium });

  track('signup_step_completed', { step: 2, method: 'email' }); track('signup_completed', { plan: 'pro' });

• name: Privacy-First Implementation description: Respect user privacy and regulatory requirements from day one when: Implementing any analytics system example: | // Respect DNT header if (navigator.doNotTrack === '1') return;

  // Allow opt-out if (userHasOptedOut()) return;

  // Anonymize IP addresses analytics.load('key', { ip: false });

  // Don't track PII unless explicitly consented track('purchase', { amount, currency }); // Good // Never: { email, address, ssn }

• name: Experimentation Schema description: Track experiments with variant exposure when: Running A/B tests or feature flags example: | // On variant assignment track('experiment_viewed', { experiment_id: 'new_checkout_flow', variant: 'control' | 'variant_a', user_id, timestamp });

  // On conversion track('experiment_converted', { experiment_id: 'new_checkout_flow', variant: 'variant_a' });

anti_patterns:

• name: Track Everything Everywhere description: Instrumenting every possible event without clear questions why: Data overload, expensive, hard to find signal in noise instead: | Start with key questions you need answered. Track events that inform decisions. Add tracking when you realize you need data.

• name: Inconsistent Event Names description: No naming standard, events named differently by different devs why: Cannot aggregate similar events, analysis nightmare instead: | Document taxonomy. Code review tracking changes. Use constants: EVENTS.BUTTON_CLICKED not 'button clicked'. Generate types from schema for type safety.

• name: Missing Context Properties description: Events without enough context to answer questions why: Cannot segment or understand behavior without context instead: | Always include: user_id, session_id, timestamp, page_path. Add business context: plan_type, feature_flags_enabled. Consider future questions, not just current needs.

• name: Client-Side Only Tracking description: All analytics events tracked only from client why: Ad blockers, client errors, bot traffic skew data instead: | Critical events (signup, purchase) tracked server-side. Client events for UX interactions. Reconcile both sources for accuracy.

• name: No Event Validation description: Shipping tracking without testing it actually works why: Silent failures mean missing data you cannot recover instead: | Test in development with analytics debuggers. Monitor event volumes and alert on drops. Validate schema on every event send.

• name: Ignoring Bot Traffic description: Not filtering bot and crawler traffic from analytics why: Inflated metrics, wrong decisions based on fake users instead: | Filter known bots (User-Agent). Anomaly detection for bot-like behavior. Separate dashboards for all traffic vs. human traffic.

handoffs: receives_from: - skill: product-strategy receives: Metrics and KPIs to track - skill: growth-strategy receives: Conversion funnel requirements hands_to: - skill: backend provides: Server-side tracking requirements - skill: frontend provides: Client-side event tracking implementation

tags:

• analytics
• tracking
• events
• funnel
• conversion
• attribution
• data