MyTona: separate purchase validation from traffic attribution
MyTona's public fraud case shows two different ways a growth decision can be corrupted: attributing the wrong install and trusting a purchase that should not count as revenue.
MyTona's public fraud case shows two different ways a growth decision can be corrupted: attributing the wrong install and trusting a purchase that should not count as revenue.
What the public case establishes
Adjust describes MyTona combining fraud prevention with purchase verification for games including Seekers Notes. The account identifies discrepancies between reported purchase values and store-side values, and dates its purchase-verification adoption to December 2017. This is a historical customer case published by the measurement supplier. 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
An acquisition team can successfully reject suspicious installs while still feeding false revenue into a bidding or forecasting system. The controls answer different questions. Attribution asks where a user came from; purchase validation asks whether the economic event is real. Treating either as a complete fraud solution creates a blind spot precisely where high-value outliers can influence spend.
The decision sequence to preserve is detection, reconciliation and correction of the optimisation input. Do not erase rejected events from the audit record: retain the reported event, its validation status and the reason it was excluded from decision-ready revenue. That creates a checkable boundary between operational evidence and the number the buyer actually used.
A usable next check
Run a controlled replay using synthetic accepted, rejected and unresolved purchase events. Confirm that only accepted amounts enter the decision total, while every event remains traceable. Then compare your production reconciliation process with the store or payment system's authorised records. The worksheet describes this check; it does not claim access to MyTona's receipts or validate a current integration.
| Test element | Proposed specification |
|---|---|
| Control | Revenue total includes every reported purchase event |
| Variant | Decision total includes only accepted events while retaining the audit trail |
| Readout | Reconciled value, unresolved-event age and exclusion reasons |
| Stop or reject | Pause value-based decisions when unresolved events materially change the ranking |
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
The supplier's fraud and performance figures are not independent findings. The historical case cannot certify present-day fraud coverage, purchase correctness or the causal effect of any individual product.
For background, see reading an mmp dashboard without fooling yourself and cohort quality checklist ua spend. No first-hand campaign result is asserted.
