Growth Metrics and Key Performance Indicators Questions

Comprehensive knowledge of growth metrics and key performance indicators used to measure user acquisition, engagement, retention, and revenue. Candidates should understand definitions, business meaning, and how to calculate metrics from raw event and transaction data. Core metrics include customer acquisition cost, lifetime value, lifetime value to customer acquisition cost ratio, conversion rate, churn rate, retention rate, monthly active users, daily active users, cohort retention, activation, engagement, average revenue per user, payback period, viral coefficient, and growth rate over time. Candidates should be able to choose appropriate leading and lagging indicators, explain unit economics, and reason about tradeoffs across acquisition, activation, retention, revenue, and referral stages. Practical skills include designing instrumentation and tracking for events and transactions, selecting attribution windows, avoiding sampling and attribution pitfalls, cleaning and deduplicating event streams, and calculating metrics by cohort and segment. Candidates must be able to perform funnel analysis and cohort analysis to diagnose problems, prioritize optimization levers, set metric baselines and success criteria for controlled experiments and split tests, assess sensitivity to seasonality pricing changes and growth initiatives, and communicate metric driven recommendations and dashboards to stakeholders. They should also identify which metrics matter for different business models such as business to business versus business to consumer and subscription versus transactional models.

MediumTechnical

87 practiced

Explain how to sessionize web/app events into sessions using a 30-minute inactivity timeout. Provide SQL or pseudocode that assigns a session_id to events(user_id, occurred_at). Discuss edge cases: background activity, very long sessions, and cross-device session stitching.

Sample Answer

Approach: sessionize by ordering events per user and marking gaps > 30 minutes (1800 seconds) as session boundaries. Then assign a session_id by cumulatively summing those boundaries or generating a UUID per session group.

Example (Postgres / ANSI SQL using window functions):

sql

WITH ordered AS (
  SELECT
    user_id,
    occurred_at,
    LAG(occurred_at) OVER (PARTITION BY user_id ORDER BY occurred_at) AS prev_ts
  FROM events
),
gaps AS (
  SELECT
    user_id,
    occurred_at,
    CASE
      WHEN prev_ts IS NULL THEN 1                     -- first event -> new session
      WHEN EXTRACT(EPOCH FROM (occurred_at - prev_ts)) > 1800 THEN 1 -- gap > 30min
      ELSE 0
    END AS is_new_session
  FROM ordered
),
session_groups AS (
  SELECT
    user_id,
    occurred_at,
    SUM(is_new_session) OVER (PARTITION BY user_id ORDER BY occurred_at ROWS UNBOUNDED PRECEDING) AS session_seq
  FROM gaps
)
SELECT
  user_id,
  occurred_at,
  CONCAT(user_id, '_', session_seq) AS session_id  -- or use uuid_generate_v4() per group
FROM session_groups
ORDER BY user_id, occurred_at;

Key points:- Using LAG() to compute inter-event gap, then cumulative SUM to number sessions.- session_id can be a concatenation of user + sequence or a generated UUID via grouping.

Edge cases:- Background activity (heartbeat/pings): filter known background event types or enforce a minimum meaningful event duration (e.g., ignore events with event_type IN ('heartbeat') or dedupe bursts within N seconds).- Very long sessions: a single user active for hours may be business-meaningful; optionally cap session max length (e.g., force new session after 8 hours) depending on product definition.- Cross-device stitching: if a user_id is consistent (logged-in), sessionize per user across devices. If not, stitch using deterministic identifiers (account_id, hashed email) or probabilistic fingerprinting—be aware of privacy and accuracy trade-offs. For ambiguous cases, keep device_id and mark sessions as “multi-device” when events from multiple devices fall into same session window.

Additional considerations:- Timezone and clock skew: store timestamps in UTC and consider device clock drift; if drift suspected, use server-side ingestion timestamps.- Late-arriving events: for streaming pipelines, use watermarking and possibly re-sessionize within an ingestion window.

MediumSystem Design

87 practiced

Design an instrumentation plan for tracking onboarding and activation: include event naming conventions, required properties for each event, identity stitching, handling offline events, and QA steps to ensure data quality across mobile and web.

Sample Answer

Requirements:- Measure onboarding funnel (visit → sign-up → first key action → activation) across web and mobile.- Capture identity to stitch anonymous → authenticated sessions.- Low-latency, high-quality event stream usable for SQL/BI tools.- Support offline/mobile buffering and data QA.

High-level plan:- Standardize events sent from front-end/mobile SDKs to a central tracking pipeline (Segment/CDC → data lake → analytics DB).

