iOS and Safari Privacy Changes: What Broke in Your Tracking and What Helps

If your Meta and Google Ads reports have looked strange since around 2021, you are not imagining it. A series of privacy changes from Apple, starting with iOS 14.5 and running through successive Safari releases, reshaped what marketers can see. Some of the effects were dramatic; others are subtle and still quietly distorting reports today.

This guide explains, without hype, what Apple actually changed, which parts affect a website or online store, what you can and cannot recover, and how a server-side setup fits in. We will also be clear about the limits, because "bypass" is a word that promises more than any honest tool can deliver.

First, a clarification: "iOS bypass" is the wrong frame

You will see vendors talk about "bypassing iOS restrictions". That framing is misleading, and it leads to bad decisions. Apple's protections exist to limit cross-site tracking of individuals. A legitimate business has no right, and no reliable technical ability, to defeat them, and attempts to do so tend to break quickly and create compliance risk.

The realistic goal is different: make sure the measurement you are entitled to make actually works. A visitor who visits your own store, browses your products and buys from you is engaging in first-party activity. Keeping that journey connected, within the limits of consent and browser rules, is reasonable and achievable. Following someone across the web against their wishes is neither. Everything below is about the first kind.

What Apple changed, in plain language

App Tracking Transparency (ATT)

Introduced with iOS 14.5 in 2021, ATT requires apps to ask permission before tracking users across other companies' apps and websites. Many users declined. This mainly affects app tracking, and it hit app-install advertising and app-based measurement hardest. It matters to web-focused stores mostly indirectly: it changed how platforms like Meta model conversions and pushed them to rely more on web-side signals that you send them yourself.

Intelligent Tracking Prevention (ITP)

This is the change that affects websites most directly. ITP is Safari's set of rules limiting cross-site tracking. Over several versions it introduced restrictions that matter to any store:

• Cookies written by JavaScript (through document.cookie) have their lifetime capped, commonly to seven days, and in some cases to 24 hours. This affects the client-side cookies that analytics and ad tags create by default.
• Traffic arriving from link-decorated ads (URLs carrying click identifiers, from domains Safari classifies as trackers) can have its cookie lifetime cut further.
• Third-party cookies are blocked outright in Safari.
• Cookies set by server responses can also be limited when the tracking subdomain resolves to infrastructure that looks unrelated to the main site, a rule aimed at so-called CNAME cloaking. More on this below, because it changes what "first-party" really buys you.

Link tracking protection

More recent versions of Safari and iOS remove certain known tracking parameters from URLs in specific contexts, such as private browsing and links opened from Mail and Messages. Click identifiers like gclid and fbclid are among the parameters affected in those situations. If a click identifier is stripped before your page loads, the attribution link between the ad click and the later purchase can be lost.

Mail Privacy Protection

Since iOS 15, Apple Mail can pre-load email content in a way that makes open tracking unreliable. If you rely on email open rates as a signal, they are inflated and no longer trustworthy. Click tracking is a better metric.

What this does to your reports

Put those changes together and you get a predictable set of symptoms. If you recognise several of these, Safari and iOS are probably part of the story.

• Returning visitors look new. When a cookie expires after seven days, a customer who comes back on day nine is counted as a new user. New-user counts rise, returning-user counts fall.
• Sales are credited to "direct". The original ad click is no longer connected to the eventual purchase, so the purchase appears with no source, or is attributed to direct traffic.
• Ad platform conversions fall short. Meta and Google report fewer purchases than your shop actually recorded from those channels, because the platform could not match the purchase to the ad interaction.
• Safari underperforms in analytics. Segment by browser and you often see Safari's conversion rate looking far worse than Chrome's. That is usually a measurement artefact, not a behavioural difference.
• Longer consideration cycles look worse. Products that people research over weeks lose the most, because cookies expire before they buy.

The key insight: these are mostly measurement problems, not necessarily performance problems. Customers still buy. The systems just lose track of why.

Why the usual fix is not enough

Many stores try the obvious remedy: install the platform's standard tag or app and trust it. But standard tags run in the browser, write their cookies with JavaScript and send data to third-party domains. Those are precisely the behaviours Safari restricts. So the default setup is the one most exposed to the limits.

What actually helps

1. Send conversions from a server

