First-Party Cookies on Shopify: Customer Identity in a Post-Cookie World

TL;DR

Chrome has delayed third-party cookie deprecation multiple times, but Safari's Intelligent Tracking Prevention (ITP) has already made cross-site cookies largely useless for a significant slice of your traffic since 2020 [3]. Shopify's architecture puts your storefront and checkout on the same registrable domain, which means first-party session cookies survive where third-party ones would not. The practical move is to understand which identity signals Shopify gives you, make sure your tracking layer is actually reading them, and start attaching them to server-side events before browser restrictions tighten further.

What First-Party Cookies Actually Are on Shopify

First-party cookies are set by the same domain the customer is visiting. If your store is yourstore.com, a cookie set on yourstore.com is first-party. A cookie set by google.com or facebook.com loaded via a script tag is third-party, and that is what Safari blocks and Chrome is planning to restrict [3].

Shopify sets several first-party cookies during a session. The most attribution-relevant ones are:

• _shopify_y: a persistent visitor identifier, valid for one year, scoped to your domain.
• _shopify_s: a session-level identifier, expires after 30 minutes of inactivity.
• cart: the cart token, tied to the current cart object.
• _shopify_sa_p and _shopify_sa_t: source/attribution tracking cookies for the storefront.

These are set by Shopify's infrastructure when a visitor loads your storefront [1]. Because checkout at yourstore.myshopify.com or a custom subdomain like checkout.yourstore.com shares the same registrable domain (.yourstore.com), these cookies persist from browse to cart to thank-you page without any cross-site hop. That is the structural advantage Shopify merchants have over, say, a WooCommerce store that routes through a third-party payment gateway hosted on a separate domain.

How Shopify Stitches Identity Across the Funnel

The session token, customer ID, and cart token do not travel independently. Shopify ties them together at the server level.

Here is the sequence on a typical session:

1. Visitor lands. Shopify sets _shopify_y (visitor) and _shopify_s (session).
2. Visitor adds to cart. Shopify creates a cart_token, tied to the cart object in the API.
3. Visitor reaches checkout. If they are a returning customer and log in, Shopify resolves a customer_id and associates it with the session.
4. Order completes. The order_id is linked to customer_id, cart_token, and the originating session.

This chain is what makes Shopify's Customer Privacy API useful [1]. The API exposes these identifiers to your pixel layer in a consent-aware way. When you fire a server-side purchase event, you can include customer_id as a stable, first-party identifier that does not degrade with browser restrictions. It is not PII (personally identifiable information) exposed in the pixel. It is a server-resolved identifier passed securely in the event payload.

Shopify's Web Pixels API gives sandboxed browser-side access to analytics events including cart and checkout data [2]. The sandbox model means pixels cannot read arbitrary cookies or DOM data. They get a controlled event object. For full server-side attribution, you need a layer that reads these signals on the server and forwards them to GA4, Meta, or Google Ads. More on that in a moment.

Why Safari ITP Matters More Than Chrome's Cookie Deprecation Right Now

Chrome has announced third-party cookie deprecation at least twice without following through [3]. Safari ITP has been active since 2017 and fully blocks third-party cookies since 2020 [3]. As of 2024, Safari holds roughly 20% of global browser market share and over 50% on mobile in the US.

That means for a US-focused Shopify store, more than half your mobile sessions are already running under ITP. Any attribution signal that relies on a third-party cookie from Meta Pixel or Google Tag being readable in the browser has a material gap on Safari traffic today. Chrome's eventual changes will widen that gap across the remaining traffic.

First-party cookies on Shopify survive ITP because they are set by your domain, not a third-party script. But there is a catch: ITP caps first-party cookies set via JavaScript (document.cookie) at a 7-day expiry. Cookies set via HTTP response headers (server-set cookies) are treated more favorably. Shopify's core session cookies (_shopify_y, _shopify_s) are server-set, so they retain their full duration under ITP. Any cookie your GTM tag writes via JavaScript gets capped at 7 days on Safari.

Where the GTM Container Loses You

GTM's standard browser-side tags write cookies via JavaScript. That 7-day ITP cap applies directly to any client-side GA4 or Meta Pixel client_id or fbp cookie your tags create.

