iOS 14+ and Shopify Tracking: What Actually Changed (and What Server-Side Fixes)

TL;DR

Most of the panic around "iOS 14 breaking tracking" conflates three separate mechanisms: ATT (in-app browsers on iOS), ITP (Safari on all Apple devices), and SKAdNetwork (app install campaigns, not web tracking). For Shopify merchants, ATT matters when buyers click ads inside Facebook, Instagram, or TikTok apps on iPhones. ITP matters whenever anyone uses Safari, roughly half of US mobile traffic. SKAdNetwork is mostly irrelevant unless you run app install campaigns. Server-side tracking with hashed PII is the fix for the first two. This article breaks down what each mechanism does, which Shopify events they affect, and how server-side CAPI sends the data platforms need without depending on browser cookies or device identifiers.

Key Takeaways

• ATT blocks device identifiers in in-app browsers. When a user opts out of tracking in iOS Settings or declines the ATT prompt, Facebook/Instagram/TikTok's in-app browser cannot access the IDFA (device advertising identifier) or set third-party cookies.
• ITP caps JavaScript-set cookies at 7 days. Safari's Intelligent Tracking Prevention means _ga, _fbp, and _ttp cookies expire after 7 days of inactivity. A buyer who clicks your ad on Monday and returns organically 8 days later looks like a new visitor.
• SKAdNetwork is for app installs, not web tracking. Most Shopify merchants do not run iOS app install campaigns and do not need to worry about SKAN.
• Server-side CAPI sends hashed PII directly to ad platforms. SHA-256 hashed email, phone, name, and address fields travel server-to-server, bypassing both ATT and ITP entirely.
• Cookie resilience strategies exist for the browser side. A 4-tier fallback for GA4's client_id (cookie, localStorage from theme extension, last known good from localStorage, generate new) keeps session identity alive longer on Safari.
• Pre-purchase funnel events remain browser-dependent. Page views and add-to-cart events still fire from the buyer's browser and are subject to ITP cookie expiration.

ATT: What It Actually Does on Shopify

App Tracking Transparency is an iOS feature that requires apps to ask permission before accessing the device's advertising identifier (IDFA). When a user declines (and opt-out rates are above 80% per multiple industry sources), the app loses access to IDFA and to cross-app tracking capabilities.

For Shopify merchants, this matters specifically in one scenario: when a buyer clicks your ad inside an iOS app (Facebook, Instagram, TikTok) and completes the purchase in that app's in-app browser.

In this flow, the ad platform's in-app browser is the execution environment. When the user has opted out of tracking, that browser blocks third-party cookies and suppresses the device identifiers that the platform would normally use to match the ad click to the conversion. The browser-side pixel fires, but without cookies or IDFA, the platform cannot reliably attribute the purchase back to the ad.

ATT does not affect Safari-to-Safari flows (those are governed by ITP, covered next). It does not affect desktop browsers. It does not affect Android. It is specifically about iOS apps requesting permission to track across other apps and websites.

If a meaningful share of your paid traffic comes from Facebook, Instagram, or TikTok ads clicked on iPhones, ATT is reducing the conversion signal those platforms receive. Meta has documented significant measurement gaps from ATT, which is why they built the Conversions API as the primary mitigation path.

ITP: The Bigger Problem for Shopify Tracking

Safari's Intelligent Tracking Prevention has been iterating since 2017 and is, for most Shopify merchants, a larger ongoing problem than ATT. ITP affects every Safari session on every Apple device, not just in-app browsers.

The specific mechanism that hurts Shopify tracking: ITP caps first-party cookies set via JavaScript (document.cookie) to 7 days of expiry. Cookies set via HTTP response headers from your own server are not affected by this cap, but tracking libraries set their cookies via JavaScript.

This means:

• _ga (Google Analytics client ID): Set by gtag.js via JavaScript. Expires after 7 days of inactivity on Safari. A buyer who visits your store, leaves for 8 days, and returns looks like a brand new visitor in GA4. The original session, the ad click attribution, the browsing history are all severed.
• _fbp (Meta browser ID): Set by fbevents.js via JavaScript. Same 7-day cap. Meta loses the ability to stitch the original ad click to a delayed conversion.
• _ttp (TikTok browser ID): Set by the TikTok pixel via JavaScript. Same cap, same consequence.

In some configurations, ITP can be even more aggressive. When Safari classifies a domain as having cross-site tracking capabilities, cookies can be capped at 24 hours. The 7-day cap is the baseline.

For stores with longer purchase cycles (B2B, high-ticket items, anything where buyers research for more than a week), ITP is silently breaking attribution on every Safari visitor. Safari's share of US mobile traffic is roughly 50%, with higher shares in the UK and Australia.

SKAdNetwork: Why Most Shopify Merchants Can Ignore It

SKAdNetwork (SKAN) is Apple's framework for measuring iOS app install campaigns. It gives advertisers aggregated, delayed conversion data for campaigns that drive app installs.

If your customers buy through a web browser (even an in-app browser), SKAN does not apply to your purchase tracking. It is relevant only if you are running campaigns to drive installs of your own iOS app, which the vast majority of Shopify merchants are not.

The confusion comes from iOS 14 announcements lumping ATT, ITP, and SKAN together as a single "privacy update." They are three separate mechanisms with different scopes.

How Server-Side CAPI Bypasses ATT and ITP

Server-side Conversions API (CAPI) sends conversion events from your server directly to the ad platform's API. The buyer's browser is not involved in this request, which means:

