iOS 17 Link Tracking Protection: What It Strips, What Survives, and How to Stay Attributed

What is iOS Link Tracking Protection, and how much attribution does it actually break?

iOS Link Tracking Protection (LTP) is a privacy feature Apple shipped in iOS 17 in September 2023, expanded in iOS 17.4, and tightened again through iOS 18. It removes certain query parameters from URLs in three specific contexts: Mail, Messages, and Safari’s Private Browsing mode. It does not run in regular Safari, in third-party browsers, or inside in-app browsers. UTM parameters (utm_source, utm_medium, utm_campaign, utm_term, utm_content, utm_id) are not on the community-reported strip list. Most of the attribution loss marketers blame on LTP is actually caused by something else: cookie expiry under ITP, ESP redirect rewrites, or in-app browser sandboxes.

Published by Terminus, the marketing taxonomy governance platform.

TL;DR

• iOS LTP runs in Mail, Messages, and Safari Private Browsing only. It does not run in regular Safari, in Chrome on iOS, or in any in-app browser (Instagram, TikTok, LinkedIn, Slack, Gmail app, etc.).
• The strip list is community-sourced (primarily PrivacyTests.org). Apple has not published an official, canonical list. Reliably reported entries include gclid, fbclid, mc_eid, twclid, and dclid. gbraid, wbraid, li_fat_id, and msclkid are sometimes reported but not reliably confirmed.
• UTMs survive. So does the HTTP Referer header (in most cases) and any campaign metadata you encode into the URL path rather than the query string.
• The right mitigations are well-understood: Google Ads Final URL Suffix, ad-level UTMs on Meta and LinkedIn, server-side click-ID capture for email, and path-encoded campaign metadata where stakes are high.
• Most “iOS killed our attribution” stories are actually cookie expiry under Intelligent Tracking Prevention, ESP click-tracking redirects, or in-app browser cookie sandboxes. Diagnose precisely before mitigating.

1. What iOS LTP actually is

Apple introduced Link Tracking Protection at WWDC 2023 and shipped it in iOS 17 in September 2023. The framing in Apple’s WWDC session was narrow: when a user taps a link in Mail, Messages, or Safari Private Browsing, iOS strips “known tracking parameters” from the URL before loading the page. The feature is on by default and there is no user-facing setting to disable it in Mail and Messages.

iOS 17.4 (March 2024) widened the behaviour. The strip list grew, and parameter removal began applying to Share Sheet handoffs, so copying a URL out of Safari Private Browsing yields a stripped URL on paste. iOS 18 (September 2024) tightened it again. The state in 2026: LTP is mature, the contexts have not expanded, and the strip list grows slowly through point releases. Apple still does not publish an authoritative list of which parameters get stripped, which is the single most important fact for marketers to absorb.

If you only remember one thing about LTP, remember its scope is narrow. Almost every paid click in a paid media campaign is unaffected.

2. Where LTP operates

This is the section most marketers skip and then regret. LTP only runs in three contexts on iOS:

1. Mail.app when a user taps a link inside an email.
2. Messages.app when a user taps a link inside an SMS, MMS, or iMessage thread.
3. Safari in Private Browsing mode when a user clicks a link or pastes one into the address bar.

That is the entire scope. Specifically, LTP does not run in:

• Regular Safari (the default, non-Private window). This is where the vast majority of organic and direct iOS traffic lands.
• Third-party browsers on iOS (Chrome, Firefox, Edge, Brave, Arc). These have their own tracking-protection behaviour, but it is not Apple’s LTP.
• In-app browsers inside Instagram, TikTok, Facebook, LinkedIn, X, Slack, Discord, Telegram, the Gmail app, Outlook for iOS, and so on. These open links in their own WebKit-based view (typically a custom WKWebView, occasionally SFSafariViewController). Based on community testing, LTP does not appear to run in these contexts; community-sourced behaviour can shift across iOS versions, so verify against PrivacyTests.org if a specific in-app browser matters for your attribution.
• Universal Links that open a native app rather than a browser. The URL is delivered to the app intact, modulo whatever the app itself chooses to do with it.

