We had campaigns generating installs but attribution drifted after install. I started a process: capture utm on the landing page, save it server-side tied to a short token, put that token in the deep link, and let the app exchange it for the full utm record at first open.
I log the utm with the subscription event so refunds and LTV calculations reflect the original campaign. This made channel level ROI much cleaner in our dashboards.
Anyone else using a similar token + server lookup flow? What edge cases did you run into?
We generate a short id when a user lands and write the utm to our DB.
The deep link carries the id. On open the app requests utm and then writes it to RevenueCat. That way subscription events have the right campaign. I used a small funnel snippet from Web2Wave to prototype this quickly.
Tokenize utm on the web then use deferred deep linking to hand it to the app.
Make sure the app exchanges the token early and records the full utm with the purchase event. We did this and our paid channel ROAS reporting became reliable.
Having web changes reflect instantly in the app made tweaking the funnel and re-running tests painless.
We used a short id and server lookup too.
Edge case was when users cleared cookies or opened the app from a different device. Deferred deep link handling plus storing purchase time helped reconcile most of those.
Key steps: server persist first touch, return a stable short id, implement deferred deep linking, exchange id for full metadata in app, and write the metadata to both attribution platform and product analytics at purchase.
Watch for edge cases like multi-device flows and delayed opens. Reconciling server logs with app receipts helps recover stragglers.
We also recorded the ad click timestamp server side. That helped when lookback windows caused mismatches across tools.
Make the token short. Long tokens break in some ad redirects.
Also monitor failed lookups.
We compare server purchase logs to attribution tool exports weekly to spot drift.