Your GA4 dashboard shows a quiet jump in new users starting in late October 2025. Traffic volume is flat. Nothing in your ad spend changed. You haven’t run a campaign that would bring in a cohort of first-time visitors. And yet returning customers — people who have bought from you for years — are suddenly showing up as brand-new. ChatGPT Atlas launched October 21 2025, and within a week 27.7% of enterprises had at least one employee running it (Cyberhaven Labs, 2025). Atlas reports itself as Chrome 141 in the user-agent string, so GA4 can’t see it — and its Chrome import doesn’t carry your cookies.
And It’s Breaking More Than Just GA4
The cookie non-transfer is the headline story. The cascade is the one nobody has written about yet. The same broken identity layer that inflates your new-user count also drops your Meta Event Match Quality, reduces Google Ads Enhanced Conversions match rate, and quietly suppresses your WooCommerce lifetime value calculations. Every place your measurement infrastructure depends on a browser cookie persisting, Atlas breaks it.
Two things are worth saying upfront. The browser itself isn’t the problem — Atlas is a reasonable product built on Chromium, and there’s no conspiracy in how it imports data. The problem is that WooCommerce measurement stacks were built for a world where a returning customer always had cookies. That world is ending, and Atlas is the cleanest recent example.
Why returning customers suddenly look new
Two technical choices in Atlas combine to produce the symptom.
User-agent masking. Atlas reports its user-agent string as Chrome/141.0.7390.108. GA4’s browser classification is driven by the user agent, so Atlas sessions are bucketed with Chrome sessions in the Tech Details report. There is no out-of-the-box filter that separates them. As Dana DiTomaso at Kick Point put it after first-party testing: “Atlas shows up as Chrome. Not ‘kind of like Chrome’ — exactly like Chrome.”
Cookie non-transfer. When a Chrome user sets up Atlas for the first time, the import brings over bookmarks, saved passwords, and browsing history. It does not bring over cookies. Every site-specific cookie — _ga, _ga_<container>, _fbp, _gcl_aw, any first-party identifier your site had set over months or years — is gone. The user arrives on your WooCommerce store with a blank cookie jar. GA4 assigns a new client ID. Meta’s pixel sets a fresh _fbp. Google Ads has no gclid to recover.
The user is the same person who has shopped with you dozens of times. The browser is a stranger.
The symptom in your dashboard: an unexplained new-user bump starting late October 2025, gradually compounding as more people install Atlas. Returning-customer segments thin out. The returning-vs-new ratio drifts in the wrong direction without any real change in behaviour.
You may be interested in: ChatGPT Is Sending Traffic to Your WooCommerce Store and GA4 Cannot See It
How the same broken cookie breaks your Meta CAPI
GA4 is where you notice the problem. Meta is where it costs you money.
Meta’s pixel and Conversions API depend on a combination of first-party cookies (_fbp, _fbc), hashed user data (email, phone, name), and event_id deduplication to match a browser event to a real Facebook user. The higher the match quality, the more useful the event for Meta’s ad optimisation. Without consistent cookies, deduplication decays.
When an Atlas session triggers a WooCommerce purchase, here’s what Meta receives. The pixel fires with a freshly-minted _fbp that has never been associated with this customer. There’s no _fbc because there’s no click ID from a Facebook ad that was followed in Chrome. The hashed email might be present if your checkout collects it and your pixel is configured to send it — but the browser-side matching signals that usually do the heavy lifting are gone.
The event still fires. It just matches less well. How Meta’s Event Match Quality actually controls your ROAS is a longer story, but the summary is that a lower score means Meta’s bidding gets weaker signal, and your cost per purchase drifts up. Nobody in the Meta UI tells you Atlas is the reason. The EMQ number just quietly declines month over month.
How it breaks Google Ads Enhanced Conversions
Same mechanism, different destination. Enhanced Conversions improves Google Ads attribution by sending hashed user-provided data (email, phone) alongside the click ID. When the click ID is missing — which is what happens when an Atlas user arrives via a shared link that the browser’s internal sandbox stripped the referrer from — Enhanced Conversions has less to work with.
For stores that never collected the customer’s email at the ad-click moment and only capture it at checkout, the fallback is the first-party user-provided data layer. If that layer depends on cookies to persist identity across pages, Atlas breaks it.
Match rate is the number Google Ads shows you in the conversion diagnostics report, and it’s the number that determines how useful Enhanced Conversions actually is. Atlas sessions degrade that number without any visible cause. The conversions still happen. They just score worse when Smart Bidding uses them to train.
And it breaks your WooCommerce LTV model
This is the one nobody in the existing Atlas coverage mentions. Your WooCommerce reports — or the customer-segment analysis your ESP or CDP builds on top of WooCommerce — usually count “returning customer” by matching the email or customer ID in the order against the prior order history. That logic survives Atlas, because the customer still types the same email at checkout.
But the cohort reports, the retention dashboards, and the returning-vs-new metrics that live in GA4 or your marketing analytics tool generally don’t match on email. They match on client ID or user pseudo ID. Atlas fragments that ID. Your retention cohorts look worse than they actually are. Quarterly LTV calculations pulled from GA4 suggest your repeat-purchase rate is falling when it isn’t.
The same mechanism is already familiar from Safari’s 7-day ITP cookie expiry — a different cause, identical symptom. Your data just looks like the customer left and came back, except now you have two parallel identity-erasure vectors running at once.
Why server-side fixes this
The common thread across all four failure modes — GA4 inflation, Meta EMQ decay, Enhanced Conversions match rate decline, broken LTV — is the same architectural assumption. Measurement is riding on a browser cookie that may or may not exist. Once that assumption breaks, everything downstream breaks.
Server-side tracking on a first-party subdomain doesn’t share the assumption. When the identity cookie is set by your own server on a subdomain like data.yourstore.com, the browser treats it as first-party, and more importantly, the identifier that matters lives on your side of the connection. At WooCommerce checkout, the customer’s email is captured server-side, hashed, and used to re-establish identity for Meta CAPI, Google Ads Enhanced Conversions, and any other destination that accepts user-provided data — regardless of whether the browser’s cookie jar remembered the previous session.
Atlas can’t strip what was never in the browser.
How you actually do this
Transmute Engine™ is a first-party Node.js server that runs on your own subdomain and handles exactly this case: the WooCommerce order event is captured server-side via the inPIPE plugin, enriched with hashed user data at the source, and sent simultaneously to GA4, Meta CAPI, Google Ads, and BigQuery. The identity doesn’t depend on a browser cookie surviving the Chrome-to-Atlas jump, because identity is established at the checkout, not the browser. The same architecture handles the next gap that’s already arriving — when an AI agent does the buying instead of a human.
Key Takeaways
- Atlas reports as Chrome 141 in the user-agent string, so GA4’s browser report cannot isolate Atlas sessions without a custom dimension.
- Chrome’s cookies do not transfer to Atlas — every returning visitor starts with a blank cookie jar and shows up as new.
- The damage cascades: GA4 new-user inflation, Meta Event Match Quality decline, Google Ads Enhanced Conversions match rate drop, and broken cohort-based LTV reports.
- 27.7% of enterprises had Atlas within a week of launch (Cyberhaven Labs, 2025), and analyst projections estimate 25–100 million Atlas users in 2026 — the effect compounds monthly.
- First-party server-side tracking is architecturally immune to cookie non-transfer, because identity is re-established at the server at checkout, not inherited from the browser.
Frequently Asked Questions
ChatGPT Atlas launched October 21 2025. Every existing Chrome user who switched to Atlas appeared as a brand-new visitor the first time they opened your WooCommerce store, because Atlas’s Chrome data import does not carry over GA4 cookies. The traffic volume is the same; the visitors are the same people. They just lost their client ID at the browser boundary. If the jump correlates with that week, Atlas is the likely explanation.
Atlas breaks the identity layer that conversion tracking depends on. A returning customer opening your WooCommerce store in Atlas for the first time has no _ga, no _fbp, and no gclid in their browser. GA4 counts them as new, Meta CAPI deduplication weakens, and Google Ads Enhanced Conversions lose match-rate signal. Client-side tracking sees a blank slate. Server-side tracking that hashes the customer’s email at checkout can re-establish identity regardless of which browser they used.
Atlas’s user-agent string reports the browser as Chrome version 141.0.7390.108. GA4 reads the user agent to classify the browser, so Atlas sessions are bucketed with Chrome sessions in the Tech Details report. There is no standard GA4 filter that separates them unless you write a custom dimension based on a JavaScript check — which most WooCommerce stores don’t. Atlas is invisible by default.
Event Match Quality depends on how well your pixel and CAPI events match back to a real Facebook user using signals like email, phone, and first-party cookies. When Atlas fragments identity — no _fbp cookie, no persistent client ID, no referrer — each browser-side event carries weaker matching signals. Meta’s deduplication relies on event_id matching between pixel and CAPI, and without consistent cookies, that deduplication decays. The fix is sending CAPI events server-side with hashed user-provided data, so match quality doesn’t depend on what the browser remembered.
Yes. ChatGPT has 900 million weekly active users, and analyst projections estimate Atlas could capture 1–3% of browser market share in 2026 — roughly 25 to 100 million users. In March 2026 OpenAI announced Atlas, the ChatGPT app, and Codex would be unified into one desktop application, which accelerates Atlas installs via the existing ChatGPT user base. Every week that goes by, more repeat customers become new users in your dashboards.
If your GA4 new-user numbers have been drifting up for no good reason, Atlas is probably a piece of the answer. Treat browser identity as a liability, not infrastructure — start at seresa.io.