GDPR and Magento 2 GA4 Tracking: The PII Controls That Actually Exist

TL;DR

No Magento module makes a store GDPR compliant, whatever a feature list implies. What a module can do is decide which personal data leaves your store, in what form, and under which consent signal. The WeltPixel Google Analytics 4 extension spreads that decision across four admin sections, which is why most stores have never seen all of it at once. This article puts it in one place: what each control does, what it does not touch, and which defaults send more than a European store probably intends.

Key Takeaways

• Enhanced Conversions is the setting that moves real customer data. When the inclusion/exclusion option is left at its default of No, the extension sends all parameters, which is the full nine in the picker: email, phone, first name, last name, street, city, region, country, postal code [1].
• The consent management method (PRO) has two documented positions. Magento cookie restriction mode keeps GTM from loading until the shopper accepts, which is Basic Consent Mode. External CMP loads GTM always and hands consent to Cookiebot, OneTrust or CookieYes, among others, which is Advanced Consent Mode and the documented recommendation for EEA stores [1].
• WeltPixel's documentation calls pre-hashing optional, on the grounds that Google hashes what it receives [1]. Turning it on means some of those parameters are hashed before they leave your store [1].
• Consent state logging (PRO) writes the Consent Mode v2 states in effect when each Measurement Protocol event was sent into var/log/ga4.log, and needs both Measurement Protocol tracking and file logging enabled [1].
• Server-side volume narrows two ways that have nothing to do with consent: track only selected customer groups [1], and, on the API addons, send only for logged-in customers.
• IP anonymization lives under GTM API Configuration, not under any section with "privacy" in the name, which is the most common reason a store audit misses it [1].
• The Google Consent Mode V2 extension is a separate paid product for merchants with no CMP. It sets and updates Google's consent parameters and does nothing wider [2].

Nobody ships GDPR compliance in a module

Compliance is a posture your business holds: a lawful basis, a privacy notice that matches reality, a retention policy, a way to answer a subject access request. Software sits underneath all of that and answers one narrower question. Which data does this store transmit, to whom, and when.

That question is answerable from the Magento admin, and it is worth answering before your next audit rather than during it. Four admin areas hold the switches:

IP anonymization: one switch, and it stops there

The setting is I.P Anonymization [ Yes / No ] under GTM API Configuration. The documentation describes it as requesting that all user IP addresses are anonymized, which helps site owners meet their own privacy policies or the recommendations of local data protection authorities that discourage storing full IP information [1].

Read that scope literally. It governs the IP address, and has no effect on the email address flowing through Enhanced Conversions, the Magento user ID, or the customer group riding along as a user property. Stores switch it on, tick a box on an internal checklist, and leave a checkout email address going to Google Ads on every order. Those are unrelated pipes.

Which consent method should your store run?

The extension asks PRO stores to choose one of two documented positions, since the Consent Management Method setting is a PRO feature [1].

Magento Cookie Restriction Mode is the default. It uses Magento's built-in cookie banner, and until the shopper accepts, the GTM container does not load, so no container tags fire [1]. The documentation labels this Basic Consent Mode. One PRO setting sits outside the container: the client ID fallback can load a lightweight gtag.js instance to retrieve the client_id when the _ga cookie is unavailable [1].

External CMP is for stores that already run a third-party consent platform. The documentation names Cookiebot, OneTrust and CookieYes as examples. GTM always loads, and the CMP drives Google Consent Mode v2. The documentation labels this Advanced Consent Mode and recommends it for the EEA [1].

The practical difference sits in what Google receives from a shopper who declines. Under the advanced pattern, tags load in a denied state and send consent signals without cookies, which is the input Google's modelling uses to fill gaps [3]. Under the basic pattern, a decline produces no signal at all, so there is nothing for Google to model from.

Google made Consent Mode v2 a requirement for sites using Google services in the European Economic Area starting in March 2024 [2]. If your store serves the EEA and you are still on cookie restriction mode because it was the default, that is worth revisiting deliberately rather than inheriting. The implementation side of this, including the module choice and the failure modes, is covered in the Consent Mode v2 implementation guide for Magento 2.

Enhanced Conversions is where real customer data leaves the store

Everything above is about signals. This section is about personal data.

Enabling Enhanced Conversions populates the dataLayer with the email address and phone number used during checkout, which the Google Ads Conversion Tracking tag then sends to Google Ads [1]. Later releases extended the same user-provided data variable to customer name and address details, and the same object can be sent to Google Analytics 4 and used for Enhanced Conversions for Leads [1]. The setup walkthrough lives in our guide to Google Ads Enhanced Conversions on Magento 2; this section is about what it sends.

Three settings sit on top of that, and the third one is the one to look at first.

Pre-hash Enhanced Conversions User Data is a PRO setting, and it hashes some of the parameters before they are sent. WeltPixel's documentation calls this optional, on the grounds that Google hashes what it receives [1]. The reason to enable it anyway is that the parameters it covers leave your infrastructure already hashed [1]; the docs do not enumerate which.

