Articles
Gaming Data Analyst Interview Case: Revenue Rises but Player Retention Falls
Solve a gaming data analyst interview case where revenue grows as D7 retention falls by reconciling IAP, ads, payers, install cohorts, and measurement windows.
A game can earn more this month while fewer new players come back next week. That is not automatically a data error, nor proof that monetization solved the retention problem. Revenue describes money collected in a period; retention describes whether members of a defined install cohort return after a chosen interval. An interview answer has to separate those populations, reconcile the money, and show what you would test before recommending a change.
Official product-documentation fact: Unity Analytics defines DAU, day-1/day-7/day-30 retention, payer measures, and revenue metrics; Google Analytics’ Firebase overview distinguishes user-cohort activity and revenue sources. Candidate reports: no named employer or candidate account is used here. Inference: the case and diagnostic sequence below are original practice material, not a claim about one studio’s results or interview rubric.
Define the two trends before explaining them
Ask whether “revenue” means gross in-app purchases, net proceeds after store fees, subscriptions, advertising, or their sum. Ask whether refunds, chargebacks, tax, and currency are included. Then ask whether “player retention” means exact-day D7, rolling D7, weekly active return, or a survival measure. Different teams use different definitions, and even the same dashboard can mix them. State the cohort start event: install, first open, account creation, or first completed session.
Unity’s retention dashboard documentation reports player retention since installing and allows filters by country, version, platform, and audience. Google’s Firebase overview describes a user-activity-by-cohort view and separates purchase, ad, and total revenue. Those are product capabilities, not evidence that your hypothetical game had any particular problem. They tell you which cuts are feasible and why a blended revenue number needs decomposition.
Maturity matters. A cohort installed five days ago cannot have an observed day-7 retention rate. If the dashboard compares last week’s partially mature cohort to a fully matured prior cohort, an apparent retention decline can be a reporting artifact. If an app update changed the first-open event or user identifier, “new installs” can jump while apparent return falls. A serious answer checks these data contracts before telling a gameplay story.
Distinguish cohort retention from period DAU. DAU includes old and new players active on a day; D7 retention asks what share of an install cohort returned seven days later. Revenue in a calendar month can be generated mainly by long-lived players even when recent installs retain poorly. The two series can therefore move apart with no contradiction. You should report both the calendar-period monetization bridge and install-cohort value curve.
Work a numerical case that reconciles
Original practice case: Month A has 100,000 average DAU, $60,000 of in-app purchase revenue, and $40,000 of ad revenue. Month B has 80,000 average DAU, $80,000 of in-app purchase revenue, and $40,000 of ad revenue. Total monthly revenue rises from $100,000 to $120,000. For fully observed install cohorts, D7 retention falls from 35% to 25%. Assume equal month lengths and consistent gross-revenue definitions solely for the exercise.
| Measure | Month A | Month B | Interpretation |
|---|---|---|---|
| Average DAU | 100,000 | 80,000 | Fewer daily players |
| IAP revenue | $60,000 | $80,000 | Higher purchase revenue |
| Ad revenue | $40,000 | $40,000 | Flat total ads |
| Total revenue | $100,000 | $120,000 | Up 20% |
| Revenue / average DAU-month | $1.00 | $1.50 | Blended rate rises |
| D7 install-cohort retention | 35% | 25% | New-player return weakens |
“Revenue / average DAU-month” is a case-specific ratio: monthly revenue divided by average DAU, not Unity’s daily ARPDAU. Do not silently call it ARPDAU. The period totals also do not prove whether player lifetime value improved; the new cohort’s future may be worse. This naming discipline prevents an attractive but misleading comparison between a monthly numerator and a daily denominator.
Break IAP into payers × average IAP revenue per payer over the month. Suppose Month A has 3,000 paying users at $20 each, giving $60,000. Month B has 2,500 paying users at $32 each, giving $80,000. Payer count fell, while spend per payer rose enough to lift IAP. You can now ask whether a limited-time bundle, price rise, whales, delayed purchases, a platform mix shift, or a bookkeeping change caused the $12 increase. The arithmetic supports “spend per payer rose”; it does not select among those causes.
The payer rates relative to average DAU would be 3.0% and 3.125%, but that ratio is only a rough period indicator: unique monthly payers divided by average daily users mixes time grains. For a proper conversion metric, divide unique payers by the unique eligible active players over the same month, or report daily payers divided by DAU per day. In an interview, calling out that mismatch is stronger than confidently quoting a false conversion improvement.
Ads staying at $40,000 while DAU falls could arise from more impressions per active player, higher eCPM, geographic mix, a new ad unit, or an integration change. The data do not show which. Reconcile ad impressions, fill, eCPM, and platform reports; inspect whether ads added friction that could plausibly hurt retention. A correlational overlap in timing is not yet causal evidence that ad load caused the decline.
Where can the retention decline come from?
Start with a fixed acquisition-cohort table. For each install date, country, platform, acquisition source, and app version, count eligible first opens and later returns at exact D1, D7, and D30 windows. Use a consistent timezone and exclude cohorts that have not aged enough. If your event stream permits multiple devices or reinstall, decide whether the unit is account, device, or app instance. Compare cohort size and event-delivery completeness before interpreting rates.
Next, separate mix from within-segment deterioration. Suppose paid acquisition doubles in a low-retention channel while organic users remain stable. Blended D7 falls even if no channel’s D7 changed. That is a composition effect. Alternatively, D7 might fall within most channels after a tutorial redesign, suggesting an experience issue. Use a fixed-weight comparison or side-by-side segment trend to identify which component dominates. “Acquisition quality dropped” remains a hypothesis until the channel-level cohort data support it.
The most useful cuts are often tutorial completion, first-session crash, load time, level progression, session count, and paywall or ad exposure. But avoid conditioning on a post-install event when estimating the effect of the acquisition channel; only engaged players complete tutorials, so the conditioned groups differ. In an interview, state whether a cut is descriptive, predictive, or causal. A funnel can locate drop-off, while an experiment is better suited to test a product change.
Inspect whether churn is broad or concentrated. The day-7 figure may hide an early day-1 failure, a day-3 difficulty spike, or a day-7 content cliff. Plot the full cohort survival curve rather than one point. Look for country/version spikes, platform-specific crashes, and changes in event instrumentation. Check that both periods use the same exact-day versus rolling definition. If D7 falls but D30 for older cohorts is stable, the problem may be new-player onboarding rather than a mature-player exodus.
Finally, ask whether the revenue and retention populations overlap. A small set of long-tenure players may account for most Month B IAP, while new install cohorts underperform. If you average spend among the surviving players, survivorship bias can make monetization look better even as many players disappear. Show revenue by install cohort and tenure, and plot payer concentration. A rising total is not a license to ignore the lost future value of new players.
A practical diagnostic matrix
| Candidate explanation | Evidence that would support it | Evidence that would weaken it |
|---|---|---|
| Acquisition-mix shift | Low-retention channel share rises; within-channel D7 stable | D7 declines across stable channels |
| Tutorial or version regression | Drop starts at release and concentrates on that version | Decline predates release and spans versions |
| Larger purchases by fewer payers | IAP payer count down, ARPPU up, top-payer share rises | Payer count and spend distribution stable |
| Ad-load trade-off | Exposure rises before exits; experiment reproduces harm | No exposure change or no retention effect |
| Measurement change | First-open or session event coverage shifts | Raw events and identity mapping stable |
This matrix is an interview tool, not a claim that one explanation must be true. Order the checks by likelihood of a bad dashboard, magnitude of the business risk, and how quickly you can validate each. A one-hour data reconciliation may prevent a costly feature rollback based on a broken retention numerator.
What would you recommend to the game team?
First state a conditional finding: “The given numbers show higher IAP revenue per paying player and lower D7 for new installs; they do not tell us whether the same players are driving both trends.” Then identify the top two hypotheses after basic quality checks. If a new ad unit launched and ad exposure increased, test an ad-frequency reduction or placement change for eligible new players. If tutorial completion fell after a release, test a targeted onboarding fix. If the drop is acquisition mix, adjust channel evaluation using cohort LTV and retention rather than total installs.
Choose outcomes and guardrails that fit the change. For an onboarding experiment, primary outcome might be D7 retention of new installs, with D1, crash rate, and 30-day revenue per install as follow-up measures. For an ad-load experiment, consider retention and total value per eligible player, with immediate ad revenue as a guardrail. Avoid optimizing one metric while moving costs to another window. Predefine cohort eligibility and allow enough time for D7 or D30 observations to mature.
Do not promise that improving retention will necessarily increase this month’s revenue. It may improve future monetizable player-days, but the magnitude depends on who returns, their value, ad load, and acquisition cost. Conversely, a one-month revenue rise might be real profit or merely a promotional spike. State the time horizon and show contribution after platform fees and acquisition spend if the interviewer asks about commercial value.
The AdMob cohort report illustrates why install-cohort retention and lifetime value can be viewed together. That does not require one vendor stack; it points to the right analytical join. The decision you recommend should be evaluated on the cohort exposed to it, not on a blended company total dominated by old players.
A two-minute case answer
“I would align the definitions first: calendar-month revenue by source versus D7 return for fully matured install cohorts. The numbers can coexist because the revenue may come from existing high-value players while fewer new players return. In a worked bridge, IAP rises from $60,000 to $80,000 because 2,500 payers spend $32 each rather than 3,000 payers spending $20; ads stay at $40,000. That explains the revenue arithmetic, not the cause.”
Then continue: “I would validate event coverage and cohort maturity, cut D7 by acquisition source, version, and geography, and inspect tutorial, crash, and ad-exposure changes. I would join revenue and retention by install cohort to see whether value is concentrated in survivors. Only then would I test the leading product or acquisition hypothesis, with retention and value guardrails.”
Practice that reasoning with Measure Game Monetization and Validate a Reporting Repair. The strongest answer makes the two time grains visible, proves the revenue bridge, and refuses to infer a cause from the headline alone.