The practical consequence: a paid social campaign that lands on Instagram’s in-app browser is not affected by LTP at all. The fbclid arrives intact. The UTMs arrive intact. The attribution problem on that traffic, if there is one, is a different problem (third-party cookie sandboxing, view-through measurement, or your own click-redirect chain), not LTP.

Where LTP genuinely bites:

• Cold email campaigns opened in Mail.app on iPhone, where you rely on a click identifier in the URL.
• SMS marketing opened in Messages.app on iPhone, where the same applies.
• Privacy-conscious power users browsing in Safari Private Browsing, who are typically a small slice of traffic.

That is a real problem for those channels, and the mitigations in section 5 are aimed at them. It is not the catastrophic, cross-channel attribution event the trade press sometimes describes.

3. The strip list

Apple has not published an official list of parameters that LTP removes. Every list you see online is community-sourced through black-box testing: researchers craft URLs with known parameters, send them through Mail, Messages, or Safari Private Browsing, and observe which parameters survive on the destination side. The leading public resource is PrivacyTests.org, which runs automated test suites across browsers and operating systems.

Treat the table below as community-sourced, not Apple-authoritative. Apple may add parameters in any point release without notice. Community sources usually catch new entries within a few weeks of a release.

Parameter	Platform of origin	Reliability of strip-list reporting
gclid	Google Ads	Reliably reported as stripped
fbclid	Meta Ads	Reliably reported as stripped
mc_eid	Mailchimp	Reliably reported as stripped
twclid	X / Twitter Ads	Reliably reported as stripped
dclid	Display & Video 360	Reliably reported as stripped
gbraid	Google Ads (iOS app campaigns)	Reported but not reliably confirmed
wbraid	Google Ads (web-to-app)	Reported but not reliably confirmed
li_fat_id	LinkedIn Ads	Reported but not reliably confirmed
msclkid	Microsoft Ads	Reported but not reliably confirmed
yclid	Yandex	Sometimes reported
_hsenc, _hsmi	HubSpot	Sometimes reported

A few notes on the hedged entries:

• gbraid and wbraid are Apple-cooperative click identifiers Google introduced to work alongside Apple’s App Tracking Transparency framework. They are designed to survive in privacy-respecting contexts. The community test record is inconsistent across iOS versions. Test in your own setup before assuming either way.
• li_fat_id appears on some community lists and not others. Treat it as “maybe stripped” and design accordingly.
• msclkid has been over-reported. Some lists include it, others find it survives. Verify in your own environment.

What is not stripped, and is unlikely to ever be stripped, because they are not tracking identifiers in the strict sense:

• utm_source, utm_medium, utm_campaign, utm_term, utm_content, utm_id
• ref, referral, source
• Any custom parameter you invent (source_email, campaign_id, seg, etc.)
• Any path segment in the URL (/campaign/spring-2026/)
• Any fragment after # (although fragments have their own client-side quirks)

The reason UTMs survive is structural. UTMs are not user identifiers. They identify the campaign, not the user. Apple’s stated criterion for LTP is “known tracking parameters that identify users across sites.” UTMs do not meet that bar, and there is no public statement or behavioural evidence that Apple intends to extend LTP to them.

4. What survives

Three things survive LTP and form the basis of every mitigation pattern in this article:

UTM parameters. All six standard UTMs survive in every context where LTP operates. This is the most important fact for marketers. If your campaign tagging is clean, you still get channel, source, and campaign attribution in GA4, Adobe Analytics, Mixpanel, or your warehouse, even on stripped iOS clicks. What you lose is the platform-specific click identifier that would have let you join the click to a paid platform’s user record (e.g. joining a gclid to Google Ads’ conversion API).

