The Stickiness Cliff
DAU/MAU fell from 35% to 28% the week the new release shipped, and growth has called an engagement emergency. Rebuild the metric from the raw events, find out who was in the numerator, and decide whether anything happened to real users at all.
The brief
You have joined Pocketpath, a habit-tracking app, as a product analyst.
Your manager forwards a thread from the growth lead:
"Stickiness — DAU over MAU — was 35% the week before release 5.2 shipped on 10 August and 28% the week after. Seven points in a week. I am pausing the roadmap until we understand what 5.2 did to engagement."
Nobody has rebuilt the number from the events. You have seven weeks of app-open events and the users file.
What you are asked to do: rebuild stickiness for the week before and the week after the release, explain the dashboard's fall, and say whether this is an emergency.
All timestamps are UTC. The dashboard's MAU is the rolling 28 days ending on each day, not the calendar month.
Three notes from the team, worth reading before you start:
Some accounts in users.csv are internal — QA automation, flagged is_internal. Nobody has checked whether the dashboard excludes them.
A double-logging bug on iOS was fixed in 5.2.1 on 24 August. Engineering was vague about when it started.
Release 5.2 also changed where the QA fleet points, from production to staging.
Treat this as you would any metric that moved the week something shipped: rebuild it from the raw events, decide who belongs in it, and be ready to show how you got every figure you report.
What to submit
- 1Your five verified answers, entered on the submission form.
- 2A one-page recommendation in your repo README — what happened to stickiness, why the dashboard fell, and whether the roadmap should stay paused. One page, not five.
- 3The SQL, Python or R you used to get your five answers, in the same repo.
- 4Optional: a chart, a dashboard link, or a three-minute Loom. None of these are required and none of them earn marks on their own.
How it is scored
| Area | Weight |
|---|---|
Data accuracyauto-graded The five verified answers. Graded automatically against the dataset, so this half of your score is arithmetic, not opinion. | 40 |
Problem framingreviewed Did you ask who is in the numerator and the denominator before explaining why the ratio moved, rather than accepting the fall as a user behaviour? | 15 |
Analysis and methodreviewed Did you rebuild DAU and rolling MAU from events, exclude internal accounts, and dedupe the double-logged rows — with the queries visible? | 20 |
Insight qualityreviewed Finding the internal accounts is good. Showing why they inflate a daily count far more than a 28-day count, and that real users did not move, is the finding. | 15 |
Recommendationreviewed A clear answer on the emergency, argued from your own numbers, plus what the dashboard should exclude. Hedging scores low. | 10 |
The data
Two files, about 7 MB.
events.csv — one row per app_open event. Columns: user_id, event_ts, event_name, app_version, platform.
users.csv — user_id, signup_date, platform, acquisition_channel, is_internal (true or false).
Events 6 July–23 August 2026. The data is synthetic, generated for this challenge. No user in it is a real person.
Recognition
Free to enter — everyone is scored and ranked
Every entrant is graded against the same rubric, ranked on the public leaderboard, and gets written feedback on their analysis — no fee, no prize, just the credential.
- The full brief and dataset
- Your score on the verified answers
- Written feedback on your analysis
- Ranked on the public leaderboard
- A certificate and badges you can add to your CV
Rules
- Scoring follows the published rubric below: 40% verified answers, graded automatically, and 60% your recommendation, scored against the rubric
- Scoring is automated. The top 10 submissions and any disputed score are reviewed by a human before results are finalized
- Your repository must be public and its commit history must show the work happening before the deadline
- Work individually. You may use any tool, including AI assistants — but you must be able to explain every number you submit
- One submission per person. You can update it any time before the deadline
- Everyone who submits is ranked by name on the public leaderboard when results are published
- Your repo has to be public for us to read it — but do not promote your solution on LinkedIn, X or Discord until judging closes, so others can still attempt it
