The short answer
Intelligent Tracking Prevention (ITP) is Safari's built-in limit on tracking. It blocks third-party cookies, deletes cookies written by JavaScript after 7 days without a visit (24 hours if the visitor came from an ad click), and gives disguised server cookies the same 7-day cap. Returning iPhone buyers lose the click that brought them, so your ads lose credit for sales they caused. Cookie tricks only buy days. The fix is to stop depending on Safari's memory.
DataCops is a tool that captures the ad click on your own domain and keeps it on the server, so Safari deleting a cookie no longer deletes the sale; it gives every visit a bot verdict and sends the confirmed sale to Meta, Google Ads, TikTok and LinkedIn.
How DataCops fixes it:
- Capture the click first. One script and one DNS record collect on your own domain. With your DNS on Cloudflare, the free DataCops Cloudflare Worker reads the click ID at the edge, before the page or any browser script runs.
- Capture the click on the server. The click ID is read server-side on the landing request and stored for up to 90 days, so Safari deleting a cookie no longer deletes the click.
- A 400-day server-set cookie. A signed first-party cookie, set by the server on your own domain (up to 400 days, where enabled), recognises the returning visitor long after Safari's 7-day and 24-hour caps would have wiped a script cookie. Set only after consent and a clean bot check.
- Send only real people. Every visit gets a bot verdict against 360+ billion IPs, so recovered conversions are humans, not bots.
- Send the confirmed sale. Matched by click ID or hashed email and phone, counted once against the pixel: from your site, from the DataCops Shopify app, or from your CRM (HighLevel natively, any CRM by webhook).
- See the truth. Bot-filtered first-party analytics from your own domain, a GA4 alternative, and a consent manager (IAB TCF v2.2) that loads from your subdomain.
The Wednesday buyer
Here is an example of how ITP costs you a sale you already made.
Someone taps your Meta ad on an iPhone on Monday night. They look around, add nothing to the cart, and close the tab. On Wednesday they come back by typing your address, and they buy. Meta sent them. Your reports say they came from nowhere.
What happened in between is not a bug. The visitor arrived through a link that carried a click ID, so Safari capped the cookie holding that click at 24 hours. By Tuesday night it was gone. The purchase fired with no click ID and nothing to tie it to the ad.
Multiply that by every iPhone buyer who thinks for more than a day. Meta optimises toward the buyers it can see, which are the impulsive ones. Your considered buyers, often the best ones, drop out of its training data.
Safari did not lose your sale. It lost the receipt that said who sent it.
The tools people use, honestly
What each common tool does about ITP. Pricing changes often, so check each vendor's current price.
DataCops
Captures the click on your own subdomain when the visitor lands, keeps it on the server, and sends the confirmed sale later, matched by click ID or hashed email and phone. Optional free Cloudflare Worker captures the click at the edge, before the page loads. On Shopify it installs as an app. More in the section above.
Best for: lead gen, clinics, agencies and anyone whose buyers take more than a day.
Server-side Google Tag Manager (self-hosted or Stape)
Moves cookie-setting to a server you control. It works for ITP only when the server answers on your own network, which is why hosts sell add-ons for it, such as Stape's Cookie Keeper. Still a cookie, still a clock. See our Stape comparison and server-side GTM comparison.
Best for: teams with an in-house tagging engineer who wants full container control.
Elevar
A Shopify-focused server-side tracking tool with a deep data layer. Elevar documents the Safari 16.4 impact openly. Identity between visits still rests on a cookie. See our Elevar comparison.
Best for: larger Shopify stores that want the deepest Shopify data model.
Tracklution, Jentis, Littledata, TrackBee
Server-side event delivery to the ad platforms with less setup than a tag manager. They extend cookie life where Safari allows it; none removes the clock. Jentis focuses on EU enterprises, Littledata on Shopify subscriptions. See our Tracklution comparison.
Best for: stores that want server-side delivery without running a container.
Meta and Google's own tools
Meta's Conversions API options and Google's first-party tagging send events server-side for their own platform. They help match quality when you pass hashed email and phone. They do not cover other platforms, and they do not decide which visits are real people.
Best for: one-platform advertisers with clean traffic.
GA4, Amplitude, Mixpanel, Triple Whale, Northbeam
They read the identity your tracking produces. If Safari reset it, they chart the reset accurately. Fix the input first; then these tools become trustworthy on iPhone traffic.
Best for: reporting, once the data feeding them is whole.
Which approach fits you
| If this sounds like you | Start with |
|---|---|
| Lead gen, clinics or B2B, sales close days later | Approach 5: store the click, send the CRM stage with hashed email and phone |
| Shopify store | The DataCops Shopify app: paid orders sent from Shopify's server with hashed email and phone |
| In-house tagging team, many tools | Server-side GTM on your own network, plus approach 4 |
| Mostly email and SMS traffic | UTMs everywhere, plus approach 4 or 5, since click IDs are stripped in Mail and Messages |
When not to use DataCops
- You have a tagging engineer who wants full container control and custom logic across many tools. Server-side GTM, self-hosted or on Stape, is the more flexible choice. DataCops is not a tag manager.
- You advertise on Meta only, with clean traffic and little volume. Meta's own server-side option may be all you need.
What is ITP?
ITP is a set of storage and tracking rules built into WebKit, the engine that runs Safari on iPhone, iPad and Mac. Apple introduced it in 2017 and has tightened it almost every year since. WebKit publishes the current rules on its tracking prevention page.
It reaches further than Safari's market share suggests. Apple has long required iPhone browsers to run on WebKit, so Chrome and Firefox on iOS live under most of the same rules. In the EU, Apple has allowed other browser engines since iOS 17.4, but most iPhone browsers there still run on WebKit. If your buyers are on iPhones, ITP is in the room whichever browser icon they tapped.
What ITP does not do
It does not block your pixel from loading or stop events from firing. UTM parameters survive. Your tags look healthy in every debugger.
What ITP does
It shortens memory. Cookies and stored click IDs expire early, so the event still fires but arrives without the identity that ties it to an ad.
The ITP rules, with dates
Six rules matter for advertisers. Each one closed the workaround the industry built for the one before.
| Rule | Since | What it does |
|---|---|---|
| Third-party cookies blocked | Safari 13.1, 2020 | Cookies set by other domains inside your page are blocked outright |
| JavaScript storage cap | ITP 2.1, 2019 | Cookies written with document.cookie, and other script storage, are deleted after 7 days without a visit |
| Link decoration cap | ITP 2.2, 2019 | Drops to 24 hours when the visitor arrived through a link carrying a click ID from a domain Safari classifies as a tracker |
| CNAME cloaking defence | Safari 14, 2020 | Server cookies set through a subdomain that points to a third party get the 7-day cap |
| IP address rule | Safari 16.4, 2023 | Server cookies get the 7-day cap when the server's IP address does not match the first half of your site's address |
| Link Tracking Protection | iOS 17, 2023 | Removes click IDs like gclid and fbclid from links opened in Mail, Messages and Private Browsing |
Read the dates in order and the pattern is plain. Third-party cookies died, so the industry moved to first-party cookies. Those were capped, so it moved to server-set cookies on a subdomain. That was caught, so it moved the server behind your domain. Then Safari started comparing IP addresses.
The IP rule is the one that caught most server-side tag setups. A tagging server on a cloud platform usually sits on a different network from your website. Safari notices, and the "first-party" cookie is treated like any other tracker cookie. The rule shipped in WebKit without a line in the release notes, which is why many teams found out from their own data.
Every cookie workaround has an expiry date. Apple just has not announced it yet.
What ITP does to your numbers
Three things, and you can check all three this afternoon.
- Inflated new users. GA4 keeps its client ID in a JavaScript cookie. A Safari visitor who comes back after a week without visiting gets a new ID. In GA4, open Reports, then Tech, then Tech details, set the dimension to Browser, and compare new users as a share of total users for Safari against Chrome. A much higher share on Safari is ITP, not growth.
- Direct and organic taking paid credit. When the click cookie expires, the return visit is credited to whatever brought the buyer back, often Direct. Paid social looks weaker on iPhone than it really is.
- Lower match quality in Meta. Events Manager shows Event Match Quality per event. Purchases that arrive without the fbc and fbp values lean entirely on email and phone. If you are not sending those either, the event barely matches.
The first is a reporting annoyance. The third costs money, because a purchase the ad platform cannot match teaches its bidding nothing.
Who ITP hurts most
| If your business has | Why ITP bites harder |
|---|---|
| A buying window longer than a day | Lead gen, clinics, B2B, high-ticket ecommerce: the 24-hour cap expires before the decision |
| Mostly iPhone buyers | Every iOS browser runs under WebKit rules |
| Email and SMS traffic | Link Tracking Protection strips click IDs from links opened in Mail and Messages |
| Sales that close offline | A booked call or a won deal happens days later, long after any browser cookie is gone |
The five ways to deal with ITP
Every tool on the market uses one of these approaches, or a mix. Judge the tool by the approach, not the pitch.
| Approach | What it fixes | What it does not fix |
|---|---|---|
| 1. Stay client-side | Nothing. Simple and free | 7-day and 24-hour caps apply in full |
| 2. Server-set cookies on your own network | The 7-day cap on JavaScript cookies, when the IP matches | Needs the visitor back while the cookie lives; needs upkeep after each Safari change |
| 3. UTMs on every ad | Campaign-level reporting, even under Link Tracking Protection | Does not identify a person, so the ad platform still cannot match the sale |
| 4. Conversions APIs with hashed email and phone | Matching that does not depend on a cookie | Needs the email or phone at the conversion point |
| 5. Store the click on your server and send the confirmed sale | The click survives Safari; the sale is matched by click ID or hashed email and phone, days or weeks later | Needs a match key at the sale: a form, a checkout or a CRM record |
Approaches 2 and 3 are worth doing anyway. Approaches 4 and 5 are the ones that keep working when Apple changes the rules again, because the identity lives with you, not in Safari.
How DataCops handles ITP
DataCops stops asking how long a cookie can live, and asks a different question: when the sale happens, can you still tell the ad platform who bought?
- The click is captured on your domain. One script and one DNS record put collection on your own subdomain. The click ID (gclid, wbraid, gbraid, fbclid, ttclid, li_fat_id) is read on the landing visit and kept on the server for up to 90 days, so Safari deleting a browser cookie does not delete the click.
- A server-set cookie that lasts up to 400 days. Instead of a cookie written by JavaScript, which Safari caps at 7 days or 24 hours, DataCops sets a signed first-party cookie from the server on your own domain, lasting up to 400 days where enabled. It recognises returning visitors, is signed per site so it cannot follow a person across other sites, and is set only after consent is given and the visit passes the bot check. It is for recognising the visitor, not a promise of 400-day attribution windows on ad platforms.
- Even earlier, at Cloudflare's edge. If your site's DNS is on Cloudflare, the free DataCops Cloudflare Worker reads the click ID and UTMs off the very first request, before the page or any browser script runs. The click is on record before Safari, or an ad blocker, gets a say. It cannot bring back a click ID that Link Tracking Protection already removed from the link.
- Only real people reach your ads. Fixing ITP recovers lost conversions, and it recovers bot conversions too unless something filters them. Every visit gets a bot verdict, checked against an IP database covering 360+ billion IPs, and a Real people only switch per platform keeps bot visits out of what Meta and Google learn from.
- The sale is matched without the browser. When the buyer gives an email or phone on a form or at checkout, the sale is sent server-side with the hashed email and phone, plus the click ID when there is one. For sales that close later, your CRM reports the stage: HighLevel natively, any other CRM through a webhook.
- On Shopify, it is an app. The DataCops Shopify app sends paid orders from Shopify's server with hashed email and phone, so iPhone checkouts are counted even when Safari forgot the visit. See Shopify orders to your ads.
- It counts once. The pixel event and the server event share an event ID, so the platform deduplicates them.
- You can see what left. Every conversion gets a row in a delivery log, marked sent, held, skipped or failed, with the reason.
- Analytics you can trust on iPhone traffic. DataCops first-party analytics loads from your own domain and filters bots out, built as a GA4 alternative. See first-party analytics.
- Consent from your own domain. In the EU the visitor cookie needs consent; the built-in consent manager (IAB TCF v2.2) loads from your subdomain, not a third-party CDN.
The Wednesday sale, on its way to MetaCRM sales go to Meta, Google Ads, TikTok and LinkedIn. More in the offline conversions guide and the Meta Conversions API page.
What Apple may do next
Apple has not announced the next ITP rule, so treat this as planning, not news. The direction has been the same for nine years: each update closes the workaround from the last one. Link Tracking Protection today strips click IDs only in Mail, Messages and Private Browsing. If Apple widens it to normal browsing, every setup that depends on reading a click ID from the URL on a return visit loses it.
The safe assumption is that the browser will remember less every year. Build attribution on what you keep: the click ID stored on your server from the first visit, and the email or phone on the order or the lead.
Cookies are the browser's memory. Your CRM is yours.
Your Safari checklist
- Measure it: compare new-user share on Safari and Chrome in GA4.
- Tag every ad with UTMs. They survive Link Tracking Protection.
- Capture the click ID on the landing visit and keep it on your server.
- Collect email or phone at the conversion point and keep it with the order or lead.
- Send conversions server-side with hashed email and phone, deduplicated against the pixel by event ID.
- Send the sale, not only the form, once your CRM confirms it.
- Check Event Match Quality in Events Manager a week later.
FAQ
What is Intelligent Tracking Prevention (ITP)?
ITP is the set of tracking and storage limits built into WebKit, the engine behind Safari. It blocks third-party cookies, deletes cookies and storage written by JavaScript after 7 days without a visit, cuts that to 24 hours when the visitor arrived through a link carrying a click ID, and applies a 7-day cap to server cookies that come through a disguised subdomain or a server on a different IP address.
Does ITP affect Chrome on iPhone?
Mostly yes. Apple has long required iPhone browsers to use WebKit, so Chrome and Firefox on iOS run under the same storage rules as Safari. In the EU, Apple has allowed other browser engines since iOS 17.4, but most iPhone browsers there still run on WebKit.
How long do cookies last in Safari?
Cookies written by JavaScript last up to 7 days without a visit, or 24 hours if the visitor arrived through a link with a click ID such as fbclid or gclid. Server-set cookies can last longer, unless they come from a subdomain that points to a third party or from a server whose IP address does not match your site, in which case they are capped at 7 days too.
What is the ITP 24-hour rule?
When a visitor lands from a link decorated with a click ID by a domain Safari classifies as a tracker, cookies set by JavaScript on that landing page expire after 24 hours. A buyer who clicks an ad on Monday and returns on Wednesday has already lost the click.
Does server-side tracking fix ITP?
Partly. Server-set cookies avoid the 7-day cap on JavaScript cookies, but only if the server shares your site's network; Safari 16.4 caps them at 7 days when the IP address does not match. It still depends on the visitor coming back while the cookie lives. The durable fix is to match the sale by hashed email and phone, plus a click ID stored on your server.
Does ITP strip gclid and fbclid?
Link Tracking Protection, added in iOS 17, removes known click IDs like gclid and fbclid from links opened in Mail, Messages and Safari Private Browsing. In normal Safari browsing the click ID still arrives, but the cookie that stores it may only live 24 hours. UTM parameters are not removed.
Why does GA4 show so many new users on Safari?
GA4 stores its client ID in a JavaScript cookie. When Safari deletes it after 7 days without a visit, the returning visitor gets a new ID and is counted as a new user. Compare new users by browser: a much higher share on Safari than on Chrome is ITP, not growth.
How does ITP affect Meta Conversions API and Event Match Quality?
The Conversions API sends events from a server, so ITP does not block it. But the event needs identifiers. If Safari deleted the fbc and fbp cookies before the purchase, the event leans on hashed email and phone alone, and Event Match Quality drops when those are missing too.
What is the most reliable way to attribute Safari buyers?
Capture the click ID when the visitor lands and keep it on your server, collect email or phone at the conversion point, and send the confirmed sale server-side with the hashed email and phone plus the click ID, deduplicated against the pixel by event ID.
