Product metrics: DAU, MAU, ARPU, LTV

Why product metrics matter in analyst interviews

If you interview for a product analyst or PM role at Meta, Stripe, DoorDash, or any subscription business, you will be asked to define DAU, ARPU, and LTV in the first thirty minutes — and the screener listens for whether you can connect them, not just recite definitions. The bar is "explain how a 20% DAU drop propagates to revenue next quarter," not "recall the acronym."

This guide walks through the metrics every product analyst owns: DAU, WAU, MAU, stickiness, ARPU, ARPPU, LTV, plus CAC and LTV/CAC. For each: formula, SQL recipe, interpretation, and the traps that get juniors dinged.

DAU, WAU, MAU — the audience metrics

DAU (Daily Active Users) is the count of unique users who took at least one tracked action in a day. WAU is the same over a 7-day window. MAU uses 30 days, or a calendar month if your reporting requires it.

The load-bearing word is unique. A user who opens the app ten times a day contributes DAU = 1, not 10. COUNT(*) instead of COUNT(DISTINCT user_id) gives you sessions, not active users.

-- DAU for the last 30 days
SELECT
    event_date,
    COUNT(DISTINCT user_id) AS dau
FROM user_activity
WHERE event_date >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY event_date
ORDER BY event_date;

For MAU as a rolling 30-day window (the version most product teams report on dashboards), join activity against a date series:

SELECT
    d.DATE AS report_date,
    COUNT(DISTINCT a.user_id) AS mau
FROM generate_series(
    CURRENT_DATE - INTERVAL '90 days',
    CURRENT_DATE,
    '1 day'
) AS d(DATE)
LEFT JOIN user_activity a
    ON a.event_date BETWEEN d.DATE - INTERVAL '29 days' AND d.DATE
GROUP BY d.DATE
ORDER BY d.DATE;

Note BETWEEN d.date - 29 days AND d.date — exactly 30 days inclusive. Off-by-one errors here are the most common reason DAU/MAU numbers disagree across teams.

Stickiness — DAU over MAU

Stickiness = DAU / MAU. It answers "what fraction of my monthly audience uses the product daily?" Higher is stickier.

A B2B SaaS dashboard with Stickiness = 8% is not broken — its users only check Monday standups. A consumer photo app at the same number probably is broken. Benchmark against the product category, not a universal target.

WITH daily AS (
    SELECT
        event_date,
        COUNT(DISTINCT user_id) AS dau
    FROM user_activity
    WHERE event_date >= CURRENT_DATE - INTERVAL '30 days'
    GROUP BY event_date
),
monthly AS (
    SELECT COUNT(DISTINCT user_id) AS mau
    FROM user_activity
    WHERE event_date >= CURRENT_DATE - INTERVAL '30 days'
)
SELECT
    d.event_date,
    d.dau,
    m.mau,
    ROUND(d.dau::numeric / m.mau * 100, 1) AS stickiness_pct
FROM daily d
CROSS JOIN monthly m
ORDER BY d.event_date;

Smooth stickiness with a 7-day moving average before showing it to a stakeholder — weekday seasonality alone moves the raw number by 20–40% in B2B products.

ARPU and ARPPU — the money metrics

ARPU (Average Revenue Per User) spreads revenue across the whole active base:

ARPU = Revenue / Active Users

ARPPU (Average Revenue Per Paying User) restricts the denominator to paying users only:

ARPPU = Revenue / Paying Users

The decomposition that unlocks diagnostics is:

ARPU = ARPPU × Paying Share

If ARPU drops, you do not yet know whether your paying users spent less per head or fewer users converted to paid. Decomposing tells you which lever moved.

WITH revenue AS (
    SELECT
        DATE_TRUNC('month', payment_date) AS month,
        COUNT(DISTINCT user_id)  AS paying_users,
        SUM(amount)              AS total_revenue
    FROM payments
    WHERE status = 'completed'
    GROUP BY DATE_TRUNC('month', payment_date)
),
active AS (
    SELECT
        DATE_TRUNC('month', event_date) AS month,
        COUNT(DISTINCT user_id)         AS active_users
    FROM user_activity
    GROUP BY DATE_TRUNC('month', event_date)
)
SELECT
    a.month,
    a.active_users,
    r.paying_users,
    r.total_revenue,
    ROUND(r.total_revenue / a.active_users, 2)            AS arpu,
    ROUND(r.total_revenue / r.paying_users, 2)            AS arppu,
    ROUND(r.paying_users::numeric / a.active_users * 100, 1) AS paying_share_pct
