Docs

iOS Link Tracking Protection Attribution Tracking

How iOS 26's expanded Link Tracking Protection strips UTM and click IDs, and what to track to keep campaign attribution accurate.

Acquisition

Apple has widened Link Tracking Protection in iOS 26 across Safari, Messages and Mail, stripping known tracking parameters from URLs the moment a user taps a shared link — before your landing page or SDK ever sees them. For any campaign that relies on a UTM string or a network click ID surviving the trip from an ad, a text message, or an email to your app, this quietly breaks the chain. The link still opens; the attribution data attached to it does not.

The teams hit hardest are the ones leaning on URL parameters as their only source of truth. If your paid social or influencer links are shared onward inside Messages, or your lifecycle emails carry campaign tags into a mobile web session, Apple’s stripping happens client-side and silently — nothing errors, nothing logs a failure, the numbers just quietly drift toward “direct” or “unknown” traffic. Marketing teams typically notice this weeks later, as a campaign that “stopped converting” when it was actually still converting, just unattributed.

Data Points to Track

  • Parameter survival rate: percentage of inbound sessions where expected UTM/click-ID parameters actually arrived intact versus were stripped
  • Referral channel classification: proportion of sessions falling into “direct”/”unknown” buckets, segmented by the app or context the link was opened from (Safari, Messages, Mail, third-party app)
  • First-party click ID presence: whether your own server-generated identifier (not a third-party network parameter) was preserved through the redirect chain
  • Landing page vs. deep link split: whether affected traffic arrived via a web landing page redirect or a native deep link, since stripping behaviour differs between the two
  • Attribution match rate over time: week-on-week trend of successfully matched installs/sessions against your MMP or attribution provider, to catch silent degradation early

Setup Steps

  1. Move campaign identifiers server-side. Generate a short-lived, first-party click ID at the point a link is created, and resolve it server-side on landing rather than relying on client-readable query parameters alone.
  2. Add a redirect-and-log step for shared links (a lightweight server redirect that records the original parameters before handing off to the app or web page), so you retain a source-of-truth copy even if the client strips the visible URL.
  3. Instrument a stripped-parameter flag in your analytics SDK: compare the parameters your landing page expected against what actually arrived, and fire an event when they don’t match.
  4. Reconcile weekly against your MMP or ad platform’s own reported installs, watching for a growing gap between platform-reported conversions and what your own attribution captures.
  5. Test across surfaces — a link shared via iMessage, opened in Safari directly, and opened from a third-party app can all behave differently under Link Tracking Protection, so validate each path separately rather than assuming one test covers them all.

Actionable Insights

A rising “direct/unknown” bucket alongside a falling parameter survival rate is the clearest signal that Link Tracking Protection, not a genuine channel shift, is behind a reporting dip — treat it as a plumbing problem before touching campaign budgets. Teams that move to server-resolved, first-party click IDs typically recover most of the lost attribution signal, because the stripping happens on the client, not on your own infrastructure. Keep an eye on which channels degrade fastest: Messages-shared links tend to be hit before Safari-typed or ad-network-opened links, so a channel-by-channel view will surface the problem faster than an aggregate one.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert