TL;DR
A consent banner lives in the browser, and server-side events do not pass through the browser. That gap is why "does my server-side tracking stop when someone declines?" had no product answer on Magento 2 until recently. Since v1.17.4 it has one, and the answer is conditional in a way worth stating precisely: there is a setting, it is off until you turn it on, and all nine Conversions API addons follow it. One of them adds an option of its own for declined consent.
Key Takeaways
-
Require Visitor Consent for Server-Side Eventsarrived in v1.17.4 on September 1, 2026, and gates the GA4 Measurement Protocol and every Conversions API addon on the shopper's Consent Mode v2 choice [1]. - It is disabled by default, so a store that upgraded and changed nothing still sends server-side events regardless of the consent choice [1]. Read that before anything else on this page.
- It works with Magento's Cookie Restriction Mode and with external consent platforms [1].
- The consent state is stored on the order, so an order sent later by cron is judged on the consent the shopper actually gave at checkout [1].
- All nine Conversions API addons follow the setting. Seven of them, Pinterest, Snapchat, Klaviyo, Reddit, Microsoft Ads, X and TikTok, word it as gated on the shopper's advertising consent with order events judged on the consent stored with the order; Meta's entry records the same fix in shorter wording [1].
- The OpenAI Ads addon follows the setting too. It adds an option to report denied-consent events with OpenAI's opt-out flag, disabled by default, and tells you to confirm this is permitted for your store before enabling it [2].
-
Log consent state for enabled Measurement Protocol eventswrites the Consent Mode v2 states in effect when each event was sent intovar/log/ga4.log, and it needs both Measurement Protocol tracking and file logging switched on [1].
What your server is sending today
Start with the uncomfortable version of the current state, because it is the one that is true for most stores. If you upgraded to v1.17.4 or v1.17.5 and touched no settings, your server-side events still go out regardless of the consent choice. The gate is opt-in and disabled by default [1].
That distinction matters when privacy or legal asks. "The extension supports consent gating for server-side events since v1.17.4" is a statement about the software. "Our store gates them" is a statement about your configuration, and only the second one answers what was asked. Google's own consent documentation is blunt about the equivalent default on its side: "By default, no consent mode values are set" [3].
What does the gate actually cover?
The GA4 change log states the scope in one line: the setting gates the GA4 Measurement Protocol and every Conversions API addon on the shopper's Consent Mode v2 choice [1]. Separated into the layers a Magento store actually runs:
| Layer | Under this setting |
|---|---|
| GA4 Measurement Protocol events from your server | Gated, once the setting is on [1] |
| Conversions API addon server-side events | Gated, per the change log's scope wording [1] |
| Order events pushed later by cron | Judged on the consent stored with the order [1] |
| Browser tags and the banner sequence | A separate mechanism, not this setting |
The browser row is the one people conflate with the others. Client-side tag behavior under Consent Mode v2, the default-then-update sequence and the banner wiring are a different subject, and our guide to Consent Mode v2 on Magento 2 is where that half lives.
Now the part that pays for the page. All nine addons follow the setting, and seven of them word it in their own v1.17.4 entries more narrowly than the GA4 change log does: the addon's server-side events are gated on the shopper's advertising consent, and order events are judged on the consent stored with the order [1]. Those seven are Pinterest, Snapchat, Klaviyo, Reddit, Microsoft Ads, X and TikTok. Meta's entry records the same fix in shorter wording [1].
The OpenAI Ads addon follows the setting too: with it switched on, a denied-consent event is dropped. What its v1.17.4 block adds is an option, Report Denied-Consent Events With Opt Out, disabled by default, that sends such an event with OpenAI's opt-out flag instead, so the conversion is still counted while the visitor is excluded from user-level personalization. It carries its own instruction: confirm this is permitted for your store before enabling [2]. If that addon is live on your store and the option is on, denied-consent events are sent flagged rather than withheld, and confirming that is permitted is a separate action item from everything else here.
Where the setting lives, and how far the documentation goes
This section is shorter than you want it to be, and the reason is worth publishing. The setting is documented in the v1.17.4 change log [1]. It has no write-up in the configuration reference, so there is no field group to screenshot and no menu path to quote. What the documentation supports is this much: the setting belongs to the GA4 PRO configuration, alongside the Measurement Protocol options, and the Measurement Protocol path as a whole is a PRO capability [1].
So the instruction is: open the GA4 PRO configuration and switch Require Visitor Consent for Server-Side Events on, alongside the Measurement Protocol options. If it is absent, check your version first and your edition second, since the Measurement Protocol path and consent-state logging are both PRO capabilities [1]. Our guide to upgrading Magento 2.4.x without breaking your analytics covers getting current on a store with patches in flight.
One prerequisite comes from a choice you have probably already made. The gate works with Magento's Cookie Restriction Mode and with external consent platforms [1], the same pair the Consent Management Method setting offers, so it is worth confirming which one your store is set to. The full privacy-control inventory is in our article on the PII controls that actually exist.
Why the consent state rides on the order
Server-side order events on Magento 2 are frequently not sent when the order is placed. They are queued and pushed by cron. That creates a timing problem specific to platforms built this way: if the consent decision were read at push time, the code would be asking about a session that no longer exists, and the answer would depend on what the cron process happened to see. The v1.17.4 change removes the question. The consent state is stored on the order, so an order sent later by cron is judged on the consent the shopper actually gave at checkout [1]. The decision travels with the record it belongs to, which is also what makes the log worth reading.
How do you confirm it is gating?
Turning the setting on is one step. Proving it from an artifact is the step that survives a review. Log consent state for enabled Measurement Protocol events writes the Consent Mode v2 states in effect when each event was sent into var/log/ga4.log, and it requires both Measurement Protocol tracking and file logging to be on [1]. Two prerequisites, both easy to miss, and an empty log file is the usual symptom of forgetting one.
- Switch on Measurement Protocol tracking, file logging, and consent-state logging.
- Place a test order in a session where you accept everything, and read the states recorded for its events in
var/log/ga4.log. - Place a second test order in a fresh session where you decline, and compare what the log shows.
- Let cron run, then check that the order pushed later carries the state from its own checkout rather than from the current session.
Reading the log, DebugView and the order grid column are covered in our guide to verifying GA4 events on Magento 2, and the wider configuration these settings sit inside is in the complete setup guide.
One thing the log cannot tell you: which consent signal the Measurement Protocol half of the gate keys on. Our documentation does not say. The gating happens in the extension, before the request leaves your server, and that is as far as the claim goes.
What does it cost you in data?
Fewer events reach GA4 and fewer reach the ad platforms. That is the trade, stated without a percentage, because a percentage would be invented: the size of it turns on your traffic mix, your banner design and how many visitors decline.
Where you will see it is in reporting that already has a consent-shaped hole. Declined-consent visitors are one documented cause behind purchases arriving with no channel attached, and our article on purchases landing as Unassigned puts that cause in its place among the others. Switching this on moves events out of your reports on purpose, so record the date. Six months later, a step change in a chart with no explanation attached costs someone a day.
On the obligation side, Google's guidance for advertisers with EEA traffic is that they must collect consent for the use of personal data from end users based in the European Economic Area and share consent signals with Google [4]. Whether your server-side events sit inside that obligation is a question for whoever owns privacy at your company, with your own counsel. The setting gives them something to say yes or no to.
If you run no consent platform and plan none, the Consent Mode v2 module sets and updates Google's Consent Mode v2 parameters, and its own documentation states that it is not a full Cookie Management Platform and is aimed at merchants without one [5]. Its v1.17.5 entry is a reason to be current: an unreadable stored consent record previously meant the consent default command was never issued, which lets tags behave as though consent had been granted [5]. That fix belongs to the Consent Mode v2 module rather than to GA4 PRO.
FAQ
Does turning this on satisfy my legal obligations?
No. What the software does is bounded: since v1.17.4, with Require Visitor Consent for Server-Side Events switched on, the extension gates the GA4 Measurement Protocol and every Conversions API addon on the shopper's Consent Mode v2 choice [1]. Whether your configuration and data handling meet a legal standard is a judgment for your own counsel.
I upgraded to v1.17.5. Is the gate on?
No. It is disabled by default, so a store that upgraded and changed nothing still sends server-side events regardless of the consent choice [1]. The upgrade gives you the switch and leaves it where it was.
What happens to an order that cron pushes tomorrow?
The cron run does not re-ask the question; the consent state stored on the order settles it [1].
Do all the addons behave the same way?
On the gate, yes: all nine follow the setting, seven of them documented in the advertising-consent wording above and Meta in a shorter form [1]. The OpenAI Ads addon follows it too and adds its own opt-out-flag option, off by default, which sends a denied-consent event flagged rather than withholding it [2].
Does this change anything about my cookie banner?
Not by itself. This setting governs what your server sends, and the banner half is the subject of the Consent Mode v2 implementation guide linked above.
The server-side path this setting governs, including the Measurement Protocol and consent-state logging, is a PRO capability of the Magento 2 Google Analytics 4 extension, currently v1.17.5, released September 16, 2026. Stores without a consent platform can pair it with the Google Consent Mode v2 extension, which sets and updates Google's Consent Mode v2 parameters, is not a full Cookie Management Platform, and is aimed at stores that do not run one and do not intend to [5].
Switch the setting on, place two test orders with opposite answers, and read var/log/ga4.log. Until those two orders show different consent states, you have a feature and not a control.
Sources
- WeltPixel Google Analytics 4 User Guide and Change Log, v1.17.5, September 16, 2026, retrieved September 21, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
- WeltPixel OpenAI Ads Addon User Guide and Change Log, v1.17.4, September 1, 2026, retrieved September 21, 2026, https://docs.weltpixel.com/OpenAIAdsAddon/User-Guide-WeltPixel-OpenAI-Ads-Addon.html
- Manage consent mode, Google Tag Platform documentation, page last updated July 30, 2026, retrieved September 21, 2026, https://developers.google.com/tag-platform/security/guides/consent
- Updates to consent mode for traffic in the European Economic Area, Google Ads Help, retrieved September 21, 2026, https://support.google.com/google-ads/answer/13695607
- WeltPixel Google Consent Mode v2 User Guide and Change Log, v1.17.5, September 16, 2026, retrieved September 21, 2026, https://docs.weltpixel.com/GoogleConsentModeV2/User-Guide-WeltPixel-Google-Consent-Mode-V2.html