WooCommerce: Open-Source WordPress eCommerce Plugin

Analytics Architecture on WooCommerce

WooCommerce is a WordPress plugin, which means all analytics implementation runs through the WordPress hook system. Every significant store action--product views, cart changes, checkout steps, and completed purchases--fires a corresponding hook that you can tap into for tracking. Understanding which hooks fire, when they fire, and whether they fire on the server or client is the foundation of reliable ecommerce measurement on WooCommerce.

Core Hooks for Tracking

The hooks that matter most for analytics work:

woocommerce_thankyou is the primary purchase tracking hook. It fires on the order confirmation page (order-received endpoint) and receives the order ID as its only parameter. This is where most client-side purchase tracking lives. The hook fires once per page load, but the page itself can be refreshed or revisited, which is why de-duplication logic is mandatory.

woocommerce_add_to_cart fires on the server when a product is added to the cart. For simple products on archive pages, WooCommerce uses AJAX add-to-cart by default, meaning the page never reloads. This has major implications for GTM-based tracking: any trigger that depends on a page load will miss AJAX cart additions entirely.

woocommerce_after_single_product fires at the bottom of single product pages. This is the natural place to inject view_item data layer pushes. It only fires on product pages, so you do not need conditional checks for post type.

woocommerce_checkout_order_processed fires server-side when the order is first created during checkout, before payment processing. This is your hook for server-side tracking via the Measurement Protocol, because it fires regardless of whether the customer ever sees the thank-you page.

woocommerce_payment_complete fires after successful payment confirmation. For gateways that redirect off-site (PayPal Standard, some bank transfer flows), the customer may not return to the thank-you page. This hook guarantees the server knows the payment went through, making it the most reliable trigger for server-side revenue tracking.

AJAX Cart Behavior

By default, WooCommerce enables AJAX add-to-cart on archive (shop/category) pages. When a customer clicks "Add to Cart" on a product listing, WooCommerce sends an AJAX request to ?wc-ajax=add_to_cart and updates the cart fragments without reloading the page. The single product page can also use AJAX, depending on the theme.

This means you cannot rely on page-load-based tracking for cart additions. You need to either:

1. Listen for the JavaScript added_to_cart event that WooCommerce fires after a successful AJAX add-to-cart.
2. Use the woocommerce_add_to_cart_fragments filter to inject tracking data into the AJAX response.
3. Disable AJAX add-to-cart entirely (not recommended for UX, but sometimes done for tracking simplicity).

The same applies to cart quantity updates and removals--these are AJAX operations that fire updated_cart_totals and removed_from_cart events respectively.

GA4 Enhanced Ecommerce Setup

There are three approaches to GA4 ecommerce tracking on WooCommerce, each with different trade-offs in coverage, accuracy, and maintenance burden.

Via Google Listings & Ads Plugin

The official WooCommerce extension from Google (formerly "Google for WooCommerce") handles GA4 ecommerce events automatically. It injects gtag.js and fires view_item, add_to_cart, begin_checkout, and purchase events without custom code.

What it does well:

• Automatic product data extraction from WooCommerce product objects
• Handles variable product price resolution correctly
• Manages the AJAX add-to-cart tracking internally
• Integrates with Google Merchant Center for product feed sync

What it does not do:

• No view_item_list tracking on archive/category pages in older versions
• No select_item tracking when a customer clicks a product from a listing
• Limited control over which product attributes map to GA4 item parameters
• No support for custom dimensions or metrics on ecommerce events
• Cannot send to multiple GA4 properties simultaneously

Configuration is straightforward: install the plugin, connect your Google account, select your GA4 property, and enable "Enable Google Analytics" under Marketing > Google Listings & Ads > Settings. The plugin adds its own gtag.js snippet, so remove any existing GA4 installation to avoid duplicate tracking.

Via GTM4WP Plugin

GTM4WP (Google Tag Manager for WordPress) is the most common WooCommerce-to-GTM bridge. It pushes structured ecommerce data into the dataLayer and lets GTM handle the tag firing logic. This gives you full control over what gets tracked and how.

After installing GTM4WP, enable WooCommerce integration under Settings > Google Tag Manager > Integration. The plugin pushes data layer objects for all standard ecommerce interactions. On product pages, you get:

// GTM4WP pushes this on single product page load
dataLayer.push({
  'event': 'view_item',
  'ecommerce': {
    'currency': 'USD',
    'value': 29.99,
    'items': [{
      'item_id': 'WC-123',
      'item_name': 'Example Product',
      'item_category': 'Clothing',
      'price': 29.99,
      'quantity': 1
    }]
  }
});

On the order-received page after a completed purchase:

