PROPOSED PROJECT
Player Drop-Off Analysis
Help game teams investigate where players stop returning. Use activity records collected with permission, game versions, and player feedback to compare groups, find where progress stops, and identify possible explanations to test. Show how many players each finding represents.
Fewer players returned. Start with the evidence.
Day-seven return window
1,200 eligible players per build
At least one session between 168 and 192 hours after the player’s first session.
Find the point of friction.
Then test the explanation.
Two fictional groups each contain 1,200 new players with a complete eight-day observation period. Build 1.7 has 300 players observed in the day-seven return window; build 1.8 has 216, a difference of seven percentage points. In the ordered progress example, gate completion falls from 720 to 480 players. Paid-acquisition share also changes from 30% to 55%, so the report cannot attribute the return difference to the gate or the release alone. These are authored sample figures, not measured game results.
WHAT IS USUALLY DONE
A dashboard shows fewer returning players after a release, but hides how many players were observed, how long they were followed, and whether the acquisition mix changed. Teams may blame a difficult level from a few comments without checking the event sequence or comparing equivalent groups.
WHAT SOVRUN CAN DO FOR YOU
Sovrun would build an investigation report from permitted player activity, release versions, and feedback. Code calculates clearly defined progress and return measures for groups with complete observation windows. Models help categorize supplied comments and propose questions to investigate, with source examples attached. The report shows where progress differs, how large each group is, what else changed, and which explanations need a controlled test.
Follow the same players
through the same steps.
Each row counts distinct eligible players who completed the steps in order within their first 24 hours. Bar widths use the full 1,200-player group as the denominator. Incomplete tracking must be investigated before interpreting an absent event as failed progress.
Started the game
Reached first checkpoint
Opened harbor gate
Started first voyage
Where the groups separate.
These percentages use checkpoint players, unlike the chart above. The difference suggests a place to investigate; it does not identify the cause.
A comparison needs
its limits in view.
Both groups have completed the return window, but they joined at different dates and had different acquisition mixes. This is an observational comparison. The report keeps those differences beside the proposed investigation.
- First session
- 1–7 September
- Eligible players
- 1,200
- Day-one return
- 540 / 1,200 (45%)
- Day-seven return
- 300 / 1,200 (25%)
- Paid acquisition
- 30%
- First session
- 15–21 September
- Eligible players
- 1,200
- Day-one return
- 456 / 1,200 (38%)
- Day-seven return
- 216 / 1,200 (18%)
- Paid acquisition
- 55%
Window definitions. Day one is 24–48 hours after the first session. Day seven is 168–192 hours. Records are available through 30 September 2026, so even the last joiner has completed both windows.
Before deciding. Verify event coverage and player eligibility, compare acquisition and platform groups, and reproduce any suspected gate issue. Then test a proposed change with a defined measure and observation period.
A clear finding.
A focused next investigation.
The proposed first report covers agreed game builds, eligible player groups, event definitions, and available feedback. It helps the team choose what to test without turning a correlation into a promised fix.
Check the gate step.
- Build 1.7
- 720 / 1,200 completed
- Build 1.8
- 480 / 1,200 completed
- Source
- Defined ordered events
- Check first
- Tracking + group mix
From signal to a test.
- Verify events and group eligibility.
- Compare like-for-like player groups.
- Reproduce the suspected gate issue.
- Test a fix with agreed measures.
How we’d make it happen.
Define who and what can be compared
Confirm event meanings, consent, identity quality, build version, and observation length. Exclude ineligible records and document missing data before computing measures.
Find where observed progress changes
Calculate return rates and ordered progress counts. Compare platform and acquisition mix, then attach relevant feedback without treating comments as proof of a cause.
Test a specific explanation
Agree on an investigation or controlled experiment with the team. Set the main measure, observation window, and checks before judging the result.
Where AI helps
Language models group de-identified feedback and draft source-linked summaries. Optional analytical models can explore associations only after the event definitions, missing-data rules, and evaluation plan are agreed. Counts, percentages, ordered progress steps, and observation windows are calculated in code. The workflow does not infer why an individual left, claim causation from a release comparison, or invent events for missing activity.
What people approve
Analysts define eligible players, event order, return windows, consent rules, and data exclusions. Game designers review possible explanations and decide what to test. Engineers verify that event tracking is comparable between builds. Results describe observed activity in the supplied data, not permanent departure or a guaranteed revenue outcome.
What we’d need to start
- Permitted, de-identified activity exports with stable player IDs, event times, game versions, and known coverage limits
- Release notes, acquisition and platform records, and consented player feedback linked to the relevant versions
- Agreed progress and return definitions, observation windows, exclusion rules, and analytics and design reviewers
How we’d test it
Reconcile every chart to distinct eligible player records and verify that each ordered step follows the previous one. Test late-arriving data, duplicated events, incomplete observation windows, and changed event names between builds. Keep cohort sizes and denominators visible. Validate any causal claim through an appropriate experiment or study; an observational release chart alone cannot establish why players stopped returning.
Prepared for Gaming & esports. We would agree on the work after reviewing your brief, materials, and requirements.
This is a proposed project, not completed client work. The visuals and numbers show example outputs, not measured results.
