Product Analytics Setup

Product Analytics Setup

A senior PM and analyst's playbook for instrumenting product analytics correctly the first time.

Most product analytics setups are some combination of inherited mistakes, dashboard sprawl, and events nobody trusts. The team launches a new feature; instrumentation gets bolted on under deadline pressure; naming drifts; properties are inconsistent; six months later nobody can answer simple questions because the answer depends on which event you trust.

This skill is the discipline that prevents that. It assumes you have answered the strategic questions about what to measure (see analytics-strategy). It assumes you have a tool connected (Mixpanel, Heap, PostHog, Amplitude, or warehouse-native via BigQuery, Snowflake, or dbt). The hard part is the systematic execution: naming conventions, property design, schema versioning, funnel construction, cohort definitions, retention measurement.

When to use this skill: setting up product analytics from scratch, auditing an existing instrumentation, fixing a "we have data but cannot trust it" problem, or designing instrumentation for a new feature.

---

What this skill is for

This skill spans instrumentation execution. It does not cover measurement strategy (use analytics-strategy), experimentation result interpretation (use experimentation-analytics), paid media analytics (use ads-performance-analytics), or platform decisions (use experimentation-platform-orchestrator). Pair this skill with the relevant integrations microsite for your specific tool.

The clean distinction from analytics-strategy. That skill (Growth category) is strategic: what to measure and why, KPI hierarchy, dashboard architecture, attribution models. This skill (Product category) is execution: how to actually instrument the product correctly. The two compose. Read analytics-strategy first to decide what matters; read this skill to instrument it.

---

The instrumentation hierarchy

The mental model. Every analytics setup is a stack of layers. Each layer depends on the one below it being correct.

• Events are the atomic facts: user_signed_up, checkout_completed, feature_x_used.
• Properties describe events: who, what, where, when, with what context.
• Identities map events to people: anonymous_id, user_id, account_id.
• Cohorts are filters across events: "users acquired via paid in March."
• Funnels are sequences of events: signup, then activated, then first paid action.
• Retention measures repeat behavior: signups still active at week N.

You cannot construct higher levels without correct lower levels. Garbage events produce garbage funnels. The discipline is bottom-up. Most "we have data but cannot trust it" problems trace back to the bottom two layers.

---

Event taxonomy design

Three rules for event design.

1. Past tense, action-oriented. checkout_completed, not checkout_complete or completing_checkout. Past tense reads as "this happened" rather than as a state.
2. Object-action format. Noun then verb. video_played, form_submitted, email_opened. Reading the event name aloud should describe what happened.
3. Granular but not redundant. Track distinct user actions, not button clicks. Fire checkout_completed once at the moment of completion, not submit_button_clicked plus checkout_completed. UI events are noise; semantic events are signal.

The verbs vs states trap.

• Verbs ARE events. checkout_completed, subscription_canceled, account_upgraded.
• States are NOT events; they are properties. user_status: active is a property on the user, not an event. Setting state via events ("status_changed_to_active") is a code smell that produces double-counting.

How many events to design. Thirty to fifty events is the sweet spot for a typical SaaS product. Below twenty means under-instrumented; above one hundred almost always means tracking UI noise or duplicating events in different formats.

Detail and a canonical event spec in references/event-taxonomy-template.md.

---

Property design: event-level vs user-level

Two property types, treated separately.

Event-level properties describe THIS event. The checkout_completed event has properties like cart_value, item_count, payment_method, discount_code. They live on the event payload and are immutable once fired.

User-level properties describe the USER over time. subscription_tier, lifetime_value, acquisition_channel. Set them once on the user profile; the analytics tool joins them onto every event the user fires. They update over time as the user changes.

The trap. Putting user-level properties on every event. Do not track subscription_tier on every event payload; set it once on the user profile and rely on the join. Putting it on the event creates payload bloat, schema drift when the value changes, and reporting confusion when a user upgrades mid-session.

Data type discipline.

• Strings for enums: status, tier, channel, region. Enumerable values where the set is bounded.
• Numbers only for actual numbers: count, value, duration, score. Never use strings for numeric data ("free trial day 7" should be trial_day: 7).
• Booleans for actual booleans: is_admin, has_trial, is_new_user. Two values; nothing else.
• Timestamps in ISO 8601, always. Always. The number of bugs caused by inconsistent date formats is uncountable.
• Arrays rarely. An array property is usually a sign you should split into multiple events with one item per event.

Worked example in references/property-design-patterns.md showing right and wrong design for a product_viewed event.

---

Naming conventions

Pick ONE convention and enforce it. Three conventions worth picking.

• snake_case for events and properties: user_signed_up, cart_value. Most platforms default to this; pushback is rarely worth it.
• Object-action format for events: user_signed_up, video_played. Reading the name should describe what happened.
• Verb-noun for user properties (or just nouns): subscription_tier, is_admin, last_active_at.

What NOT to do.

• Mixed case across events. user_signedUp, User Signed Up, userSignedUp all coexisting in the same project. Pick one and migrate.
• Spaces in event or property names. "Sign Up Completed" breaks every URL-encoding scenario and confuses every tool.
• Inconsistent verbs. user_signed_up plus completedCheckout plus VIEW_PRODUCT in the same project means nobody can predict an event name without looking it up.
• Brand names in event names. mailchimp_email_opened ages badly when you switch to Customer.io.

