Analytics that survive a WooCommerce storefront migration

A useful setup tracks the funnel, not just pageviews. In GA4 terms that means view_item_list on category pages, view_item on product pages, add_to_cart and remove_from_cart on the cart, begin_checkout at the handoff, and purchase on the confirmation. Each needs the right item data — id, name, price, currency, quantity — so revenue and product reports are trustworthy. On a Next.js storefront these fire from real user actions and route changes, pushed to a dataLayer you control rather than guessed at by a theme plugin.

• view_item_list and select_item on category and search
• view_item on product pages with correct item data
• add_to_cart, remove_from_cart and begin_checkout in the cart flow
• purchase on the WooCommerce confirmation, with order value and items

In a hybrid setup the shopper browses on the Next.js storefront and completes payment in the native WooCommerce checkout. That crossing between two contexts is exactly where sessions split and attribution is lost if it is not handled. The fix is deliberate continuity: carry the client and session identity across the handoff, fire begin_checkout before it and purchase after it, and make sure the same GA4 configuration and consent state apply on both sides so one journey is not counted as two.

Analytics that ignores consent is a liability, not an asset. The storefront should integrate a consent mechanism so tags only fire with permission, honour GA4 Consent Mode where used, and avoid collecting personal data it has no basis to hold. Because a Next.js storefront controls its own script loading, consent can gate tags precisely rather than relying on a plugin that loads everything and asks later.

Client-side tagging is simplest and fine for most stores. Server-side tagging — sending events from your own endpoint — can improve data quality, reduce the impact of ad blockers and keep third parties at arm's length, at the cost of more setup. The honest recommendation is to start client-side with a clean dataLayer, then add server-side tagging only if data loss or privacy requirements justify it, rather than building the complex version by default.

The one event you cannot afford to lose is purchase, and on a hybrid storefront it fires from the WooCommerce confirmation after the handoff — exactly where client-side tracking is most fragile. Ad blockers, a shopper closing the tab on the thank-you page, or a redirect from a payment gateway can all drop a client-side purchase, quietly understating revenue in your reports. The robust pattern backs the client event with a server-side signal from WooCommerce itself: an order webhook or server event fires when the order is actually created, so revenue is recorded whether or not the browser cooperated. For a store making decisions on ROAS and conversion value, that reliability is the difference between analytics you can trust and numbers you have to caveat.

• purchase fires from the WooCommerce confirmation, where client tracking is fragile
• Ad blockers, closed tabs and gateway redirects drop client-side events
• Back it with a server-side signal from a WooCommerce order webhook
• Reliable revenue data is what ROAS and conversion decisions depend on

Analytics changes are invisible until a report is wrong, so they need active validation. Use GA4 DebugView and the network tab to confirm each event fires once with correct parameters, place real test orders to verify purchase and revenue, and compare a stable period before and after launch to catch silent drops. The goal is a migration where the funnel is continuous and the numbers still mean what your team thinks they mean.