Sections

End-to-end DAU triage the way strong DS/PM orgs run it: lock the metric definition, validate instrumentation before narrative, decompose the composite into new vs returning and session depth, segment to localize a sharp break, and ship actions with impact sizing and explicit uncertainty. Includes worked timing, SQL-shaped diagnostics, and the Simpson / mix-shift traps that sink mid-level answers.

45 min read 14 sections 9 interview questions

DAUWAUMetric Root CauseSegmentationData QualityPipeline DebuggingCohort AnalysisProduct AnalyticsScenario InterviewA/B Test DebuggingSimpson ParadoxMobile ReleaseKPI TreeStakeholder CommsDIAGNOSE Framework

What Strong Answers Optimize For

DAU is a headline, not a mechanism. In production, it moves when any of these move: the count of new users, the probability a logged-in user returns, the number of sessions per user, the probability any session includes a "counted" active event, or the definition of active (schema, identity merge, or client instrumentation). Senior candidates make that explicit in the first two minutes. Weak candidates treat DAU as a single lever and drown the interview in ad hoc slices.

Interviewers are grading: (1) instrument discipline before cause stories, (2) decomposition so you do not "explain" a new-user problem with a ranking story, (3) localization to a version/geo/tenure slice that narrows the hypothesis set, and (4) decision quality—rollback, holdout, comms, guard alerts—with impact sizing and a statement of what you still do not know. This walkthrough is structured to make each step legible in a 35–45 minute round.

IMPORTANT

What Separates 6/10 vs 9/10

6/10: "I'd segment by platform and check seasonality" without ordering checks; one causal story; ends without an action or with a vague "monitor."

8/10: clear D → I → A → N → O; instrument first; 3+ hypotheses; uses segmentation to localize; names at least one confounder (Simpson, mix, experiment exposure).

9–10/10: ties the localized slice to a binary world event (ship at T-0, outage window, ad pause), quantifies user/revenue order of magnitude, defines P0 response and invalid metric window for exec readouts, and states pre-registered falsifiers for the top hypothesis. Sounds like someone who has owned an exec metric during an outage.

The Accounting View — Decompose Before You Explain

Even without perfect data, treat DAU as a small set of levers so your story cannot contradict arithmetic.

A durable mental model: active users ≈ new + returning (with overlap handled by your identity graph). Returning is driven by D1/D7-style habits; new is driven by acquisition and activation. Sessions per DAU and events per session capture "depth" when you suspect engagement moved but the user base did not. If the business only surfaces DAU, you still triangulate with whatever exists on the same clock: app opens, session_start counts, WAU, signups, notification sends.

If DAU is down but signups and activation are up while return visits fall, your acquisition funnel is not the first story—the product or retention layer is. If DAU is down and only the paid channel's new users are down, the story may be spend or attribution, not a universal product regression. The interview win is consistency between decomposition and the hypothesis you bet on.

DIAGNOSE — DAU Investigation (Operable Checklist)

D — Define the signal

Calendar day vs rolling 7; active = any client event vs login; dedupe of identities; which timezone is 'day' for a global app? Is the drop vs prior day, vs same DoW, vs trailing 28d baseline? Step change (sharp timestamp) vs gradual?

I — Instrument + pipeline

Ingestion lag, event volume, SDK error rate, server 5xx on collectors, id_merge changes, two-source check (warehouse vs stream). Pause exec storytelling if sources disagree.

A — Hypothesis tree (ranked)

Internal: client release, feature flag, recommender, paywall, experiment arm, email/push cadence, outage. External: DoW/season, holiday, competitor, OS / App Store, regional news. Data: wrong join, new filter, experiment bucketing bug.

G — Generate diagnostics

Cheapest disproofs first: release log vs metric step; infra dashboard vs time; A/B exposure vs non-exposure. Then segment drill-down with a hypothesis per slice, not 40 charts.

N — Narrow to root cause

Use localization: iOS 17.2 + build 4003 only, or DE-only, or users <7d tenure only. Require a mechanism that matches the slice.

O — Own the outcome

Impact: % of MAU, rough revenue if ARPU known; P0 if outage vs P1 if gradual. Action: rollback, kill flag, re-weight experiment, comms. Guard: alert on the precursor signal next time.

S — State uncertainty + next data

What you need by EOD: longer window, holdout, client hotfix A/B, or A/A. What would flip your call.

Happy-Path Investigation Order (Data vs Story)

Rendering diagram...

EXAMPLE

Worked Thread — Step Change at 17:00 UTC

Signal: DAU -14% DoW-adjusted vs 4-week baseline; starts at 17:05 UTC, flat before.

I: Event volume from iOS clients is down; warehouse agrees with stream; no ETL delay spike. Not a pure pipeline story.

N: iOS 18% down, Android +1%. Geo is global; new vs return both down within iOS, strongest on the newest app version.

