Link Tracking Not Working on Mobile? The iOS and Android Causes to Check

Around 63% of clicks on a typical SaaS marketing link now come from a mobile device, and a large share of those never make it into your analytics at all.

If your dashboard shows healthy click counts but almost no mobile-originated conversions, the tracking is not "underperforming" on mobile. It is broken.

Mobile introduces three failure modes that desktop rarely triggers: in-app browser sandboxes that wipe storage on exit, Safari's Intelligent Tracking Prevention capping cookie lifetime to hours, and iOS 17 physically deleting tracking parameters from the URL before your server ever sees them.

The reason this feels mysterious is that each cause hides the same symptom, missing mobile attribution, behind a different mechanism. A marketer sees "mobile clicks: 9,400, mobile conversions: 12" and assumes mobile traffic just does not convert.

The engineer who looks closely finds that 9,000 of those clicks landed in an environment where the tracking cookie was dead on arrival.

Link tracking not working on mobile is almost never a single bug; it is the combined effect of in-app WebView isolation, Safari ITP cookie caps, and iOS URL parameter stripping, each of which silently discards attribution data that a desktop click would have preserved.

Why This Matters for Your Revenue

Mobile is not a rounding error in SaaS acquisition; it is where discovery happens. Someone finds you in a TikTok comment, a LinkedIn post, a newsletter opened on their phone, or a Slack message read on the commute.

That first touch is the click that should carry attribution all the way to the Stripe charge.

When mobile tracking fails, the entire top of your funnel gets misfiled as "direct" or vanishes, and the channels actually driving pipeline look worthless in your reports. You then cut spend on the exact source that was working.

The financial distortion compounds because mobile-first channels are often your cheapest.

If organic social and newsletter clicks disappear on mobile but your paid search clicks (mostly desktop, mostly intact) track perfectly, every ROI comparison you run is rigged against your best-performing channels.

You over-invest in the channels that happen to track well and starve the ones that convert but cannot be measured.

A 40% mobile tracking gap does not just lose data, it actively reallocates budget toward the wrong half of your marketing.

Cause 1: In-App Browsers Wipe Their Own Storage

The single biggest mobile tracking killer is not Apple or Google. It is the fact that a click inside Instagram, TikTok, Facebook, LinkedIn, or Snapchat almost never opens in Safari or Chrome.

It opens in that app's embedded WebView, an isolated browser instance the app controls entirely.

Why WebView storage is ephemeral

In-app WebViews run in a private, per-session storage context. Cookies and localStorage written during that session frequently exist only until the user closes the in-app browser tab, and are wiped when the host app is backgrounded or terminated.

There is no shared cookie jar with the system Safari or Chrome, so a returning visitor looks brand new every single time.

This means the classic tracking pattern, set a cookie on click, read it on conversion, is dead on arrival.

The user clicks your link in TikTok, browses your pricing page inside TikTok's WebView, then closes the app to think it over.

When they come back an hour later through Safari, the cookie you set is gone, and there is no way to connect that first click to the eventual signup.

Which apps are the worst offenders

Not every in-app browser is equally destructive, and knowing the ranking helps you prioritize.

In practice, TikTok, Instagram, and Facebook are the heaviest storage-resetting environments because they aggressively terminate their WebView to reclaim memory, while LinkedIn and Snapchat sit close behind.

Twitter/X and Slack tend to hand off to the system browser more readily, which is why the same campaign can track fine when shared in Slack but disappear when shared on Instagram.

If your channel mix leans on the first group, expect the largest mobile attribution gap there.

The key insight is that this is a distribution-channel problem masquerading as a tracking problem.

The exact same landing page, with the exact same tracking code, will report wildly different conversion rates depending on which app the click came from, purely because of how each app manages its embedded browser storage.

How to detect an in-app browser

Check the User-Agent string of your incoming clicks. In-app browsers announce themselves: Instagram appends Instagram, Facebook uses FBAN or FBAV, TikTok includes musical_ly or BytedanceWebview, and LinkedIn adds LinkedInApp.

If a large fraction of your mobile clicks carry these tokens and almost none of them convert on the same session, you have found your leak.

• Instagram: User-Agent contains Instagram and often iabmv.
• TikTok: look for BytedanceWebview or musical_ly.
• Facebook: FBAN, FBAV, or FB_IAB.
• LinkedIn: LinkedInApp in the agent string.

