TL;DR
Adding server-side tracking to a Magento 2 store changes the route events take to Google, and leaves your store's own record of them exactly as it was. The WeltPixel GA4 extension keeps the client-side dataLayer and a generated GTM container as the base layer, and GA4 PRO adds Measurement Protocol delivery on top. Most of the setup problems merchants hit after switching are configuration problems that existed before the switch: an unpublished container, a stale container import, orders parked in an excluded status, or the wrong currency. Server-side delivery fixes ad blockers and browser restrictions. It does not fix any of those.
Key Takeaways
- The extension's primary server-side path is the GA4 Measurement Protocol, configured under
Admin -> WeltPixel -> GA4 PRO -> Enable Measurement Protocol Tracking Configuration. - Server-side GTM container JSON generation is a separate, beta capability added in v1.14.7 for merchants who already run their own server container.
- Client-side and server-side run together. Deduplication is a setting, either pausing the matching GTM tags or turning on "Automatically disable data layer for enabled measurement protocol events".
- Never pause the main "WP - GA4" tag when deduplicating. That tag carries the client-side events that have no server-side twin.
- STANDARD (
weltpixel/module-ga4) covers the full client-side dataLayer and GTM set. Everything server-side, plus all nine client-side pixel integrations and Hyvä support, lives in PRO (weltpixel/module-ga4-pro). - For the GA4 extension, Composer is the official and only supported install route since v1.16.0 (2026-01-07).
- Magento's own release notes matter here. 2.4.8 and 2.4.9 both shipped Content Security Policy fixes that affect whether Google tags load at all [1][2].
What server-side tracking does not fix
Start here, because this is where most of the disappointment comes from. If you have ever watched an order sit in the Magento admin and never appear in GA4, you already know the shape of the problem, and you probably assumed a server-side pipeline would end it.
Sometimes it does. Often it does not, because the gap has a different cause.
A wrong or missing dataLayer. The Measurement Protocol purchase payload is built from the frontend event and stored, so the cron job can push it later for orders that were not sent at checkout time. The server-side path depends on frontend correctness. If your product data is wrong in the dataLayer, it is wrong on the way out of your server too.
Currency. GA4 PRO adds a setting controlling which currency the extension reports. Sending a misconfigured currency from a server produces the same wrong revenue as sending it from a browser, just more reliably.
Consent. This one is worth being precise about, because a lot of writing about server-side tracking is loose here. In the WeltPixel extension, the GTM container and the frontend pixels honor whichever consent management method you configure, and the extension can log consent state alongside server-side events so you can inspect it while debugging. That is the accurate description. Server-side delivery is not itself a consent feature, and no server-side pipeline should be sold to you as one.
Orders in an excluded status. If you exclude certain order statuses from tracking, those orders are not sent while they sit in one. A cron job re-pushes them once they leave, which means the fix usually lives in your order workflow.
Platform-side reporting rules. GA4 changed on June 15, 2026, so that Ads cookie and identifier collection from the GA4 tag is governed solely by your Google Ads Consent Mode settings [3]. On August 11, 2026, conversion lookback windows became configurable in GA4 [4]. Both change your reported numbers. Neither is something a Magento module can override.
Server-side is a delivery change, not a data-quality change.
What actually changes when events leave your server?
Three things, and they are worth separating.
First, coverage. The extension's own documentation gives the reason plainly: server-side events are not affected by ad blockers or browser restrictions, and the Measurement Protocol path is there to avoid missing and duplicated orders. That is the whole pitch, and it is a narrow one.
Second, verification. Once the Measurement Protocol is on, the Magento order grid gains a column marking which orders were actually sent. The extension also writes a ga4.log file and can point traffic at GA4's Debug Collect endpoint while you test. So the question "did this order get sent" stops being a matter of staring at GA4 realtime and becomes a column you can sort. If you are still debugging on the browser side, the missing transactions and revenue guide covers that half.
Third, the event set narrows. The client-side dataLayer covers the full ecommerce funnel. The Measurement Protocol path covers Purchase, Refund, Sign Up, Login, View Item, View Item List, Select Item, Search, Add to Wishlist, Add to Cart, View Cart, Begin Checkout, Add Payment Info and Add Shipping Info. Anything outside that list stays client-side only. The full event reference lists what the extension tracks across both routes.
There is a fourth thing that is not about the extension at all. Magento itself has been changing what browsers are allowed to load. Version 2.4.8 added region1.analytics.google.com to the Content Security Policy allow list when Google Analytics is enabled, which had been producing CSP errors for EU visitors, and it fixed the GTM add-to-cart dataLayer push for configurable products [2]. Version 2.4.9 made the GA module's CSP whitelist independent of the Adwords module [1]. Payment pages have run CSP in restrict mode since 2.4.7 for PCI DSS 4.0 (other pages stay in report-only mode). If your client-side tags broke on a specific date and nobody touched GTM, check your Magento version before you check anything else, and see the patching guide for the current release cadence.
The free module, STANDARD, and PRO: what each layer adds
There are three layers, and the honest description of the first one is short.
The free GTM module. It lives on GitHub at Weltpixel/magento2-weltpixel-google-tag-manager and installs with Composer alongside the shared WeltPixel Backend module, then php bin/magento module:enable WeltPixel_GoogleTagManager and setup:upgrade. Its public README documents installation and dependencies only [8].
STANDARD, weltpixel/module-ga4. The full client-side model: a GA4 dataLayer plus a GTM container configuration you export from Magento as JSON and import into GTM. This is the direct successor to the older Universal Analytics Enhanced Ecommerce GTM extension, which is why merchants searching for "Magento 2 enhanced ecommerce" land on GA4 documentation now.
PRO, weltpixel/module-ga4-pro. Everything server-side sits here, along with a long list of things that are not: all nine client-side pixel integrations (Meta, TikTok, Reddit, Microsoft Ads, X, Klaviyo, Pinterest, Snapchat and OpenAI Ads), Google Ads enhanced conversions, new-customer and cart data, GS2 cookie support, currency selection, order-status exclusion, category depth and exclusion rules, UTM persistence, Redis caching, multi-property sending, the order grid column, client ID fallback, the consent management method setting, and consent-state logging. Hyvä support is PRO only, delivered through two compatibility modules that need no configuration of their own. If you are on Hyvä, start with the Hyvä compatibility notes.
Composer has been the official and only supported install route since v1.16.0 on 2026-01-07. The extension supports Magento 2.3.0 through 2.4.9, with 2.4.9 and PHP 8.5 supported since v1.17.0. If you are still deciding between integration approaches at all, the integration comparison is the better starting point than this article.
How do client-side and server-side events avoid double counting?
They coexist by default, which means a purchase can reach GA4 twice unless you tell it not to. The extension gives you two ways to handle that.
The first is manual: pause the GTM tags that correspond to events you have enabled for the Measurement Protocol. The second is a single setting, "Automatically disable data layer for enabled measurement protocol events", which suppresses the dataLayer push for exactly those events. The setting name is long and it sits in the GA4 PRO section. It works.
One rule survives both approaches: do not pause the main "WP - GA4" tag. It carries the client-side events that have no Measurement Protocol equivalent, and pausing it silently removes them.
Then the part everyone skips. When you change extension configuration, regenerate the container JSON, re-import it into GTM, and then publish the container, because an imported but unpublished container does nothing at all. The regenerate step is easy to forget because the old container still works, right up until the thing you changed is the thing you are debugging.
Measurement Protocol, sGTM containers, and the Data Manager API
These three get conflated constantly, so here is where each one sits.
The Measurement Protocol is Google's established server-to-server route into GA4 [5], and it is the extension's primary server-side path. You supply a Measurement ID and an API Secret under Admin -> WeltPixel -> GA4 PRO -> Enable Measurement Protocol Tracking Configuration and events go out from Magento.
The Data Manager API is Google's newer server-to-server option, listed in the GA4 what's-new documentation on 2026-05-07 as an alternative to the Measurement Protocol [4][6]. Google has not announced that the Measurement Protocol is going away, and we are not going to guess at a timeline it has not published. For now it is an alternative, not a replacement.
Server-side GTM is a different thing again: a container you provision and host yourself, usually on Google Cloud, which receives events and forwards them onward. GA4 PRO can generate a container JSON for a server container you have already set up, a capability added in v1.14.7 and described in the extension's documentation as beta and aimed at advanced users. The extension does not host a server container for you and does not pretend to. If that is the direction you want, start with creating a server-side GTM container, then sending data to it, a custom domain, and preview and debug before you move it into production.
Do you need first-party tag gateway on top of this?
Google tag gateway for advertisers serves the Google tag from your own domain instead of a Google domain, and forwards measurement events through your infrastructure. Google's Ads help documentation reports an 11% uplift in signals for advertisers who configured it [7].
GA4 PRO can generate a Cloudflare Worker for this, and its documentation is careful in two ways worth repeating. It labels the capability advanced and experimental, and it tells you not to enable Cloudflare's own built-in Tag Gateway feature alongside the generated Worker.
The decision criterion here is your infrastructure. If Cloudflare is already in front of your store and someone on the team is comfortable deploying and debugging a Worker, it is worth testing. If not, the ordering is Measurement Protocol first, then the container hygiene above, then this, because a first-party gateway on top of an unpublished GTM container improves nothing.
FAQ
Does server-side tracking replace Google Tag Manager on Magento 2?
No. The extension's client-side model stays in place: a dataLayer plus a GTM container you import and publish. Measurement Protocol delivery runs alongside it, and you deduplicate the overlapping events with a setting that leaves GTM in place.
Which GA4 events does the extension send server-side?
Purchase, Refund, Sign Up, Login, View Item, View Item List, Select Item, Search, Add to Wishlist, Add to Cart, View Cart, Begin Checkout, Add Payment Info and Add Shipping Info. Events outside that list continue to fire from the dataLayer.
Do I need GA4 PRO for Hyvä?
Yes. Hyvä support is a PRO capability, delivered through two dedicated compatibility modules that require no configuration of their own once installed.
Should I move to the Data Manager API instead of the Measurement Protocol?
Not yet. Google documents it as one option alongside the Measurement Protocol, which remains supported and is what the extension uses [4][5][6]. If Google announces a deprecation, that changes.
Why do my GA4 numbers still disagree with my Magento reports after enabling server-side?
Check the order grid column first to confirm which orders were sent, then check excluded order statuses, then check your GA4 property's conversion lookback window setting, which became configurable on August 11, 2026 [4]. If events are being sent but not landing, the Measurement Protocol troubleshooting guide walks through the usual causes.
If you want the Measurement Protocol path, the order grid confirmation column and the nine client-side pixel integrations on your own store, they ship in the PRO tier of the Magento 2 GA4 extension with GTM server-side tracking.
Sources
- Adobe Experience League, Adobe Commerce 2.4.9 release notes: https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/adobe-commerce/2-4-9
- Adobe Experience League, Adobe Commerce 2.4.8 release notes: https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/adobe-commerce/2-4-8
- Google Analytics Help, changes to Ads data collection from the Google tag (June 15, 2026): https://support.google.com/analytics/answer/17016975?hl=en
- Google Analytics Help, What's new in Google Analytics: https://support.google.com/analytics/answer/9164320?hl=en
- Google for Developers, Measurement Protocol for Google Analytics 4: https://developers.google.com/analytics/devguides/collection/protocol/ga4
- Google for Developers, Data Manager API: https://developers.google.com/data-manager
- Google Ads Help, Google tag gateway for advertisers: https://support.google.com/google-ads/answer/16214371?hl=en
- GitHub, Weltpixel/magento2-weltpixel-google-tag-manager: https://github.com/Weltpixel/magento2-weltpixel-google-tag-manager