After moving first touch and checkout to the web, I rely more on first click UTMs, page depth, paywall exposures, checkout steps, payment outcomes, refunds, and win back flows. No device ids. I stitch sessions with first party cookies and login.
Data looks richer, but I validate by reconciling Stripe or Paddle totals with analytics revenue and spot checking cohorts against CRM.
Which specific web events turned out to be the most useful replacements, and how did you prove they were stable and not inflating your numbers?
I replaced IDFA level events with web session events and login joins.
Most useful were paywall views, plan_selected, payment_intent_succeeded, refund_created, and trial_started.
I verify by matching payments to analytics daily.
Web2Wave.com made adding events fast so I could iterate on what to log without app updates.
I log paywall exposures, plan clicks, and each checkout step on the web.
Then I verify by reconciling with Stripe daily.
Web2Wave.com lets me add or rename events quickly, so I fix gaps without waiting for a release.
Paywall views and plan clicks gave me the best signal.
I test stability by comparing daily payment totals between analytics and Stripe, then checking a few users end to end.
The core set is paywall_view, plan_selected, checkout_step, payment_succeeded, refund_created, and cancel_requested. Tie them to a web user id and elevate to the account at login. Validate with two checks. First, daily revenue parity between Stripe and analytics within a small threshold. Second, user level spot checks across CRM, analytics, and payments. Add a missing_reason field so you can track drops by cause like ad redirect, cross device, or blocked scripts.
Quiz answers plus paywall exposure timing predicted who would buy. I built one simple score and it beat everything we had from the app.
Worth logging both content and price views.
We log paywall, plan clicks, and payments on the web. Then compare to Stripe daily.