Reconcile two attributed-install lists without counting their overlap twice
Analysis
By Isaac Turner, Measurement Editor — 2 min read
View author profile
Two attribution systems can each credit an install without their totals being additive. A reproducible synthetic example with editable inputs and explicit limits.
Two attribution systems can each credit an install without their totals being additive. This lab uses a known overlap to calculate the union of two lists. It is an accounting exercise for matched records, not a method for deciding which vendor deserves credit.
Define the calculation before using it
First obtain an authorised matching rule that makes the two populations comparable. Count the records in each list and the records appearing in both. Add the two list sizes and subtract the shared count once. The overlap must be no larger than either input list. Do not manufacture a device-level match where privacy restrictions or different identifiers prevent one.
Work through the synthetic example
List A contains 600 installs, list B contains 500 and 150 appear in both. The distinct union is 950 rather than 1,100. The duplicate share of the summed claims is about 13.64%. That difference identifies a reconciliation question; it does not establish incremental installs, fraud or which attribution model is correct.
| Output | Worked-example result |
|---|---|
| Distinct union | 950.0000 |
| Overlap share of summed claims % | 13.6364 |
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 overlap 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 export schema separates the reporting date, UTC timestamp and event parameters. The worksheet uses simplified aggregate inputs; it does not claim that an export already contains a correctly reconciled cohort. See Google Analytics BigQuery Export schema, especially “event_date, event_timestamp, event_value_in_usd and event_params fields”.
The worksheet assumes exact, permitted matching. Probabilistic matching, re-installs and divergent conversion windows can invalidate that assumption and must be documented before using the union as an operational total.
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.
Featured
Related posts
measurement
media buying
·1 min read
Using predicted LTV in bids: disclosure checklist for the UA team
measurement
media buying
·1 min read
Blended ROAS targets that hide channel failure in F2P portfolios
measurement
media buying
·2 min read
Web-shop LTV with VAT-inclusive prices versus store net proceeds (labelled synthetic)
measurement
media buying
·1 min read
View-through attribution windows on F2P rewarded and interstitial traffic
More from the Measurement desk
measurement
·2 min read
Airbridge adds Amazon Ads as an app measurement channel
measurement
·2 min read
When to freeze a cohort for payback review (and when not to)
measurement
·1 min read
Web-shop purchaser quality vs store IAP purchaser quality
measurement
·1 min read