The HTTP Referer header. When a user clicks a link in Mail, Messages, or Safari Private Browsing, the Referer header behaviour is more permissive than the URL parameter behaviour. The destination site can usually still read a referrer. Caveats: many ESPs route clicks through a tracking domain redirect that obliterates the original referrer, and Safari Private Browsing tightens referrer policy in some scenarios. The underlying HTTP header itself is not stripped by LTP the way query parameters are.

Path-based parameters. A URL like https://www.terminusapp.com/campaign/spring-promo-2026/email-warmup-3 is not touched by LTP. The path is the path. If you encode campaign metadata into the path rather than into query parameters, it survives. This is an underused mitigation for high-stakes campaigns.

5. Mitigation patterns

This section covers concrete patterns for the channels where LTP actually causes problems. Each pattern is independent. Pick the ones that match your stack.

5.1 Google Ads: Final URL Suffix

Google’s Final URL Suffix (account-level setting under Account settings > Tracking) appends parameters to every destination URL after auto-tagging has run. The parameters you add here are appended to URLs that already carry gclid (and gbraid/wbraid for app and iOS-aware campaigns).

Even if iOS LTP strips the gclid from a click that lands in Mail or Messages, your Final URL Suffix UTMs survive. This is the cleanest mitigation pattern Google Ads supports:

utm_source=google&utm_medium=cpc&utm_campaign={campaignid}&utm_content={creative}&utm_term={keyword}

You lose Google’s user-level click join when LTP fires, but you retain campaign-level attribution in your own analytics. For most reporting needs (which campaigns drove revenue, which keywords converted), this is enough. For Smart Bidding signal back to Google, the offline conversion import via the Google Ads API or enhanced conversions for leads partially closes the loop without needing a gclid.

5.2 Meta and LinkedIn: ad-level UTMs

Meta’s Ads Manager and LinkedIn Campaign Manager both let you set UTM parameters on each ad. Set them. Do not rely on fbclid or li_fat_id as your only campaign-attribution signal.

For Meta, the URL Parameters field on each ad is your friend. A sensible default:

utm_source=facebook&utm_medium=cpc&utm_campaign={{campaign.name}}&utm_content={{ad.name}}&utm_id={{campaign.id}}

For LinkedIn, the URL Tracking Parameters field on each ad takes the same approach. Use LinkedIn’s macros where you can, and fall back to static values when macros are not supported for your ad format.

The point is: when LTP strips a click identifier, your UTMs are still in the URL and your campaign attribution is still intact. The Conversions API on Meta and the Conversions API on LinkedIn handle the user-level join server-side; you do not need the click ID to survive the click for those APIs to work, you only need it on the server side at conversion time, which is a different code path.

5.3 Email: server-side click-ID capture

Email is where LTP genuinely hurts, because Mail.app is exactly the context LTP runs in. If your email click identifier is in a query parameter, LTP can strip it.

The pattern that works in 2026:

1. Use an ESP redirect (mail.example.com/c/abc123) as the landing URL. ESPs already do this for click tracking, so this requires no change.
2. On the redirect, capture the click identifier server-side before redirecting to the destination. Drop it into a first-party cookie on your domain (in the same redirect response, if the redirect domain is a subdomain of your main domain) or write it to your event store keyed by a short-lived token in the final URL.
3. Redirect to the destination URL with UTMs in the query string and, optionally, a short opaque token in the path or query (LTP will not strip an unknown parameter name; only listed identifiers are removed).

This pattern survives LTP because the click identifier is captured at the redirect, not at the destination. The destination URL no longer needs the identifier in plaintext.

Klaviyo, Mailchimp, HubSpot, Iterable, Customer.io, and most modern ESPs already follow some version of this pattern, with varying levels of cookie persistence on the redirect domain. The piece teams often miss is configuring the ESP redirect domain as a subdomain of their primary site (e.g. links.example.com rather than klaviyo.com/c/...) so that the first-party cookie set at the redirect is readable on the destination.

5.4 Path-encoded campaign metadata

