--- title: "GTM Kit 2.14.0: GA4 engagement events out of the box, and WooCommerce block tracking rebuilt" date: 2026-06-02 author: "GTM Kit" categories: - name: "Software releases and updates" url: "/category/software-releases-and-updates.md" --- # GTM Kit 2.14.0: GA4 engagement events out of the box, and WooCommerce block tracking rebuilt GTM Kit 2.14.0 adds four GA4 standard engagement events that fire the moment you upgrade, and ships a ground-up rebuild of WooCommerce block tracking on stable APIs so cart, checkout, Mini Cart, and Product Collection blocks all report ecommerce events end to end. If you run a classic WooCommerce store, your tracking is unchanged. If you run block-based Cart and Checkout, or a Product Collection homepage, this release closes gaps you may not have known were there. And every site now gets `login`, `sign_up`, `search`, and `generate_lead` events without touching GTM. Read on for what each one does. ## What changed ### GA4 engagement events, on by default GTM Kit has always pushed a full set of ecommerce events. It did not push the GA4 standard engagement events that round out a funnel: `login`, `sign_up`, `search`, and `generate_lead`. Until now you configured those by hand inside GTM, or did without them. The new **Engagement events** section adds all four, each with its own toggle, all defaulting to on. Upgrade and they start firing: - **`login`** on every successful WordPress and WooCommerce account login. - **`sign_up`** on every new account registration, including accounts created during WooCommerce checkout. The `method` parameter tells a checkout-created account apart from a standalone registration, so you can split those funnels in GA4. - **`search`** on WordPress and WooCommerce product search results pages, with the actual query in `search_term`. No more relying on GA4’s legacy search-view setting. - **`generate_lead`** alongside the existing `form_submit` event on successful Contact Form 7 submissions, so your GA4 lead conversions are first-class rather than a filter on `form_submit`. Each event can be switched off independently if your GTM container already covers it, which keeps double-fires a checkbox away rather than a code change. It is cache-safe by design. The events that depend on a user action (login, sign-up) are handed off through a short-lived cookie that the browser reads and clears on the next page, so nothing per-visitor is ever baked into cached HTML. Search runs entirely from the URL. All four work behind Cloudflare, Varnish, LiteSpeed, and WP Rocket. ### WooCommerce block tracking, rebuilt GTM Kit’s block tracking was built years ago against WooCommerce’s private `experimental__` block hooks. Since then WooCommerce moved on: Product Collection arrived with its own render lifecycle, Mini Cart became a first-class block, and the supported way to read cart and checkout state is now the `wc/store/cart` and `wc/store/checkout` data stores. The old approach left silent gaps, and any WooCommerce update could quietly break it. This release rebuilds the whole block surface on those stable data-store APIs. Coverage now spans Cart, Checkout, Mini Cart, All Products, Product Collection, Single Product, Related Products, the Cart block cross-sells, and product filter blocks. Concretely, that means: - The **Mini Cart** now fires `add_to_cart` and `view_cart`, not just `add_to_cart`. - **Product Collection**, the modern WooCommerce default for product grids, now reports impressions (`view_item_list`) and clicks (`select_item`). - Changing a **product filter** or paging a collection re-fires `view_item_list` for the new set. - The full GA4 ecommerce set fires on block stores the same as on classic stores: `view_item_list`, `select_item`, `view_item`, `add_to_cart`, `remove_from_cart`, `view_cart`, `begin_checkout`, `add_shipping_info`, `add_payment_info`, `purchase`. It stays zero-config and full-page-cache safe. There are no new settings, and every per-visitor decision runs client-side from the live data stores. Building on stable APIs also means a WooCommerce update is far less likely to silently break tracking, and our own automated tests now cover the block path so regressions surface before they reach your store. ## Developer notes New filters for the engagement events let you adapt them without forking: - `gtmkit_engagement_event_login_method` and `gtmkit_engagement_event_signup_method` to tag the `method` parameter (the user object / user ID is passed along). - `gtmkit_engagement_event_search_term` to normalise the search term before it is pushed. - `gtmkit_engagement_event_generate_lead_payload` to assign a lead `value` and `currency` (or any other fields) to the `generate_lead` event. - `gtmkit_engagement_event_cookie_name` to rename the short-lived handoff cookie. - `gtmkit_engagement_event_should_emit` as a final veto on any engagement event, for any reason, without touching the toggles. - `gtmkit_is_search_results_page` to opt a custom search template into the `search` event when it does not use the standard search query. For blocks: - `gtmkit_blocks_supported` lets you add custom block names to the list that loads GTM Kit’s block tracking, so a custom block wrapping Product Collection gets tracked too. All engagement and block events flow through the `window.gtmkit.events.push()` seam introduced in 2.13.0, so consent gating and the Premium event-deferral queue apply to them automatically. GTM Kit Premium customers also get a new **Event deferral** section on the Consent settings page in this release: hold ecommerce events such as `add_to_cart` and `purchase` in the browser until a visitor grants consent, then release them in the order they fired, with a configurable timeout and a flush-or-drop fallback. The decision runs entirely client-side, so a cached page stays identical for every visitor. ## Upgrade notes **Engagement events start firing on upgrade.** All four default to on, so `login`, `sign_up`, `search`, and `generate_lead` will appear in your data layer immediately. If your GTM container or GA4 setup already produces any of them, switch that one off in the new Engagement events section to avoid duplicates. **Minimum WooCommerce is now 10.3.** The rebuilt block tracking relies on data-store contracts that stabilised in WooCommerce 10.3. Stores on older WooCommerce keep classic-template tracking exactly as before and simply do not get the new block coverage, which they did not have previously. This is additive for the classic install base, not a regression. If you run block-based Cart or Checkout, update WooCommerce to 10.3 or later to get the new coverage. Nothing else needs action. Classic-template ecommerce tracking is unchanged.