Server-Side Purchase Events Now Honor Visitor Consent
Starting with Pixel Manager version 1.62.0, server-side purchase events (server-to-server / Conversions API) respect the consent choice your visitors make in the browser. If a visitor declines consent, the purchase event is no longer sent to the ad and analytics platforms through the server.
This is a behavior change for stores that use explicit consent management, and we want you to understand exactly what changes, why we made this decision, and what to do if your situation requires the previous behavior.
What Changes
Until now, the Pixel Manager handled consent differently on the two tracking paths:
- Browser pixels have always honored consent. When a visitor declines, no browser pixel fires. That does not change.
- Server-side purchase events were sent for every order, regardless of the visitor's consent choice. That changes now.
With version 1.62.0, the Pixel Manager captures the visitor's consent state during checkout and stores it with the order. When the purchase event is later sent from your server, even days later for delayed payment methods like bank transfer, the stored consent decides whether the event goes out.
The check is category-aware per destination:
- Google Analytics 4 purchase events require statistics consent.
- Meta (Facebook), TikTok, Snapchat, Pinterest, Reddit, and OpenAI purchase events require marketing consent.
So if a visitor accepts statistics but declines marketing, your GA4 revenue data stays complete while the ad platforms correctly receive nothing.
Why We Made This Change
Enabling a Conversions API is about recovering conversions that are technically lost: ad blockers, browser privacy features, or a thank-you page that never finished loading. It was never meant to be a way around a visitor's explicit "no".
Three reasons drove the decision:
- It is what the law expects. Consent obligations like the GDPR attach to the processing of personal data, not to the transport. A declined consent does not become irrelevant because the request originates from your server instead of the visitor's browser.
- It is what the platforms require. Meta's terms and Google's EU User Consent Policy both require a lawful basis for the data you send them. Sending purchase data of visitors who declined consent violates those policies too.
- It is what you would expect. The browser side always honored consent. The server side behaving differently was surprising, and surprises in compliance are the worst kind.
Who Is Affected
The change is only noticeable on stores that run the Pixel Manager in explicit consent mode together with a consent management platform. Visitors who decline consent on those stores no longer produce server-side purchase events.
Stores using implicit consent are practically unaffected, because consent is granted by default unless the visitor opts out.
Orders without a stored consent state, such as manually created orders, marketplace imports, or orders placed before the update, are sent exactly as before.
Your Reports Stay Honest
Two details we took care of so your numbers keep making sense:
- Tracking accuracy: Orders from visitors who declined all consent categories are excluded from the payment gateway accuracy statistics. They cannot be tracked by any pixel, so counting them would only make your accuracy look worse than it is. These orders are marked accordingly on the order itself.
- Refunds: If a purchase event was withheld because of consent, the matching refund event is withheld too. The platforms never receive a refund for a purchase they never saw.
Every withheld event is also written to the Pixel Manager logger, so you can always see exactly why an event was not sent.
See the Impact on Your Store
The payment gateway accuracy report shows you exactly how many orders came from visitors who declined all consent, and what share of your total order volume that is, for any period you select. The report's chart also shows the affected orders per day.
This turns the decision below into an informed one: if the share is negligible, you accept it and move on. If it is significant, you know precisely how many conversions are at stake.
If You Need to Send Events Regardless of Consent
Some merchants operate in jurisdictions or under legal assessments where sending server-side events independently of the visitor's consent choice is permissible. That decision belongs to you as the data controller, not to us.
For that case the existing setting Always Send Server-Side Events is the override: when enabled, server-side events, including purchases, are sent regardless of the consent state. If you have server-side tracking active and this setting is off, the Pixel Manager will also show you an opportunity card so you can make a deliberate choice.
For Developers
Two filters give you fine-grained control:
pmw_s2s_require_consent_snapshot: returntrueto also suppress purchase events for orders that have no stored consent state (strict mode).pmw_skip_s2s_purchase_event: unchanged, still lets you skip the server-side purchase event for specific orders.
The consent snapshot is stored on the order in the _pmw_consent_snapshot meta field, and withheld events are recorded in _pmw_s2s_purchase_consent_suppressed.
Available in Version 1.62.0
The new behavior ships with Pixel Manager version 1.62.0 and applies automatically. There is nothing to configure: honoring your visitors' choice is the default, and the override exists for those who need it.
Interested to get updates?
Sign up to our monthly newsletter today.Happy (and compliant) tracking! 🎯
