> Site index: https://usehardal.com/llms.txt > Every content route also serves markdown at .md # Safari ITP: Cookies, Tracking, and Conversion Fixes Safari ITP explained: how Intelligent Tracking Prevention limits cookies, attribution, and remarketing, plus compliant ways to recover conversion data. Source: https://usehardal.com/safari-itp-guide Published: 2026-03-03 Updated: 2026-08-22 Author: Ecem Bircan Category: Web Analytics --- Safari ITP, short for **Intelligent Tracking Prevention**, is WebKit's system for limiting cross-site tracking in Safari. It blocks third-party cookies, limits some first-party browser storage, and detects workarounds such as link decoration and CNAME cloaking. That changes measurement. A Safari visitor can click an ad, return later, and convert after the browser has removed the identifier that tied those sessions together. Analytics may count a new user, an ad platform may miss the conversion, and a remarketing audience may be smaller than the business expects. ITP leaves teams with a narrower measurement path: collect data as a real first party, keep permitted records on the server, and report conversions without assuming a durable cross-site identity. ## What is Safari Intelligent Tracking Prevention? Apple introduced ITP in WebKit in 2017. ITP is a WebKit privacy feature, and Safari users see its effects through the **Prevent Cross-Site Tracking** setting. [WebKit's tracking-prevention documentation](https://webkit.org/tracking-prevention/) describes a set of browser rules rather than one cookie timer. Some rules apply to every website. Others use on-device classification to identify domains with cross-site tracking capabilities or detect patterns such as decorated links and bounce redirects. A tag can send its network request even when Safari withholds the cookie it expected. ## How Safari ITP works Safari treats storage differently based on who created it, where it is used, and how the visitor reached the page. | Safari ITP rule | What Safari does | Common measurement effect | | --- | --- | --- | | Third-party cookies | Blocks cookies for cross-site resources by default | A third-party pixel cannot rely on its cookie to recognize the same browser across sites | | JavaScript first-party cookies | Caps persistent cookies created with `document.cookie` at seven days | Anonymous user and campaign IDs may reset between visits | | Link decoration | Can cap JavaScript cookies on a decorated landing page at 24 hours when the referring domain is classified for cross-site tracking | A click ID may disappear before a later conversion | | Script-writeable storage | Deletes items such as LocalStorage and IndexedDB after seven days of Safari use without interaction with the site | Moving an ID out of a cookie does not make it durable | | Cloaked third-party responses | Caps cookies set through third-party CNAME or IP cloaking at seven days | Pointing a first-party subdomain at a tracker does not create a durable first-party identity | | Cross-site referrers | Reduces `document.referrer` to the source origin | Analytics loses the full referring page URL | The seven-day rule means seven days of **Safari use without interaction with the site**, not a simple seven-day countdown from the first visit. A real interaction resets the site-use timer. The rule targets browser storage, not records in your backend. Secure, `HttpOnly` authentication cookies set by the site server follow a different path from JavaScript analytics cookies. ### Third-party cookies Safari has applied [full third-party cookie blocking](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) since Safari 13.1 and iOS 13.4. An ad can still load, but its cross-site cookie may not be sent. That breaks the identifier used for audience building, frequency controls, and conversion attribution. Safari provides the Storage Access API for legitimate embedded services that need cookie access, such as authenticated content. It requires browser-controlled user interaction and is not a general escape hatch for advertising trackers. ### First-party cookies and browser storage [ITP 2.1](https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/) capped persistent cookies created through `document.cookie` at seven days. Safari later applied the same seven-day inactivity rule to script-writeable storage, including LocalStorage, IndexedDB, SessionStorage, service worker registrations, and service worker cache. The limit can apply even though the cookie or storage key belongs to the website in the address bar. Safari cannot assume that a first-party JavaScript cookie came from the site owner because third-party scripts also run in that context. ### Link decoration and the 24-hour cap Ad platforms often add parameters such as `gclid` or `fbclid` to a landing URL. This is called link decoration. If Safari classifies the referring domain as having cross-site tracking capabilities, [ITP 2.2](https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/) can cap persistent JavaScript cookies created on that landing page at 24 hours. The rule depends on the source classification, decorated navigation, and storage method. A URL parameter alone does not make every campaign cookie expire after one day. A browser-only attribution setup can still lose the click ID before a purchase made several days later. ### CNAME cloaking and server-set cookies Server-set first-party cookies follow HTTP cookie rules rather than the blanket seven-day `document.cookie` cap. Other ITP defenses still apply. Safari detects when a first-party-looking subdomain resolves to a third-party tracker through CNAME or IP cloaking. WebKit then caps cookies from that response at seven days. [WebKit's CNAME cloaking defense](https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/) exists specifically to stop tracker domains from borrowing a site's hostname to evade ITP. A sound first-party setup sends events to infrastructure controlled by the same organization as the website. A DNS alias alone does not make a third-party tracker first party. ## Does a cookie consent banner bypass Safari ITP? No. A cookie consent banner and Safari ITP do different jobs. - The banner records a visitor's choice and tells your site which processing may run. - Safari decides whether browser storage or cross-site cookie access is available. Clicking **Accept** does not switch off ITP. A marketing pixel may run after consent and still find that its third-party cookie is blocked or that its JavaScript cookie has a limited lifetime. Clicking **Reject** should flow through your consent logic and suppress any processing that requires permission. Sending the same event from a server does not change that choice. [WebKit's Tracking Prevention Policy](https://webkit.org/tracking-prevention-policy/) treats attempts to circumvent tracking prevention like security exploits and grants no site-specific exceptions. Build ITP-compatible measurement within those rules. There is no official "ITP compliant" certificate. Teams usually use that phrase for a setup that: 1. accepts Safari's restrictions instead of hiding a third-party tracker; 2. collects events through a genuine first-party endpoint; 3. respects consent and data-retention rules; and 4. keeps working when browser identifiers expire or disappear. ## How ITP affects conversion tracking and remarketing ITP removes signals from browser-only measurement. The underlying visit or sale still happened. | Use case | What breaks | What you see in reports | | --- | --- | --- | | Conversion attribution | The browser loses the click ID or anonymous visitor ID before conversion | Fewer attributed conversions and shorter reported paths | | Remarketing | A third-party ad cookie is unavailable across sites | Smaller pixel-only audiences and fewer recognized return visitors | | Segmentation | A JavaScript identifier resets between visits | Returning Safari users can appear as new users | | Personalization | Browser state is missing on a later visit | On-site experiences lose prior-session context | | Funnel analysis | Page and conversion events arrive under different IDs | More broken sessions and unattributed revenue | Pixel-only remarketing is especially exposed. A browser pixel can observe post-click behavior only while its allowed identifier remains available. If the cross-site cookie is blocked or the first-party ID expires, the platform cannot reliably connect a product view today with a return visit or purchase later. ITP is effective against cookie-based cross-site tracking because it controls the storage layer inside the browser. A website can still record its own orders, account activity, or consented first-party events on its server. That boundary supports a more reliable measurement design. ## How to recover conversion data affected by Apple ITP Preserve the first-party conversion record. Safari intentionally removes cross-site identity, so design the measurement system without it. ### 1. Collect events through your own endpoint Send page, product, checkout, and form events to a same-site collection endpoint. Keep the browser payload small and validate it on the server. This removes the third-party pixel as the only copy of the event. ### 2. Keep permitted attribution data on the server When a visitor arrives with campaign parameters and your consent state permits storage, attach the source data to a server-side session, account, lead, or cart record. Apply a clear retention period. Do not depend on LocalStorage to carry the entire attribution history. For anonymous traffic, use a legitimate first-party identifier set in an HTTP response. For signed-in users, join activity through the account your customer chose to use. Do not replace missing cookies with fingerprinting. ### 3. Capture the conversion from its source system Record purchases in the commerce backend, qualified leads in the CRM, and subscriptions in the billing system. A thank-you-page pixel can fail because the tab closes, a script is blocked, or the browser identifier has expired. The system that completed the transaction has the stronger record. Include the fields the destination needs, such as event name, event time, order or lead ID, value, currency, campaign data, and consent state. Avoid collecting fields that have no measurement purpose. ### 4. Send consented conversions through server APIs Forward eligible events from the server to analytics and ad-platform APIs. Use one stable event ID in browser and server copies so each destination can deduplicate them. A server call improves delivery, but the destination may still report less attribution when it cannot match the event to an allowed ad interaction. ### 5. Reconcile platform reports with first-party totals Treat backend revenue or qualified leads as the source of truth. Compare those totals with browser events, accepted server events, and attributed conversions. The gaps tell you whether the problem sits in collection, delivery, matching, or the platform's attribution model. [Server-side analytics](https://usehardal.com/analytics) can handle first-party collection and destination delivery, but the same rule applies to any implementation: respect the visitor's choice and keep a clear boundary between your customer data and cross-site tracking. ### What server-side tracking can and cannot fix | Server-side tracking can | Server-side tracking cannot | | --- | --- | | Preserve a first-party copy of a permitted site event | Restore a third-party cookie that Safari blocked | | Record a purchase without depending on a thank-you-page pixel | Recreate a person's cross-site browsing history | | Send one conversion to several destinations | Turn rejected consent into permission | | Keep campaign data in a server-side record | Make CNAME-cloaked third-party tracking exempt from ITP | | Deduplicate browser and server events | Guarantee that every ad platform attributes the event | Server-side tracking preserves first-party measurement by removing the dependency on a cross-site browser identity. Calling it an ITP bypass misstates the design. ## How to test Safari ITP and use ITP Debug Mode ITP Debug Mode is a Safari developer option on macOS. It logs domain classification and scheduled website-data deletion. It is useful when a cookie disappears in Safari but survives in another browser. [Apple's current Safari developer settings](https://developer.apple.com/documentation/safari-developer-tools/developer-settings) still include ITP Debug Mode. [WebKit's detailed guide](https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/) documents this logging workflow: 1. Enable Safari's developer features in Safari Settings under **Advanced**. 2. Open the **Develop** menu and enable **Intelligent Tracking Prevention Debug Mode**. The exact menu wording can vary by Safari release. 3. Open the macOS Console app, include info messages, and filter for `ITPDebug`. 4. Reproduce the landing, return visit, and conversion flow. 5. Disable Debug Mode when you finish because the log can contain sensitive browsing information. You can also stream the log from Terminal: ```bash log stream -info | grep ITPDebug ``` Test the full measurement path: - Start with a fresh Safari profile and no existing site data. - Visit through a cross-site URL that includes a test campaign parameter. - Inspect `Set-Cookie` response headers separately from cookies created with `document.cookie`. - Confirm which third-party requests send cookies and which do not. - Complete a conversion and compare the browser event, first-party server record, and destination response. - Send browser and server copies with the same event ID and confirm that the destination counts one conversion. - Repeat the core flow in Safari Technology Preview to catch upcoming WebKit changes. ## Safari ITP timeline Production implementations should target Safari's current behavior. The old version labels remain useful for understanding individual rules. | Release | Main tracking change | | --- | --- | | ITP 1.0, 2017 | Introduced on-device classification and limits on cross-site cookie access | | ITP 2.1, 2019 | Capped persistent cookies created with `document.cookie` at seven days | | ITP 2.2, 2019 | Added the 24-hour cap for certain decorated-link landings | | ITP 2.3, 2019 | Extended decorated-link defenses to script-writeable non-cookie storage | | Safari 13.1, 2020 | Enabled full third-party cookie blocking | | Safari 14, 2020 | Added a seven-day cap for cookies from third-party CNAME cloaking | | Later Safari releases | Expanded cloaked IP defenses and storage partitioning; Private Browsing added known-tracker and fingerprinting defenses | Start with one Safari purchase flow from an ad-like URL. Verify the landing event and conversion in your first-party store, then verify that the destination accepted one deduplicated conversion. If the browser pixel disappears and the server event remains, the setup is doing the job it should.