Google Analytics 4 for Shopify Stores Designed in Framer

Setting up Google Analytics 4 for Shopify on a Framer-built storefront takes two tracking paths, not one. You fire the catalog and cart events yourself from the Framer side, let Shopify's own GA4 channel record checkout and purchase, then reconcile the two with a shared client ID so one shopper stays one user. Skip the third step and your funnel splits in half.

The reason is structural. Shopify's native Shopify GA4 setup is built on the Web Pixels API, which emits fifteen standard events from pixels loaded inside Shopify's own sandbox. That sandbox lives on pages Shopify serves. A Framer product page is served by Framer, so no Shopify pixel is present to emit product_viewed when a shopper lands on it. The checkout handoff is the moment a shopper leaves your Framer domain for Shopify's hosted checkout, and it is the exact seam where tracking ownership changes hands.

Which GA4 events have to fire from the Framer side?

Every event before the checkout handoff is yours. Google defines seven recommended ecommerce events for the standard purchase flow, and a Framer + Shopify build splits them cleanly down the middle: four belong to your Framer pages, three belong to Shopify's checkout.

Read the table as an ownership contract. The four rows marked you will never appear on their own, no matter how correctly the Shopify side is configured, because nothing on a Framer page is listening. That is the whole of the gap, and it is also why Shopify conversion tracking can look healthy in the Shopify admin while GA4 shows a funnel that starts at checkout.

How do you set up Google Analytics 4 for Shopify on a Framer build?

Install gtag.js once, then send the four Framer-side events by hand. In Framer, add your GA4 tag to the site's custom head code so it loads on every page, then call gtag('event', ...) from the components that already know the product data. A product page component that receives a product object has everything view_item needs: item ID, name, price and currency.

The cart is the one that catches people out. If your cart is a Framer overlay rather than a route, there is no page change to hang the event on, so add_to_cart has to be called in the same handler that adds the line item. If you are pairing Framer with Shopify through FramerLink, that handler is the component's add-to-cart action, and it is the right place for both the Shopify mutation and the GA4 call.

Leave checkout alone. Connect Shopify's Google & YouTube channel and let it own begin_checkout, add_payment_info and purchase. Rebuilding those from scratch means fighting the sandbox for data Shopify already sends, and it is the fastest way to double-count revenue. The headless architecture split is worth internalising here: the frontend is yours, the checkout is Shopify's, and analytics has to respect the same line.

Why don't GA4 sessions match across your Framer domain and Shopify checkout?

Because they are different domains, and GA4 treats them as different people until you tell it otherwise. Your Framer site runs on your own domain; Shopify's checkout runs on Shopify's. Without cross-domain measurement configured, Google is explicit about the outcome:

"two users and two sessions instead of one user and one session"

— Google Analytics Help, on cross-domain measurement

The fix is to list both domains in your GA4 data stream's cross-domain settings so the client ID rides along in the _gl parameter on the handoff link. Do this before you spend a day debugging event names, because an unstitched session makes correct events look broken: the purchase lands under direct traffic, and the view_item that preceded it sits in a separate session attributed to your real acquisition channel.

Privacy limits bite in the same place. Safari's Intelligent Tracking Prevention caps client-side cookies at seven days, so a shopper who browses on Monday and buys three weeks later arrives as a new user regardless of how clean your tagging is.

What Shopify checkout extensibility changed

The old workarounds are gone. Shopify sunset checkout.liquid and additional scripts on the Thank you and Order status pages on August 28, 2025, and script tags on those pages follow for non-Plus stores on August 26, 2026. Pasting a GA4 snippet into the order status page is no longer an option, which is precisely why the purchase event now has to come from Shopify's channel or a custom pixel.

Shopify checkout extensibility is not the villain here, though. It is the reason the checkout half of the table is reliable at all: the events are standardised, sandboxed and maintained by Shopify rather than by whoever last edited a theme file. The cost is that you cannot reach into checkout to patch a missing catalog event, so the Framer side has to be right on its own.

How much mismatch is normal?

Some gap is unavoidable. Littledata's audit of Shopify stores found that 20 out of every 100 orders fail to appear in Google Analytics on a default setup, driven by shoppers leaving before the Thank you page renders, blocked scripts and consent declines. That figure is a ceiling for a broken install, not a target.

A healthy Framer + Shopify build should land much tighter. Compare GA4 purchase count against Shopify's order count for the same date range weekly, and treat a persistent gap above roughly ten percent as a tracking fault rather than a privacy tax. If the gap sits in the catalog events instead, the cause is almost always a Framer component that never got its gtag call, and the guest checkout handoff is where to look first, since that is the moment the shopper leaves your domain.

Build the event map before you build the dashboard. Four events on your side, three on Shopify's, one client ID holding them together.