A customer who browses in week one and converts in week two on Safari: attribution lost. The client_id cookie expired. GA4 sees a new session. Meta sees no match. The conversion gets attributed to direct or not at all.

The fix is not to abandon GTM. The fix is to supplement browser-side tagging with server-side event forwarding that reads Shopify's server-set identity signals (customer_id, cart_token, session identifiers) rather than relying solely on JavaScript-written cookies. Those server-set signals are available on every order, regardless of browser.

For GA4, that means sending user_id (the Shopify customer_id) as a stable identifier alongside the standard client-side event. For Meta, it means using the Conversions API to send external_id (the same customer_id) along with hashed email, which Meta's matching algorithm uses for deduplication and attribution. You can read more about how custom dimensions fit into this GA4 data model in the WeltPixel guide to GA4 custom dimensions for Shopify.

What Changes When a Customer Checks Out via Shop Pay

Shop Pay introduces a wrinkle worth understanding. When a customer uses Shop Pay, the checkout experience can be accelerated and the session context can shift. The customer_id Shopify assigns is still first-party and still accessible server-side via the Order webhook. But the browser-side pixel firing sequence differs from a standard checkout.

Specifically, the checkout_complete web pixel event fires in the Shop Pay checkout environment, not your standard storefront. If your GA4 or Meta tracking depends entirely on a purchase event fired from a GTM tag on the thank-you page, you may see Shop Pay orders with incomplete or missing attribution, because the tag did not fire in the expected browser context.

The customer_id on the completed order is available via the Order webhook regardless of checkout method. That is the signal to anchor to. The WeltPixel breakdown of Shop Pay checkout tracking gaps covers the specific event sequence and where the standard pixel setup falls short.

Verify on Your Own Store: Check Whether First-Party Signals Are Reaching Your Tracking

Step 1: Confirm Shopify cookies are being set. In Chrome DevTools (F12), go to Application > Cookies > your domain. Look for _shopify_y, _shopify_s, and cart. If you are on a custom domain, these should be scoped to .yourdomain.com, not .myshopify.com. If you only see them on .myshopify.com and your storefront is on a custom domain, your subdomain configuration may be incomplete.

Step 2: Check whether your GA4 setup is reading customer_id. Go to Shopify Admin > Settings > Customer events. Look at which pixels are installed. If you only have the standard Shopify Google channel pixel (no server-side component), you are not passing customer_id to GA4. Verify in GA4 by going to Reports > Engagement > Events, clicking on purchase, and checking whether user_id appears in the event parameters. No user_id means you are missing the stable identifier.

Step 3: Check Meta Conversions API match quality. In Meta Business Manager, go to Events Manager > your pixel > Overview. Look at the "Event Match Quality" score for Purchase. A score below 6.0 typically means you are missing server-side identifiers like external_id or hashed email. If your Meta integration is browser-side only, this is expected and fixable.

Step 4: Spot the Safari attribution gap. In GA4, go to Explore > create a Free-form exploration. Dimension: Browser. Metric: Transactions. Compare Safari vs Chrome conversion rates. A Safari conversion rate that is materially lower than Chrome, without a UX reason, often signals attribution loss from ITP.

What to Do Today to Future-Proof Attribution

Third-party cookie deprecation on Chrome is still on the roadmap, even after multiple delays [3]. The direction is not reversing. The practical steps are not complicated:

Use server-set cookies, not JavaScript cookies, as your primary identifiers. Shopify's own session cookies qualify. Build your tracking around them rather than around document.cookie writes from GTM.

Pass customer_id in every purchase event. Server-side, as user_id in GA4 and external_id in Meta. This is a stable, first-party identifier that survives both ITP and any future Chrome changes. It also improves audience matching quality for retargeting.

Implement server-side event forwarding for at minimum your purchase event. Browser-side purchase tracking on Safari already has a gap. Server-side forwarding via the Order webhook fires regardless of browser, ad blocker, or cookie restrictions. For stores spending more than $3,000/month on paid channels, the attribution improvement from server-side purchase events typically justifies the setup effort within the first month.

