Goodgame: deduplication restores a decision, but it does not create a player

Goodgame's published iOS measurement case explains why a team may pause spending when two reporting systems count overlapping outcomes. The remedy starts with reconciling credit, not claiming new growth.

What the public case establishes

AppsFlyer describes Goodgame Studios facing overlapping SKAN and other attribution records, temporarily pausing some Facebook activity and adopting its Single Source of Truth approach. The historical case explains a conversion-value flag used to identify overlap and says the team later regained confidence in campaign decisions. AppsFlyer 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

Removing duplicate credit can lower a reported install total while making the report more useful. That is a measurement correction, not evidence of weaker demand. Conversely, restoring confidence and resuming a channel does not prove that the deduplication system itself generated additional players. A debrief should keep reporting correctness, decision confidence and economic outcomes in separate stages.

The proposed reconciliation ledger stores the original counts, estimated or identified overlap, resulting combined count and the method used. It should also show unknown coverage rather than force every outcome into a precise-looking category. A single dashboard can be convenient without becoming unquestionable ground truth; its rules still require inspection.

A usable next check

Run a synthetic overlap example through the team's reconciliation logic, including no overlap, full overlap and an unresolved case. Check that deduplication never creates additional outcomes and that uncertainty remains visible. For the current production implementation, consult current provider and platform documentation rather than implementing the historical conversion-value example from this case unchanged.

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 draft does not verify the current SSOT algorithm or recommend a particular conversion-value allocation. No Goodgame data was inspected; the public case is historical primary evidence of the supplier's account, not an independent product audit.

For background, see reading an mmp dashboard without fooling yourself and cohort quality checklist ua spend. These are existing archive discussions, not independent certification of this case. No first-hand campaign result is asserted.