Why UTM Parameters Don't Work for Mobile App Attribution (And What Does)

# UTM Tracking for Apps: Why it Fails (and What Comes Next)

If you’ve tried UTM tracking for mobile apps, you’ve probably seen this play out: you add UTM parameters to your creator or affiliate link, you see clicks in Google Analytics, but then you check your app installs and have no idea which clicks led to which installs. All the data goes dark at the App Store. You’re not doing anything wrong. UTM parameters work great for web attribution -- they’ve been the standard for over a decade. But mobile app attribution is a different problem, and UTM parameters were never designed to solve it. Here’s why UTM tracking fails for apps, what developers try instead, and how SDK-based attribution fills the gap.

Why UTM parameters don’t work for apps

UTM parameters are tags you add to a URL as a query string. When a user clicks a link like https://yoursite.com?utm_source=creator_jane&utm_medium=youtube&utm_campaign=summer, your web analytics tool picks up those parameters on page load and records the attribution data. Straightforward, dependable, and well understood. The problem comes when the link points to a mobile app. The user journey looks like this:

• The user clicks on a link with UTM parameters
• The user is redirected to the App Store or Google Play
• The store strips all the URL parameters (Apple and Google don’t pass them through)
• The user taps “Install”
• The user opens the app for the first time
• Your app has no idea which link the user clicked originally

The App Store is a black box. You give it a link with UTM parameters, and it strips them. Then it delivers an install with no source data. There is no way in iOS to pass arbitrary URL parameters through the App Store install process. On Android, Google has an Install Referrer API that can pass referrer data, but it requires specific implementation and won’t work with a standard UTM link that just points to a Google Play listing. This isn’t a configuration issue -- it’s an architectural one. The store sits between the click and the install, and the store does not preserve your tracking data.

What developers try after UTM parameters fail

Once you discover UTM parameters don’t survive the App Store, you start looking for alternatives. Here are the most common ones, and why they all eventually run into the same roadblock.

Firebase Dynamic Links Google built Dynamic Links to fix exactly this problem. They could pass data through the install process and deep-link users into specific in-app content. They worked well. Then Google deprecated them, with the service shutting down in August 2025. If you were using Dynamic Links, you've already had to migrate. Google suggested App Links and Universal Links as replacements, but neither supports the deferred deep linking or attribution tracking that Dynamic Links provided. Tracking in spreadsheets. A creator says they sent you installs, you look for a bump in your analytics around when their content went live, and you try to guess how many installs they drove. This works for one or two creators. Beyond that, you're spending hours on attribution guesswork that still doesn't give you per-creator numbers. Custom landing pages for each creator. You create yoursite.com/jane and yoursite.com/mike, track traffic to each page, and try to match page visits with installs based on timing. This is a step up from spreadsheets -- at least you're trying to instrument the system -- but it falls apart if there's any lag between the page visit and the install. If someone visits the page on Monday, installs on Wednesday, and opens the app on Thursday, you've lost the connection. You also have to maintain a custom landing page per creator, which doesn't scale. Promo codes. You give each creator a unique promo code and ask their audience to enter it on install. This does give you deterministic attribution, but at the cost of onboarding friction. Asking users to do something extra during onboarding (like entering a promo code) measurably hurts your activation rate. You're trading attribution data for conversion rate.

All of these are reasonable ideas. They're just not reliable enough to support a real creator program at scale.

How SDK-based attribution actually works

The key insight behind SDK-based attribution is that you need to have a presence on both sides of the App Store wall, something that can record the link click before the store, and something that can identify the install after the store. Then you can match the two on your servers.

Here's how it works with Appfiliate, step by step:

• The creator shares their tracking link. Each of your creators gets a unique tracking link from their Appfiliate dashboard. When a user clicks the link, the click is registered on Appfiliate's servers along with relevant metadata (timestamp, IP address, user agent, etc.).

• The user is redirected to the App Store. The tracking link redirects the user to the app's store listing. The App Store (or Google Play) takes over from there. UTM parameters don't matter at this point because the click is already recorded.

• User installs and opens the app. When the user first opens the app, the Appfiliate SDK makes a trackInstall() call. This sends similar metadata to Appfiliate’s server (timestamp, IP, user agent).

• Server-side matching. Appfiliate’s server matches the install event with the most likely click event based on these signals. On Android, this is deterministic (via the Install Referrer API). On iOS, it’s probabilistic (based on the signals, within Apple’s privacy framework).

• Attribution is recorded. The install is attributed to the creator who generated the link. Revenue from that user’s purchases is tracked going forward.

