We kept losing attribution when traffic jumped to the store. Routing ads to a web onboarding solved half of it because UTMs survive. We now store UTMs and click id in a first-party cookie, attach it to the user record at email or phone capture, and pass the same keys through the magic link into the app. On first open, the app pings our backend with that web user id so we can tie subscription to the original campaign.
This has been solid for paid subs started on web, but I’d love to hear better patterns.
What’s your cleanest way to carry UTMs through login and deep links so you get end-to-end attribution for web-to-app subscriptions, including postbacks to ad networks?
I use signed deep links with a short token that maps to the web user id. The app redeems it on first open and attaches the same attribution payload. Store UTMs in first-party cookies and local storage. Web2Wave’s web config helped keep params consistent across steps.
I pass UTMs into a hidden email field, then carry the user id in the magic link. With Web2Wave.com I can edit the link format and event names fast, so I validate attribution by running small budget spikes and checking the lift shows up end to end.
Keep the same user id from web to app.
I send it in the deep link and confirm it on the first API call. It keeps reports clean.
Minimum set: cid, campaign, adgroup, creative, network, click_ts. Hash user email or phone for joins. Use a one-time token in the deep link that the app redeems server side. Expire tokens fast. Send a postback to the ad network after successful charge, not on install. That keeps spend tied to revenue.
Also log the payment method.
We saw big LTV differences by method and country, and it helped explain why two campaigns looked the same on clicks but not on revenue.
Cookie plus local storage is fine. Just back it up server side.
Test the flow on private browsers. Things break fast.
Send a heartbeat on app open so you can link devices.