Why UTM Parameters Don't Work for Mobile App Install Tracking

UTM parameters were designed for websites. They don't work for app stores.

This post explains exactly why, and what to use instead. If you want the full picture of how per-link install tracking actually works, see the broader guide on tracking app installs with links.

You've no doubt used UTM parameters for a web campaign at least once. They're easy to set up, they function well. All you do is add ?utm_source=twitter&utm_medium=social&utm_campaign=launch to any link, and your GA dashboard is populated with the exact data source.

The moment you've built your new app and you begin sending out links to it, your first instinct might be to do the same. Add UTMs to your App Store and Play Store links, then monitor the campaigns that deliver the installs.

Wrong. UTM parameters don't work this way. It's more than a gap we can just fill in with our own hacks. It's a disconnect.

What actually happens when you use UTM parameters in App Store links?

Let's trace the path, from beginning to end:

• The user clicks a link that looks like this https://apps.apple.com/app/your-app/id123456?utm_source=twitter&utm_medium=social
• The link opens up in a browser (Safari, or in-app browsers such as one found within an iMessage app)
• The browser re-directs them to the App Store application
• The App Store application takes you to the app's page in the store
• The user clicks on "Get"
• The app is installed and starts up

At this point, the user is inside your app.

Notice that the only time the user interacts with the link's parameters is during step 1. Once it's been clicked, the App Store takes over the rest of the handoff. Because the app lives in a different app space than the browser, the UTM parameters don't make it there.

UTM parameters aren't passed to your app when you use a link like this. They evaporate at the point of transition from browser to store app.

Android is slightly better off than iOS here, but still unreliable — even where partial referrer data is available, you won't receive it from every Play Store user you drive to your listing.

So, some try a work around: a landing page

Rather than link directly to the App Store, we create a landing page that serves as a bridge of sorts.

Let's say instead of pointing the user to your App Store link, your UTM-tagged link points to yoursite.com/download?utm_source=twitter. This landing page can be easily tagged to pass the UTM parameters on to Google Analytics.

In this way, you will track the users that landed on the download page. But, once the user leaves that landing page to go to the App Store, the connection gets severed.

So, what we do now is we track the users that landed on your download page.

But we still don't know how many of those people actually downloaded your app. It's the same problem again.

Some people will try to patch that gap. They'll say, "I saw 500 users click the link from Twitter at 2pm. And I see in the App Store Connect page a sudden increase in installs at 3pm. So let's assume those were all from Twitter."

We just can't be certain of this.

It all starts with one simple problem: UTMs do not exist on the App Store. It’s at best directional and, at worst, useless. Especially if you’re running multiple campaigns at once!

What App Store Connect and Google Play Console can actually tell you

Both platforms let you track some of the installs, but they have limitations:

App Store Connect tells you:

• Total installs per day
• Installs by source type (App Store Browse, App Store Search, Web Referrer, App Referrer)
• Web Referrer only shows the domain (not which page on the domain or campaign)
• 24–48 hours of data delay
• Only for iOS

Google Play Console tells you:

• Total installs per day
• Acquisition reports by traffic source
• UTM tracking through Google Play Campaign URLs (limited functionality)
• Up to several hours of data delay
• Only for Android

Neither of them will tell you how many installs came from which individual link. You share 10 different links with 10 different creators and all you get is one number: total installs. You don’t get any more granularity than that.

What's the difference between UTMs and tracking links?

The key difference is: How does the system connect the install to the click that led to the install? UTMs need URL parameters to survive from the moment the user clicks through the moment they click the app store link to downloading and opening the app. Tracking links take a completely different approach to connect install to click.

In the case of a tracking link, the data flows like this:

• A user clicks on a tracking link (for example, instally.io/abc123)
• The tracking service records the click
• The user is redirected to the correct app store (iOS: Apple App Store, Android: Google Play)
• The user downloads and opens the app
• An SDK (a lightweight set of code embedded in your app) reports the install to the tracking service
• The tracking service matches the install to the original click

