You open Google Analytics 4 and see something exciting: several new purchases and a significant jump in revenue.
Then you check Shopify, WooCommerce, your CRM, payment processor, or another backend system.
Those orders don’t exist.
So where did the GA4 purchases come from?
This can be alarming, particularly when GA4 reports thousands of dollars in revenue that your business never actually received. But GA4 isn’t an accounting system. It records the events that are sent to it.
If something sends a purchase event to GA4, GA4 has no way of independently knowing whether an actual financial transaction occurred.
That’s why GA4 can sometimes report purchases that never happened.
Here are the first things I would investigate.
1. Check the Transaction IDs
Start with the transaction_id parameter.
Every legitimate ecommerce purchase should have a unique transaction ID that corresponds to an actual order in your ecommerce or backend system.
Compare the transaction IDs reported in GA4 with the orders in your source-of-truth system.
You may discover:
- Transaction IDs that don’t exist in your backend
- The same transaction ID appearing multiple times
- Test transaction IDs
- Missing transaction IDs
- Unexpected transaction ID formats
This comparison can quickly tell you whether GA4 is receiving legitimate purchase events or something else.
2. Check for Duplicate Purchase Events
A common ecommerce tracking problem is firing the purchase event more than once.
For example, a customer might refresh the confirmation page, return to it later, or trigger multiple mechanisms that send the same purchase.
You might also have purchase tracking implemented in multiple places.
Perhaps you have:
- A GA4 purchase tag in GTM
- Ecommerce tracking built into your website platform
- A plugin sending GA4 ecommerce events
- Server-side tracking
- Another integration sending events
If two systems report the same purchase independently, your GA4 revenue can become inflated.
Don’t just ask whether the purchase tag fired.
Ask how many different systems are capable of sending a purchase event.
3. Look for Measurement Protocol Events
Not every GA4 event comes directly from someone’s browser.
GA4’s Measurement Protocol allows events to be sent directly to Google Analytics from servers and other systems.
That’s extremely useful for server-side and offline measurement.
It also means that when mysterious events appear, you need to consider whether another system is sending them.
If your organization uses Measurement Protocol, identify:
- Which systems can send GA4 events
- Which events they send
- How transaction IDs are generated
- Whether test systems use the production GA4 property
- Whether old integrations are still active
An implementation that looks perfect in GTM doesn’t rule out another source sending events directly to GA4.
4. Check Your Testing Process
Test purchases have an unfortunate habit of ending up in production analytics.
Developers, agencies and marketers may test checkout flows while working on the website.
If those tests send events into the production GA4 property, GA4 will happily record them.
This is particularly worth investigating when you see strange transaction values, unusual products, repeated transaction IDs, or sudden purchases during development work.
Your analytics environment should have a clear process for separating testing from production measurement.
5. Inspect GTM and Website Changes
If phantom purchases suddenly started appearing, ask an important question:
What changed?
Look at recent changes to:
- GTM tags
- GTM triggers
- Ecommerce plugins
- Checkout pages
- Website releases
- Server-side tracking
- Consent configuration
- Third-party integrations
A sudden measurement problem often has a corresponding implementation change.
Knowing that a GTM container changed on the same day that purchase numbers became abnormal can dramatically reduce the time required to troubleshoot the issue.
6. Compare GA4 Against Your Source of Truth
For actual revenue, GA4 should not be your accounting system.
Your ecommerce backend, order management system, CRM, or payment system is generally the source of truth for completed transactions.
GA4 serves a different purpose.
It helps you understand how users arrived, what they did, and how marketing activity contributed to conversions.
Some differences between systems are expected.
But large unexplained discrepancies deserve investigation.
For example, if your backend shows 100 orders and GA4 shows 103 purchases, you might investigate but not necessarily panic.
If your backend shows 100 orders and GA4 shows 160 purchases, you likely have a measurement problem worth finding.
Follow the Purchase Event Backward
When GA4 reports purchases that don’t exist, don’t start by staring at the GA4 revenue report.
Follow the event backward:
GA4 purchase → transaction ID → event source → tag/integration → checkout → actual backend order
The goal is to identify exactly where the reported transaction entered the measurement system.
This approach is much more effective than simply asking:
“Why is GA4 wrong?”
GA4 may be accurately recording exactly what your implementation told it happened.
The real question is:
Why did your implementation tell GA4 that a purchase occurred?
Trust Requires More Than Collecting Data
Analytics quality isn’t simply about whether data is flowing.
Bad data can flow perfectly.
A broken implementation that stops sending purchases is relatively easy to notice.
An implementation that continues sending purchases — but sends incorrect ones — is potentially more dangerous because the reports still look believable.
That’s why ecommerce measurement should be regularly validated against actual business outcomes.
GA Auditor is being built around this broader idea of measurement confidence: auditing your GA4 implementation, checking important ecommerce signals, and monitoring changes that could affect the quality of your analytics data.
Because seeing revenue in GA4 is useful.
Knowing you can trust that revenue is far more important.