Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
Server-side tracking sends measurement data from a server you control, rather than directly from the shopper's browser to each analytics and advertising vendor. The browser sends one stream of events to your tagging server (for example a Google Tag Manager server container on your own subdomain), which then forwards the data you choose to each vendor. Stores use it to reduce browser script weight, gain control over what data leaves the site, and make conversion data more durable. It does not remove the need for consent; consent choices must flow through to the server and be respected there.
This guide compares client-side and server-side tracking, explains how the setup works, and gives a consent-aware checklist for implementing it on an online store.
How server-side tracking works
In a typical client-side setup, the browser loads separate scripts for analytics, each ad platform and other tools, and each sends data directly to its vendor. With server-side tagging:
- The browser loads one tag (for example the Google tag) configured to send events to your server container's URL.
- The server container runs on infrastructure you control. Google recommends Cloud Run for Tag Manager server containers, and other environments are supported.
- "Clients" in the server container receive incoming requests and turn them into events. Google's documentation describes clients as adapters between the software on the shopper's device and your server container.
- Server-side tags then send the data you choose to each vendor, such as Google Analytics, Google Ads or other platforms through their server APIs.
Google strongly recommends serving the container from a first-party subdomain of your store. Many stores also send order events directly from the commerce back end, for example when an order is placed or refunded, so that conversions do not depend on the browser at all.
Client-side vs server-side: a comparison
| Factor | Client-side tracking | Server-side tracking |
|---|---|---|
| Where vendor requests come from | The shopper's browser, one per vendor | Your server container |
| Browser script weight | Grows with each vendor tag | Fewer vendor scripts in the browser |
| Control over data sent | Each vendor script collects what it is built to collect | You decide which fields reach each vendor and can remove or redact others |
| Resilience to browser restrictions | Affected by blockers and cookie limits | Generally more durable, especially from a first-party domain; not immune |
| Cost and operations | Vendor hosting; little infrastructure | Hosting costs that scale with traffic; monitoring and maintenance |
| Debugging | Visible in browser tools | Needs server-side preview and logging |
| Consent handling | Tags read consent state in the browser | Consent state must be passed to the server and enforced there |
The comparison is not one-sided. Server-side tracking adds infrastructure, cost and a new place for errors. It is most useful for stores with significant advertising spend, several marketing platforms, or a need for tighter control over data sharing.
What server-side tracking does not do
- It does not make tracking compliant by itself. Moving collection to a server changes where data flows, not whether you are allowed to collect it.
- It does not recover data from shoppers who declined consent. Using a server to work around a refusal undermines the consent itself.
- It does not fix bad event design. Wrong product IDs, duplicate purchases and missing values still need to be fixed at the source.
Consent with server-side tagging
Google's consent mode defines four signals: ad_storage, analytics_storage, ad_user_data and ad_personalization. According to Google's documentation for server-side tagging, consent mode is configured in the web container: the Google tag passes the shopper's consent state to the server container with each request, and Google's server-side tags adjust their behavior accordingly. For example, when ad storage is denied, Google Ads conversion tags do not read or write advertising cookies.
Non-Google tags in the server container do not automatically follow these signals. You need to read the consent state in the server container and add conditions so each vendor tag fires only when the relevant consent is granted.
Consent rules differ by jurisdiction, and the EU and UK generally require consent for non-essential cookies and similar technologies. This is general information, not legal advice; confirm your requirements with qualified counsel.
Consent-aware setup checklist
Plan
- List every tool that receives tracking data today, the events it gets and the consent category it belongs to.
- Define your event schema: event names, product identifiers, values, currency, and a unique event ID for each purchase.
- Decide which events come from the browser and which come from the back end (order placed, refund, subscription renewal).
Build
- Deploy the server container on a first-party subdomain with HTTPS, and plan hosting capacity for peak traffic.
- Point the Google tag at the server container URL.
- Configure consent mode in the web container with defaults that match your markets, including stricter defaults by region where needed.
- Make sure your consent platform updates consent state before or alongside the first measurement events.
- In the server container, add consent conditions for every non-Google tag.
- Remove or hash personal data fields that vendors do not need, and send hashed customer data to ad platforms only where consent and terms allow it.
- Use the event ID to deduplicate when the same conversion is sent from both browser and server.
Verify
- Test every consent combination (all granted, all denied, analytics only, ads only) and check what each vendor receives.
- Reconcile tracked purchases against back-end orders for a sample period; investigate gaps and duplicates.
- Check that browser-side vendor scripts you replaced are actually removed.
- Set up monitoring for server errors, request volume and cost.
- Document the data flows for your privacy notice and records of processing.
Implementation notes for Magento stores
On Adobe Commerce and Magento Open Source, the browser data layer usually comes from the theme or a tracking extension, and back-end events can be sent from an observer or message queue consumer when orders are placed, invoiced or refunded. Sending purchases from the back end avoids losing conversions when a shopper closes the confirmation page early, and it makes refunds easier to report. Keep product identifiers identical across the data layer, server events and product feeds.
Clean server-side data also helps elsewhere: reliable purchase events improve A/B test reporting, which our conversion rate optimization guide depends on, and consistent order and session signals feed the checks described in our ecommerce fraud prevention guide.
FAQ
Does server-side tracking make my site faster?
It can reduce the number of vendor scripts in the browser, which helps page performance. The size of the benefit depends on how many scripts you actually remove.
Do I still need a cookie banner?
Where consent is required, yes. Server-side tagging changes how data is routed, not the legal basis for collecting it.
Is Google Tag Manager the only option?
No. Other tag management and event-routing services offer server-side collection, and some stores send events directly to vendor APIs from their back end. The consent checklist applies to all of them.
Next steps
If you want back-end purchase events, a clean data layer and consent-aware server-side tagging on Adobe Commerce, Mistri's Adobe Commerce development services cover the store-side implementation and testing.
Sources
Google: An introduction to server-side tagging; Google: Server-side tagging and consent mode; Google: Set up consent mode.
