Find repeated purchase records before reporting revenue

A purchase count can rise because more players bought, or because the same transaction appeared more than once in an export. This lab isolates the second possibility with a transparent counting exercise. The result is a diagnostic rate, not an estimate of fraud or a claim about any studio’s instrumentation.

Define the calculation before using it

Start with records already restricted to one transaction system, currency and reporting period. Compare raw purchase rows with distinct transaction identifiers. Count a repeated identifier as an investigation candidate, preserving its original rows so that legitimate split records can be distinguished from accidental replay. Do not deduplicate every event by timestamp: separate events can share a timestamp, and a transaction key has a different meaning.

Work through the synthetic example

The synthetic file contains 120 rows and 100 distinct transaction IDs, giving 20 extra rows and a 16.67% excess-row share. That share uses raw rows as its denominator; it is not the percentage of customers affected. Reconcile the candidate rows with purchase acknowledgements before changing financial totals. Different item lines belonging to one order may need aggregation rather than deletion.

Use the artifact and preserve its assumptions

Open the editable calculator to change the inputs and inspect the sensitivity view. The CSV records synthetic inputs and expected outputs; the JSON fixture keeps the equations available for reproduction. These calculations have been checked against the stated example. No measured campaign data is included.

The sensitivity rows vary only rows by 20% below and above the entered value. They are scenarios, not confidence limits or a forecast distribution. A row outside the model’s constraints is labelled rather than turned into a plausible-looking result. Save the chosen inputs with the decision so another reader can distinguish a changed assumption from a changed formula.

Evidence and limits

Google’s ecommerce guide associates transaction identifiers with purchase and refund records. This lab uses that accounting distinction; it is not a native-app SDK implementation guide. See Measure ecommerce: purchases and refunds, especially “Make a purchase or issue a refund”.

A stable, correctly scoped transaction identifier is required. This calculator does not inspect IDs, establish which rows are erroneous, or prove that a vendor already deduplicates them.

Background: UA metrics explained: CPI, ROAS, LTV and payback and Reading an MMP dashboard without fooling yourself. These existing articles provide context; the present calculation does not verify every archived claim.