// GTM4WP pushes this on the thank-you page
dataLayer.push({
  'event': 'purchase',
  'ecommerce': {
    'transaction_id': '10542',
    'value': 67.98,
    'tax': 5.44,
    'shipping': 8.50,
    'currency': 'USD',
    'items': [
      {
        'item_id': 'WC-123',
        'item_name': 'Example Product',
        'item_category': 'Clothing',
        'price': 29.99,
        'quantity': 2
      }
    ]
  }
});

GTM4WP also handles the AJAX add-to-cart problem. It hooks into the added_to_cart JavaScript event and pushes an add_to_cart data layer event automatically. In GTM, create a Custom Event trigger matching add_to_cart and a GA4 Event tag that reads from ecommerce.items.

One critical setting: under GTM4WP's Integration tab, set the data layer variable name to dataLayer (the default). Some older configurations used gtm4wp_datalayer, which breaks GA4 ecommerce tag templates.

Manual Implementation

When you need full control--custom item parameters, non-standard funnels, or tracking to multiple destinations--implement the data layer pushes directly in your theme or a custom plugin.

Track purchases on the thank-you page with de-duplication:

add_action('woocommerce_thankyou', function($order_id) {
    $order = wc_get_order($order_id);
    if (!$order || $order->get_meta('_ga4_tracked')) return;

    $items = [];
    foreach ($order->get_items() as $item) {
        $product = $item->get_product();
        $items[] = [
            'item_id'   => $product ? ($product->get_sku() ?: (string) $product->get_id()) : '',
            'item_name' => $item->get_name(),
            'price'     => (float) $order->get_item_total($item),
            'quantity'  => $item->get_quantity(),
        ];
    }

    echo '<script>
    window.dataLayer = window.dataLayer || [];
    dataLayer.push({ ecommerce: null });
    dataLayer.push({
        "event": "purchase",
        "ecommerce": {
            "transaction_id": "' . esc_js($order->get_order_number()) . '",
            "value": ' . (float) $order->get_total() . ',
            "tax": ' . (float) $order->get_total_tax() . ',
            "shipping": ' . (float) $order->get_shipping_total() . ',
            "currency": "' . esc_js($order->get_currency()) . '",
            "items": ' . wp_json_encode($items) . '
        }
    });
    </script>';

    $order->update_meta_data('_ga4_tracked', 'yes');
    $order->save();
}, 10, 1);

Track product page views:

add_action('woocommerce_after_single_product', function() {
    global $product;
    if (!$product) return;

    $categories = wp_get_post_terms($product->get_id(), 'product_cat', ['fields' => 'names']);

    echo '<script>
    window.dataLayer = window.dataLayer || [];
    dataLayer.push({ ecommerce: null });
    dataLayer.push({
        "event": "view_item",
        "ecommerce": {
            "currency": "' . esc_js(get_woocommerce_currency()) . '",
            "value": ' . (float) $product->get_price() . ',
            "items": [{
                "item_id": "' . esc_js($product->get_sku() ?: $product->get_id()) . '",
                "item_name": "' . esc_js($product->get_name()) . '",
                "item_category": "' . esc_js(!empty($categories) ? $categories[0] : '') . '",
                "price": ' . (float) $product->get_price() . ',
                "quantity": 1
            }]
        }
    });
    </script>';
});

Note the dataLayer.push({ ecommerce: null }) call before each ecommerce push. This clears the previous ecommerce object from the data layer, preventing stale item data from bleeding into subsequent events. This is a GA4 requirement--skip it and you will see phantom items in your reports.

AJAX Add-to-Cart Tracking

The AJAX cart is the single biggest source of missed ecommerce events on WooCommerce stores. Standard GTM "Page View" or "DOM Ready" triggers never fire because the page does not reload. You must listen for WooCommerce-specific JavaScript events.

// Listen for WooCommerce AJAX add-to-cart on archive pages
jQuery(document.body).on('added_to_cart', function(event, fragments, cart_hash, $button) {
    var productId = $button.data('product_id');
    var productName = $button.data('product_name') ||
        $button.closest('.product').find('.woocommerce-loop-product__title').text().trim();
    var productPrice = parseFloat($button.data('product_price') || 0);
    var quantity = parseInt($button.closest('form').find('input.qty').val() || 1, 10);

    window.dataLayer = window.dataLayer || [];
    dataLayer.push({ ecommerce: null });
    dataLayer.push({
        'event': 'add_to_cart',
        'ecommerce': {
            'currency': wc_add_to_cart_params.currency || 'USD',
            'value': productPrice * quantity,
            'items': [{
                'item_id': String(productId),
                'item_name': productName,
                'price': productPrice,
                'quantity': quantity
            }]
        }
    });
});

A few things to watch for with this approach:

