GA4 Stopped Tracking Purchases After a Theme Change: The Usual Culprits
You ship a theme update or edit the checkout, and within a day or two the purchase numbers in GA4 go flat. Sessions still look normal. Add to cart still fires. But the revenue line drops to zero, or to a fraction of what your payment processor reports. Nothing in the interface tells you anything broke.
This is one of the most expensive silent failures in digital marketing, because your ad platforms optimize against the conversions they can see. When GA4 and your ad pixels stop recording purchases, Google Ads and Meta keep spending but lose the signal that tells them which clicks turn into buyers. The good news is that a broken GA4 purchase event fails in a small number of predictable ways, and each one leaves a fingerprint you can confirm in about ten minutes.
The five causes that account for almost every case
When the purchase event stops after a template or checkout change, the root cause is nearly always one of five things. A code edit removed the tag or the dataLayer push it depends on. The measurement ID changed and the tag now reports to nowhere. A Google Tag Manager trigger stopped matching. On Shopify, a checkout migration moved order events into the Customer Events sandbox where your old script cannot reach them. Or a consent banner started blocking analytics_storage before the tag could fire.
Here is how each cause shows up in GA4 and how to confirm which one you have.
| Cause | Symptom in GA4 | How to confirm |
|---|---|---|
| Theme edit removed the gtag call or dataLayer push | No purchase event at all in DebugView or Realtime | Complete a test order with DebugView open. If no purchase event arrives, the trigger source is gone |
| Measurement ID changed or was replaced | Purchase fires in tag assistant but never lands in this property | Compare the ID in the tag to Admin, Data Streams. A mismatch sends data to a different or dead property |
| GTM trigger no longer matches | Tag shows as not fired in GTM Preview on the confirmation page | Open GTM Preview, load the order confirmation, check whether the purchase tag is under Tags Fired |
| Shopify checkout moved to Customer Events | Add to cart still works, purchase is missing only on the thank you page | Check whether tracking lived in checkout.liquid or additional scripts, now deprecated |
| Consent Mode denies analytics_storage | Purchases drop sharply or show as modeled, not a clean zero | Inspect the consent state in GTM Preview. analytics_storage denied means events are throttled |
Start in DebugView and Realtime before touching any code
Do not guess. Reproduce the failure first. Install the Google Analytics Debugger browser extension or use GTM Preview to put your session into debug mode, then open GA4 Admin, DebugView and place a genuine test order end to end.
Watch what arrives. If you see the full event stream including add_to_cart and begin_checkout but no purchase on the confirmation page, the failure is isolated to the final step, which points at the checkout template or the Shopify Customer Events migration. If nothing from your session shows up at all, debug mode is not connecting and you have a measurement ID or container problem higher up. Realtime is a coarser backup: it lags more and aggregates data, but if a purchase never appears there either, the event is genuinely not reaching this property.
DebugView is where you confirm not just that the event fired, but that it carried the right data. A purchase event with no revenue is often mistaken for no purchase at all.
The ecommerce parameters that must be present
A GA4 purchase event is only useful if it carries the ecommerce payload. The event name has to be exactly purchase, and it needs these parameters populated:
value: the order total as a number, not a string with a currency symbolcurrency: a three letter ISO code such as USD, required for GA4 to attribute revenuetransaction_id: a unique, stable order identifieritems: an array of the products purchased, each with item_id or item_name
If currency is missing, GA4 often drops the revenue even when the event itself is recorded, which produces the maddening case of purchase counts that look right and a revenue column stuck near zero. If items is empty, your product performance and shopping reports go blank while the top line still moves. Click the purchase event in DebugView and read the parameters directly. Half of the tracking failures we see are not missing events at all. They are events firing with a broken or partial payload because a template edit changed how the order data was assembled.
Why the Shopify checkout is its own problem
If you are on Shopify, the theme change may not be the real story. Shopify has deprecated the old customization points, checkout.liquid and the additional scripts fields, in favor of checkout extensibility. Any purchase tracking that lived in those places stops running once your store migrates. The order still completes, the customer still sees a thank you page, but the script that used to fire your purchase event is simply gone.
The current path is the Customer Events system, also called the Web Pixels API, where you subscribe to standard events like checkout_completed inside a sandboxed pixel and forward them to GA4 and your ad platforms. This is a different model from dropping a snippet into a template, and code that worked for years will not survive the migration untouched. We cover the migration in depth in Shopify checkout extensibility and what it breaks in your tracking, because it is the single most common reason a healthy Shopify store loses its purchase data overnight.
Consent Mode can look exactly like a broken tag
If a consent banner went live around the same time, look there before you rewrite any tracking. Under Consent Mode v2, GA4 reads four signals: ad_storage, analytics_storage, ad_user_data, and ad_personalization. When analytics_storage is denied, GA4 does not record full events. It sends cookieless pings that feed modeled conversions instead of the clean, deterministic purchase rows you are used to seeing.
The result looks like a tracking failure because your recorded revenue drops, sometimes steeply, even though the tag is technically firing. Confirm it in GTM Preview by inspecting the consent state on the page: if analytics_storage reads denied by default and your banner never flips it to granted, or flips it too late, that is your cause. This is a configuration decision, not a bug, but it has the same effect on your numbers. If you also run Google Ads, the same denied signals degrade Enhanced Conversions, which rely on hashed first-party data being allowed through.
Deduplicate transaction_id or you will overcount revenue
The opposite failure is just as costly. Once you fix a missing purchase event, watch for the mirror-image problem of revenue that reads too high. This almost always comes from the same order being counted more than once, usually because a customer refreshes or bookmarks the confirmation page and the event fires again.
GA4 deduplicates purchases that share the same transaction_id, so as long as every purchase event carries a stable, unique order ID, a refresh will not double your revenue. The danger is a transaction_id that is missing, empty, or regenerated on each page load, because then GA4 treats every fire as a distinct sale. This is also the field that keeps GA4 aligned with the Meta Pixel and Meta Conversions API, where a shared event_id plus event_name deduplicates the browser and server versions of the same Purchase event. One consistent order identifier flowing through every system is what keeps your reported revenue honest. If your numbers already look inflated, that is often a symptom of a wider break, and our conversion tracking audit guide walks through catching it across every platform at once.
Find out what your tracking is hiding
A flat revenue line in GA4 is rarely the whole problem. When the purchase event breaks, the same edit usually breaks the Meta Pixel, the Conversions API, and your Google Ads conversion actions at the same time, which means every campaign you are running is optimizing on incomplete data. The cost is invisible until you reconcile GA4 against your actual payment records and find the gap. If your purchase numbers stopped making sense after a theme change, checkout migration, or consent update, our conversion tracking repair service traces every event from click to confirmed order and fixes the break at its source, so your ad platforms are optimizing on real sales again.
FAQ
Why did GA4 stop tracking purchases after a theme change?
A theme or checkout edit almost always removed the code that fires the purchase event, either a dataLayer push that Google Tag Manager listens for or a direct gtag call. Custom themes and checkout templates frequently hardcode tracking that gets wiped when the template is replaced or updated. Confirm it by completing a real test order and watching GA4 DebugView for a purchase event that never arrives.
How do I check if the GA4 purchase event is firing?
Open GA4 DebugView, enable debug mode with the Google Analytics Debugger extension or GTM Preview, then place a test order. If the purchase event appears with value, currency, transaction_id, and items populated, tracking works. If it is missing or arrives with empty parameters, the event is either not firing or firing without ecommerce data.
Why is GA4 showing purchases but the revenue is wrong?
Duplicate or inflated revenue usually means the purchase event fires more than once for the same order, often because a customer refreshes the confirmation page or the event exists in two places at once. GA4 deduplicates purchases that share the same transaction_id within a short window, so a missing or changing transaction_id lets every page view count as a new sale. Send a stable transaction_id on every purchase event to prevent this.
Does Consent Mode stop GA4 from recording purchases?
Yes. When analytics_storage is set to denied under Consent Mode v2, GA4 sends cookieless pings that are modeled rather than recorded as full events, which can make purchases appear to vanish or drop sharply. If a consent banner change coincided with the tracking loss, that is a likely cause. Check the consent state in GTM Preview or the tag assistant to see which signals are being denied.