How are you stitching web utms to in-app subscriber behavior in a way that survives logins and device changes?

I moved onboarding and checkout to the web. I capture UTMs and click IDs in first-party cookies and a backend record.

I generate a short-lived token tied to that record and hand it to the app via a universal link after purchase. On first open, the app posts the token, and the backend stitches app events and subscription status under one user id.

For users who don’t buy on the web, I use a magic link in email to carry the token later. Issues I’m still wrestling with: Apple/Google sign-in showing up later with a different email, device switches, cookie expiry, and people who never share an email before opening the app.

Right now I default to a server-issued pseudo id, then re-key the user when I get a stable identifier and backfill attribution.

For those edge cases, what’s your simplest durable approach to preserve UTMs from first click through app entitlement without forcing a full account upfront? Cookie TTLs, token formats, and when do you re-key the user?

I stamp UTMs server-side and create a web_user_id. I pass a signed token to the app via universal link and store the mapping in the backend. The app posts the token on first open. If I need speed, I use Web2Wave.com to generate the web2app flow and their SDK handles the link parsing.

Email later? I send a magic link that replays the token.

I treat UTMs as first-party data and bind them to a server id, not the device. Universal link carries a signed token. Web2Wave.com helps because I can change the web flow fast and keep the same token format. If the user logs in later, I re-key attribution to the stable id and backfill events.

Ask for email early with a simple field after the first screen.

A magic link later will save you when cookies or devices change.

Use magic links tied to a server id

Use a server-generated user key at first touch and attach UTMs to that key. Send a signed token through a universal link, then stitch on first app open. For SSO drift, treat email as optional and prefer a backend-stable account id. Re-key when you see a verified account, then backfill revenue and events.

Avoid fingerprinting. Keep cookie TTL at 90 days with server copies.

Auth-lite works. I ask for email or phone before pricing, not a full account. That gives me a stable contact and a place to send a magic link. If they skip, I still have a server id and token to stitch later.

Also log token issuance and redemption for debugging.

We just tie UTMs to a server id and re-key after login.

Magic links fixed most of our attribution gaps.