For high-stakes campaigns where you cannot afford parameter stripping at all (regulatory disclosures, legal-sensitive offers, must-reconcile attribution), encode the campaign identifier in the URL path:

https://www.terminusapp.com/lp/2026-q2-launch/source-email-warmup-3

A small middleware on your landing page parses the path, maps it to UTMs, and writes them to a first-party cookie. The path survives every stripping rule in every privacy context because no current major privacy tool strips path segments.

The cost is operational. Path-based campaign URLs require either a route handler or a wildcard URL rewrite, and your landing pages need to know how to parse them. For most teams this is overkill. For a handful of marquee campaigns it is the right answer.

5.5 A worked example

A SaaS team running a cold email + paid retargeting sequence wants to know which warmup step in the email sequence converted, even on iOS clicks.

Their pre-LTP setup put the step ID in a custom query parameter step_id and a Mailchimp mc_eid for user identification. LTP strips mc_eid. The custom step_id survives because it is not on the strip list. They take three steps:

1. Email URLs use a tracking subdomain (go.example.com/c/<token>) that resolves to a small redirect service. The token is captured server-side and joined to the email send record. The final destination URL carries UTMs and the surviving step_id parameter.
2. A governed campaign taxonomy drives the UTM values across the whole sequence. The marketing ops team manages source, medium, campaign, and step naming in Terminus, exports the values into the ESP, and the ESP merges them into outbound URLs at send time. This is the natural place a marketing-taxonomy governance platform fits into the picture: it is the system of record for what each parameter value means, so the same step_id decoded six months later still maps to a known campaign step.
3. Reporting in GA4 and the warehouse keys off UTMs and the surviving custom parameter. The LTP strip of mc_eid no longer matters because the user-level join is done server-side at click time, not on the destination URL.

The point of the example is not the specific tools. It is the order of operations: capture the identifier at the redirect, lean on UTMs for campaign attribution, encode mission-critical metadata in custom parameters or the path, and govern the taxonomy upstream so the values mean something six months later.

6. What is commonly mis-attributed to LTP

Marketers blame LTP for attribution problems that LTP does not cause. The three big misattributions:

Cookie expiry under ITP. Safari’s Intelligent Tracking Prevention (ITP), which is a separate and older feature, caps the lifetime of first-party cookies set in JavaScript to 7 days. If you persist a UTM into a first-party cookie via document.cookie in JavaScript, that cookie expires inside a week. A user who clicks an ad on day 1 and converts on day 9 will look “direct” in your analytics. This is ITP, not LTP. The fix is to set the cookie server-side via Set-Cookie with a long Max-Age, which ITP does not cap, rather than via JavaScript.

ESP redirect strips. Some ESPs build their click-tracking redirect in a way that the destination URL receives only a subset of the parameters that were in the email body. The ESP may strip its own click-ID at redirect time (correctly), or it may flatten custom parameters into a different format, or it may rewrite UTMs based on its own conventions. None of this is LTP. The fix is in the ESP configuration, not at iOS.

In-app browsers and their cookie sandboxes. When a user taps a link in the Instagram or TikTok app, the link opens in that app’s in-app browser. Cookies set in that browser are isolated from cookies set in regular Safari, so a returning visitor does not look returning. The fbclid arrives intact (LTP did not run), but the user’s session looks new because there is no cross-app cookie. This is the in-app browser sandbox, not LTP. The fix is server-side conversion APIs that match users on hashed identifiers, not on cookies.

Diagnose before you mitigate. A surprising fraction of “iOS broke our attribution” investigations turn out to be one of these three rather than LTP.

FAQ

What does iOS Link Tracking Protection strip?

iOS LTP strips a community-sourced list of click-identifier parameters from URLs in Mail, Messages, and Safari Private Browsing. Reliably reported entries include gclid, fbclid, mc_eid, twclid, and dclid. Apple has not published an official list. UTM parameters are not on any reliable list and are not stripped.

Are UTM parameters stripped by iOS LTP?