It’s the tracking service doing the matching, not the browser or the app store. The app store is basically just a middleman here. This is how the install is connected to the click that led to it in the first place, which is why the data survives the journey.

	UTM Parameters	Tracking Links
Click tracking	Yes (if landing page exists)	Yes (server-side, automatic)
Install tracking	No (data lost at app store)	Yes (SDK matches install to click)
Revenue tracking	No	Yes (with payment provider integration)
Per-link granularity	No (aggregated by source)	Yes (unique link = unique data)
Cross-platform	Separate for iOS and Android	One link handles both
Real-time data	Depends on analytics tool	Yes
Setup required	Just append params to URL	Create link + integrate SDK
Works with creators	No (can’t give them their own data)	Yes (creator dashboards)

When to use UTMs?

UTM tracking isn’t completely useless. It just solves a different problem. If you’re driving traffic to a website, UTMs work just fine. If you have a web app (rather than a native app), you probably want to use UTMs. UTMs are the way to track which pages of your website (your blog, landing pages, etc.) get the most traffic before the user clicks through to the app store.

It’s just where things start when the user has left your website and gone to the app store that UTM tracking stops working. UTMs can track your traffic before the app store. Everything after "did they install, did they pay" they don't.

Some people use a hybrid approach where they have UTMs on their landing pages for web analytics, and also have tracking links for install tracking, and then they get the full picture. So you get to see both campaigns that drive web traffic as well as campaigns that drive installs and revenue.

What "per-link tracking" looks like

When you create a unique tracking link for each campaign, creator or channel, you get:

Per campaign: You shared a link in your newsletter and also a link on Twitter and also a link on Reddit and you can see that your newsletter got you 340 installs, Twitter got you 85 installs and Reddit got you 12 installs. So now you know where you should invest time. Per creator: You are working with 5 Youtube creators. Every creator gets a unique tracking link. And you can see Creator A got you 1,200 installs with an average revenue per install of $0.42. And Creator B got you 3,000 installs but their revenue per install is only $0.08. So Creator A's audience actually converts way better. You now have numbers to show them when you negotiate. Per channel: You have a link-in-bio on Instagram, you have a pinned post on X and also your link in Discord. And each of them has a unique tracking link. And you get to see not what channel you get the most clicks on but what channel you get the most installs and revenue on.

None of this is possible with UTMs because they don't have install data on the other end.

The layer UTMs can't solve: revenue

Even if UTMs could pass the app store barrier (which they don't), you still wouldn't get your revenue data through UTMs.

And knowing that one link got you 500 installs is nice. But knowing that those 500 installs generated $2,400 of revenue in IAP is useful. And knowing that a different link only got you 200 installs, but those 200 installs generated $3,100 of IAP revenue is even more useful. Because you can adjust your strategy accordingly.

Revenue tracking requires you to connect your billing provider (RevenueCat, Stripe, Superwall, Adapty, etc.) to your tracking platform and when a user generates revenue, it connects that revenue to their original tracking link. So you now have clicks, installs and also revenue data, all broken down by link. UTMs were never made to do this; UTMs were made to track what website page traffic came from, and that is their entire purpose in life.

The real-world solution

If you are a mobile app developer who wants to know what link got you their install, then do this:

• Do not use UTMs on app stores. They do not make it through. You are not tracking anything.
• If you want your web traffic data, it's fine to add UTMs to your website. That part works, but only the click.
• For install and revenue tracking use tracking links. Create a unique tracking link for each of your campaigns, creators or channels. Add a lightweight SDK to your app. Track clicks, installs and revenue for each link.
• Connect your billing provider. Installs by themselves are not worth a damn, especially not without revenue data. Connect RevenueCat or Stripe or whatever you have to get revenue data and see what links actually get paying users.

The app store barrier is not a configuration problem, it's a hard technical barrier. And no amount of configuration can pass through that barrier. Use the right tool for the right purpose.