The naming convention reference file provides a complete style guide. Cite it in your team's data contract.

Detail in references/naming-convention-reference.md.

---

Schema versioning

Schema changes are inevitable. The pattern.

Additive changes are safe. New event, new property on an existing event, new value in an enum. Just ship. Existing dashboards continue to work.

Breaking changes require migration. Renamed event, removed property, changed property type, narrowed enum. These break dashboards downstream; the migration plan is part of the change.

Versioning patterns.

• Append _v2 to events when semantics change. checkout_completed_v2 fires alongside checkout_completed during a transition.
• Keep old events firing during the transition (90 days is typical). Both versions fire; analytics queries gradually migrate to v2.
• Migrate dashboards to v2 before retiring v1. Then deprecate v1 explicitly with a documentation note.

The data contract idea.

• Document the canonical schema in code: TypeScript interface, JSON Schema, or Protobuf definition.
• Code review every schema change. Schema is product, not afterthought.
• CI lint rejects schema violations before they hit production. The deploy that adds an event with the wrong type fails the build.

Detail in references/schema-versioning-patterns.md.

---

Funnel design

Funnels measure progression through a sequence. Four rules.

1. Order matters. A then B then C is a different funnel from B then A then C. The platform will compute different conversion rates depending on order.
2. Time windows matter. Most funnels use a 1 to 30 day window from the first event. Document the window explicitly; "users who completed signup AND activated" is meaningless without "within 14 days."
3. Drop-off interpretation is hard. Eighty percent of users dropping at step 2 might be the funnel design (audience is wrong), might be the audience (timing is wrong), or might be the product (genuine drop-off). Investigate before declaring.
4. The anchor event pattern. Every funnel starts with a high-intent action: signup, trial start, key feature use. Not a vanity event like page_view or session_start. Vanity-event-anchored funnels show 99% drop-off and tell you nothing.

Common funnel mistakes.

• Funnels that include events firing automatically. session_started happens for every visit; using it as a step inflates the denominator and makes the rest of the funnel meaningless.
• Funnels too long (10+ steps). Break into two or three shorter funnels. A 10-step funnel produces near-zero end-to-end conversion that is hard to interpret.
• Funnels with the same event in multiple positions. The platform handles this poorly; the analyst handles it worse.
• Mixing different time windows in one funnel. "Users who signed up within 7 days AND converted within 30 days" is two different cohort definitions glued together.

Common funnel shapes and time-window guidance in references/funnel-design-templates.md.

---

Cohort definitions

A cohort is a group of users sharing an attribute or behavior. Useful patterns.

• Acquisition cohorts. Users acquired in month X. The standard for retention analysis.
• Behavioral cohorts. Users who completed action Y. Useful for activation analysis ("users who sent first message in week 1").
• Property cohorts. Users with subscription_tier: pro. Useful for segment-level analysis.
• Combined cohorts. Signup in March AND completed onboarding AND in EU. The most common in real analytics work.

Cohort discipline.

• Define cohorts in code (or in your tool's saved-cohort feature) so they are reusable.
• Version them when criteria change. Compare apples-to-apples.
• Do not compare a 30-day-old cohort to a 365-day-old cohort on retention; the older cohort has had more time to retain by definition.

Detail in references/cohort-definition-patterns.md.

---

Retention measurement

Retention is repeat behavior over time. Three flavors.

• N-day retention. Did user X come back on day 7, day 14, day 30 specifically. High noise on any single day; useful for short-cycle products.
• Bracket retention. Did user X come back at any point during the week 7 to 13 window. More stable than N-day; reads cleaner on retention curves.
• Unbounded (rolling) retention. Did user X come back any time after signup. Useful for longer-cycle products where weekly cadence is misleading.

For most SaaS products, bracket retention is the right default. Day-7 is high-noise; week-2 (bracket) is more stable. Day-1 retention is almost always over-indexed to onboarding effects rather than product-market-fit signal.

Retention curve interpretation.

• Steep early drop, then plateau. The product has core users; the rest churn fast. Typical for most SaaS products.
• Gradual decay across weeks with no plateau. No one is sticking. Usually a value-prop or onboarding problem; the product is not delivering recurring value.
• Flat line at low percentage. A power-user product with a small but engaged base. Not a problem; just a different shape.

Detail in references/retention-measurement-patterns.md.

---

North Star and supporting metrics

North Star metric (NSM) selection rules.

• Reflects user value, not company value alone.
• Captures the core action that, if it grows, the business grows.
• Measurable consistently across time.
• Hard to game.

Bad NSMs. Signups (vanity; many signups never activate). Revenue (lagging; not action-oriented; varies by mix). DAU (only useful for engagement-driven products; misleads on monthly-cadence products).

Better NSMs. Weekly active editors (Figma). Nights booked (Airbnb). Messages sent per day (Slack). Products created per workspace per week (Linear). Each names a user-value action that maps to business growth.

Supporting metrics framework.

• One NSM.
• Three to five input metrics that drive the NSM. For "weekly active editors" these might be: signups per week, signup-to-active conversion rate, week-over-week active retention.
• Five to ten health metrics that warn of problems. Monthly churn rate, account-level concentration, support ticket volume.

Detail and product-type-specific examples in references/north-star-metric-selection.md.

---