Tie consent to your pixel firing, not as an afterthought. Shopify's Customer Privacy API [1] lets you gate pixel firing on consent status in a compliant way. If you are in a market with consent requirements, read the WeltPixel guide to Consent Mode v2 on Shopify before wiring up server-side events.

Key Takeaways

• Shopify's _shopify_y and _shopify_s cookies are server-set and survive ITP. Any cookie your GTM tags write via JavaScript gets capped at 7 days on Safari.
• Safari has blocked third-party cookies since 2020 [3], affecting 50%+ of US mobile traffic. Chrome's deprecation is still pending but directionally confirmed.
• The customer_id, cart_token, and session token form a first-party identity chain that Shopify resolves server-side on every order, regardless of browser.
• Shop Pay checkout can break browser-side purchase event firing. Anchor your conversion tracking to the Order webhook, not the thank-you page tag.
• Pass customer_id as user_id in GA4 and external_id in Meta Conversions API to use a stable identifier that does not depend on cookies.
• A Meta Event Match Quality score below 6.0 is a direct signal that server-side identifiers are missing from your purchase events.
• Server-side purchase event forwarding is worth implementing at $3,000+/month in paid spend. Below that, fixing browser-side tag firing on Shop Pay is the higher-value first step.

FAQ

What is a first-party cookie on Shopify?

A first-party cookie on Shopify is a cookie set on your store's own domain (e.g., yourstore.com) by Shopify's servers or your own scripts. Shopify automatically sets _shopify_y (visitor ID) and _shopify_s (session ID) as first-party, server-set cookies [1]. These are not blocked by Safari ITP, unlike third-party cookies set by external analytics or ad platforms.

Does Shopify's checkout share the same domain as the storefront?

Yes, and this is a meaningful advantage. Whether you use yourstore.myshopify.com or a custom domain like yourstore.com, Shopify routes checkout through the same registrable domain [1]. That means first-party session cookies set on the storefront are readable at checkout and on the thank-you page without a cross-domain cookie transfer.

Does Safari ITP block Shopify's own cookies?

Not the server-set ones. ITP targets JavaScript-written cookies (set via document.cookie) and caps them at 7 days. Shopify's core session cookies are set via HTTP response headers, which ITP treats as legitimate first-party cookies with their full expiry intact [3]. However, if you or a third-party script writes additional tracking cookies via JavaScript, those are subject to the 7-day cap on Safari.

What is the difference between _shopify_y and customer_id?

_shopify_y is an anonymous visitor identifier. It is assigned to every visitor, including guests, and persists for one year. customer_id is a Shopify account identifier, only assigned when a visitor has a customer account and is logged in or completes a checkout with account creation. For attribution purposes, customer_id is the more stable signal for known customers. _shopify_y covers anonymous sessions that customer_id cannot reach.

Do I need to change anything now, before Chrome deprecates third-party cookies?

Yes, because Safari's ITP is not a future event. It is already affecting your Safari traffic. The most impactful changes are: (1) confirming your GA4 setup passes user_id on purchase events, and (2) adding a server-side Conversions API connection to Meta that includes external_id and hashed email. Both of these use Shopify's first-party signals and improve attribution on Safari traffic starting the day you implement them.

Start Using Shopify's First-Party Signals in Your Tracking

WeltPixel Conversion Tracking reads Shopify's native first-party identity signals (customer_id, session_id, cart_token) and attaches them to server-side events forwarded to GA4, Meta Conversions API, TikTok Events API, and Google Ads on every plan (Explorer free with 100-order cap, and Plus at $39/month unlimited). Plus also adds multi-pixel support, server-side refund tracking, and admin/POS order events. That means your purchase events carry stable, first-party identifiers regardless of browser restrictions, ad blockers, or Shop Pay checkout flow variations.

If your current setup is browser-side only, you are already missing attribution on Safari. WCT's server-side layer closes that gap without requiring custom development.

Install WeltPixel Conversion Tracking

Sources

1. Shopify Customer Privacy API documentation. https://shopify.dev/docs/api/customer-privacy
2. Shopify Web Pixels API documentation. https://shopify.dev/docs/api/web-pixels-api
3. Privacy Sandbox: Cookie deprecation timeline and updates. https://privacysandbox.com/cookies/