marketing-product-analytics（营销产品分析）

Product Analytics - Instrumentation & Measurement OS

Modern Best Practices (January 2026): PostHog-first, session context registration, strict event naming, North Star activation events, privacy-first attribution.

Primary sources live in data/sources.json. If web search is available, refresh time-sensitive details against official docs before giving definitive advice.

No fluff. Only executable steps, templates, and checklists.

When to Use This Skill

• Event taxonomy design: Naming conventions, event hierarchy, property structure
• Tracking plan creation: What to track, where, and why
• Marketing attribution: UTM capture, campaign tracking, source attribution
• Activation metrics: Defining and measuring user activation
• Retention analysis: Cohort analysis, churn prediction, engagement scoring
• Platform setup: PostHog, Pendo, Amplitude, Mixpanel, Heap configuration
• Data quality: Event validation, debugging, governance

Default Workflow (Use Unless User Overrides)

1. Clarify goals and constraints: business questions, lifecycle stages, identity model, privacy/consent requirements, platforms (web/mobile/backend).
2. Define the North Star value event: one canonical event that represents value received (plus the smallest set of supporting events).
3. Write the tracking plan: use assets/tracking-plan-saas.md as the starting template; define required properties and ownership.
4. Implement instrumentation: pick the platform guide in Quick Reference (PostHog/Pendo/Amplitude/Mixpanel/Heap; server-side if needed).
5. QA and harden: use assets/analytics-qa-checklist.md + references/event-quality-rules.md + references/production-hardening.md.

Core Principles

1. North Star Value Event (VITAL)

Every product must have ONE canonical activation event - the single event that means "user received real value."

Rule: Every feature event should collapse into ONE activation event with properties:

// PASS CORRECT: One event, differentiated by property
posthog.capture('value_delivered', { value_type: 'report', value_id: 'rpt_123' });
posthog.capture('value_delivered', { value_type: 'integration', value_id: 'int_456' });

// FAIL WRONG: Fragmented "value" events (harder to unify in retention/funnels)
posthog.capture('report_generated');
posthog.capture('integration_working');

2. Minimum Viable Analytics (MVA)

Start with 5-15 events, not 200. You can always add more.

For auth-heavy products, add email reliability instrumentation early:

• auth_email_requested (type: signup_confirm, magic_link, reset_password)
• auth_email_delivered / auth_email_bounced / auth_email_complained (from provider webhooks)
• auth_email_link_clicked (completion quality signal, not just send volume)

3. Session Context Registration

Register standard context once per session using posthog.register():

posthog.register({
  app_env: 'prod',
  platform: 'web',
  landing_path: window.location.pathname,
  traffic_source: deriveTrafficSource(),
  utm_source, utm_medium, utm_campaign
});

4. Event Naming Convention

Quick Reference

Implementation Checklist

### Event Correctness
- [ ] Activation event fires only when value is **visible** (not on mount)
- [ ] Event includes required properties defined in the tracking plan (e.g., `object_type`, `object_id`, `surface`, `flow`)
- [ ] Dedupe guard used where re-renders can double-fire (see `references/production-hardening.md`)
- [ ] Event fires in **exactly one place** per feature

### Session Context
- [ ] `registerSessionContext()` called on app init
- [ ] Includes: `app_env`, `platform`, `landing_path`, `traffic_source`, UTMs

### Type Safety
- [ ] `TrafficSource` uses TypeScript enum, not free string
- [ ] All properties use `snake_case`

### Privacy
- [ ] Person properties contain **no PII** by default
- [ ] Email only stored with explicit consent

Decision Tree

### Not seeing expected events?
├─ PostHog default events visible? ($pageview, autocapture)
│   ├─ Yes -> Custom event bug -> Check component, guards, dedupe
│   └─ No -> SDK issue -> Check env vars, consent, ad blockers
├─ Check DevTools Network -> verify /e/ calls
└─ Check PostHog Live Events (not Activity)

### Can't answer business questions?
├─ Missing events -> Add custom events for key moments
├─ Missing properties -> Enrich with context
├─ No user ID -> Implement identify() calls
└─ Attribution gaps -> Capture UTMs, persist through signup

Anti-Patterns Summary

See references/event-quality-rules.md for detailed examples.

Metrics and Benchmarks

Default to internal baselines and trendlines; use external benchmarks only when comparing like-for-like segments and definitions.

If you need external references, see data/sources.json -> benchmarks_research.

Templates

International Markets

This skill uses US/UK market defaults. For international product analytics:

If your query is primarily about GDPR/PIPL/LGPD or consent configuration, use marketing-geo-localization alongside this skill.

Related Skills

• marketing-cro - A/B testing, conversion optimization
• marketing-leads-generation - Lead funnel, B2B attribution
• qa-agent-testing - LLM agent testing (complements AI analytics)
• data-sql-optimization - SQL for analytics queries

Data Sources

See data/sources.json for official documentation links.

Ops Runbook: Instrumentation Gate (Pre-PR)

Use this to keep analytics changes production-safe and queryable.

Pre-PR Commands

# 1) Find changed tracking calls
rg -n "capture\(|track\(|analytics\.|posthog\." src app lib

# 2) Enforce event/property naming policy
rg -n "[A-Z]" src | rg "capture\(|track\("  # quick camelCase/PascalCase smell

# 3) Validate tracking plan coverage
# (keep a single source of truth file; fail if event is missing)
rg -n "signup_started|signup_completed|checkout_started|trial_started" docs src

# 4) Run analytics gate test (if project defines one)
npm run test:analytics-gate

Post-Deploy Smoke Query Template

-- Replace table names for your warehouse/provider
select event,
       count(*) as events,
       count(distinct distinct_id) as users
from events
where timestamp >= now() - interval '24 hour'
  and event in ('signup_started','signup_completed','checkout_started','trial_started')
group by event
order by events desc;

Event Contract Minimum

Each critical event must include:

• stable event name (snake_case)
• actor id (user_id or distinct_id)
• object id (*_id)
• source context (surface, entry_point, utm_* when relevant)
• timestamp from server or trusted client clock

Gate Failure Policy

• Missing critical event or required property: block merge.
• Non-critical property drift: allow merge only with follow-up issue.
• Silent event rename: block merge until dashboard/query migration is prepared.