The launch went live on schedule. Two weeks later, finance asks why the MMP is reporting revenue about 30 per cent below the payment gateway. The investigation finds a revenue event that fired without a value on one platform, so a third of purchases were logged as zero. The QA protocol that would have caught it before launch took one afternoon. The two weeks of decisions made on understated revenue cannot be taken back.
Attribution QA is the discipline of proving, before a single rupee is spent, that what your dashboard reports matches what actually happened on the device. It is not campaign QA, which checks budgets, audiences, and creative on a specific campaign. This is instrumentation QA: installs, events, revenue, deep links, and postbacks, tested against expected results with a go or no-go sign-off at the end. Help centres document individual tests. This is the complete launch protocol.
What Attribution QA Covers, and What It Is Not
Mobile attribution QA is the pre-launch process of verifying that installs, events, revenue, deep links, and postbacks all record correctly, tested on real devices against expected results. It is instrumentation testing, and it is separate from campaign QA.
The distinction matters because the two get confused and one gets skipped:
- Attribution QA asks: does an install attribute to the right source, does a purchase report the right value, does a deferred link route correctly? It runs once per instrumentation change, before launch.
- Campaign QA asks: are the budgets, bids, audiences, and creative correct for this campaign? It runs before every campaign. Our 48-point campaign launch checklist covers that side. Keep them distinct in your process. Campaign QA on a broken instrumentation base still produces wrong numbers, because the campaign was fine and the measurement was not. This protocol fixes the base.
Building the Test Matrix
QA is only trustworthy if it covers the conditions your real users create. A test matrix defines those conditions so nothing important goes untested.
The matrix should span:
- Devices and OS versions: at least two Android and two iOS versions, including the oldest you support and the newest, because deep link behaviour and privacy prompts differ across them.
- Install states: fresh install, reinstall, and existing-user update, since each attributes differently.
- Network conditions: a normal connection and a slow or interrupted one, because deferred link resolution and event delivery can fail on poor networks.
- Attribution scenarios: organic, paid per network, and a deferred deep link install. Write the matrix down before testing, because an untested combination is the one that breaks in production. Use the Linkrunner integration testing docs as a model for structuring the cases.
Testing Install Attribution
Install attribution is the foundation, and it fails quietly when organic and paid get crossed. Test each source deliberately.
- Organic install: install directly from the store with no campaign link. Pass: install attribution reads organic, not a paid source.
- Paid install per network: install from a Meta, Google, and TikTok test link in turn. Pass: each attributes to the correct network and campaign.
- Reinstall: delete and reinstall for an existing user. Pass: the reinstall attributes per your reattribution rules, not as a brand-new organic install.
- Deferred install: tap a deep link, install, open. Pass: the install is credited to the link that drove it. The failure mode to hunt for is a paid install quietly reading as organic, which makes your best channel look free and your budget look wasted. If installs attribute wrong, nothing downstream can be trusted, so this section gates the rest.
Testing Events and Revenue
Events and revenue are where the most expensive silent failures live, the ones finance finds a fortnight later. Test parameter accuracy, deduplication, and currency explicitly.
- Each event fires once. Trigger each key event and confirm one event, not zero and not three. Pass: counts match the test script.
- Properties are populated. Confirm the fields you will segment on are present and correct, not null.
- Revenue carries value and currency. Make a test purchase on every platform and confirm the amount and currency are correct, not zero. Pass: the value matches the transaction.
- No duplicates and correct dedupe. Confirm a single purchase is not double-counted across the SDK and a server event. Across audits, the revenue-versus-gateway mismatch in this article's opening is the single most common expensive failure, and it almost always traces to a value that fired null on one platform. Test revenue on every platform you ship, not just the one the developer happened to build on. The upstream discipline that prevents most of these is a well-designed event taxonomy, and when numbers still diverge, the attribution discrepancy diagnostic guide walks the causes in order of likelihood.
Testing Deep Links and Deferred Deep Links
Deep links fail across surfaces in ways that only manual, cross-device testing catches. Test both the installed-user path and the pre-install path.
- Direct deep link: as an installed user, tap a link and land on the exact screen. Pass: correct destination, no home-screen fallback.
- Deferred deep linking****: as a new user, tap a link, install, open, and land on the intended screen. Pass: routing survives the store visit.
- Across surfaces: test links opened from social apps, browsers, and messaging apps, since in-app browsers handle links differently.
- Fallbacks: confirm desktop and unsupported-device taps reach a sensible page. The deferred case is the one teams skip and regret, because it only breaks for users who did not already have the app, which is precisely your paid acquisition audience. The full device-by-device method is in our step-by-step guide to QA-ing deep links before launch.
Testing Postbacks to Meta, Google and TikTok
Postbacks are how the ad platforms learn what worked, so a misfire trains the algorithm on the wrong signal. Verify each one reaches the right place.
- Connection is live. Each network shows an authorised, active connection.
- The right event is mapped. A purchase maps to purchase, not a generic event, in each network's optimisation slots.
- Postbacks** arrive on the correct account and pixel.** Confirm in the network's own event manager, not just the MMP.
- Value passes through. For value-based postbacks, confirm the revenue amount arrives, and no test traffic leaks into the production pixel. A common issue is troubleshooting a Meta event that appears in the MMP but never reaches the pixel, which our guide to troubleshooting Meta SDK event attribution addresses directly. Check the destination, not just the source, because the MMP showing an event does not prove the network received it.
The Sign-Off Log and the Go or No-Go Decision
QA without a recorded decision is just poking at the app. The sign-off log turns the protocol into an accountable gate.
The log should capture, for each test case: the condition, the expected result, the actual result, pass or fail, and the tester. Then a single named owner reads the log and makes one call:
- Go: every case passed, spend can flow.
- No-go: any case failed, the fix happens before launch, and the case is re-run. The discipline is that "probably fine" is a fail, and a launch without a completed, signed log is a launch nobody certified. Set the attribution window expectations in the log too, so a tester knows how long to wait for an event before calling it missing rather than merely delayed.
Ongoing QA After Launch
Instrumentation decays. A new app version, a renamed event, or a changed pricing flow can silently break what QA once passed, so attribution QA is not a one-time gate.
Build a monthly re-test into the calendar:
- Re-run the highest-value cases: revenue events with value, deferred deep link routing, and postback delivery.
- Diff against last month. A metric that shifted without a campaign change is a broken event until proven otherwise.
- Re-test after every release that touches events, links, or the payment flow. Our guide to monthly MMP data quality checks covers what to re-verify and how to spot drift before it becomes a quarter of bad reporting. The launch protocol proves the base is sound; the monthly re-test keeps it that way.
How to Run This QA in Your MMP
The protocol is tool-agnostic, but running it is faster when your dashboard surfaces the raw event stream. Practical steps in any MMP:
- Use a debug or test mode so QA events do not pollute production data or the ad pixels.
- Watch events arrive in real time on a device, confirming each fires as expected before checking aggregates.
- Reconcile against source of truth: installs against the store console, revenue against the payment gateway.
- Export the sign-off log so the go or no-go decision is on the record. Tech Explainer: why the MMP showing an event is not proof. An MMP can register an event it received from the SDK while the postback to the ad network silently fails, or a revenue event can appear with a null value that the summary view rounds past. Seeing a green tick in one dashboard proves that one hop worked, not the whole chain. Real QA verifies each hop independently: device to MMP, MMP to network pixel, and the value at each step. That is why the protocol checks the network's own event manager and the payment gateway, not just the MMP's summary.
Where a single platform unifies deep linking and attribution, the matrix shrinks because there is one SDK to test rather than two, and no connector between a link tool and the MMP to verify. Platforms like Linkrunner collapse those cases, which is why a unified stack tends to pass QA faster.
The Most Expensive QA Misses, Ranked
Not every QA failure costs the same. These are the ones that do the most damage, roughly in order of how much money they waste before anyone notices.
- Null-value revenue on one platform. Purchases fire with no amount, so ROAS reads far too low, and the team throttles a profitable channel. This is the fortnight-later finance surprise, and it is the costliest miss.
- Paid installs reading as organic. A misattributed source makes your best paid channel look free and inflates organic, so budget flows to the wrong place for as long as it goes unseen.
- Postbacks to the wrong pixel. The ad platform optimises on a broken or absent signal, degrading delivery quietly across the whole campaign.
- Broken deferred deep links. Paid users land on the home screen instead of the promoted offer, tanking conversion while installs still count.
- Duplicate events. A single action counted twice inflates conversions and misleads bidding. The ranking is a triage guide: if you can only test a handful of cases before a launch, test these first, on every platform, because each one silently corrupts a decision the team will make with real money. The cheapest afternoon you will ever spend is the one that catches a null revenue value before spend, not after.
Frequently Asked Questions
How long does attribution QA take?
The full protocol on a first launch is typically an afternoon to a day, depending on how many platforms and event types you ship. That is a fraction of the cost of the alternative, which is discovering a null-value revenue event two weeks into spend after optimising against understated numbers. The monthly re-test is far shorter because you are re-running known cases.
What must be re-tested after launch?
Re-test the highest-value cases every month and after any release that touches events, deep links, or the payment flow: revenue events firing with value, deferred deep link routing on both platforms, and postback delivery to each network. Any metric that moved without a matching campaign change should be treated as a broken event until QA proves otherwise.
Is this the same as testing my campaigns?
No. Attribution QA tests the instrumentation, installs, events, revenue, deep links, and postbacks, once per instrumentation change before launch. Campaign QA tests budgets, bids, audiences, and creative before every campaign. Both matter, and clean campaign QA on broken instrumentation still produces wrong numbers, which is why this protocol comes first.
Catching the Expensive Failures Before Spend
The revenue mismatch that finance finds a fortnight after launch is not bad luck. It is a null value that a one-afternoon protocol would have caught. Build the test matrix, verify installs, events, revenue, deep links, and postbacks against expected results on real devices, and gate the launch on a signed go or no-go log. Then re-test monthly so the base stays sound.
If you want a stack where the QA matrix is smaller because deep linking and attribution share one SDK and one event model, that is what platforms like Linkrunner are built around, and you can request a demo from Linkrunner to run your setup against it. Start by writing your test matrix and sign-off log, and do not let spend flow until every case has a recorded pass.