Third-Party Cookies

A third-party cookie is written by a domain other than the one in the browser's address bar. Visit a news site that embeds an ad network's script, and the network can save a cookie under its own domain. When you visit a different site that carries the same network's script, the network reads that cookie back and recognizes the same browser. That cross-site recognition powered retargeting, frequency capping across websites, and some view-through reporting for roughly two decades. The technology is old and simple. The embedded script is the key, because any widget, pixel, or ad slot loaded from another domain can set or read such a cookie.

Browsers have been closing this door for years. WebKit says Safari's Intelligent Tracking Prevention blocks all third-party cookies by default. Chrome held out, and Google announced plans to remove them, then changed course. In a post dated October 17, 2025, Google's Privacy Sandbox team said Chrome would maintain its current approach to offering users a choice about third-party cookies. In practice, they still work in Chrome unless a user or an organization turns them off. Their usefulness depends on which browser a visitor happens to use. Chrome's decision means the cookies still work for many visitors, but Safari's block and the user choice in Chrome mean you cannot assume they will be present for any given person.

Because coverage differs by browser, the effects show up unevenly in your reports. Retargeting lists built from third-party cookies miss Safari visitors. Cross-site frequency caps fail in Safari, so the same person may see an ad more often than intended. Conversion tracking that relied on a third-party cookie from an ad platform loses sales that happened after a click in Safari. The usual replacements are first-party cookies, click identifiers passed in URLs, server-side event sending, and platform-level modeling to fill gaps. Many platforms have adapted by sending data from your server, using hashed emails, and modeling the conversions they cannot see. Those modeled numbers are estimates, so treat them as directional.

A common mistake is building new work on them because Chrome kept them. Chrome is not the only browser, and iPhone users are a major share of traffic in many US markets. A second mistake is reading the Chrome decision as permission to ignore consent: privacy laws such as the GDPR and ePrivacy rules treat advertising cookies as needing consent in many places regardless of what the browser blocks. A third is leaving old tags in place without checking whether they still collect anything. The legal side is independent of the browser: if your site sets advertising cookies in a region with consent rules, you need a compliant banner whether or not the browser would have blocked them anyway.

To see your exposure, split conversion and retargeting-list size reports by browser or device in your analytics tool. If Safari conversions are far below its share of clicks, you are probably losing signal. This week, confirm your ad platform tags send conversions through first-party cookies or a server connection, such as Google's enhanced conversions or Meta's Conversions API, and check that your consent banner controls advertising cookies properly. Do not plan any strategy that depends on a third-party cookie existing. Keep a list of the third-party tags on your site and retire any whose purpose you cannot name. Plan for a mixed environment. Keep tags that still work for some visitors, but make sure each reported conversion has a fallback path, so the account does not depend on any single cookie.