GTM Kit Premium can record the consent your customer grants at checkout on the order itself, then apply that consent to every server-side webhook dispatched for the order. This covers webhooks fired during checkout, on order-status changes, and on off-session subscription renewals dispatched from cron weeks or months later.
The feature is off by default. Enable it from GTM Kit → WooCommerce → Webhooks, under “Consent gating of webhooks”.
How it works
At checkout, GTM Kit captures the customer’s consent state from the WP Consent API and stores it on the order in _gtmkit_consent meta. Every server-side webhook for that order then reads the stored consent and applies it at dispatch time. The recorded consent state is also attached to the webhook body in a consent field, so your server-side GTM container can make per-platform routing decisions from the same source of truth.
Modes
Off
The default. Webhooks are sent regardless of the consent given at checkout. The recorded consent state is not attached to the webhook body.
Off governs the webhook, not the capture. Identifiers read from the order request obey the visitor’s consent whatever this setting is.
Suppress
Strips identifiers the customer did not consent to from the webhook payload. When both marketing and analytics consent were denied, the webhook is not sent at all and no _gtmkit_purchase_event_fired stamp is written. Aggregate conversion numbers will reflect the full-denial drops.
Anonymize
Always sends the webhook, but with the unconsented identifiers stripped. Platform cookies and click IDs are removed when the corresponding consent category was denied; the ecommerce block and URL-based attribution stay intact. Aggregate conversion numbers are preserved.
Unknown consent
Some orders have no recorded consent state. Examples: orders placed before this feature was enabled, orders created by an administrator from wp-admin, or orders created programmatically. The Unknown consent setting governs what happens to those:
- Allow (default): treat the order as if all consent was granted. The webhook dispatches unchanged.
- Deny: treat the order as if all consent was denied. The webhook is suppressed or anonymized per the selected mode.
What appears on the order
The GTM Kit Attribution meta box on the order-edit screen shows the recorded consent state under “Consent at order time”. Both HPOS and the classic order screen are supported.
Webhook payload
When the feature is on, every server-side webhook for the order carries a consent object alongside ecommerce and attribution. The object includes the consent categories that were granted or denied, the source of the recorded consent (client or server), and the capture time. Use this in your server-side GTM container to make per-platform decisions; the gating logic in the plugin and the routing logic in your container read the same recorded state.
When the setting that adds hashed customer identifiers is switched on, the customer’s email address and phone number are added to the event in hashed form. They are added only for customers whose consent covers advertising, they are worked out fresh each time an event is sent, and they are not stored anywhere. The setting is off until you turn it on.
Performance and caching
Consent capture runs client-side, so a full-page cache (Cloudflare, Varnish, LiteSpeed, WP Rocket) cannot bake the wrong visitor’s consent state into a cached page. Gating runs server-side at dispatch time, against the per-order stored state, so off-session events dispatched from cron honour the consent that ran at the original checkout.
Identifiers that GTM Kit reads from the order request itself are checked against consent at the moment they are captured, not only when the webhook is sent. A visitor who declined has nothing recorded against their order, so consent denial is honoured even in modes that would otherwise send the webhook.