Measurement and data
Measurement running from the browser sees less every year: because of cookie refusals, ad blockers and browser lifetime limits, some conversions simply never show up in Google Analytics 4 or in the ad accounts. Server-side tracking solves this by not sending the events straight from the browser to Google, but through a collection container running on your own server, where you decide what goes on, in what form and with what consent.
With us this is not put together by a marketer clicking through an interface, but by the team that also builds the webshop. That difference shows exactly where most rollouts get stuck: at the order confirmation event sent from the server, at duplicate-free event identification, at passing the consent state on correctly, and at attribution back in the ad account.
Lost conversions
Measurements blocked or interrupted in the browser are replaced by the event sent from the server. The purchase is recorded even if the browser of the user does not let the Google scripts run.
Short-lived identifiers
Browsers limit the lifetime of cookies written from JavaScript, so a returning visitor shows up as a new user. Served from the server side, that problem disappears.
Consent handling
Consent Mode v2 is not a checkbox but a state that has to be carried through every point of the measurement chain. We handle it consistently between the cookie banner, the container and the server-side forwarding.
One expectation is worth clearing up at the start: server-side tracking is not a tool for bypassing consent. The data of anyone who has not consented to processing for measurement purposes does not travel on in identifiable form; the design of the system ensures that. The gain comes from the data of consenting users arriving complete, not from the data of those who did not consent arriving too.
- A server-side collection point on your own infrastructure. Whether we work with an sGTM container or our own measurement layer, the collection point runs on your server, on your own subdomain and certificate, not on a third-party service. The measurement data does not leave the infrastructure before it is decided where it goes.
- The GA4 e-commerce event chain. Product list views, add to cart, checkout steps and purchase: the whole chain wired in and fitted to the actual data model of the webshop, not to a generic template.
- A developer implementation of Consent Mode v2. The default state, the update and passing consent on to the server-side container, tied to the actual events of the cookie banner.
- Enhanced Conversions. Sharpening Google Ads attribution from the order data, with pre-processing that meets the Google requirements.
- Facebook / Meta Conversions API. Events sent from the server, paired with the browser-side pixel without duplicates.
- Order-based attribution. Where an order can change after the purchase (cancellation, return, later approval), we measure the real, final order state rather than the appearance of the thank-you page.
- Verification and documentation. At handover you get an event map, a test log and the container configuration in writing, so anyone can take it on later, not only us.
There is no single correct implementation of server-side measurement. We build two kinds of solution and, after the survey, recommend the one that fits your system and your traffic. Both run on your server, and in both cases the setup is done by the same team that builds the webshop.
1. An sGTM container on your own VPS
The standard Google server-side Tag Manager container runs on your Ubuntu VPS, on your own subdomain. A familiar GTM interface, plenty of ready-made templates, easy to hand over to another specialist. It is a good choice if many ad systems have to be connected, or if it matters that anyone can take the setup over. In exchange, a separate container has to be run as well.
2. Our own measurement layer
Direct server-side measurement from the code of the webshop, without a separate tracking container, for WordPress, Magento and custom PHP systems alike. Fewer moving parts, lower running costs, and it can measure the final state of an order accurately. It is a good choice when the measurement evolves together with the webshop and there is no need to serve a dozen external systems.
The cost difference usually shows up in running costs: a container on a rented service is charged monthly and scales with the number of requests, while with your own server solutions essentially only the cost of the server remains after a one-off setup fee. The price of a rollout depends on the number of events to measure, the platform and the number of ad systems to connect, so we always give a written quote after a survey.
The large companies know exactly what they are doing. It is no accident that their advertising is so effective: they use server-side tracking, so their campaigns learn and optimise on real data.
Recently a few marketing agencies have also started using server-side tracking with a Google Tag server container. That, however, typically only pays off for larger companies, since it needs a separate server, infrastructure and continuous operation, all of which cost a fair amount.
Our route
We have developed a direct server-side injection solution that works from the existing web server, whether the site runs on WordPress, Magento or custom PHP. There is no separate tracking server and no extra infrastructure, yet the same data quality arrives.
In Hungary we are among the first to use this technology. At present only a handful of development teams in the country have managed to build and roll out server-side tracking that genuinely works in a live environment. This is not a template solution or a plugin, but a system that takes real development knowledge, understood in few places and used effectively in even fewer.
The new GDPR and privacy rules, private browsers and the strict privacy protections of the iPhone and Safari have fundamentally changed the measurement environment. Classic browser-side tracking no longer sees a significant share of purchases.
No feedback
The ad systems never receive the purchase signal, so they do not know which click delivered a result.
The campaigns do not learn
The algorithm optimises on incomplete data, so it targets an increasingly poor audience.
Falling returns
Fewer customers, more expensive ads, a declining return. The gap grows month by month.
Server-side measurement bridges this gap: the purchase reaches the ad systems even when the tracking code never ran in the browser.
The most common questions people ask before requesting a quote, with honest answers, including the times when the answer is that it is not worth it yet.
How much data does my webshop lose with its current measurement?
This cannot be guessed in general, because it depends heavily on the audience, the device mix and the wording of the cookie banner. It is easy to establish, though: compare the order count and revenue seen in GA4 with the order data of the webshop itself for the same period. The difference is the real data loss. We do this free of charge in the measurement audit, before you decide.
Does a small webshop need server-side tracking?
Most of the time it does not pay off straight away. If the webshop is at a few dozen orders a month and there is no meaningful ad spend, more accurate measurement does not bring in what it costs. The line is where the measurement already drives the decisions about ad spend: if the algorithm learns from bad data, part of the ad budget is certainly lost. At that point a rollout usually pays for itself quickly.
Does server-side measurement bypass cookie consent?
No, and it must not. Without consent the data of a user cannot be passed on in identifiable form, whether it would go from the browser or from the server. Anyone who promises otherwise is selling you risk. The advantage of the server-side solution is that the data of consenting users arrives complete, and that you decide which fields leave the system.
What is the difference between Consent Mode v2 and the cookie banner?
The cookie banner is the interface where the visitor decides. Consent Mode is the mechanism that passes that decision on to the Google systems so they can act on it. The two are often wired up so that the banner shows up nicely but the decision never reaches anywhere. In that case the webshop carries the same legal risk and loses data on top of it. During a rollout we always tie the state change to the actual banner events.
Is Consent Mode v2 enough for GDPR compliance?
Not on its own. Consent Mode is a technical tool, not legal compliance. It needs a proper privacy notice alongside it, a genuine choice, the option to withdraw consent, and logging of the consents. We do and document the technical part; the legal wording needs a lawyer, and we do not give legal advice.
Should I run it on my own server or on a rented service?
At lower traffic a rented service starts faster and needs less attention. At higher traffic your own VPS is usually cheaper, because the price of rented solutions grows with the number of requests while the server does not. The other consideration is the data: on your own server the raw event stream stays with you and you decide how much of it goes on to third parties. Since server operation is part of what we do anyway, the own-server route does not mean an extra supplier.
What happens to my existing GA4 data?
Nothing, the earlier data stays, and the measurement continues to arrive in the same GA4 property. What changes is the completeness of the data, so after the switch the numbers are typically higher. It is worth annotating the reports with the date of the switch, otherwise it later looks like new growth when it is really measurement accuracy.
Does it work on top of Shoprenter, UNAS or Shopify?
Where the platform allows your own script and data layer, yes, but hosted systems always limit which events and which parameters can be extracted, especially at the checkout steps. On a custom or self-hosted system (Magento 2, WooCommerce, custom development) the measurement is complete and we can also attribute against the final state of the order. In the survey we always say what will not work on a given platform.
What is duplicate-free event identification and why does it matter?
If the same purchase is sent both from the browser and from the server, it can be counted twice and the return on ad spend appears to double. To avoid this every event gets a unique identifier that both routes carry, and the receiving system merges them on that basis. This is one of the most common errors in badly implemented server-side measurement.
Can a cancelled or returned order be measured?
Yes, and it is worth doing. Measurement based on the thank-you page records the moment the order is placed, even though the real revenue is settled later. Where the system allows it we measure against the final order state or send a later correction, so the ad algorithm does not optimise for cancelled orders. For a webshop with cash on delivery this matters a great deal.
How much does it cost and what are the running costs?
The price of a rollout depends on the number of events to measure, the platform and the number of ad systems to connect, so we give a written quote after a survey, at a fixed price rather than an hourly rate. The running cost on your own server is typically the cost of the server itself; on a rented service it is the monthly fee of the provider, which grows with traffic.
How long does it take to put together?
For an average webshop it is three to four weeks from the measurement audit to live operation, most of it spent on wiring in the events and verifying them. With a custom platform or many integrations it takes longer. The old measurement keeps running throughout, so there is no blind period.
Who has access to the system after handover?
You do. The container, the server and the measurement accounts stay in your ownership; we only get access in order to work. At handover you also receive the complete configuration in writing, so any developer can take it on later. We do not build in dependency.
What happens if Google or Meta changes the API?
This happens several times a year, and poorly maintained measurement quietly breaks: the report still shows numbers, they are just no longer the real ones. That is why supervision alongside it is worth having: we watch the share of failing events and the changes at the platforms, then adjust when something changes, before any data is lost.
These terms come up in every quote and with every provider. They are worth knowing, if only so that the quotes can be compared.
- Server-side tracking
- A form of measurement in which the events of a website do not travel to the measurement and advertising systems straight from the browser of the visitor, but through an intermediate server under your own control. This makes it possible to control which data leaves the system, and the measurement depends less on the limits of the browser.
- sGTM (server-side Google Tag Manager)
- The version of Google Tag Manager that runs on a server rather than in the browser. The events of the website arrive here and travel on to the target systems from here: filtered, enriched or transformed.
- Consent Mode v2
- The consent handling mechanism of Google, which passes the cookie decision of the visitor on to the Google systems so they can act on it. It does not replace the cookie banner and on its own does not amount to legal compliance.
- Enhanced Conversions
- A Google Ads feature that attaches pre-processed identifying data to the conversion event, so that ad attribution is more accurate even where browser-side identification does not work.
- Conversions API (CAPI)
- The server-to-server connection of Meta, through which purchase and other events can be sent bypassing the browser. It should be used together with the browser-side pixel, paired without duplicates.
- Measurement Protocol
- The interface of Google Analytics through which measurement events can be sent directly from a server. It is typically used to feed back events that happen later, such as a change in order state or a later approval.
- Data layer (dataLayer)
- The standard interface for passing data between the website and the measurement system. Its quality decides what can be measured at all: if the product price, the quantity or the order id does not go into it, the measurement cannot see it either.
- Event deduplication
- A procedure in which the same event arrives on both routes (browser and server) with a unique identifier, so the receiving system recognises it and counts it once. Without it the conversion count and the return are overstated.
- First-party data
- Data collected by your own system on your own domain. The whole point of server-side measurement is that the event stream arrives here first and only travels on from here, not the other way round.
- ITP (Intelligent Tracking Prevention)
- A browser-side protection that limits the lifetime and use of cookies suitable for tracking. One consequence is that a returning visitor can show up as a new user in the statistics.