Safari Just Put a 7-Day Clock on Your ChatGPT Ad Clicks
OpenAI’s ChatGPT Ads pixel stores the click identifier in a first-party __oppref cookie with a 30-day lifetime. But Safari’s Intelligent Tracking Prevention caps any cookie set by JavaScript at 7 days, and drops it to 24 hours when tracking parameters are present in the URL. For the 26% of mobile shoppers on Safari, the oppref click ID silently expires before most WooCommerce purchases complete, breaking attribution for the fastest-growing ad channel. Server-side capture at landing preserves the click ID in your own infrastructure, beyond ITP’s reach.
The 30-Day Promise That Safari Breaks in 7
The pixel sets a 30-day cookie. Safari overwrites the expiry to 7 days. The pixel has no idea it happened.
OpenAI’s ChatGPT Ads pixel uses the __oppref cookie to link ad clicks to downstream conversions. When a user clicks a ChatGPT ad and lands on a WooCommerce store, the pixel captures the oppref identifier from the URL and stores it in a first-party cookie with a 30-day lifetime. That 30-day window is what connects the click to any purchase that follows, whether it happens in the same session or three weeks later.
The problem is how the cookie gets set. The ChatGPT Ads pixel runs as JavaScript in the browser. It writes the __oppref cookie using the document.cookie API. And Safari’s Intelligent Tracking Prevention caps any cookie written through that API at 7 days, regardless of the expiry the script requests.
Safari ITP caps the __oppref cookie to 7 days because the ChatGPT Ads pixel sets it via JavaScript’s document.cookie API, regardless of the 30-day lifetime OpenAI intended.
The pixel does not know this happened. It wrote a cookie with a 720-hour lifetime. Safari accepted it and silently rewrote the expiry to 168 hours. No error fires. No warning appears in the console. The cookie simply stops existing after 7 days of inactivity, taking the click ID with it.
If the landing URL contains recognised tracking parameters, ITP tightens further. The cap drops to 24 hours. Whether OpenAI’s oppref parameter triggers this classification depends on Safari’s heuristic, but even without it, the 7-day baseline is short enough to break most purchase cycles.
Who This Affects: One in Four Mobile Shoppers
Safari is not a niche browser. It is one in four mobile sessions worldwide and one in two in North America.
Safari holds 26% of worldwide mobile browser sessions as of April 2026. In North America, it controls 51.2% of mobile browsing. For a WooCommerce store with US or UK customers, Safari is not a testing edge case. It is the majority of mobile traffic.
| Region | Safari Mobile Share | Impact on __oppref |
|---|---|---|
| Worldwide | 26% | 1 in 4 mobile shoppers lose click ID after 7 days |
| North America | 51.2% | Majority of mobile sessions affected |
| UK / Western Europe | ~30-35% | Nearly 1 in 3 mobile sessions affected |
| India / Southeast Asia | ~5-10% | Lower impact, Chrome dominates |
With Safari holding 26% of worldwide mobile browser sessions, roughly one in four mobile shoppers on a WooCommerce store loses ChatGPT ad attribution after 7 days.
The compound effect is invisible in aggregate reporting. ChatGPT Ads shows a certain number of conversions. WooCommerce shows a higher number of orders. The gap is easy to dismiss as normal measurement variance. But the gap concentrates on Safari users, on longer purchase cycles, and on higher-value orders where customers research for more than a week before buying. The attribution loss is not random. It is systematically biased against the purchases that take the longest to decide.
The Decay Pattern in Practice
Day 1: click ID present. Day 8: click ID gone. Day 14: purchase completes. Attribution: zero.
Consider a real WooCommerce purchase cycle. A customer sees a ChatGPT ad for outdoor furniture on a Monday. They click through, browse the store, add a set to their wishlist, and leave. The __oppref cookie is set with the click ID. On Safari, ITP has already rewritten its expiry to the following Monday.
The customer returns the next Saturday, six days later. The cookie is still alive. They compare prices, read reviews, and leave again. The cookie’s 7-day timer resets on this visit if there was any interaction that refreshed it, depending on the pixel’s implementation. But if no interaction refreshes the cookie value, the original 7-day clock keeps counting from the first visit.
The customer comes back 10 days after the original click. They purchase the furniture set. The __oppref cookie is gone. The pixel fires on the thank-you page but has no click ID to include. The Conversions API has no oppref to send. OpenAI receives a conversion event with no link to the original ad interaction. The purchase happened. The attribution did not.
This pattern repeats for every Safari user whose purchase cycle exceeds 7 days. Higher-value products with longer consideration periods are disproportionately affected. The WooCommerce stores selling products where customers research, compare, and deliberate are exactly the stores where the __oppref decay causes the most damage.
You may be interested in: One Wrong event_id and You’re Double-Counting Every WooCommerce Sale
The Same Problem, Different Pixel
fbclid, gclid, and now oppref. Every browser-set click ID follows the same decay path on Safari.
The __oppref cookie decay is not a new problem unique to ChatGPT Ads. It is the same ITP behaviour that has been degrading Meta’s _fbc cookie, Google’s _gcl_aw cookie, and every other JavaScript-set click identifier on Safari since 2019.
The same Safari ITP decay that breaks __oppref already broke fbclid and gclid attribution years ago, making this a known architectural problem with a proven server-side fix.
Meta solved it with the Conversions API, which captures the fbclid server-side at landing and includes it in server-to-server event transmission. Google solved it with Enhanced Conversions, where the gclid is captured server-side and hashed user data bridges the attribution gap. Both solutions share the same architectural principle: capture the click identifier at the server before ITP can expire it in the browser.
OpenAI’s Conversions API provides the server-side leg. But it does not automatically capture the oppref from the landing URL. The pixel captures it in the browser and stores it in the __oppref cookie. The API accepts it as an input. The gap between those two statements is where the attribution breaks. Someone, or something, needs to read the oppref from the URL at the server level, store it durably, and pass it to the API when the conversion fires.
The Server-Side Fix
Capture the click ID at the server. Store it where ITP cannot reach it. Pass it to the API when the conversion fires.
The fix follows the same pattern that works for every other decaying click identifier on Safari.
Step 1: Intercept the oppref at landing. When a visitor arrives at your WooCommerce store from a ChatGPT ad, the URL contains the oppref parameter. Your server reads this value from the request before the page renders. This happens at the PHP/WordPress level, not in JavaScript, so ITP is not involved.
Step 2: Store it durably. The oppref value goes into two places. First, into a first-party HTTP cookie set via the Set-Cookie response header from your own server. Cookies set this way by a genuine first-party server persist for up to 400 days and are exempt from ITP’s 7-day JavaScript cap. Second, into your session or database, tied to the visitor or order, so it survives even if the cookie is cleared.
Step 3: Use it at conversion. When the purchase completes, the Conversions API call includes the stored oppref value. The pixel may or may not have its own copy in the browser cookie, depending on whether 7 days have passed. But the server has the authoritative copy, captured at landing and stored beyond ITP’s reach.
Server-side capture of the oppref click ID at landing, stored as a first-party HTTP cookie or in the session database, survives Safari ITP because genuine server-set cookies are not subject to the 7-day cap.
The Transmute Engine™ handles this flow natively for WooCommerce. The oppref parameter is captured from the landing URL at the server level when the visitor first arrives. It is stored as a genuine first-party HTTP cookie via Set-Cookie header from your own subdomain, and persisted in order meta. When the purchase completes, the same oppref value feeds both the Conversions API POST and the browser pixel’s dataLayer, ensuring the click ID survives regardless of how long the customer takes to buy.
You may be interested in: Your First-Party Cookies Still Die in 7 Days
Why sGTM Alone Is Not Enough
A server-side tag manager running on the wrong infrastructure still gets the 7-day cap.
The instinctive response to ITP is to deploy server-side Google Tag Manager. But sGTM does not automatically solve the __oppref problem, and in some configurations, it does not solve it at all.
Since Safari 16.4, released in April 2023, ITP extends the 7-day cap to server-set cookies when Safari detects that the setting server is disconnected from the primary domain. A CNAME pointing to a third-party hosting provider, or an sGTM container running on Google Cloud with a different IP range than your domain, gets caught by this heuristic. The cookies it sets are treated as client-set and capped to 7 days.
The only configuration that survives is a genuine first-party server: one that runs on your domain (or a subdomain), resolves to an IP address in the same range as your primary domain, and sets cookies via HTTP headers. This is why the server architecture matters as much as the server existence. An sGTM container that runs on a subdomain with matching IP and sets the oppref via Set-Cookie header works. An sGTM container that runs on a Google-hosted domain and relies on CNAME does not.
For WooCommerce stores, the simpler path is often to handle the capture at the WordPress level. The server is already first-party. It already runs on your domain. It already processes every request. Reading a URL parameter and setting an HTTP cookie is a few lines of PHP, not a separate infrastructure deployment. The server-side tag manager adds value for routing events to multiple destinations, but the cookie capture itself is native to the platform.
Key Takeaways
- The __oppref cookie decays to 7 days on Safari: OpenAI’s pixel sets it via JavaScript with a 30-day lifetime, but ITP silently rewrites the expiry to 7 days. No error, no warning.
- One in four mobile shoppers is affected: Safari holds 26% of mobile sessions worldwide and over 51% in North America. The attribution loss concentrates on longer purchase cycles and higher-value orders.
- Server-side capture is the proven fix: Read the oppref from the URL at the server, store it via Set-Cookie HTTP header, and pass it to the Conversions API at conversion. The same pattern works for fbclid, gclid, and every other decaying click ID.
- sGTM is not enough by itself: Safari 16.4 extended ITP to catch server-set cookies from disconnected servers. Only a genuine first-party server with matching IP sets cookies that survive.
- This is a known problem with a known fix: Meta and Google both solved the same ITP decay years ago with server-side capture. OpenAI’s oppref follows the exact same pattern and requires the exact same architectural response.
No. Chrome allows first-party cookies up to 400 days. Firefox has its own Enhanced Tracking Protection but does not cap first-party cookies as aggressively as Safari. The 7-day cap is specific to Safari ITP’s treatment of cookies set via JavaScript. On Chrome, the __oppref cookie keeps its intended 30-day lifetime.
It depends on the implementation. A basic server-side GTM setup using a CNAME that resolves to a third-party IP still gets caught by Safari 16.4’s extended ITP rules and receives the same 7-day cap. Only a genuine first-party server on the same IP range as your domain sets cookies that ITP treats as truly first-party.
It may be. ITP applies the 24-hour cap when known tracking parameters appear in the landing URL. If OpenAI’s oppref parameter is classified as a tracking identifier by Safari, the cookie could be capped to 24 hours instead of 7 days. Even without classification, the 7-day cap alone breaks most WooCommerce purchase cycles.
Transmute Engine captures the oppref parameter from the landing URL at the server level when the visitor first arrives. It stores the value as order meta and in a genuine first-party HTTP cookie set via the Set-Cookie header from your own subdomain. This cookie is not subject to ITP’s JavaScript cap and persists for the full attribution window.
References
- JavaScript Pixel — OpenAI Platform Documentation (May 2026)
- WebKit Privacy Blog — Apple / WebKit (2026)
- Apple Intelligent Tracking Prevention 2.x — Adobe Experience League (2026)
- Mobile Browser Usage Statistics 2026 — SQ Magazine (July 2026)
- Browser Market Share 2026: Complete Statistics — Digital Applied (April 2026)
- How to bypass Safari ITP Limitations — Jentis (November 2025)
- Tracking Cookie Lifetimes — Snowplow (2026)
Every click ID written by JavaScript follows the same 7-day decay path on Safari. The fix is always the same: capture it at the server, store it where the browser cannot touch it, and use it when the conversion fires. See how Transmute Engine preserves every click ID server-side.