How to Set Up GA4 on Shopify Without Losing Data

You open GA4 to compare this year's peak week against last year's. The rows are not wrong. They are empty. The detail was deleted months ago because nobody changed a dropdown on the day the property was created.

That is the part nobody warns you about with how to set up GA4 on Shopify. Installing the tag is the easy half. The hard half is a short list of settings that apply forwards only, and no support ticket recovers what they cost you.

So this guide runs in order of irreversibility, not in the order the setup wizard walks you through. Configure, install, verify. Do it that way and next year's report still means something.

Which GA4 decisions can never be fixed retroactively?

Sort every setting before you touch anything. The permanent ones are cheap on day one and expensive on day two hundred.

The pattern: anything that touches collection or counting is forwards only. Anything cosmetic is free.

• Retention is the one that bites. The default keeps less than most merchants assume. Nobody notices until an exploration across a full year comes back blank.
• Timezone drives every daily total. If it does not match the timezone finance uses, every daily reconciliation is off by a few hours of orders, forever.
• Currency is a display decision with permanent consequences. Pick the currency you report the business in, not the one your busiest market charges in.

How do you create the property and stream so the data is still readable in a year?

This is the configuration pass. No Shopify work yet, and no events arriving while you do it.

1. Create the property under the account that will still own it after any agency change. Name it for the store and domain, not for a project.
2. Set the reporting timezone to the one finance already uses. Write it down where the team can see.
3. Set the reporting currency to your accounting currency. On a multi-currency store the currency you charge in and the one you report in need not agree, so choose deliberately.
4. Raise data retention to the longest option available, then reopen the screen to confirm it stuck.
5. Choose the reporting identity and record it with a date, so a future analyst can explain any step change.
6. Create one web data stream for the storefront domain. One stream. Extra streams are the most common cause of doubled sessions.
7. Define internal traffic filters for your office, home and agency, and set them active rather than testing.
8. Copy the measurement ID into a note. You need it once, in the next section, and never again.

Steps four through seven cannot be backdated. If you are interrupted, be interrupted after them.

How to set up GA4 on Shopify without editing the theme

Install through Customer Events. Shopify's Web Pixels API runs your code in a Lax or Strict sandbox with controlled APIs per Shopify's Web Pixels API documentation, and that sandbox is what lets one subscription cover the storefront, the checkout and the thank you page.

A theme snippet cannot do that. Checkout is not your theme. Snippet installs give tidy sessions, healthy page views and no purchases, the worst failure mode of all because everything looks alive.

1. Open Settings, then Customer events in the Shopify admin and add a custom pixel.
2. Name it plainly, for example GA4 web, so the next person knows what it does.
3. Load the Google tag with your measurement ID, then subscribe to the customer events you need.
4. Map each Shopify event to its GA4 counterpart explicitly. Do not assume the names line up.
5. Set the pixel's privacy permissions to match how your consent banner classifies analytics.
6. Save, then connect the pixel so it runs.

One consequence to hold onto: the sandbox cannot reach the parent page, so anything you used to read off window is gone.

Which ecommerce events matter, and which parameters must ride along?

Six events carry almost all the value. Send those properly first. A partial event is worse than a missing one, because it looks like data.

• items is not optional. Without it your product report is empty while revenue looks fine, and you will not notice for a month.
• value and currency travel together. A value with no currency code is a number GA4 cannot bank.
• transaction_id must be the real order identifier, stable and unique, taken from the order rather than generated in the browser.
• Send tax and shipping as their own parameters rather than folding them into value, or your average order value quietly inflates.

Item-level detail is the only reason to run ecommerce tracking rather than a revenue total. Send it.

How do you mark key events so conversion counts stay comparable over time?

A key event is a flag, not a recalculation. GA4 counts from the moment you set it, so every period before that date reports zero conversions even though the events are sitting right there. This belongs in the configuration pass, not in month three.

