A Practical Guide to What Is Cross Site Tracking

Ad platforms connect an ad click, an article read, a pricing-page visit and a purchase somewhere else; what is cross site tracking covers is exactly that linking of one person across separate sites and apps.

Cross-site tracking is the practice of linking a person's activity across different websites or apps. It is what lets an ad platform know that the same browser clicked an ad, read an article, visited a pricing page, abandoned a cart, and later bought something elsewhere.

Some cross-site tracking uses cookies. Some uses pixels. Some uses browser or device fingerprints. Some uses link decoration: extra parameters added to URLs so a platform can recognize the click later.

Apple's iOS 17 Link Tracking Protection targeted that last category.

This is not a niche Apple feature. It reflects a broader privacy direction: browsers and operating systems are trying to reduce passive tracking that happens without a clear user choice.

What Apple's Link Tracking Protection Does

Apple announced that iOS 17, iPadOS 17, and macOS Sonoma would remove some tracking parameters from links shared in Messages and Mail, and from links opened in Safari Private Browsing. Apple's iOS 17 preview described the feature as removing extra URL information used to track users across websites while keeping links functional.

In plain English: the page still opens, but known tracking parameters may be stripped.

Link Tracking vs UTM Tracking

Not every URL parameter is the same.

Cross-site tracking parameters often identify a click or user for an advertising platform:

• fbclid for Meta
• gclid for Google Ads
• msclkid for Microsoft Ads
• other platform-specific click IDs

UTM parameters describe the campaign:

• utm_source=linkedin
• utm_medium=social
• utm_campaign=launch
• utm_content=video_ad

Apple's feature focuses on parameters associated with cross-site tracking. Standard UTMs are generally designed for aggregate campaign reporting and are less invasive when used properly.

Why Apple Targets Link Decoration

Browsers have restricted third-party cookies for years. Link decoration became one workaround: attach an identifier to the URL, pass it to the destination site, then store or sync it.

This can be useful for ad attribution, but it can also allow tracking across contexts where the user did not expect it. If a friend shares a link in Messages, the recipient does not need the sender's ad click ID.

What Marketers Should Expect

Expect to see:

• fewer ad click IDs arriving on Apple private contexts
• differences between ad platform and site analytics reports
• more modeled conversions inside ad platforms
• cleaner shared URLs
• continued UTM attribution where UTMs remain intact

Do not panic if platform dashboards and privacy-first analytics disagree. They measure different things with different access to identifiers.

The healthiest response is to separate ad platform optimization from business reporting. Let ad platforms optimize within the consent and browser limits they have, but use your own analytics for source-level trends and onsite conversions.

How to Adapt

Use UTMs consistently. They are the most durable campaign attribution method because they describe the campaign rather than the individual click.

Keep ad click IDs out of your core reporting assumptions. If gclid or fbclid disappears in some contexts, your own analytics should still know that the visit came from utm_source=google and utm_medium=cpc.

Measure onsite outcomes yourself:

• landing page visits
• signup starts
• signup completions
• demo requests
• purchases
• activation events

Then compare aggregate performance by campaign.

Privacy-Friendly UTM Rules

UTMs should never contain personal data. Do not put emails, names, customer IDs, wallet addresses, invoice numbers, or private terms in campaign parameters. URLs are copied, logged, and shared.

Good:

utm_source=newsletter&utm_medium=email&utm_campaign=privacy_guide

Bad:

utm_source=newsletter&utm_campaign=jane.doe@example.com

Broader Browser Trend

Link Tracking Protection is part of a wider shift. Browsers and operating systems are limiting cross-site tracking through cookie restrictions, referrer-policy defaults, storage partitioning, private browsing protections, and tracker blocking.

The EDPB's Article 5(3) guidance also reinforces that tracking technology is broader than cookies. Marketers should plan for a web where individual-level cross-site attribution keeps getting weaker.

On Apple platforms, remember the browser-engine caveat. Most iOS browsers have historically shared WebKit behavior, but Apple now allows eligible alternative browser engines in the EU under specific conditions (Apple alternative browser engines). Test the browsers your audience actually uses instead of assuming every iOS browser will behave exactly like Safari forever.

Cross-Site Tracking Audit

Review the signals you send and receive:

