DeNA: define a player before reconciling the acquisition report
DeNA's public data-management interview explains a problem that can survive a technically correct integration: teams may be counting different things when they say users.
DeNA's public data-management interview explains a problem that can survive a technically correct integration: teams may be counting different things when they say users.
What the public case establishes
Adjust's interview with DeNA's Yuichi Fukada describes forwarding raw data into internal analysis, joining creative material with performance, and varying views according to the KPI. The account discusses devices, accounts and users, including repeated installs associated with players rerolling an early random reward. Adjust case study.
This debrief analyses a public customer case published by a commercial supplier. It is not an original UA Ledger interview. The chronology below follows the supplier’s account; we did not inspect the advertiser’s dashboards or interview its staff.
The decision worth examining
A device install, an account and a person are not interchangeable units. In a game where a player restarts to seek a preferred initial result, install counts can change without equivalent growth in the player population. The operating decision comes before dashboard design: choose the entity needed for the question, and retain the transformations that connect it to other entities.
Our proposed metric dictionary gives each reported count an entity, qualifying event, deduplication rule and time boundary. It also names the owner who can explain exceptions. A creative report may still use install events, while a product report uses accounts, provided the interface makes the difference explicit rather than pretending both are the same measure of demand.
A usable next check
Create a synthetic sequence containing an initial install, a restart, a second account and a return session. Ask different teams to calculate their usual headline metric from it. Resolve disagreements by writing definitions, not by choosing whichever dashboard appears more authoritative. Then test those definitions against permitted internal records and preserve the original event history.
| Test element | Proposed specification |
|---|---|
| Control | Unqualified user count drawn from each team's usual view |
| Variant | Counts labelled by entity, event and deduplication rule |
| Readout | Definition agreement and reconciliation of the same event sequence |
| Stop or reject | Do not compare counts whose entity or restart treatment differs |
Download the populated case worksheet. Its control, variant and decision rules are a proposed experiment, not an account of results already measured. Keep the source URL with the worksheet when circulating it so reported findings cannot become unattributed team benchmarks.
Evidence boundary
This is analysis of Adjust's published interview, not an interview conducted by UA Ledger. Historic SDK behaviour in that account is not a current implementation specification, and no DeNA user data was accessed.
For background, see reading an mmp dashboard without fooling yourself and cohort quality checklist ua spend. No first-hand campaign result is asserted.