Cause 2: Safari ITP Caps Cookie Lifetime

Even when a mobile click opens in real Safari, Apple's Intelligent Tracking Prevention (ITP) actively limits how long your tracking survives.

On iOS, Safari is the default browser and ITP is on by default, so this applies to the majority of iPhone traffic whether the user knows it or not.

The 24-hour and 7-day caps

ITP caps the expiry of cookies set via document.cookie (client-side JavaScript) to 7 days, and to just 24 hours when the visitor arrived from a domain ITP classifies as having cross-site tracking capability.

Any script-set cookie that tries to persist beyond that window is silently truncated. Your 90-day attribution window becomes a 1-day window without any error being thrown.

For SaaS this is brutal, because the median B2B buying cycle spans days or weeks. A prospect clicks your link Monday morning, evaluates, talks to their team, and subscribes Friday.

If your attribution rode on a client-side cookie, ITP deleted it on Tuesday. The Friday conversion shows up as direct traffic, and the channel that actually drove it gets zero credit.

We cover the full mechanics in our guide to Safari ITP and attribution.

Why server-set first-party cookies survive longer

ITP treats cookies set by an HTTP response header (Set-Cookie) from your own first-party server differently from cookies written by JavaScript.

A first-party cookie set server-side on your own domain is not subject to the same 24-hour truncation, which is precisely why the fix for mobile attribution is architectural, not a setting you toggle.

The difference between server-side click tracking versus a client-side pixel is the difference between an attribution window that survives the buying cycle and one that expires overnight.

What Android and Chrome Custom Tabs do differently

Android is not immune, but it fails differently. Chrome does not run ITP, so cookie lifetimes are not truncated the same way.

However, many Android in-app browsers use Chrome Custom Tabs, which share the system Chrome cookie jar in some flows and use an isolated context in others, an inconsistency that produces intermittent, hard-to-reproduce tracking loss.

And with third-party cookies now deprecated across Chrome, any Android attribution still leaning on cross-site cookies is on the same path to failure, just arriving from a different direction.

Cause 3: iOS 17 Strips Tracking Parameters From the URL

Introduced in September 2023, iOS 17's Link Tracking Protection goes further than blocking cookies. It edits the URL itself.

When a link is opened in Mail, Messages, or Safari Private Browsing, iOS removes query parameters it recognizes as tracking identifiers before the request is ever sent to your server.

Which parameters get stripped

Apple maintains a list of known tracking parameters (things like fbclid, gclid, and various campaign identifiers) that get removed in protected contexts.

Standard UTM parameters are more nuanced, but the practical result is that any attribution strategy that depends on a parameter surviving the round trip from tap to server is fragile on iOS.

If your entire tracking model is "read the utm_source off the landing URL," a chunk of iOS clicks will arrive with that data already deleted.

We break the specifics down in iOS 17 Link Tracking Protection and in the broader context of first-party link tracking after iOS 17.

Why a redirect on your own domain protects the parameters

Short links matter more than people assume, and this is the reason.

When a redirect happens on your own domain, your server captures the full parameter set at the redirect step, in the HTTP request log, before iOS has any chance to strip anything on the final destination page.

The stripping only affects what the browser passes forward to the landing page; it cannot retroactively remove what your redirect server already recorded. That timing difference is the entire game.

This is why the fix is to capture attribution at the hop, not at the destination.

Encode the campaign into the link, resolve it server-side, store the source against a server-owned click ID, and the iOS strip becomes irrelevant because you already have the data.

If you are seeing UTMs vanish, our piece on why UTM parameters get stripped walks through each stripping vector.

Cause 4: Redirect Chains and Deferred Deep Links

The final class of mobile failures happens in the hop between the click and the landing page: redirect chains that lose parameters, and deep links that open an app instead of a browser and drop context in the handoff.

Lossy redirect chains

Every redirect is a chance to lose data.

If a link goes short domain, to marketing site, to app subdomain, and one of those hops uses a 302 that does not forward the query string, your UTMs die mid-chain, on desktop and mobile alike.

Mobile makes it worse because in-app browsers sometimes handle redirects differently and can drop the referrer entirely. Attribution that breaks between www and app is common enough that we wrote a dedicated guide on cross-subdomain conversion tracking.

The empty-referrer problem

Many in-app browsers and privacy-hardened mobile configurations suppress the HTTP Referer header entirely, sending an empty referrer or a generic one.