1. Send one real test purchase so the purchase event exists.
2. Open Admin, then Events, find purchase and mark it as a key event.
3. Set its counting method deliberately. Once per session and once per event answer different questions.
4. Stop there. Mark nothing else in week one.
5. Record the flag date in the same note as your other permanent choices.

The temptation is to flag six events so the dashboard looks busy. Resist it. Every extra key event dilutes the number you steer the business by, and un-flagging later leaves a second step change.

• One primary key event per property. For a store that is purchase.
• Secondary flags come after a quarter of clean data, once you know which upper-funnel action predicts a sale.
• Never re-flag to fix a reporting gap. It creates a discontinuity rather than filling one.

How do you keep checkout from starting a fresh session and stealing the source?

This failure costs the most money and is the hardest to see. A shopper arrives from a paid campaign, browses, then moves to checkout. If GA4 treats that hop as a new visit, the session restarts and the purchase is attributed to a referral from your own store.

Paid campaigns look weak. Direct and referral look strong. Budget follows the wrong numbers.

1. In your web stream's tag settings, open Configure your domains.
2. Add every domain the shopper legitimately crosses, including checkout.
3. Add the same domains to your unwanted referrals list so they cannot open a session.
4. Confirm your pixel is subscribed to checkout events, not only storefront ones.
5. Place a real order and watch DebugView from landing to thank you page. It should be one session with one source.

Session continuity is also why browser storage matters. Safari deletes all script-writable storage after seven days of Safari use without interaction on the site as documented by WebKit. A long consideration window loses its origin story whatever you configure. If that describes your customers, read server-side tracking versus the pixel.

How do you prove it works in DebugView before anyone builds a report on it?

DebugView shows events as they land, so verification is a fifteen minute job, not a next-day wait.

1. Enable debug mode in your browser and confirm your device appears in DebugView.
2. Load a product page. Expect view_item with populated items.
3. Add to cart, then begin checkout. Watch each event arrive in order.
4. Complete a real order with a discount code that takes it to a low value.
5. Open the purchase event and read every parameter: transaction_id, value, currency, items.
6. Confirm the journey stayed inside one session with one source.
7. Refund the test order, then check the refund event.

Here is what a broken build looks like.

• Storefront events arrive and purchase never does. The pixel is not seeing checkout. Almost always a theme install.
• purchase arrives with a value but no items. The item array is not being built. Revenue reports fine, product reports stay empty.
• A second session begins at checkout. Your domain configuration is incomplete.
• Two identical purchase events land together. Something is measuring twice. Find it now, not after a month of inflated revenue.
• Nothing appears in DebugView. Debug mode is off, or your internal traffic filter is doing exactly what you asked it to.

Only after all seven pass should anyone build a dashboard on this property.

Where does Trackproof stop and GA4 configuration begin?

Trackproof handles delivery. It sends your Shopify events from the server with the identifiers intact. It does not set your retention window, choose your reporting identity or decide which event deserves a key event flag. Nothing can. Those are business decisions dressed as dropdowns.

Plenty of tools imply the configuration comes free with the install. It does not. Everything above the DebugView section is yours to own, whichever tool you use.

• Configuration is the hour of work here. Do it once, correctly, on day one.
• Delivery is the ongoing problem. Blocked scripts, closed tabs and short storage windows erode client-side collection every month, which is what server-side tracking addresses.
• Trackproof is free and has no reviews yet on the Shopify App Store, so judge it on your own test order, not on our word.

If you would rather buy a long review history, Littledata shows 4.8 stars from 124 reviews and Elevar 4.6 from 137 Littledata Elevar. Both cost real money: Littledata Scale is $199 a month up to 1,500 orders, Elevar Core $225 a month up to 2,000. For some stores that is the right trade. Either way, get the configuration right first. No tool fixes a property that was configured after the traffic arrived.

Pricing and features checked on 22 August 2026. App Store listings change without notice, so verify on the listing before you commit to a plan.