TL;DR
The 1.17.4 release moves consent and data quality onto the server, where WeltPixel already sends your conversions. The headline is a Require Visitor Consent for Server-Side Events option that holds the GA4 Measurement Protocol and every Conversions API addon behind the shopper's Consent Mode v2 choice, with the choice stored on the order so a conversion pushed later by cron is judged on the consent given at checkout. It also adds server-side bot filtering, anonymous matching for guest visitors, a Meta server-side PageView, and attribution fallbacks that survive Varnish and Full Page Cache. If you run the OpenAI Ads addon, update: the previous version was silently discarding customer matching data. Nothing changes until you enable it, because every new option is off by default.
For the past year the work on WeltPixel's tracking stack has pointed one direction: move measurement off the browser and onto the server, where ad blockers and tracking prevention cannot reach it. Server-side delivery closed the coverage gap. It also created a new obligation. Once your Magento server is the thing talking to Meta, TikTok, Google and the rest, the server is where consent has to be respected too. That is most of what 1.17.4 is about.
Server-side consent, on your terms
There is a new option in the GA4 configuration called Require Visitor Consent for Server-Side Events. Turn it on and the GA4 Measurement Protocol, plus every Conversions API addon, will only send when the visitor's advertising consent is granted. It reads Consent Mode v2 state, and it works whether you gate consent through Magento's built-in Cookie Restriction Mode or an external consent platform.
The detail that makes it usable is where consent gets read. It is stored on the quote and the order, not pulled from cookies at send time. Plenty of stores push the purchase event from a cron job minutes or hours after checkout, when the shopper's browser and its cookies are long gone. Reading consent at that moment would tell you nothing. Instead the extension records the choice the shopper made at checkout and honors it whenever the event finally goes out.
The option defaults to off. Nothing about your current sending changes until you switch it on.
Bot traffic stays out of your reports
Server-side bot filtering is new across the whole family. The extension keeps a merchant-editable list of user-agent patterns, and traffic matching a known crawler is dropped before it reaches the Measurement Protocol or any Conversions API. The GA4 module and all nine addons share one list, so you maintain it in a single place.
Orders are the deliberate exception. A completed order is a real conversion no matter what user agent submitted it, and cron-pushed orders carry no user agent at all, so orders always send.
This replaces an older client-side bot flag that had a nasty failure mode. Because the flag was rendered into the page, Full Page Cache stored it, and a single crawler hitting an uncached page could poison the cached copy served to every real shopper after it. Filtering now happens per request on the server, where the cache cannot carry one visitor's verdict to the next.
Better matching, fewer conversions lost in the gap
A cluster of changes goes after match quality, the number that decides how many of your server-side events a platform can actually tie to a person.
- Anonymous matching for guests. The Meta and OpenAI Ads addons can send a stable anonymous identifier for visitors who are neither logged in nor have placed a guest order. It sits next to the usual signals instead of replacing them, and both the browser pixel and the server send it, so the platform can stitch the two together. Consent-gated, off by default.
- Meta server-side PageView. PageView is now available as a Conversions API event, selectable on its own and sharing an event ID with the browser pixel so Meta deduplicates the two into one.
- Attribution that survives your cache. utm parameters and the Google click ID are captured from the landing URL into a first-party cookie and read back on the server. Stock Varnish strips those parameters and Full Page Cache drops cookies on cacheable responses, so capturing them early is what lets the attribution arrive at all. There is an equivalent fallback for the OpenAI Ads click ID, so ChatGPT attribution holds up even when the pixel is blocked.
The OpenAI Ads fix worth updating for
If you run the OpenAI Ads addon, treat this update as required. The previous version sent the Conversions API user object with the wrong field names. OpenAI ignores unknown fields rather than rejecting the request, so every call came back a clean 200 while the identifiers inside it were quietly discarded. Matching was running close to blind.
Every identity and location field is corrected now. The guest identifier, which used to be a PHP session ID that changed on every visit and matched nothing, is derived from the customer ID with an email-hash fallback, so the browser and server send the same value. Admin-created and imported orders, previously reported as web conversions with an invented source URL, are now reported as offline. If you have been running OpenAI Ads campaigns against this addon, your real match rate has been lower than your dashboard suggested.
Also fixed
- Zero-priced configurable child items were being duplicated in the server-side purchase and add_payment_info events, which inflated item counts.
- A PHP session could start on anonymous Full Page Cache hits, handing a session cookie to visitors who should never have received one.
- Cookie writes attempted on cron, CLI and admin requests, where no browser exists to receive them, raised "Cannot modify header information" errors.
How to update
Update through Composer as usual, then run setup:upgrade (there is a schema patch for the stored consent state), setup:di:compile, and cache:clean. Suite PRO customers get everything above in the bundle at no extra cost. Because every new option is off by default, the update is safe to apply now and lets you turn features on when you are ready. Full per-module release notes are on docs.weltpixel.com.
Key Takeaways
- Turn on Require Visitor Consent for Server-Side Events in the GA4 configuration to gate every server-side send on Consent Mode v2. Because the consent state is saved on the order, conversions your cron pushes later are judged on the consent the shopper gave at checkout.
- Server-side bot filtering uses one merchant-editable user-agent list shared across GA4 and all nine addons, and real orders are always sent regardless of user agent.
- The Meta and OpenAI Ads addons can now match guest visitors with a stable anonymous identifier, and Meta adds a server-side PageView that deduplicates against the browser pixel.
- If you run OpenAI Ads, update right away: 1.17.4 fixes a bug where the Conversions API user object used the wrong field names, so identifiers were dropped while every request still returned a 200.
- utm and gclid values are captured into a first-party cookie and read on the server, so Varnish and Full Page Cache stop costing you campaign attribution.
- Update with composer update followed by bin/magento setup:upgrade; the consent gate adds a schema patch, and Suite PRO owners get the whole release in the bundle.
- Every new option is off by default, so you can update safely first and decide what to enable afterward.
Frequently asked questions
Does updating to 1.17.4 change how my tracking behaves? No. Every new capability in this release ships disabled. Until you enable the consent gate, bot filtering, or the new matching options, your store sends exactly what it sent before.
Do I have to turn on the consent gate? No. It is optional and off by default. It exists for stores that want server-side sends to follow Consent Mode v2. If you already handle consent another way, you can leave it off.
Which products are included in 1.17.4? The Google Analytics 4 extension in both the free and PRO editions, the Marketing Suite PRO bundle, and the nine server-side Conversions API addons: Meta, TikTok, Reddit, Microsoft Ads (Bing), X (Twitter), Klaviyo, Pinterest, Snapchat, and OpenAI Ads.
Is there anything I must do after updating? Run setup:upgrade, setup:di:compile, and cache:clean. The consent gate adds a database patch, so setup:upgrade is required even if you do not plan to enable it right away.