FROM active a
LEFT JOIN revenue r ON a.month = r.month
ORDER BY a.month;

A freemium app with ARPU = $0.40 and a 2% paying share has ARPPU = $20 — fifty times ARPU. Misreading that as "users pay $0.40" tanks pricing decisions.

LTV — customer lifetime value

The textbook formula:

LTV = ARPU × Average Customer Lifetime  (same time unit)
LTV = ARPU / Churn Rate

If ARPU = $12/month and monthly churn = 5%, then LTV = $240. That is the expected revenue from one acquired user across their entire relationship with the product.

This works when ARPU and churn are steady. They almost never are in young products — early cohorts are spikier, churn is front-loaded, expansion revenue kicks in later. The honest version is cohort LTV:

WITH cohort AS (
    SELECT
        user_id,
        DATE_TRUNC('month', MIN(event_date)) AS cohort_month
    FROM user_activity
    GROUP BY user_id
),
revenue_by_month AS (
    SELECT
        c.cohort_month,
        (DATE_TRUNC('month', p.payment_date) - c.cohort_month) AS months_since,
        SUM(p.amount)               AS revenue,
        COUNT(DISTINCT c.user_id)   AS cohort_size
    FROM cohort c
    JOIN payments p ON c.user_id = p.user_id
    GROUP BY c.cohort_month, months_since
)
SELECT
    cohort_month,
    months_since,
    cohort_size,
    revenue,
    ROUND(revenue / cohort_size, 2) AS arpu_per_period,
    SUM(revenue) OVER (
        PARTITION BY cohort_month
        ORDER BY months_since
    ) / cohort_size AS cumulative_ltv
FROM revenue_by_month
ORDER BY cohort_month, months_since;

The cumulative LTV curve flattens once a cohort stops paying. The plateau value is the realized LTV — not an extrapolation. For deeper SQL on this exact recipe, see how to calculate LTV in SQL and the per-cohort variant in LTV by cohort.

CAC and the LTV/CAC ratio

CAC (Customer Acquisition Cost) is acquisition spend divided by new users in the same window:

CAC = Acquisition Spend / New Users Acquired

Spend $200k on paid ads in March, acquire 8,000 new signups → CAC = $25. The hard part is what counts as "spend": paid media only, or paid media plus marketing salaries, content, referral incentives, tooling (blended CAC). Both are valid; mixing them in one report is not.

The metric that closes the loop on whether your business model works:

LTV / CAC

Pair it with payback period = CAC / monthly contribution per user. LTV/CAC = 4 with 18-month payback is great strategically but cash-hungry tactically. Stripe and Netflix can absorb that; a seed-stage startup with six months of runway cannot.

How the metrics fit together

Juniors treat these as a checklist. They are a system.

DAU/MAU drives the engagement layer. Higher stickiness means users open the app more, see more value, and graduate to paid more often — lifting both Paying Share and ARPPU.

ARPU decomposes into ARPPU × Paying Share. When ARPU moves, you need both components. The classic case: ARPU is flat, but ARPPU rose 20% while Paying Share dropped 16%. The "flat" headline hides a pricing win and a conversion problem.

LTV is a function of ARPU and retention. Holding ARPU constant, every percentage point of improved cohort retention shifts LTV materially. Many growth wins come from retention, not monetization. LTV/CAC ties the system to the P&L — if it sits below 1, no DAU growth fixes the unit economics. Walking through that chain unprompted is the marker of a strong senior candidate.

Common pitfalls

The most damaging mistake is inconsistent activity definitions across teams. Growth defines DAU as "any backend ping," product defines it as "completed a core action," marketing slices on "opened a notification." All three are defensible; reporting them as a single "DAU" number to leadership is not. Pin the definition in your metric registry and link from every dashboard.