Event naming convention (consistent, readable):- <category>_ <action>_<object> e.g. onboarding_signup_submit, onboarding_email_verified, onboarding_first_project_created, activation_first_successful_run.

Required properties per event (core schema for every event):- event_name (string)- timestamp (ISO8601, UTC)- platform (web|ios|android)- env (prod|staging)- sdk_version- locale- device_id (mobile UUID / browser fingerprint)- session_id (UUID)- user_id (nullable, persistent authenticated ID)- anonymous_id (nullable, assigned before auth)- page_or_screen (string)- referrer / utm_source, utm_medium, utm_campaign- event_properties (object) — event-specific props below

Event-specific required properties (examples):- onboarding_signup_submit: email_domain, signup_method (email|google|sso), invite_code (nullable)- onboarding_email_verified: verification_method, elapsed_since_signup_seconds- onboarding_first_project_created: project_id, template_used (bool), features_enabled[]- activation_first_successful_run: run_id, runtime_ms, success=true, relevant_metrics{}

Identity stitching:- Assign anonymous_id on first touch (cookie or mobile install ID).- On authentication/registration, emit identify event with user_id and anonymous_id mapping.- Store mapping in identity service / identity table: user_id ↔ anonymous_ids[], device_ids[], emails (hashed).- Upsert into analytics DB daily to resolve historical anonymous events to users for cohorting.

Handling offline events:- Mobile SDKs buffer events locally; send with sequence numbers and local timestamp when reconnecting.- Include client_generated_id and original_timestamp; server-side dedupe by client_generated_id.- Mark events with upload_delayed boolean and delivered_timestamp.

QA & data quality checks:- Validation at ingestion: schema validation, required fields, types; drop or quarantine bad events with alerting.- Daily automated checks: event volume by platform vs. expected baselines, top 20 events coverage, missing user_id rate for authenticated flows, funnel conversion ratios and sudden deltas.- Anomaly alerts (PagerDuty/Slack) for >20% deviation or schema break.- Backfill process for delayed mobile uploads and manual reconciliation.- Sample replay tests: QA env emits known test events; verify in analytics DB and dashboards end-to-end.- Periodic audits: compare client logs vs server events, check identity stitch accuracy (>99% for active users).- Documentation: event catalog (name, props, owners, examples) and monitoring dashboard for event health.

Metrics to expose for stakeholders:- Sign-up conversion, email verification rate, time-to-activation, activation rate by acquisition channel, activation by cohort date/platform.

This plan balances analyst needs (clean, joinable fields, identity resolution) with engineering constraints (offline buffering, dedupe, schema validation) to ensure reliable activation measurement across web and mobile.

MediumTechnical

85 practiced

Calculate the payback period in months given: CAC = $120, average monthly revenue per paying user = $15, and gross margin = 70%. Show your formula and perform sensitivity analysis for CAC ±20% and ARPU ±10%. Explain business implications of shorter vs longer payback periods.

MediumTechnical

77 practiced

Discuss trade-offs when selecting attribution windows (7, 30, or 90 days) for paid acquisition campaigns. How do different windows affect CAC, conversion rates, and channel optimization? Propose a decision framework to choose a window and describe tests you'd run to validate the choice.

Sample Answer

Short answer: attribution window length trades off timeliness vs. completeness. Short windows (7d) give fast feedback and lower reported CAC but miss later conversions; long windows (30–90d) capture more long-tail conversions, raise CAC and lower observed conversion rates per click, and shift credit toward upper-funnel/brand channels. Choice affects channel ranking, budget allocation, and perceived ROAS — shorter windows bias toward direct/retargeting channels; longer windows favor awareness channels with longer conversion latency.

Trade-offs (practical):- 7 days: fast signal, lower lag for optimization, but undercounts delayed conversions → underinvests in top‑of‑funnel channels.- 30 days: balance between signal stability and latency; often default for SaaS/ecommerce with moderate purchase cycles.- 90 days: more complete LTV capture, better for high-consideration/high-ticket purchases, but slower learning and noisier attribution.

Decision framework (Data-Analyst friendly):1. Measure conversion latency: compute time-to-conversion CDF / median by campaign, channel, cohort.2. Define business objectives: short-term CAC targets vs. LTV/retention focus.3. Set coverage rule: choose window that captures X% of conversions (commonly 70–90%) for target channels.4. Evaluate signal quality: ensure sufficient sample size within window for statistical tests.5. Consider cost of delayed optimization: quantify revenue impact per day of slower reallocation.6. Governance: use channel-specific windows if behaviors differ (e.g., 7d for retargeting, 30–90d for upper funnel).

