Verify attribution before you spend: proving the funnel works in staging, not in a campaign report

Attribution is the kind of system that fails silently. A missing Android fingerprint, an AASA file served with the wrong content type, a consent gate that never opens — none of these throw an error. They produce a campaign report a month later with 'organic' where the paid installs should be, and a launch retrospective about why the numbers don't add up. The whole thing is testable before launch. Most teams don't.

What problem does this solve?

Before spend goes out, you want proof that a click on a link produces an install that attributes deterministically to that link, on both platforms, with consent handled. The proof is a row in the match audit log. Getting that row in staging costs an afternoon. Getting it from a live campaign costs the campaign.

How do you set the test up?

One test link per platform, tagged so the test installs are unmistakable and can be excluded later. Then the full loop on a real device: tap the link, install from the store, open, and read the audit log for that install.

{
  "deepLinkPath": "/",
  "customData": {"cmp": "qa-attribution-check", "env": "staging", "run": "2026-09-03-a"}
}

What does a passing run look like?

Anything other than deterministic on this run is a finding. 'None' usually means the click token didn't survive — the Referrer on Android, the paste control on iOS. 'Probabilistic' means matching is on for the workspace and the deterministic path failed, which is worth knowing before you rely on it.

How do you run it more than once?

• resetForTesting in the SDK clears the install flag, cached attribution and device ID, so the next open behaves like a genuine first launch without an uninstall cycle. It's for testing only; it must not ship.
• The link validator checks the AASA and assetlinks.json files the whole thing depends on. Run it against the link domain before the device test, not after.
• Register every Android signing fingerprint you'll install from — Play, upload key, and each developer's debug key. A missing one is the most common reason the Android run fails.
• Test with consent declined too. The correct result is an install with no attribution and events queued; if attribution appears, the gate isn't gating.

Which metric should you watch?

There's only one: the match type on the test install, on each platform, on the day before spend starts. Deterministic on both is the green light. Anything else is a bug you just found for free.