A second trap is mixing calendar and rolling windows. MAU for March is not MAU for the trailing 30 days ending March 31 — February has 28 days, seasonal spikes land differently. Pick one approach per surface (rolling for executive trends, calendar for finance) and never switch silently mid-report.

The cross-platform double-count problem hits any product with web plus mobile. Without a unified user_id joining device IDs, the same person counts as two users — inflating MAU, deflating ARPU and stickiness. Fix identity before aggregation, not after.

For revenue metrics, the killer is outliers in ARPU. One enterprise customer paying $1M skews the mean across 50,000 free users into meaninglessness. Use median for diagnostics and trimmed ARPU (drop the top 1% by spend) for trend reporting. Finally, treating refunds as zero revenue rather than negative: gross and net ARPU can diverge 5–15% in subscription products with grace-period cancellations. Compute on net revenue and label what you quote.

What interviewers actually ask

"What's the difference between ARPU and ARPPU?" — ARPU divides revenue across all active users; ARPPU only across paying users. The decomposition ARPU = ARPPU × Paying Share is the answer they want. Freemium products with 2% paying share have ARPPU fifty times ARPU.

"DAU dropped 20% week over week. How would you investigate?" — Start with a trustworthiness check: tracking outage, schema change, release that broke the activity event? Then segment by platform, country, acquisition channel, cohort. Decompose into new-user vs returning-user DAU. Check external events (holidays, competitor launches, a viral negative story).

"How would you compute LTV for a 3-month-old product?" — The honest answer: any single number is an estimate with wide error bars. Build the cohort curve to date, fit a simple decay to extrapolate retention, and report a range with explicit assumptions. Refuse to give a point estimate without one.

"LTV/CAC = 2. Is that good?" — It depends. For a Series A SaaS company with 6-month payback and 90%+ gross margin, 2 is acceptable with a credible path to 3. For a low-margin marketplace with 18-month payback, 2 is dangerous. Ask for payback period, gross margin, and growth stage before declaring health.

Related reading

• How to calculate DAU/MAU in SQL
• How to calculate ARPU in SQL
• How to calculate LTV in SQL
• How to calculate CAC in SQL
• Cohort analysis — data science interview
• North star metric for PM

If you want to drill questions like these every day, NAILDD is launching with 500+ analyst-interview problems on exactly this pattern.

FAQ

What's the difference between DAU and MAU?

DAU counts unique active users in a single day; MAU counts unique active users over 30 days (rolling or calendar). A user who opens daily contributes DAU = 1 every day and MAU = 1 across the month. The ratio DAU/MAU — stickiness — tells you how much of your monthly audience actually uses the product daily, and is the best one-number summary of engagement.

Why use ARPPU instead of ARPU?

ARPU spreads revenue across everyone, useful for tracking total monetization efficiency. ARPPU isolates pricing and packaging effects on the people who actually pay. Change pricing and ARPPU moves first; change conversion (paywall, free trial) and Paying Share moves while ARPU follows. Track both to know which lever you pulled.

How do I compute LTV when the product is only 3 months old?

The simple ARPU / Churn formula is unreliable with that little data — early churn is artificially low because users have not had time to churn. Build a cohort curve of cumulative revenue per user by month-since-acquisition, then fit a decay model (Kaplan-Meier or geometric) to extrapolate. Report a range with assumptions, not a single number.

What is a good LTV/CAC ratio?

The conventional benchmark is LTV/CAC > 3 for sustainable growth, with 1.5–3 acceptable for high-growth startups that can absorb longer paybacks. Below 1 means each paid signup destroys value — fix retention, change channels, or kill the spend. Pair the ratio with payback period and gross margin before making a verdict.

How does stickiness compare to retention?

Stickiness (DAU/MAU) measures frequency within a window — what share of monthly users come back daily. Retention measures survival across windows — what share of a cohort returns N days later. They tend to move together but can diverge: a product can keep a loyal core engaged daily while losing most new signups in week one. Look at both before declaring engagement healthy.