Product Analytics Fundamentals

• Explain what product analytics measures and why it differs from web analytics
• Distinguish outcome metrics from diagnostic metrics
• Map the instrumentation lifecycle from event to decision

• Anyone can guess which feature matters; product analytics shows which feature users actually return for.
• Funnels and cohorts answer 'where do users churn' precisely, so teams fix the real bottleneck.
• A well-instrumented product lets you run experiments with trustworthy readouts.
• Without events, product decisions are vibes — with them, decisions are re-testable and accountable.

The counter records every dish ordered, by whom, at what time, in what combination, and which dishes get returned. That record is the restaurant's product analytics — the recipe changes happen because of it.

• SDKs on web, iOS, Android and backend capture events like 'signup_completed' with properties (user_id, plan, source).
• Events stream to a warehouse (or product analytics tool) where they land as a usable events table.
• Analysts build metrics on top: activation rate, DAU/MAU, retention cohorts, funnel conversion.
• Teams review metrics in dashboards and experiments, then decide what to build.
• New builds emit new events, and the loop restarts — measurement is continuous.

• A SaaS maps activation to 'created first dashboard' and finds new users who hit it in the first session retain 3x longer — so onboarding is redesigned around it.
• A mobile app teams the drop-off for 'add payment method' and ships a prefilled drawer, lifting conversion by 12%.
• An e-commerce team watches DAU/MAU weekly and triggers an investigation whenever stickiness dips below its 90-day band.

• Define metrics with an explicit grain (daily active user = unique user_id with at least one app-opened event that day).
• Instrument the events your decisions need, not everything imaginable — event volume is a real cost.
• Store raw events immutably and derive metrics from them, so historical numbers never change.
• Keep an event dictionary: name, description, properties, owner and example.

• Measuring clicks instead of outcomes — 'button clicked' is not 'user retained'.
• Renaming events or changing property values, silently breaking every historical metric.
• Building dashboards before instrumenting the underlying events, then showing zeroes.
• Treating every metric change as a product failure instead of first checking data quality.

• When a metric jumps, check for tracking changes first — deploys and SDK bumps cause more 'insights' than product changes do.
• Compare event counts between adjacent time windows to spot dropped or duplicated payloads.
• Test events on an internal build before release by querying the events table for your own user_id.
• If two dashboards disagree, reconcile at the events level (same filter, same date range) before trusting either.