Platforms such as Meta and Google offer server-to-server conversion interfaces (Meta's Conversions API, Google's enhanced conversions and offline conversion imports). Instead of relying on the visitor's browser to report the purchase, your server reports it directly. This is not affected by browser cookie lifetime, because the browser is not the messenger.

The catch: the server-side event still needs something to match it to an ad click. That is where identifiers come in, and why the next two points matter.

2. Capture click identifiers on your own terms

When someone lands on your store from an ad, the URL may carry a click ID. Capturing it at that moment, storing it in a cookie set by your own server, and sending it with the later conversion restores the link between click and purchase. Doing so from a first-party context is more durable than a script-written cookie.

3. Extend first-party cookie life carefully

A cookie set in an HTTP response from your own domain is treated more favourably by browsers than one written by a third-party script. Combined with a mechanism to restore cookies for returning visitors, this can bring measurement of returning customers back closer to reality. We explain the mechanics, and the limits, in first-party cookies and why lifetime matters.

An important honesty note: Safari applies extra scrutiny when a tracking subdomain is served from infrastructure whose network address differs from your main site's. A plain CNAME to a tagging server can therefore still see cookie lifetime capped in Safari. This is why some providers offer a cookie restoration feature, which stores an identifier separately and re-issues the cookie when a visitor returns, rather than relying on a long expiry alone. FlyNode's Cookie Keeper power-up works in this spirit, restoring selected cookies for up to 400 days on paid plans.

4. Use modelled and aggregate measurement as a complement

Some conversions will always be unobservable. Platforms fill the gap with modelled conversions, and analytics tools offer modelled data too. Treat those as directional estimates, not ground truth, and compare trends against your actual order data.

5. Prefer first-party data you collect with consent

Email addresses and phone numbers that customers give you during checkout are first-party data. Platforms allow you to send them, hashed, to improve matching (Meta's advanced matching and Google's enhanced conversions are examples). This is legitimate when your privacy notice covers it and consent requirements are met, and it improves match rates without depending on cookies at all.

A practical setup for a store

Here is a sensible sequence for a store that is losing Safari and iOS data:

1. Measure the damage first. Compare Safari and Chrome conversion rates, and compare platform-reported purchases against shop orders for the same period. This gives you a baseline.
2. Put a tagging server on your own subdomain. Route browser events to it, and let it forward to analytics and ad platforms. See custom first-party tracking domains.
3. Turn on server-side conversion delivery for the platforms you advertise on, with a shared event ID so browser and server versions are counted once. Our article on the Meta Conversions API with server-side GTM shows how de-duplication works.
4. Capture click IDs and user data at the right moments, respecting consent.
5. Add cookie restoration if returning-visitor measurement is a priority.
6. Re-measure after two to four weeks. Look at the same comparisons. You should see a smaller gap between shop orders and platform conversions, and fewer sales in "direct".

What you should not expect

It is worth setting honest expectations so you do not judge the project unfairly:

• You will not recover every conversion. Some visitors decline consent, use aggressive protections, or switch devices mid-journey.
• Numbers between platforms will still not match exactly. They use different attribution windows and rules.
• Browser rules keep changing. Anything sold as a permanent bypass is a warning sign. Sound measurement is built on first-party, consent-respecting practices that hold up as rules tighten.

A note on consent

None of the techniques above replaces consent where it is required. If a visitor declines tracking in your consent banner, your setup should honour that, including on the server side. A server does not give you permission the browser did not; it simply gives you a more reliable path for the data you are allowed to collect. For more on this, see server-side tracking and privacy.

Checklist

• Segment key reports by browser and compare Safari against Chrome.
• Compare platform conversions against actual orders.
• Serve tracking from your own subdomain.
• Send conversions server-side, with shared event IDs.
• Store click identifiers in first-party cookies you control.
• Consider cookie restoration for returning visitors.
• Honour consent choices everywhere, including on the server.
• Re-measure and document what changed.

The bottom line

Apple's changes did not end online advertising, but they ended the era when a couple of third-party tags gave you a complete picture for free. The stores that adapted are the ones that moved measurement closer to their own infrastructure, sent conversions from a server, and stopped expecting the browser to do the whole job.

If you want to start, deploying a server-side GTM container on FlyNode takes a few minutes, and the Free plan lets you test the effect on your own traffic before you commit.