Enable inclusion / exclusion for Enhanced Conversion data switches on the attribute picker. And here is the default worth writing down: leaving this at No sends all parameters [1]. A store that enabled Enhanced Conversions two years ago for the conversion accuracy, and never opened this screen again, is sending the full set.

Select Enhanced Conversion Attributes is the picker itself. Nine attributes are selectable [1]:

That second column is our editorial judgment from working on merchant accounts, not a ranking Google publishes. Data minimisation is a principle you can implement on this screen. Pick the identifiers that measurably improve matching for your account, drop the rest, and write down why in the same document that holds your privacy notice.

What does the server-side layer actually send?

Measurement Protocol tracking is PRO only, and it carries its own set of toggles under Admin > WeltPixel > GA4 PRO [1].

Send User-ID attaches the User ID, which is what connects behavior across sessions and devices [1]. Send User Provided Data (Enhanced Conversions) attaches a user-provided data object to server-side purchase events. Send User Properties with enabled events can carry browser, browser version, platform and customer group, which then become custom dimensions in GA4 [1].

Two narrowing controls reduce volume without touching consent. Track Only Specific Customer Groups limits server-side events to selected groups, which is how stores keep wholesale and staff orders out of their marketing analytics. On the server-side API side, each addon's own guide documents a logged-in-only option and customer-group scoping.

Then there is the audit artifact. Log consent state for enabled Measurement Protocol events writes the Consent Mode v2 state values as they stood at send time into var/log/ga4.log, and it needs both Measurement Protocol tracking and file logging switched on [1]. When someone asks what a server-side event sent for a given order carried, and under which consent state, that file is the answer; client-side tags are out of its scope.

One phrasing point, since this is where marketing copy usually overreaches. Under Magento Cookie Restriction Mode the extension gates the GTM container and its frontend pixels; under External CMP that job belongs to your CMP [1]. Measurement Protocol events are sent by your Magento server, and the log records the consent state alongside them, which is a different thing from gating them.

Where does the separate Consent Mode v2 module fit?

The Google Consent Mode V2 extension for Magento 2 is a different product with a different licence, and its documentation draws its own boundary: the extension is not a full Cookie Management Platform, and only serves to set and update Google's specific Consent Mode v2 parameters. It is aimed at merchants who do not have a CMP and do not intend to implement one [2].

What it does provide: a default consent state, a consent form shown as a popup or an insertable Magento widget, a configurable default toggle position, optional grouping of the parameters into two labelled groups (Marketing, Analytics and Personalization; Functionality and Security), URL passthrough for cases where ad_storage is denied, and a wp-consent-popup-open class you can put on a footer link so shoppers can reopen the form later [2]. Compatibility runs Magento 2.3.0 through 2.4.9, composer-only [2].

So the decision has a clean answer. If you run Cookiebot, OneTrust or CookieYes, set the GA4 extension to External CMP and stop reading here. If you run nothing, this module covers the Google parameters and leaves the wider cookie inventory question open, which for many small EU stores is the honest gap to acknowledge rather than paper over.

FAQ

Does enabling IP anonymization make my Magento store GDPR compliant?

No. It requests that Google anonymize users' IP addresses, and it covers nothing else [1]. Enhanced Conversions, user IDs, and customer group dimensions are separate settings on separate screens, and compliance itself is a legal posture rather than a configuration state.

Which Enhanced Conversions attributes should a European store send?

Start from email, add phone if your account shows better matching with it, and leave the rest off unless you can point at a measured improvement. The picker only appears after you set Enable inclusion / exclusion for Enhanced Conversion data to Yes; the default of No sends all parameters, which is the full nine in the picker [1].

Do I need the Google Consent Mode V2 extension if I already have a CMP?

No. Set the GA4 extension's Consent Management Method (PRO version) to External CMP and let the platform you already pay for handle consent. The Consent Mode V2 module exists for stores with no CMP at all, and its documentation states plainly that it is not a full Cookie Management Platform [2].

Where can I see what consent state an order was tracked under?

In var/log/ga4.log, if you enable Log consent state for enabled Measurement Protocol events along with Measurement Protocol tracking and file logging [1]. The entry records what a server-side event sent for a given order carried, and under which consent state; client-side tags are out of its scope.

If you are auditing this configuration and want the full control surface in one extension rather than spread across a CMP, a tag manager and a plugin you inherited, the WeltPixel Google Analytics 4 PRO extension holds all of the settings described above, including the attribute picker and the consent state log.

Sources

1. WeltPixel Google Analytics 4 User Guide, v1.17.3, August 3, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
2. WeltPixel Google Consent Mode V2 for Magento 2 User Guide, v1.17.0, May 18, 2026, https://docs.weltpixel.com/GoogleConsentModeV2/User-Guide-WeltPixel-Google-Consent-Mode-V2.html
3. Google, "Set up consent mode on websites," tag platform security guides, accessed August 26, 2026, https://developers.google.com/tag-platform/security/guides/consent