The $button parameter references the clicked "Add to Cart" button. On some themes, data-product_name and data-product_price are not set as data attributes on the button. In that case, you need to extract this information from the DOM or pre-populate it using a separate data layer push on page load that maps product IDs to their names and prices.

For variable products on single product pages, the add-to-cart is typically a form submission, not an AJAX call. The added_to_cart event does not fire for form-submitted carts. Instead, hook into the woocommerce_add_to_cart PHP action or track the form submission directly.

For cart quantity updates:

// Track quantity changes in the cart page
jQuery(document.body).on('updated_cart_totals', function() {
    window.dataLayer = window.dataLayer || [];
    dataLayer.push({
        'event': 'cart_updated'
    });
});

Server-Side Tracking

Client-side purchase tracking on WooCommerce has a fundamental reliability problem: if the customer never reaches the thank-you page (browser closes, redirect fails, payment gateway does not redirect back), the purchase is never recorded in analytics. Server-side tracking via the GA4 Measurement Protocol solves this.

add_action('woocommerce_payment_complete', function($order_id) {
    $order = wc_get_order($order_id);
    if (!$order || $order->get_meta('_ga4_mp_tracked')) return;

    $measurement_id = 'G-XXXXXXXXXX';
    $api_secret     = 'your_api_secret_here';

    $items = [];
    foreach ($order->get_items() as $item) {
        $product = $item->get_product();
        $items[] = [
            'item_id'   => $product ? ($product->get_sku() ?: (string) $product->get_id()) : '',
            'item_name' => $item->get_name(),
            'price'     => (float) $order->get_item_total($item),
            'quantity'  => $item->get_quantity(),
        ];
    }

    // Retrieve the GA client ID stored during checkout
    $client_id = $order->get_meta('_ga_client_id') ?: 'server.' . $order->get_id();

    $payload = [
        'client_id' => $client_id,
        'events'    => [[
            'name'   => 'purchase',
            'params' => [
                'transaction_id' => $order->get_order_number(),
                'value'          => (float) $order->get_total(),
                'currency'       => $order->get_currency(),
                'tax'            => (float) $order->get_total_tax(),
                'shipping'       => (float) $order->get_shipping_total(),
                'items'          => $items,
            ],
        ]],
    ];

    $url = "https://www.google-analytics.com/mp/collect?measurement_id={$measurement_id}&api_secret={$api_secret}";

    wp_remote_post($url, [
        'body'    => wp_json_encode($payload),
        'headers' => ['Content-Type' => 'application/json'],
        'timeout' => 5,
    ]);

    $order->update_meta_data('_ga4_mp_tracked', 'yes');
    $order->save();
});

The client_id is the critical piece. Without it, GA4 creates a new user for every server-side event, inflating user counts and breaking attribution. Capture the GA client ID during checkout and store it as order meta:

// Capture GA client ID at checkout
add_action('woocommerce_checkout_order_created', function($order) {
    if (isset($_COOKIE['_ga'])) {
        // _ga cookie format: GA1.1.123456789.1234567890
        $parts = explode('.', $_COOKIE['_ga']);
        if (count($parts) >= 4) {
            $client_id = $parts[2] . '.' . $parts[3];
            $order->update_meta_data('_ga_client_id', sanitize_text_field($client_id));
            $order->save();
        }
    }
});

Server-side is essential when payment gateways redirect off-site (PayPal, Klarna), when ad blockers suppress client-side analytics, or when running headless WooCommerce. Client-side is better when you need full session context or real-time data. The most reliable setup uses both: client-side for the browsing session, server-side as a fallback for purchases.

Plugin Conflicts

Analytics implementations break when multiple plugins compete to inject tracking code or alter the checkout flow.