If your attribution logic infers the source from the referrer, mobile social traffic collapses into "direct" the moment the referrer is blank.

The fix is to never depend on the referrer: encode the source in the link path itself, so it is present in the request line regardless of what the browser reveals about where the click came from.

This is one of the largest silent contributors to the direct traffic problem on mobile.

A click that clearly came from LinkedIn shows up as direct simply because the in-app browser refused to disclose the referring page, and referrer-based attribution had nothing else to go on.

Deferred deep links and app handoffs

If your funnel involves opening a native app, the mobile OS may hand off from the WebView to the app with no shared cookie and no preserved URL fragment.

Unless you explicitly pass a click identifier through a deferred deep link mechanism, the attribution context is severed at the app boundary.

This is the same root problem as cross-device attribution: the identifier has to be something you carry and re-associate on your own server, not something you hope the browser preserves.

A quick server-log sanity check

Before you rebuild anything, run one diagnostic: segment your redirect logs by device type and by presence of a tracking parameter or referrer.

If mobile requests show the parameters intact at the redirect hop but your downstream analytics shows them missing at conversion, the loss is happening after the redirect, which points squarely at cookie eviction or WebView reset rather than a broken link.

This five-minute check tells you which of the four causes above you are actually fighting.

Why Bitly, Dub, Rebrandly, and Short.io Do Not Fix This

The popular link shorteners all count clicks well, but click counting is exactly the layer that mobile breaks least.

Where they fall short is connecting a mobile click to a downstream Stripe conversion across an ITP reset or a WebView wipe.

Bitly records the click at redirect, which is good, but its attribution effectively ends at the click.

It has no first-party server-side identity that follows the visitor to your checkout, so a mobile click that converts five days later is invisible to Bitly's revenue picture, because there is no revenue picture.

Dub is a strong, modern, open-source shortener with clean analytics, but it is built around the click event and its conversion tracking still leans on the same client-side signals that ITP and in-app WebViews erode.

Rebrandly and Short.io are branded-link managers focused on link management and click stats; neither ties a mobile click to an actual Stripe charge, so the mobile attribution gap simply shows up as "our clicks look fine but we cannot explain our revenue." We compare these head to head in Bitly vs TrackRev and Dub.co vs TrackRev.

How TrackRev Handles This

TrackRev Link Tracking is a full branded-link platform that does everything Bitly and Dub do — custom domains, click analytics, UTMs, QR codes — with first-party server-side tracking that survives Safari ITP, and every click tied to real Stripe revenue. $19/month.

Mechanically, the difference is where the identity lives.

When a mobile user taps a TrackRev link, the redirect happens on your own custom domain, and TrackRev captures the click, the full parameter set, and the User-Agent server-side at that hop, before iOS can strip anything and before any WebView storage decision is made.

It sets a first-party cookie via an HTTP response header on your domain, which is not subject to ITP's 24-hour client-side truncation, and it also mints a server-owned click identifier that lives in the database, not the browser.

When that visitor later converts in Stripe, TrackRev matches the charge back to the original click even if the browser cookie was wiped, because the durable identity was never dependent on the browser in the first place.

The practical outcome: an Instagram click on Monday that becomes a Stripe subscription on Friday still credits Instagram, not direct.

This is the same first-party, cookieless-resilient approach described in link tracking without cookies, applied specifically to the mobile failure modes above.

Because every link ties to real revenue, you can finally see revenue by marketing channel instead of mobile click counts that mean nothing.

When NOT to Use TrackRev for This

If your product has no payment layer, TrackRev is overkill.

The entire value proposition here is tying a mobile click to a real Stripe (or Paddle, or Lemon Squeezy) charge; if you are tracking clicks to a content site with no monetization, an ad-supported blog, or a purely informational campaign where you genuinely only need raw click volume, a simple shortener like Dub or Bitly does that job at lower conceptual overhead.

Likewise, if your mobile traffic is trivial, mostly desktop B2B where ITP and in-app browsers are not eroding your data, then the mobile-specific machinery is solving a problem you do not have.

And if you need deep native-app product analytics, session replay, funnel visualization inside the app itself, a dedicated mobile product analytics platform is the right tool; TrackRev's job is the marketing-attribution layer from click to charge, not in-app behavioral analytics.

Use it when the mobile click actually leads to money, and when knowing which channel drove that money changes how you spend.