• ATT cannot block it (no in-app browser restrictions apply to server-to-server calls)
• ITP cannot expire the cookies it depends on (the server reads customer data from the order, not from browser cookies)
• Ad blockers cannot intercept it (no browser-originated request to block)

The data that travels server-side is hashed customer information. Here is what each platform receives:

Meta Conversions API

SHA-256 hashed: email, phone, first name, last name, city, state, zip code, country, and an external ID. The server also passes _fbp and _fbc cookie values when they are available (captured at checkout before ITP expires them). Meta uses this data to match the server-side event to the ad click, even when the browser pixel was suppressed or the cookie expired.

Google Ads Enhanced Conversions

SHA-256 hashed with platform-specific normalization: email addresses get Gmail-aware processing (dots and plus-suffixes removed from @gmail.com addresses before hashing), phone numbers are formatted to E.164 international standard, and names have symbols stripped. This normalization ensures the hash matches Google's records even when the input formatting varies.

TikTok Events API

SHA-256 hashed: email, phone, first name, last name, city, state, zip code, country. The server also passes _ttp (TikTok cookie) and ttclid (TikTok click ID) when available. Same principle as Meta: hashed PII enables matching when browser-side identifiers are missing.

Server-side CAPI does not replicate what the browser pixel does. It provides an alternative matching path. The browser pixel matches via cookies and click IDs. The server-side event matches via hashed PII from the order. When both fire, the platform deduplicates them using a shared event_id. When the browser pixel is blocked, the server-side event still arrives with enough data to attribute the conversion.

Cookie Resilience: What Happens on the Browser Side

Server-side tracking solves the purchase event problem, but pre-purchase events (page views, add-to-cart) still depend on browser cookies for session identity. A well-built tracking setup implements fallback strategies to keep session identity alive as long as possible on Safari.

For GA4's client_id, a 4-tier resilience strategy handles ITP cookie expiration:

1. Read the _ga cookie directly. If the cookie is present and not expired, use it. This is the happy path and works on all non-Safari browsers and on Safari within 7 days of the last visit.
2. Read from localStorage via theme extension. A theme-level script writes the client_id to localStorage, which is not subject to ITP cookie caps. If the cookie is gone but localStorage has a value, use that.
3. Read the last known good value from localStorage. A secondary localStorage key preserves the most recent valid client_id as a fallback.
4. Generate a new client_id. When all persistence layers are exhausted, generate a fresh ID. The session continuity is broken, but at least the event fires.

This strategy extends the effective lifetime of GA4 session identity on Safari beyond the 7-day cookie cap, though it is not bulletproof. A buyer who clears localStorage or uses private browsing will still appear as a new visitor.

What iOS Privacy Changes Mean for Your Ad Spend

ATT and ITP cause your ad platforms to report fewer conversions than actually occurred. The downstream effects:

• ROAS calculation: Reported revenue is lower than actual revenue. You might pause a profitable campaign because the dashboard shows it underperforming.
• Smart Bidding optimization: Google Ads, Meta, and TikTok use reported conversions to tune bidding algorithms. Fewer conversions means more conservative bidding or wrong audience targeting.
• Audience modeling: Lookalike audiences and retargeting pools are built from tracked events. Missing conversions mean smaller, less accurate seed audiences.

Server-side tracking addresses the first two by recovering purchase events. Audience modeling improves indirectly through more matched conversions, but the pre-purchase browsing data gap remains.

Frequently Asked Questions

Does ATT affect Android users?

No. ATT is an Apple/iOS feature. Android has its own privacy framework, but it does not include an ATT-equivalent prompt. Your Android traffic is not affected by ATT.

Does ITP only affect Safari?

ITP is Safari-specific. Firefox has Enhanced Tracking Protection and Brave blocks third-party cookies by default, but the 7-day JavaScript cookie cap is unique to Safari. Chrome does not currently enforce a similar cap.

Will using a custom domain fix ITP issues?

A custom domain ensures cookies are first-party, which is necessary but not sufficient. ITP's 7-day cap applies to first-party cookies set via JavaScript regardless of domain. Server-set cookies (via HTTP Set-Cookie headers) are not affected, which is why some setups proxy tracking scripts through a first-party endpoint.

Do I need to worry about iOS 17/18 changes?

Apple continues to tighten ITP with each release. The core mechanism (JavaScript cookie cap) has been stable, but new restrictions can emerge. Server-side tracking is structurally immune to browser-side restrictions. The first-party cookies article covers the evolving cookie landscape in detail.

WeltPixel Conversion Tracking Handles ATT and ITP Recovery

WeltPixel Conversion Tracking sends server-side purchase events (plus GA4 refund events) with SHA-256 hashed PII to GA4, Meta, TikTok, Google Ads, and Reddit, recovering the conversion signal that ATT and ITP suppress on the browser side. The 4-tier cookie resilience strategy for GA4 client_id extends session identity on Safari beyond the standard 7-day ITP cap. Deduplication via shared event_id ensures you never double-count when both browser and server events arrive.

Explorer plan covers all five channels. No GTM server container, no custom proxy infrastructure.

Install WeltPixel Conversion Tracking on the Shopify App Store

Sources

1. Apple Developer Documentation, App Tracking Transparency: https://developer.apple.com/documentation/apptrackingtransparency
2. WebKit Blog, Intelligent Tracking Prevention: https://webkit.org/blog/category/privacy/
3. Shopify Developer Documentation, Web Pixels API: https://shopify.dev/docs/api/web-pixels-api