Multiple analytics plugins is the most common conflict. Google Listings & Ads, GTM4WP, and a standalone gtag.js snippet all active simultaneously means each fires its own purchase event, tripling reported revenue. Audit the page source on the thank-you page and search for gtag(, dataLayer.push, and google-analytics script tags. You should see exactly one source of purchase events.

Cart and checkout funnel plugins (CartFlows, FunnelKit) replace WooCommerce's native checkout and thank-you pages with their own templates. The woocommerce_thankyou hook may not fire on custom thank-you pages, GTM4WP's checkout step tracking misses custom funnel pages, and data layer pushes injected via woocommerce_before_checkout_form never render. Check whether your funnel plugin provides its own analytics hooks.

Payment gateway redirects (PayPal Standard, Mollie, bank transfers) send customers to external payment pages. If they close the browser after paying, woocommerce_thankyou never fires. The fix is server-side tracking via woocommerce_payment_complete or configuring the gateway to always redirect back.

Mini-cart and cart fragment plugins that replace WooCommerce's default AJAX handler can suppress the added_to_cart JavaScript event. If AJAX add-to-cart tracking stops after installing a new theme or cart plugin, verify wc-add-to-cart.js is still enqueued.

Caching and Analytics

Page caching will destroy ecommerce tracking if misconfigured. A cached thank-you page serves stale order data to every visitor. WooCommerce sets Cache-Control: no-store and DONOTCACHEPAGE on transactional pages, but not all caching plugins respect these signals. These pages must be excluded from all caching: /cart/, /checkout/, /my-account/, URLs containing order-received, and URLs containing wc-api.

WP Rocket Exclusions

// Ensure WooCommerce transactional pages bypass WP Rocket page cache
add_filter('rocket_cache_reject_uri', function($urls) {
    $urls[] = '/cart/(.*)';
    $urls[] = '/checkout/(.*)';
    $urls[] = '/my-account/(.*)';
    $urls[] = '/(.*)\?.*order-received(.*)';
    return $urls;
});

// Exclude analytics cookies from cache key to prevent per-user cache variants
add_filter('rocket_cache_reject_cookies', function($cookies) {
    $cookies[] = '_ga';
    $cookies[] = '_gid';
    return $cookies;
});

LiteSpeed Cache Exclusions

In LiteSpeed Cache settings (LiteSpeed Cache > Cache > Excludes), add these URI patterns:

/cart
/checkout
/my-account
order-received
wc-api

Also check "Do Not Cache Cookies" and add woocommerce_cart_hash and woocommerce_items_in_cart--LiteSpeed should already detect these, but verify after any plugin update.

Redis or Memcached object caching does not interfere with analytics tracking (it caches database queries, not HTML). However, full-page caching layers like Varnish, Cloudflare APO, or Nginx FastCGI cache need the same URI exclusion rules. WooCommerce's woocommerce_cart_hash cookie is the standard signal to bypass full-page caches for users with items in their cart.

Common Errors

High-Volume Store Considerations

High-Performance Order Storage (HPOS)

WooCommerce 8.2+ introduced High-Performance Order Storage (HPOS), which moves order data from the wp_posts and wp_postmeta tables into dedicated wp_wc_orders and wp_wc_orders_meta tables. This changes how order meta is stored and retrieved.

For analytics tracking code, the WooCommerce CRUD API ($order->get_meta(), $order->update_meta_data(), $order->save()) works identically with both storage backends. If your tracking code uses raw SQL queries against wp_postmeta to check for duplicate tracking flags, those queries will break when HPOS is enabled without the compatibility layer.

Check if HPOS is active:

// Verify which order storage is active
if (class_exists('Automattic\WooCommerce\Utilities\OrderUtil')) {
    $hpos_enabled = Automattic\WooCommerce\Utilities\OrderUtil::custom_orders_table_usage_is_enabled();
    // true = HPOS active, use CRUD methods only
    // false = legacy post-based storage
}

Always use the CRUD API for order meta operations in tracking code. Never query wp_postmeta directly for order data.

Checkout Blocks vs Classic Shortcode

WooCommerce 8+ ships with a block-based checkout that replaces the classic [woocommerce_checkout] shortcode. The block checkout uses React and renders client-side, which affects tracking in several ways:

• The woocommerce_before_checkout_form and woocommerce_after_checkout_form PHP hooks do not fire on the block checkout. Any tracking code attached to these hooks is silently skipped.
• Checkout field validation and step progression happen in JavaScript, not via form submission. Checkout step tracking requires listening to the block checkout's JavaScript events rather than PHP hooks.
• The thank-you page behavior is the same for both checkout types--woocommerce_thankyou still fires. Purchase tracking is unaffected.

If your store uses the block checkout and you need checkout funnel tracking, use the woocommerce/checkout block's JavaScript filters and the @woocommerce/blocks-checkout package's extensibility API.

Subscription and Recurring Revenue

WooCommerce Subscriptions processes renewal orders automatically. Each renewal fires woocommerce_payment_complete and creates a new order, which means your server-side tracking will fire for every renewal. This is generally what you want for revenue tracking, but be aware that:

• Renewal orders do not have a corresponding client-side session (no page views, no browsing data)
• The GA client ID stored on the original order may be stale or expired
• GA4 will attribute renewal revenue to "(direct) / (none)" unless you pass a valid client ID

For subscription analytics, consider tracking initial sign-ups and renewals as separate event types to distinguish new revenue from recurring revenue in your reports.

Related Guides

• GA4 Ecommerce on WooCommerce
• GA4 Event Tracking on WooCommerce
• GTM Setup on WooCommerce
• GTM Data Layer on WooCommerce
• Meta Pixel on WooCommerce
• WooCommerce Troubleshooting
• WooCommerce CLS Troubleshooting
• WooCommerce LCP Troubleshooting
• WooCommerce Events Not Firing