Uber Monthly Active User Decline: Root Causes, Response and Early-Warning Signals

Uber's monthly active users (MAU) fell in August, a few months ago. Work out why the decline might have happened, explain what you would do about it, and describe how Uber could get early warning of a drop like this before it shows up. Address each part from both a product management perspective and an engineering perspective. ### Clarifying Questions - How is an active user defined for this MAU figure: anyone who opens the app, anyone who requests a ride, or only someone who completes a trip? Does it include drivers or food-delivery customers? - How large was the drop, was it a sudden step or a gradual slide, and has MAU recovered since August? - Is the decline global, or concentrated in certain countries, cities, platforms (iOS or Android), app versions or ride products? - Did MAU also dip in August in previous years? ### Part 1 — Find the likely causes Describe how you would investigate the decline and which explanations you would test, covering data and engineering causes as well as product and market causes. For each, say what evidence would confirm or rule it out. ```hint Real or just measured? Before looking for reasons riders left, rule out the possibility that only the way the number is counted or logged changed. ``` #### What This Part Should Cover - Validation of the metric itself (definition, event logging, data pipeline) before any product analysis. - Localizing the drop by segment and by step of the rider journey. - Internal and external hypotheses in a sensible order, each with the data that would test it. ### Part 2 — Respond to the decline Assume your investigation points to a likely cause. Describe what you would do, how you would choose between possible fixes, and how you would know the response worked. ```hint Fit the fix to the cause Different root causes need different owners and timelines; consider which actions can be undone quickly and which should be tested before rolling out widely. ``` #### What This Part Should Cover - Actions matched to specific root causes, with engineering and product owners. - Prioritization by expected impact, confidence, cost and speed. - How the response is measured, including guardrails. ### Part 3 — Get warned earlier Propose how Uber could detect a decline like this before it appears in the monthly figure. ```hint Monthly numbers move late A monthly count changes only after weeks of changed behavior; look for faster signals that sit upstream of a rider deciding not to come back. ``` #### What This Part Should Cover - Leading indicators upstream of MAU and how often they are checked. - Engineering monitoring: data-quality checks, release health and reliability, with seasonality-aware alert thresholds. - Ownership and a response process so that alerts lead to action. ### What a Strong Answer Covers - An ordered, structured diagnosis instead of an unranked list of guesses. - Both the engineering and the product perspective in every part, as the prompt asks. - Hypotheses grounded in Uber's two-sided marketplace, covering rider demand and driver supply. - A clear link from each cause to its response and to the signal that would have flagged it earlier. ### Follow-up Questions - The drop turns out to be concentrated among Android users on the newest app version. What are your next steps? - MAU fell, but trips per active rider went up. How do you interpret that, and does it change your response? - How would you set alert thresholds so the team is not flooded with false alarms around holidays and seasonal swings?