Web to app attribution: from first ad to in-app purchase

You run ads to your website. People install the app, start a trial and subscribe inside it. The ad platform reports installs. The App Store reports revenue. Nothing connects them.

One app founder compared the numbers: "Google's own conversion numbers were far from what I saw in RevenueCat." Google reported 53 conversions; RevenueCat showed 9 new customers (Indie Hackers). A commenter's advice: "judge ads on cost per paying customer, not cost per install."

This guide shows how to build that view.

Why web-to-app funnels are hard to measure#

Four gaps break the trail between ad and purchase.

1. The app store sits in the middle. A visitor clicks your ad, lands on your site, then goes to the App Store or Google Play. The store doesn't pass your campaign data to the app.

2. iOS limits tracking. Since iOS 14.5, apps need permission through Apple's App Tracking Transparency prompt to track users across apps (Apple). Opt-in rates vary by source: Adjust reported 35% in Q2 2025 (Adjust), AppsFlyer 50% (AppsFlyer).

3. Apple's privacy reports are slow and coarse. SKAdNetwork 4 sends up to three reports covering days 0–2, 3–7 and 8–35, each after a random delay of up to several days (Adjust). They don't identify users.

4. Revenue lives in different systems. In-app purchases sit with Apple and Google. Web purchases sit in Stripe. Renewals happen with no app open at all.

The building blocks of mobile app attribution#

One change worth knowing: Google retired its Privacy Sandbox technologies, including on Android, in October 2025, citing low adoption (Android Authority). Don't build plans around them.

How to connect web and app: 6 steps#

Step 1: Create the account on the web when you can#

The strongest link between web and app is a login. If the visitor creates an account on your website before installing, you can tie the ad click to a user ID immediately. When they log in to the app, it's the same person. No guessing.

For many apps that means a short web onboarding flow: a few questions, an account, then "download the app."

Step 2: Capture click data on landing#

Store UTMs, gclid, gbraid, wbraid and fbclid on your server when the visitor lands, against an anonymous ID. Move them onto the user ID at sign-up. This is the same first step as our SaaS marketing attribution setup.

Step 3: Carry the click through the install#

For visitors who install before creating an account:

• Use a deferred deep link from a deep-linking or attribution provider, so the first app open receives the campaign data.
• On Android, also add your parameters to the Play Install Referrer.
• Use Universal Links and App Links for people who already have the app.

Step 4: Tag every purchase with your user ID#

Both stores let you attach your own ID to a purchase:

• Apple: appAccountToken, "a UUID that associates the transaction with a user on your own service" (Apple)
• Google Play: setObfuscatedAccountId() (Android Developers)
• Stripe (web purchases): client_reference_id or customer metadata

Step 5: Count revenue on your server#

Don't rely on the app to report purchases. Use:

• App Store Server Notifications V2 for purchases, renewals and refunds (Apple)
• Google Play real-time developer notifications for subscription changes (Android Developers)
• Stripe webhooks for web payments

Each event carries your user ID from step 4, so you know who paid, how much and when.

Step 6: Report revenue by the first ad#

Join all revenue to each user's first and last ad click. Report cost per paying customer and revenue per campaign across web and app together.

Then use SKAdNetwork, AdAttributionKit and the ad platforms as a cross-check, not the source of truth. Send paid events back to the ad platforms so their bidding learns from payers.

Web checkout vs in-app purchase in 2026#

Court rulings have changed what US apps can do, and the rules are still moving. Check current terms before you change your checkout.

Apple (US storefront). After the April 30, 2025 order in Epic v. Apple, Apple's guidelines allow US apps to include buttons and links to outside purchases (512 Pixels). In December 2025 an appeals court allowed Apple to seek a reasonable commission on those purchases. Apple proposed rates in August 2026, and the Supreme Court agreed to hear Apple's appeal (iClarified; IPWatchdog). Whether a fee applies is unsettled as of October 2026.

Google Play (US). Google opened external links and alternative billing for US developers, with service fees for apps in those programs starting October 1, 2026 (Google Play Console Help).

Does web checkout earn more? Not automatically. In one test by the app Dipsea, published by RevenueCat, in-app checkout converted 27.0% of US iOS users against 18.1% for web-only checkout. Even after Apple's 30% fee, web-only earned about 6% less per customer (RevenueCat). That's one app. Test it on yours.

Context from RevenueCat's 2026 report of about 115,000 apps: web purchases were 4.9% of subscription revenue in North America, and median download-to-paid conversion by day 35 was 2.0% (RevenueCat).

Whatever you choose, the attribution setup above works for both. Stripe and store purchases join on the same user ID.

Getting found in the stores matters as much as measuring. See our app store optimization checklist for 2026.

How to do this in Kratly#

1. Connect your ads, website, apps and Stripe. The Kratly SDK and verified Google Play and App Store purchases join clicks, installs and payments on one user ID.
2. See one funnel. From first ad to install, trial and paid subscription, across web and app.
3. See cost per paying customer by campaign. Not cost per install.
4. Act on it. Kratly suggests budget shifts toward campaigns that bring paying users, wherever they pay.

This is one of the loops an AI growth agent can run end to end. See autonomous growth for how it works.

Go deeper: Server-side tracking explained: first-party data after cookies