--- title: "Four hard problems in WooCommerce tracking, and what GTM Kit Premium does about each one" date: 2026-06-15 author: "Torben Lundsgaard" categories: - name: "Announcements" url: "/category/announcements.md" tags: - name: "attribution" url: "/tag/attribution.md" - name: "consent" url: "/tag/consent.md" - name: "GA4" url: "/tag/ga4.md" - name: "tracking" url: "/tag/tracking.md" - name: "WooCommerce" url: "/tag/woocommerce.md" --- # Four hard problems in WooCommerce tracking, and what GTM Kit Premium does about each one GTM Kit Premium 1.0 ships today. Before the feature tour, here is the story of what we built it to solve. WooCommerce tracking has a silent-failure problem. The dashboard shows events arriving, GA4 reports look populated, the consent banner is ticking, and somewhere in the stack, conversions are leaking, attribution is dying, or consent is being respected in some channels and quietly violated in others. None of these failures are visible unless you go looking for them, and most of them only become obvious months later in long-term LTV reports or at audit time. GTM Kit Premium built around four specific failure modes WooCommerce tracking has to get right. Here is the story of each one. ## 1. Consent that follows the customer through every server-side event A consent banner runs in the customer’s browser. They tap Allow or Deny, and the client-side GTM tags adjust accordingly. So far, so standard. A WooCommerce order generates more than client-side tags. Server-side webhooks fire on order completion, on refund, and on every subscription renewal cycle dispatched weeks or months later from cron. End-to-end consent compliance means every one of those server-side dispatches has to respect the same consent state the browser respected at checkout. By the time a renewal fires, the browser is closed, the cookies are gone, and the consent state has to come from somewhere durable. Premium 1.0 records the consent your customer granted at checkout on the order itself. Every server-side webhook for that order, now and for the lifetime of any subscription it started, applies that consent at dispatch time. Two modes: **Suppress** strips identifiers the customer denied, and skips the webhook entirely when all relevant consent was denied. **Anonymize** always sends the webhook but with the denied identifiers removed, preserving your aggregate conversion numbers. Every webhook also carries the recorded consent state alongside the payload, so your server-side GTM container can make per-platform routing decisions from the same source of truth. Off by default. Turn it on once and it covers every order from then on, for the full lifetime of the customer relationship. ## 2. Server-side webhooks that don’t drop conversions The common pattern for a server-side conversion webhook is to fire it inside the checkout request. The customer hits Place Order, WooCommerce does the order-create, and a webhook to your server-side GTM container goes out before the customer reaches the thank-you page. This pattern has two cost points. First, every extra millisecond the customer waits for the webhook to round-trip is latency added to the most critical moment in the funnel. Second, if the container is slow, briefly unreachable, or returning a transient 5xx, the webhook fails and the conversion is lost. No retry, no log, no signal. Premium 1.0 ships an opt-in background webhook queue built on WooCommerce Action Scheduler. Enable it and the `purchase`, `order_paid`, and `refund` webhooks dispatch from a background worker after checkout completes. The customer pays no latency cost. Failed deliveries retry with backoff. An order’s event is marked fired only after a confirmed 2xx response from the container, so a failed send is no longer treated as delivered and quietly dropped. Terminal failures are logged to a dedicated `gtmkit-webhook` log source where you can actually see them. The body of the queued request is byte-identical to the synchronous one. If your container already accepts the synchronous webhook, it accepts the queued one without any change at the container. Three new status events ride the same queue: `order_processing`, `order_completed`, and `order_refunded`. Each has its own opt-in toggle. They fire from every code path the synchronous `purchase` webhook missed, including admin actions, payment-gateway callbacks, and scheduled tasks. ## 3. Subscription renewals that attribute to the source, not “direct” A WooCommerce Subscriptions renewal fires from cron, days or months after the original checkout. The customer’s browser is closed. The GA `client_id` is gone, the platform cookies are gone, the UTMs are gone. Without something durable to replay, an off-session renewal has no source to attribute to, so it lands in GA4 as “direct,” and your long-term LTV calculation systematically undercounts every paid channel that drove a subscription. Premium 1.0 ships GA4 subscription lifecycle tracking with off-session events that attribute. At sign-up, the parent order’s captured attribution snapshot (UTMs, click IDs, GA `client_id`, platform cookies) is copied onto the subscription record. When the renewal fires six months later, the server-side dispatch carries the original `client_id` and the original campaign attribution. The renewal lands in GA4 attributed to the source that actually drove the original purchase. `subscription_started`, `subscription_renewed`, `subscription_cancelled`, `subscription_expired`, and `subscription_reactivated` all ship in 1.0. Each event has its own opt-in toggle in the WooCommerce settings, off by default. The section is only visible when WooCommerce Subscriptions is active. ## 4. First-party attribution that survives the trip Marketing attribution has a survival problem. UTMs and click IDs are captured at the landing page. Between then and the order being placed, the visitor may switch browsers, come back three days later, hit ad blockers that strip query parameters, navigate through cached pages, or visit from a privacy browser that truncates third-party cookie lifetimes. Server-side capture can disagree with client-side, and full-page caching can serve one visitor’s UTMs into another visitor’s cached HTML response. Premium 1.0 records a first-party attribution snapshot to every WooCommerce order and every Gravity Forms entry, written to `_gtmkit_attribution` order meta. The capture runs client-side, so a full-page cache cannot bake one visitor’s UTMs into another visitor’s HTML. It writes to a first-party cookie set on your own domain, which survives ad blockers configured against third-party scripts, and survives ITP for the lifetime of a first-party cookie. The captured data ends up in three places where you can use it. The `purchase` event on the order-received page carries an `attribution` object alongside `ecommerce`, ready for your GTM tag templates to read. The order-edit screen surfaces a meta box showing the order’s source at a glance, on both HPOS and the classic orders screen. The server-side webhook forwards the same attribution context to your container, so source / medium / campaign survive on the server path, not just platform cookies. WP Consent API gated. When marketing consent is denied, platform tracking cookies are skipped; URL-based attribution still captures. Native WooCommerce attribution is preserved alongside under `enrichment.native_woo`. --- ## What it costs Premium 1.0 is **€85/year for one site**, with five additional tiers up to **50 sites for €448/year**. Six tiers, no per-feature gating; the same five fixes above apply on every tier. 14-day money-back guarantee, self-serve from your account page. Stripe Checkout, instant licence delivery. [See the full pricing ladder](/pricing/) · [Read the documentation](/documentation/) · [Read the 1.0 release notes](/changelog/gtm-kit-premium-1-0/)