Repairing GA4 Ecommerce Attribution

5-7 minute read.

Modern ecommerce analytics stacks are deceptively fragile. Dashboards can appear healthy, events can be firing and revenue can look “about right” at a glance. Meanwhile, underneath, attribution logic is fundamentally broken. This case study documents a recent real-world scenario in which an ecommerce business believed its Google Analytics 4 (GA4) purchase tracking was broadly working, only to discover that nearly all revenue appeared to be attributed to paid media, email underperformed mysteriously and true channel performance was obscured.

What followed was a *deep* technical investigation across GA4, Google Tag Manager (GTM), WooCommerce, a third-party payment gateway and of course Google Ads. The outcome was not only a repaired tracking setup, but a repeatable framework for diagnosing and fixing GA4 ecommerce attribution issues without replatforming or rebuilding the site.

This case study is anonymised, but all technical steps, logic, and testing procedures are real and transferable.

Background and Context

Our client operated a WooCommerce-based ecommerce site serving a mix of B2B and B2C audiences. Transactions were a mix of direct, organic search, email marketing and paid Google Ads activity. GA4 had long since replaced Universal Analytics and Google Ads conversions were imported from GA4 to support bidding and Return On Ad Spend (ROAS) reporting.

On the surface, everything looked operational:

• GA4 showed purchase events.
• Google Ads showed conversions.
• Orders were completing successfully in WooCommerce.

However, various commercial instincts flagged that something was off.

Symptoms Observed – Do these sound familiar to you?

The first red flag was attribution imbalance. Google Ads appeared to be responsible for an implausibly high proportion of revenue. Email campaigns showed healthy click activity but little visible conversion impact. Organic search appeared weak relative to known demand.

In GA4, purchase events were visible, but revenue figures were inconsistent or missing in some reports. Transaction IDs were absent in others. Realtime reports contradicted historical views. Debug tools showed events firing, but without reliable monetary context.

Most dangerously, there was no single, obvious error. The system looked “mostly fine”, which is exactly how attribution failures hide.

The working assumption was that GA4 purchase tracking existed but was misconfigured. The challenge was to determine whether the problem lay in GA4 event configuration, GTM tags / triggers / variables and related logic, WooCommerce order context, the payment gateway return flow, or Google Ads conversion setup.

The investigation therefore followed the full lifecycle of a purchase, from checkout click to final attribution…. several times!!!

Root Cause Analysis

The first discovery was that multiple definitions of “purchase” existed simultaneously.

Within GTM, there were pageview-based purchase triggers, regex-based ecommerce triggers, multiple GA4 purchase tags (some paused, some active), and legacy logic retained from earlier iterations, going back several years and from several incumbent agencies.

This alone made deterministic behaviour impossible. A purchase could fire before checkout completed, on a generic thank-you page, or without order confirmation.

However, removing duplication alone did not solve the revenue issue.

Loss of Order Context

The deeper problem lay in WooCommerce order context. Instead of using WooCommerce’s native order confirmation endpoint (/checkout/order-received/), customers were being redirected directly to a custom thank-you page. This broke the “chain of truth”. WooCommerce only knows the order ID, transaction value, tax, shipping, and item details when the order-received endpoint is loaded with the appended order key.

By bypassing this endpoint, GA4 was being asked to record a “purchase” at a moment when no order actually existed in scope. As a result, cart data was available, order data was not, and revenue and transaction IDs were missing or unreliable. In short: a purchase event was firing without a purchase.

Reintroducing the Source of Truth

The solution was to reintroduce WooCommerce’s order-received endpoint into the flow. The payment gateway was allowed to return to the default WooCommerce success URL, restoring full order context.

At that moment, the dataLayer began to contain a complete ecommerce object, including transaction_id, value, currency, tax, shipping, and item-level detail.

Critically, this ecommerce object was pushed alongside a dataLayer event explicitly named “purchase”.

Correcting the GTM Architecture

With a clean dataLayer signal now available, GTM could be simplified dramatically. The revised architecture enforced a single rule: a purchase exists only when a purchase event is pushed, which sounds obvious but it wasn’t the case prior to this point.

All pageview-based and regex-based purchase triggers were deleted. All legacy GA4 purchase tags were removed. One trigger remained: a Custom Event trigger where event equals “purchase”.

One GA4 Purchase tag remained, configured with event name “purchase”, sendEcommerceData set to true, data source set to dataLayer, and no manual parameter overrides. This ensured GA4 consumed exactly what WooCommerce emitted, with nothing added or removed.

Testing and Validation Framework

With the plumbing corrected, rigorous testing followed!

First, dataLayer inspection confirmed that at the moment the purchase event fired, the ecommerce object contained correct transaction ID, accurate revenue value, tax and shipping, and item array.

Second, the GTM preview confirmed the purchase tag fired once; fired only on the purchase event; and did not fire on checkout or page load.

Third, GA4 DebugView showed purchase events with full parameters and consistent transaction IDs.

Finally, attribution testing was performed.

A non-paid, direct purchase was completed. GA4 recorded the purchase and Google Ads recorded zero conversions.

A paid Google Ads click was then tested. GA4 recorded the purchase, Google Ads recorded exactly one conversion, and the transaction ID matched.

This absolutely proved that Ads attribution was no longer being inflated by tracking logic.

Outcomes

Once corrected, the impact was immediate and obvious! Revenue reporting in GA4 stabilised. Email campaigns began to show measurable contribution. Organic search regained credibility. Google Ads performance metrics normalised, allowing bidding decisions to be made with confidence, for example, by recording accurate order values when (and only when) orders were placed by someone having initially arrived via a Google ad.

Perhaps most importantly, the client’s technical and leadership team regained trust in the data.

Several lessons emerged from this work

• A firing purchase event does not equal a valid purchase.
• Custom thank-you pages frequently break ecommerce tracking.
• GA4 requires order context, not assumptions.
• Google Ads rarely steals attribution – it simply exposes weak signals (i.e. from GTM).
• One purchase definition is not optional; it is essential.

Conclusion

This case-study demonstrates that most GA4 ecommerce attribution failures are not caused by GA4 itself, but by broken assumptions carried forward from Universal Analytics-era setups.

By restoring a single source of truth, simplifying GTM logic, and validating attribution through deliberate testing, it is possible to repair even severely distorted ecommerce data without throwing the baby out with the bathwater.

For teams struggling with implausible ROAS, disappearing email revenue, or GA4 confusion, the lesson is clear: fix the data acquisition first, then trust the numbers!