← Back to changelog

GTM Kit Premium 1.4.0

Free

GTM Kit Premium 1.4.0 is about one shared server-side container doing more work with less wiring. If you run a single sGTM container across several sites, or you want standard GA4, Meta CAPI and Google Ads tags to just work with GTM Kit’s webhook traffic, this release removes the manual steps that used to stand in the way. It also gives every purchase a shared event ID, so the destinations that deduplicate on one stop counting an order twice when it arrives from both the browser and the server.

One shared server container, one GA4 property per site

Agencies and multi-site owners have long pointed a single server-side container at many WordPress sites, then hand-rolled per-site routing with the gtmkit_webhook_payload filter. The new Server-side GA4 measurement ID setting (WooCommerce settings, under Server-side webhooks) makes that a first-class option.

Set a measurement ID on each site and every webhook that site sends (purchase, order-status, refund, subscription, and Preview test sends) carries its own destination. The routing travels with the event, so adding a site means filling in one field, not editing the shared container. Leave the field empty and that site keeps using the measurement ID configured in the container itself, exactly as before.

Using this setting means re-importing the updated server container template once, so the container reads the destination from the incoming event. After that, onboarding a new site needs no container work at all.

Standard tags work with no mapping variables

GTM Kit’s server-side webhook has always delivered a GA4-shaped payload, but the ecommerce, cookie, attribution and consent values sat inside nested objects. Standard sGTM endpoint tags read their parameters from the flat Event Data model, so implementers had to build a mapping variable for nearly every parameter on every tag.

Webhook events now also carry those values as flat top-level fields, alongside the original nested objects. Standard GA4, Meta CAPI and Google Ads tags in your server container pick them up through default parameter inheritance, with no per-parameter mapping variable and no GTM template to import. The nested objects stay in place, so anything already reading them keeps working. The same set of endpoint tags can now serve both your browser GA4 traffic and GTM Kit’s webhook traffic.

One purchase, one event ID

Correction, August 2026: this section originally said that the shared ID makes your GA4 tag deduplicate the order. Later testing established that Google Analytics 4 does not reconcile a purchase delivered by both the browser and the server at all. The section below has been corrected, and the practical advice is to send the purchase to GA4 from one side only.

When the same order reaches a shared server container from both the browser and the webhook, it can be counted twice. Every purchase now carries a stable, transaction-based event_id on both the browser event and the server-side webhook. Because both sides use the same ID, a destination that deduplicates on event_id treats the two as one event. That is the mechanism Meta, TikTok, Reddit, Snap and Pinterest use, and it is why a retried webhook stays idempotent rather than adding a second sale.

Google Analytics 4 is not one of them. GA4 keys on transaction_id, not event_id, and testing on a fully verified setup established that it does not reconcile a purchase delivered by both the browser and the server, even with the transaction ID, client ID, session ID and session count all confirmed identical on the wire. Dual delivery to GA4 double counts by design. Send the purchase to GA4 from one side only: either keep the browser purchase event and let the webhook serve your other destinations, or disable the browser purchase event and let the webhook carry it.

You can turn the flat fields and the shared purchase event ID on or off with a single setting (on by default). If several stores share one container, an optional event_id prefix (defaulting to your site name) keeps their IDs from colliding.

Cleaner server-side debugging in Preview

While an sGTM Preview/Debug session is active, server-side webhook events now carry GA4’s debug signal, the same one browser debug traffic carries. It is scoped to the Preview session and never marks normal traffic, so you can watch webhook events in the container’s Preview panel without touching a live setup.

One caveat worth stating plainly: GA4’s DebugView does not reliably list purely server-originated events, even with the debug signal attached. Verify webhook delivery in the server container’s Preview/Debug panel and in GA4 Realtime, not in DebugView.

Developer notes

  • The flat top-level fields are additive. They are set only when absent and never overwrite an existing value, the nested ecommerce, cookies, attribution and consent objects are preserved, and the gtmkit_webhook_payload filter still runs last, so any override you already have keeps winning.
  • If you previously hand-built flat aliases (in a Data Client template patch or through gtmkit_webhook_payload), you can retire that once you have confirmed parity with the built-in behaviour.
  • Deduplication at the destinations that support it uses a transaction-based event_id on both the browser and the webhook. Deploying only one side leaves nothing to deduplicate against; both halves ship together here, so the default behaviour is correct out of the box. GA4 ignores event_id for this purpose and keys on transaction_id, which it does not act on for browser-plus-server delivery either.

Upgrade notes

  • The flat Event Data fields and the shared purchase event ID are on by default and require no container or template changes. Nothing in your existing container breaks.
  • The per-site GA4 measurement ID setting is opt-in. To use it, re-import the updated server container template once so the container reads the destination from the incoming event. Sites that leave the field empty are unaffected.
  • No minimum-core change in this release.