The reason this works where UTMs fail is that attribution data never flows through the App Store. The click and the install are recorded independently, then matched server-side. The store is irrelevant because you’re not trying to force data through it.

The implementation is minimal:

// iOS
import Appfiliate

Appfiliate.configure(appId: "APP_ID", apiKey: "API_KEY")
Appfiliate.trackInstall()

// Android
import com.appfiliate.sdk.Appfiliate

Appfiliate.configure(this, appId = "APP_ID", apiKey = "API_KEY")
Appfiliate.trackInstall(this)

For Flutter, React Native, and full integration instructions, see the SDK documentation.

Appfiliate vs manual UTM tracking: side-by-side comparison

Feature	UTM Parameters	SDK-Based Attribution
Data survives App Store	No -- parameters are stripped	Yes -- click recorded before store
Per-creator attribution	Only on the web side	Yes -- each creator gets a unique link
iOS support	No install attribution	Probabilistic matching, no IDFA needed
Android support	No install attribution	Deterministic via Install Referrer API
Revenue attribution	Not possible	Per-creator revenue tracking
Real-time reporting	Web clicks only	Installs, purchases, and revenue
Creator dashboard	You build it yourself	Built-in -- creators see their own data
Integration effort	Add params to URLs	Two lines of SDK code
Scales past 10 creators	Painful	Yes
Ongoing maintenance	Manual reconciliation	Automated

The bottom line: UTM parameters tell you someone clicked a link. SDK-based attribution tells you someone clicked a link, installed your app, and spent money. UTMs are still the right choice for web properties. For mobile apps, they solve about 20% of the problem.

How to migrate from UTMs to SDK attribution

If you’re already running a creator program with UTM links and want to make the switch, the migration process is simple.

Step 1: Integrate the SDK. Add the Appfiliate SDK to your app. It’s two lines of code in your app’s entry point. No IDFA, no ATT prompt, no special permissions. See the full SDK setup guide for iOS, Android, Flutter, and React Native. Step 2: Create tracking links. In the Appfiliate dashboard, create a tracking link for each creator. These are a replacement for the UTM links you’re sending them today. Step 3: Integrate your billing provider. If you use RevenueCat, Stripe, Superwall, Adapty, or Qonversion for subscriptions, connect the webhook so purchases are auto-attributed. This replaces whatever manual revenue tracking you were doing. Step 4: Release the build. Once the SDK is live in the build and users download it, the attribution starts working. There’s nothing to do for existing users; trackInstall() only fires once per install, so they won’t be re-attributed. Step 5: Continue to use UTM links for the web. If you have a web product as well, keep using UTM links for that. That’s the right tool for the job. Just don’t expect it to work across the App Store boundary.

Most teams get this all done in an afternoon. Pricing starts at $79/month with no annual contracts, so you can try this without too much of a commitment.

FAQ

Can I use UTM parameters in addition to SDK attribution? Yes. UTM parameters still work for tracking traffic to your website or landing page. Keep using them for web analytics (Google Analytics, Mixpanel, etc.) and use the SDK attribution for app installs and revenue. They’re solving different problems and don’t overlap. What about Apple’s App Analytics campaign links? Apple lets you append campaign tokens to App Store URLs, and you can see aggregate install numbers per campaign in App Store Connect. But you don’t get user-level attribution, revenue attribution, or real-time data. It tells you “Campaign A generated 200 installs” but not which specific user came from which specific creator link. Does Appfiliate work without IDFA? Yes. The SDK doesn’t use IDFA and doesn’t trigger the ATT prompt. We wrote a detailed article on how attribution works without IDFA if you want the technical details. What about Google’s Privacy Sandbox on Android? Google’s Privacy Sandbox for Android is rolling out gradually, but the Install Referrer API remains supported and is the recommended mechanism for install attribution. Appfiliate uses it on Android for deterministic matching. How accurate is SDK-based attribution compared to UTMs? On Android, the Install Referrer provides deterministic attribution -- just as accurate as UTM parameters on the web. On iOS, probabilistic matching means you’ll miss some installs, but for the single-click-to-install pattern that creator campaigns typically generate, the match rate is high enough to run a real program. We cover the details in our post-IDFA attribution guide. I only have a couple of creators. Is this even worth it? If you only have two creators and very low volume, a spreadsheet might still work. But most teams hit the pain point at around five to ten creators, especially once they need to calculate commissions on revenue. The sooner you set up proper attribution, the less historical data you lose.