• Keep UTMs that describe campaigns.
• Drop click IDs from internal reports once campaign context is captured.
• Strip personal data, subscriber IDs, and lead IDs from URLs.
• Test Safari, Messages, Mail, Private Browsing, Chrome, Firefox, and major ad redirects.
• Reconcile aggregate onsite conversions with backend outcomes.

If a parameter identifies a person, device, household, or ad-platform profile, it is not just "campaign tracking." Treat it as cross-site tracking risk.

The Bottom Line

Cross-site tracking tries to follow people across contexts. UTM tagging labels campaigns. That difference matters.

Build reporting around privacy-friendly campaign labels and aggregate conversions, not fragile identifiers that browsers are increasingly designed to remove.

Audit Your Links

Review marketing links before browser protections remove or rewrite the signals you rely on. Keep campaign parameters that describe the campaign itself, such as utm_source, utm_medium, utm_campaign, and utm_content. Avoid parameters that identify a person, household, device, subscriber, lead, or ad-platform profile. Apple's Link Tracking Protection notes are a reminder that browsers increasingly distinguish useful attribution labels from tracking parameters designed to follow people.

The same audit should cover redirects. Some email, ad, affiliate, and social tools wrap outbound links through tracking domains, adding click IDs along the way. Those IDs can leak through referrers, server logs, support screenshots, and analytics tools. If you need campaign reporting, preserve the campaign label on the landing page and drop the user-level identifier as early as possible. Then measure aggregate conversions by source and content. This gives marketing enough signal to compare campaigns without building a cross-site identity trail that browsers, users, and regulators are actively pushing back against.

Frequently Asked Questions

Will iOS 17 stop UTM parameters from working?

No, standard UTM parameters such as utm_source, utm_medium, and utm_campaign are not the target of Apple's Link Tracking Protection. The feature focuses on parameters tied to cross-site tracking, like fbclid and gclid. Campaign attribution built on UTMs keeps working.

Which URL parameters does iOS 17 remove?

Apple's Link Tracking Protection removes parameters associated with cross-site tracking, including fbclid for Meta, gclid for Google Ads, and msclkid for Microsoft Ads. It strips these from links shared in Messages and Mail, and from links opened in Safari Private Browsing.

Where does Apple's Link Tracking Protection apply?

Link Tracking Protection applies to links shared in Messages and Mail, plus links opened in Safari Private Browsing. Links opened outside those contexts, such as a normal Safari tab, are not affected by this specific feature.

Does the stripped link still open the destination page?

Yes, the page still opens. Apple designed the feature to remove tracking parameters while keeping the link itself functional, so the recipient lands on the same destination with less identifying information attached.

Why does Apple target link decoration specifically?

Link decoration became a common workaround once browsers restricted third-party cookies. Attach an identifier to the URL, then store or sync it on the destination site. Apple's feature closes that gap for links shared through Messages, Mail, and Private Browsing, where a click ID was never something the recipient agreed to share.

Should marketers remove UTM parameters from their links?

There's no reason to. UTM parameters describe the campaign rather than an individual user, and Apple's feature is not designed to remove them. Keeping utm_source, utm_medium, and utm_campaign intact is still the most durable way to track campaign performance.

What should marketers put in place of click IDs like gclid or fbclid?

Rely on UTM parameters for the core reporting logic, since click IDs disappear in Apple private contexts. If gclid or fbclid gets stripped, your own analytics can still attribute the visit through utm_source=google and utm_medium=cpc.

Why do ad platform dashboards and website analytics start disagreeing after iOS 17?

Ad platforms and site analytics measure different things with different access to identifiers, so gaps show up once click IDs get stripped in Apple private contexts. Expect more modeled conversions inside ad platforms and cleaner shared URLs, without a matching change in your own onsite numbers. Treating the two sources as measuring different things, rather than expecting them to match, keeps reporting sane.

Are UTM parameters ever a privacy risk?

UTM parameters become a privacy risk when someone puts personal data inside them. Emails, names, customer IDs, wallet addresses, and invoice numbers should never appear in campaign parameters, since URLs get copied, logged, and shared. A parameter that identifies a specific person, device, or household counts as cross-site tracking risk even if it looks like a UTM.

Does Apple's alternative browser engine policy in the EU change any of this?

Apple's alternative browser engine policy can change this over time. Apple now allows eligible alternative browser engines in the EU under specific conditions, which means not every iOS browser is guaranteed to share Safari's WebKit behavior forever. The practical takeaway is to test the actual browsers your audience uses rather than assuming uniform behavior across iOS.