What causes install attribution credited to the wrong campaign?

The campaign id is read after install from a fresh session rather than from the install referrer, so the link between click and install is lost and credited to organic.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix Install Attribution Credited to the Wrong Campaign

Quick answer: Capture the Play install referrer or iOS attribution token at first launch, match it to the click, and attach the campaign id to the first_open event.

Paid installs show up as organic because the campaign parameters never survived the install, making your ad spend look ineffective. Reading the install referrer at first open restores correct attribution.

How to fix it

1. Read the install referrer

On Android, query the Play Install Referrer API at first launch to recover the utm parameters from the click. On iOS, use SKAdNetwork or the attribution token rather than guessing.

2. Stamp first_open with campaign

Attach the resolved campaign, source, and medium to the first_open event so attribution is fixed at the start of the player's life. Later sessions inherit it via cohort.

3. Reconcile with the network

Compare your attributed installs against the ad network's reported conversions to catch systematic gaps. A large divergence usually means the referrer is not being read.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every mobile error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

Most of the time the fix is small. Seeing the failure clearly is the part that actually costs you.