No. utm_source, utm_medium, utm_campaign, utm_term, utm_content, and utm_id are not on any community-sourced strip list. UTMs are designed to identify campaigns, not users, which is why Apple’s stated criterion for LTP does not capture them. Your campaign-level attribution in analytics platforms is intact on iOS clicks.

Does iOS LTP run in regular Safari?

No. LTP runs only in Safari’s Private Browsing mode, plus Mail.app and Messages.app. Regular (non-private) Safari does not invoke LTP. Most iOS traffic to your site is in regular Safari and is unaffected.

Does iOS LTP affect Chrome or other browsers on iOS?

No. LTP is an Apple feature tied to Mail, Messages, and Safari Private. Third-party browsers on iOS (Chrome, Firefox, Edge, Brave) have their own tracking-protection behaviour, but it is not LTP and the strip list differs. In practice, Chrome on iOS does not strip query parameters the way LTP does.

Does iOS LTP affect in-app browsers like Instagram or TikTok?

No. In-app browsers inside Instagram, TikTok, Facebook, LinkedIn, X, Slack, the Gmail app, and Outlook for iOS do not invoke LTP. They have their own cookie-sandboxing behaviour, which is a separate attribution problem. A fbclid from an Instagram ad click arrives intact at your landing page.

Is gclid stripped by iOS LTP?

Yes, gclid is reliably reported as stripped in Mail, Messages, and Safari Private Browsing. The mitigation is to set a Final URL Suffix in Google Ads that appends UTMs to every destination URL, so even when LTP strips the gclid, your campaign attribution survives in analytics.

Are gbraid and wbraid stripped by iOS LTP?

Community testing is inconsistent. gbraid and wbraid are Apple-cooperative click identifiers Google introduced to coexist with Apple’s privacy framework, so it would be surprising if Apple stripped them aggressively. They have been reported on some lists but the reporting is not reliably confirmed across iOS versions. Test in your own environment if you depend on them.

Is fbclid stripped by iOS LTP?

Yes, fbclid is reliably reported as stripped in the three LTP contexts. Mitigate by setting ad-level UTMs in Meta Ads Manager and by relying on Meta’s Conversions API for server-side user-level joins rather than on the fbclid surviving the click.

How do I keep email attribution working under iOS LTP?

Capture the click identifier server-side at your ESP’s redirect step rather than on the destination URL. Use an ESP redirect domain that is a subdomain of your main site so first-party cookies set at the redirect are readable on the destination. Lean on UTMs (which survive) for campaign attribution. This is what modern ESPs like Klaviyo, Mailchimp, and HubSpot do by default; check that your domain configuration matches.

Should I worry about LTP for paid search and paid social?

For paid search: not much. Google’s auto-tagging puts gclid in the URL, LTP strips it in the narrow contexts where it runs (mostly people clicking ad links from inside Mail or Messages, which is a small slice of paid search traffic), and Final URL Suffix UTMs survive regardless. For paid social: even less. Most paid social clicks land in an in-app browser, which is outside LTP’s scope entirely.

What is the difference between iOS LTP and Safari ITP?

Different features. ITP (Intelligent Tracking Prevention) is older, runs in regular Safari, and primarily limits third-party cookies and caps JavaScript-set first-party cookie lifetime to 7 days. LTP is newer, runs in Mail, Messages, and Safari Private Browsing, and strips specific query parameters from URLs. Most “iOS broke attribution” reports are actually ITP cookie expiry, not LTP parameter stripping.

How can I tell if LTP is affecting my campaigns?

Compare two segments in your analytics: iOS-Safari sessions with gclid present, and iOS-Safari sessions with the same UTMs but no gclid. If a meaningful share of the second group has the same UTM set as the first and is arriving from Mail or Messages (check the referrer where you can), LTP is in play. If the numbers are tiny, you are mitigating a small problem. Most teams overestimate the volume by 5x to 10x before they actually measure it.

---

Last updated: 2026-06-16.