100 People Visited Your Store. 70 Added to Cart. Only 20 Bought. Here's How I Built the System That Shows You Exactly Where You Lost the Other 50.
| Type | Self-initiated portfolio project |
|---|---|
| Platform | WooCommerce — LocalWP local development environment |
| Store | Protein4Eva Demo Store |
| GTM Container | GTM-TDM8J9MQ · 7 tags · 6 triggers · 4 variables |
| Tools | Google Tag Manager · GA4 · DataLayer for WooCommerce (Stape) · GTM Preview · GA4 DebugView · Browser DevTools |
| Outcome | Full e-commerce event suite validated end-to-end in GA4 DebugView, with correct transaction ID, revenue, currency, and product data |
Most store owners check revenue every morning and know which products are selling — but almost none can answer the question that actually matters: out of every 100 people who visit your store, how many make it all the way to buying something, and at which exact stage are you losing the rest?
A typical, unmeasured store looks like this:
| Stage | Visitors Remaining |
|---|---|
| Land on a product page | 100 |
| Add something to cart | 70 |
| Reach checkout | 40 |
| Complete purchase | 20 |
That's 80 people who left — and without proper tracking, no visibility into where or why. This project was about building the system that makes that visible, validated first in a controlled local environment before it would ever touch a live client store.
Problem 1 — The Two Dashboard Problem
WooCommerce's built-in reporting only records completed orders — it starts counting at the end of the journey. It can't show how many people viewed a product but never added to cart, added to cart but never reached checkout, or which marketing channel drove the people who actually purchased.
Running WooCommerce's native analytics alongside GA4 simultaneously also causes double counting — the same purchase recorded twice, through two different mechanisms, producing numbers that don't match.
Problem 2 — WooCommerce Doesn't Push Data to GA4 on Its Own
The dataLayer is the JavaScript communication layer between a store and GTM. WooCommerce does not natively push e-commerce data into it — install GA4 and GTM alone, and the only thing that fires on a purchase is a generic page view on the thank-you page. GA4 knows someone visited a URL; it has no idea a transaction happened.
The fix: installed DataLayer for WooCommerce by Stape, configured with GTM container GTM-TDM8J9MQ and the GA4 Ecommerce dataLayer toggle enabled — hooking into WooCommerce's order events to push a fully structured ecommerce object on every completed purchase (transaction ID, value, currency, item name, category, quantity).
Problem 3 — The CartFlows Plugin Conflict (The Silent Failure)
With the dataLayer plugin installed and GTM connected, the first test purchase produced silence — no purchase event in GA4 DebugView. Inspecting the browser console on the thank-you page revealed the cause: {pagePostType: 'cartflows_step'}.
CartFlows — a third-party checkout funnel plugin — had replaced WooCommerce's native checkout and thank-you page with its own template. The customer experience looked identical, but WooCommerce's native completion hook never fired because the page it fires on no longer existed in the flow.
The fix: deactivated CartFlows. WooCommerce reverted to its native checkout flow, and the very next test order fired the dataLayer push correctly.
Building the Journey Map
With infrastructure working, every meaningful step in the customer journey was instrumented — not just the final sale:
| Stage | Event | GTM Trigger |
|---|---|---|
| 1 | view_item | Page view on product URLs |
| 2 | add_to_cart | Click trigger scoped to the Add to Cart button |
| 3 | begin_checkout | Page-view trigger on the checkout URL |
| 4 | purchase | Custom dataLayer event from the Stape plugin push, with Send Ecommerce Data enabled |
When all stages are tracked correctly, GA4 can show exactly how many people made it from one stage to the next — and exactly where the rest fell off. That's the conversion funnel, and it only exists if every stage is instrumented.
Validation
Every claim in this implementation is backed by two simultaneous sources of evidence, both open during the same test session:
- GA4 DebugView — the purchase event appeared with a green flag (GA4's confirmation it recognised a standard e-commerce event), full parameter set populated, and the complete journey sequence firing within the same session: view_item (×3), scroll (×3), begin_checkout (×2), add_to_cart (×1), purchase.
- Browser console — the raw ecommerce object confirmed at the moment of purchase: transaction_id: "8933", value: 19, currency: "USD", item_name: "Handpicked Red Chillies" — confirming the data was clean at the source, not just at the destination.
Complete event sequence validated in a single session: view_item → add_to_cart → begin_checkout → purchase. Zero duplicate events. Zero missing parameters.
What This Means for Drop-Off Analysis
| Drop-off point | Likely cause |
|---|---|
| view_item → add_to_cart | Product page not converting interest into intent — images, pricing, or trust signals failing at the decision moment |
| add_to_cart → begin_checkout | Something in the cart experience breaking momentum — unexpected shipping costs, slow load, distraction |
| begin_checkout → purchase | The most expensive drop-off — almost always a trust failure: unrecognised payment method, missing security indicator, broken mobile form, or final price higher than expected |
The Quickest Check You Can Run Right Now
If GA4 is installed on your WooCommerce store and you've never verified it's actually recording purchases: check last month's revenue in WooCommerce's order reports, then check the same period in GA4 → Reports → Monetisation → Ecommerce purchases.
| What you see | What it means |
|---|---|
| Numbers roughly match | Tracking is probably working |
| GA4 shows significantly less | Purchase tracking is partially broken — likely a plugin conflict or missing dataLayer plugin |
| GA4 shows zero | Purchase tracking is completely absent — more common than most people expect |