Mechanism match: a mobile release landed at 17:00 UTC for iOS; crash rate for that build jumps in the same five-minute bin.

O: recommend rollback or feature-flag off the crashing path; comms: "product metrics unreliable for iOS until hotfix" with ETA; P0. S: confirm crash-free DAU in 24h on rollback cohort vs holdout; postmortem on staged rollout and crash gates.

The interview point is not bragging—it's that time-aligned binary events plus a localized slice is how you get from DAU to an owner in one hour.

Simpson, Mix, and 'Global Flat / Segment Ugly'

Simpson's paradox and mix effects are not stats trivia; they are how smart people ship wrong conclusions. Example: DAU is flat overall while new user DAU craters and returning DAU rises—if acquisition mix shifts toward low-retention geos, the aggregate can hide a severe activation problem. Always ask: "If I only looked at the total, which story am I forbidden to tell?"

Experiments add another wrinkle: if 40% of users are in a holdout, and a bad treatment hits only that arm, the global DAU can look mildly negative while the affected slice is very negative. The fix is to join to exposure tables and read intent-to-treat or treatment effects—not just a global DAU line.

Hypothesis Tree (Internal vs External vs Data — First Pass)

Rendering diagram...

Segment Drill-Down — Analytic Shape (Pseudocode)

sqldau_localize.sql

-- Analytic *shape* only: in interview, narrate the intent per slice, not 15 queries.

WITH daily AS (
  SELECT
    dt,
    platform,
    app_version,
    country,
    user_tenure_bucket,  -- e.g. 0-1d, 2-7d, 8-30d, 30d+
    COUNT(DISTINCT user_id) AS dau
  FROM fct_client_events
  WHERE dt BETWEEN :start AND :end
    AND is_active_user_event = TRUE
  GROUP BY 1,2,3,4,5
)
SELECT
  *,
  dau - LAG(dau) OVER (PARTITION BY platform, app_version, country, user_tenure_bucket ORDER BY dt) AS dau_delta
FROM daily
ORDER BY ABS(dau_delta) DESC
LIMIT 200;

-- What interviewers want to hear: you will *not* run this blind;
-- you pick platform first when the story is a client crash,
-- or country first when the story is regional outage/ads.

Slices — What Each Break 'Sounds Like' (Interview Diagnostic)

Slice pattern	Leading hypotheses	Fast falsification
iOS down, Android flat	Bad release, WebView, push token, ASO	Release timestamp vs crash; version histogram
Single country	Outage, regional campaign pause, data residency	Infra/ISP map; ad spend; CDN
New users only	Attribution, store, ASO, paid fraud, onboarding	Signups, CAC, creative change log
Returning only	Relevance, habit, notifs, paywall, competitor	Session depth, reactivation campaigns
Exposed-to-test only	Bad treatment	Bucket integrity · SRM · guard metrics
Flat DAU, down revenue	Mix — not this scenario's hero metric	Cross-check: ARPU, paid events

Executive Readout — What You Refuse to Ship Without

Two-source or single-source of truth for DAU for the period in question, with a named owner if the sources diverge.
Localized slice or honest statement 'still global' with top 2 unexcluded possibilities.
Impact order-of-magnitude — not fake precision: % of user base, rough ARPU if revenue is on the line.
Action + rollback with a next-check time (e.g. T+2h, T+24h) and guard metric for the precursor.
Invalid window if pipeline was broken: explicit 'do not use 6h after deploy X for iOS DAU' for downstream teams.

⚠ WARNING

Traps That Fail Senior Bar

Dawn-of-time SQL without a hypothesis: infinite slices → noise mining; you get correlation theater.
Mistaking DoW noise for a break: always anchor DoW or YoY for consumer apps.
Treating p-values on 20 metrics as independent—multiple testing is how teams ship false fixes.
Forgetting identity: MAU/DAU merge rules change can move "users" without moving humans.

When the Answer Is 'We Do Not Know Yet' — and That Is the Right Answer

Staff-level candidates earn trust by separating confidence from clarity. If instrument checks are still running, you do not invent a P0. You time-box: "By T+2h we will know if warehouse matches stream; if not, I recommend freezing iOS DAU in exec decks only for that window and using Android as a sanity shadow metric—not as ground truth, but as a directional check on global hype."

That sentence shows you understand governance and externalities to other teams' decisions—higher signal than a clever causal graph no one can verify in time.

TIP

Close Strong — 45-Second Version

"I treat DAU as non-stationary and composite: I lock the definition, verify data, decompose levers, localize the break, and only then name a cause with a timestamped world event. My ask of leadership is: give me 90 minutes to rule out pipeline, then we either rollback with a cost estimate or we broaden the search with acquisition and market calendar on the same timeline."

Interview Questions

Click to reveal answers