Tests to validate:- Time-to-conversion analysis: plot CDFs by channel/cohort; pick window where marginal gain in captured conversions flattens.- Sensitivity analysis: compute CAC/ROAS under 7/30/90d and measure rank-order stability of channels.- Incrementality/holdout experiments: run geo or user-level holdouts to measure true lift vs. attributed conversions across windows.- Survival / hazard modeling: predict long-tail conversion probability beyond chosen window.- Back-test budget allocation: simulate reallocations based on different windows and estimate impact on revenue using historical funnel data.

Recommendation: start with data-driven rule (capture 80–90% of conversions), validate with incrementality tests, and operationalize channel‑specific windows + periodic re-evaluation (quarterly or after major funnel changes).

EasyTechnical

75 practiced

Define conversion rate in the context of a funnel: 'page_view' -> 'signup' -> 'purchase'. Given an events table:

sql

events(user_id, event_type, occurred_at)

Write SQL to compute step-to-step conversion rates and overall conversion from visit to purchase for March 2024. Explain how to handle users who perform steps multiple times and what conversion window you'd choose.

Sample Answer

Approach: compute each user’s first timestamp for each event_type in March 2024 (to avoid double-counting repeated events), then measure how many users progressed to the next step. Optionally enforce a conversion window (e.g., 7 days) so only forwards that happen within that window count.

SQL (first-occurrence + 7-day conversion window example):

sql

WITH first_events AS (
  SELECT
    user_id,
    event_type,
    MIN(occurred_at) AS first_at
  FROM events
  WHERE occurred_at >= '2024-03-01' AND occurred_at < '2024-04-01'
    AND event_type IN ('page_view','signup','purchase')
  GROUP BY user_id, event_type
),
pivot AS (
  SELECT
    u.user_id,
    fv.first_at AS page_view_at,
    fs.first_at AS signup_at,
    fp.first_at AS purchase_at
  FROM (
    SELECT DISTINCT user_id FROM first_events
  ) u
  LEFT JOIN first_events fv ON fv.user_id = u.user_id AND fv.event_type = 'page_view'
  LEFT JOIN first_events fs ON fs.user_id = u.user_id AND fs.event_type = 'signup'
  LEFT JOIN first_events fp ON fp.user_id = u.user_id AND fp.event_type = 'purchase'
)
SELECT
  COUNT(DISTINCT user_id) FILTER (WHERE page_view_at IS NOT NULL) AS visits,
  COUNT(DISTINCT user_id) FILTER (WHERE signup_at IS NOT NULL) AS signups,
  COUNT(DISTINCT user_id) FILTER (WHERE purchase_at IS NOT NULL) AS purchases,
  ROUND(
    100.0 * COUNT(DISTINCT user_id) FILTER (WHERE signup_at IS NOT NULL) /
    NULLIF(COUNT(DISTINCT user_id) FILTER (WHERE page_view_at IS NOT NULL),0), 2
  ) AS pct_visit_to_signup,
  ROUND(
    100.0 * COUNT(DISTINCT user_id) FILTER (WHERE purchase_at IS NOT NULL) /
    NULLIF(COUNT(DISTINCT user_id) FILTER (WHERE signup_at IS NOT NULL),0), 2
  ) AS pct_signup_to_purchase,
  ROUND(
    100.0 * COUNT(DISTINCT user_id) FILTER (
      WHERE purchase_at IS NOT NULL
        AND signup_at IS NOT NULL
        AND purchase_at <= signup_at + INTERVAL '7 days'
    ) /
    NULLIF(COUNT(DISTINCT user_id) FILTER (WHERE page_view_at IS NOT NULL),0), 2
  ) AS pct_visit_to_purchase_within_7d
FROM pivot;

Key points and reasoning:- Use first occurrence per event per user to prevent inflating funnel counts when users trigger the same step multiple times.- Joining first times preserves order; apply a conversion window (here 7 days) when you want to ensure the steps are meaningfully connected. Choose the window based on business behavior: e.g., e‑commerce often uses 7–30 days, impulse apps might use same-day.- Edge cases: users who sign up before March but purchase in March — if you want those, expand window or consider events outside month range; adjust WHERE accordingly.- Alternative: compute rolling funnels (session-based) or count any qualifying progression (not only first) if repeat behavior matters.

Unlock Full Question Bank

Get access to hundreds of Growth Metrics and Key Performance Indicators interview questions and detailed answers.

Join thousands of developers preparing for their dream job.