Problem
GA4 purchase event not firing: how to fix it
When the purchase event stops, every ecommerce report goes quiet while the store keeps taking orders, so the failure is invisible unless someone is watching. The event has to be created on the order confirmation, carry the right parameters, and reach the right property. Follow it in that order, because each stage fails in a different way and produces the same empty report.
By CartKernel · Last reviewed 2026-09-07
Does this look familiar?
- Ecommerce reports show sessions and add to cart events but no purchases
- The realtime view never shows a purchase even when an order has just been placed
- Purchases are recorded but with no revenue value or no items
- The event appeared in the debug view during testing and never in the reports
- Purchases stopped on the day a checkout, theme or tag container change went live
- Some payment methods produce a purchase event and others do not
Causes, ranked
Why it happens, most common first
Check them in this order. The first two account for most cases we open.
- most common
The tag does not run on the order confirmation step
Modern checkouts are separate applications that do not load storefront scripts, so a tag installed on the theme never reaches the page where the order completes. The event has to be added through the platform's customer event or pixel mechanism instead of a template edit.
- most common
The event is pushed before the container is ready
When the data layer push happens before the tag manager container loads, or the tag fires on a trigger that has already passed, the event is created and lost. Single page checkouts make this worse because there is no fresh page load to fall back on.
- common
Required parameters are missing so the event is ignored
An ecommerce purchase needs a transaction identifier, a numeric value, a currency code and an items array. Sending a value as a formatted string with a currency symbol, or omitting the currency, produces an event that arrives but does not populate the revenue reports.
- common
Consent is defaulting to denied and never updated
With consent controls in place the tag waits for a signal. If the banner blocks the script outright, or the update never fires because the visitor closed the banner rather than choosing, the purchase is never sent. Region specific defaults mean this can affect only part of your traffic.
- occasional
The event goes to the wrong property or stream
A measurement identifier copied from a test property, a second container left in place after a migration, or a stream created for a staging domain will all accept events silently. Everything looks correct in the browser and nothing arrives where you are looking.
- occasional
The confirmation page is skipped or replaced
Wallet payments, buy now pay later flows and some payment providers can return the customer to a different page, or to no page at all if they close the window after paying. Any implementation that depends solely on a confirmation page view will miss those orders.
The fix
In this order
Each step is something you can do today. Do them in sequence; skipping ahead is how a review fails twice.
Prevent it next time
- Keep the purchase implementation in the platform's supported checkout mechanism, not in theme files
- Include an order confirmation tracking test in the checklist for every release
- Alert on a day with no purchase events so a silent failure surfaces immediately
- Document which container, which property and which stream own the purchase event
Confirm whether the event exists at all
Place a test order and watch the debug view while you do it. If no purchase appears, the event is not being created. If it appears in debug but not in reports, the problem is the destination or the parameters rather than the trigger.
Install through the checkout mechanism the platform supports
Use the platform's customer events or pixel sandbox to subscribe to the completed checkout event, and build the purchase payload from the data that event provides. Avoid template edits, which do not run inside the checkout and are removed by upgrades.
Validate every parameter on the payload
Check that the transaction identifier is unique per order, the value is a number without a currency symbol, the currency is a three letter code, and each item carries an identifier, a name, a price and a quantity. Correct the payload at the source rather than patching it in the tag.
Fix the sequencing between the data layer and the tag
Ensure the container loads before the purchase is pushed, or push into a queue that the container drains when it initialises. Where the checkout is a single page application, trigger on the event itself rather than on a page view.
Verify the destination identifier
Read the measurement identifier actually in use on the confirmation step and compare it with the one on the property you are reporting from. Remove any second container or duplicate tag left behind from a previous setup.
Test a denied consent journey deliberately
Decline the banner and place another test order. If nothing is sent at all, the consent tool is blocking rather than signalling. Reconfigure it so the tag loads in a waiting state and receives an explicit signal in both directions.
Cover the payment methods that behave differently
Repeat the test with each accelerated wallet and any deferred payment option the store offers. Where a method does not reliably return to a confirmation step, send the purchase from the order record on the server instead of relying on the browser.
Add a monitor so the next break is noticed
Create an alert on the property for a day with zero purchase events, and check the ecommerce report against store orders weekly. A tracking break found in a day costs far less than one found at the end of a quarter.
When to get help
Bring in help when the store uses a headless front end, a custom checkout, or a payment flow that leaves the site and does not reliably come back, because in those cases a browser event is the wrong mechanism and the purchase should be sent from the server against the order record. Help is also worth it when consent requirements differ across the regions you sell in, since the configuration has to satisfy each of them without silently discarding measurable traffic.
Free. We reply within one business day.
Can I send the purchase event from my server instead of the browser?
Yes. A server side implementation sends the event from the order record, which makes it independent of browser behaviour, blocking extensions and whether the customer returns to a confirmation page. It needs a client identifier passed through so the purchase joins the right session, which is the part most implementations get wrong.
Why does the debug view show the purchase but the reports stay empty?
Standard reports process on a delay, so wait a day before concluding anything. If it still shows nothing, the likely causes are a missing or malformed value and currency, a filter on the property excluding internal traffic that matches you, or events arriving at a different property than the one you are viewing.
Do I need a data layer if the platform integration handles ecommerce?
Not for a basic purchase, since the official integration builds the event for you. A data layer becomes worthwhile when you want consistent item data across several tools, custom parameters such as margin or product line, or a single definition that survives changing which vendors you send data to.
Will a duplicate purchase event be counted twice?
The transaction identifier is what distinguishes one order from another, so events repeating the same identifier are handled as the same purchase. Events with different identifiers for one order are counted separately. Making the identifier unique and stable per order is what prevents both kinds of error.
Services that fix it for good
Related problems, answers and terms
Stop the leak.
A free Growth Analysis finds what is broken and ranks it by the revenue it costs you.