GA4 server-side tracking
without data loss

With traditional measurement, the visitor's browser sends data directly to Google and the other systems. Plenty of things can break this chain: ad blockers, browser protection, short-lived cookies, slow-loading scripts.

With server-side tracking, the browser only sends data to your own server, and from there it moves on, in a controlled form, to the measurement and advertising systems. This way less data is lost, and you decide which fields leave the system.

This can't be guessed in general, because it depends heavily on your audience, the device mix and the wording of your cookie banner. It's easy to establish, though: compare the order count and revenue shown in GA4 with the webshop's own order data for the same period. The gap is the real data loss. We work this out free of charge in the tracking audit, before you decide on anything.

Blockers use a blocklist to block typical measurement and advertising addresses, so the request from the browser simply never goes out. For Hungarian webshops this affects a sizeable share of visitors, and it's highest among technical and younger audiences.

When measurement is served from your own subdomain, the request goes to your domain, so it typically gets through. This isn't a way around the visitor's decision: if someone hasn't consented to tracking, their data still doesn't go anywhere.

In most cases, not straight away. If your webshop is at a few dozen orders a month and there's no meaningful ad spend, more accurate measurement won't bring in as much as it costs. The line is where measurement already drives ad spend decisions: if the algorithm learns from bad data, part of the ad spend is certainly wasted. In that case, the setup typically pays for itself quickly.

The old Google Analytics (Universal Analytics) thought in sessions and pageviews, and was shut down in summer 2023. GA4 is event-based: every interaction (scroll, add to cart, purchase) is a standalone event with parameters. This makes it more flexible, but setting it up needs more planning.

Server-side tracking builds on GA4's event model: it sends the same events, just through your own server. According to Keyword Planner, the term “google analytics” gets 8,100 searches a month in Hungary and “ga4” gets 480, so the topic clearly keeps a lot of webshop owners busy.

No, and it shouldn't. Without consent, a user's data can't be transmitted in identifiable form, whether it travels from the browser or from a server. Anyone who promises otherwise is selling you risk. The advantage of the server-side approach is that consenting users' data arrives in full, and you decide which fields leave the system.

The cookie banner is the interface where the visitor makes their choice. Consent Mode is the mechanism that passes this choice on to Google's systems, so they can act on it. The two are often wired up so that the banner appears nicely, but the decision never actually gets through. In that case, the webshop is just as legally exposed, and loses data on top of it. During setup, we always tie the state change to the actual banner events.

Not on its own. Consent Mode is a technical tool, not legal compliance. You also need a proper privacy notice, a genuine choice, a way to withdraw consent and a log of consents given. We handle and document the technical side; for the legal wording you need a solicitor, we don't give legal advice.

Nothing, your existing data stays as it is, and measurement keeps arriving in the same GA4 property. What changes is the completeness of the data, so the numbers typically go up after the switch. It's worth noting the switch date in your reports, otherwise it can look like new growth later on, when it's actually just measurement accuracy.

For smaller traffic, a hosted service gets you started faster and needs less attention. For larger traffic, your own VPS is typically cheaper, because hosted solutions scale in price with request volume while a server doesn't. The other factor is 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 we already include server management as standard, going the own-server route doesn't mean an extra supplier.

Yes, the measurement endpoint runs on your own domain, typically on a subdomain, for example data.yourdomain.com, with its own certificate. This is first-party serving: as far as the browser is concerned, the request doesn't go to an external provider, but to the site's own system.

This has two benefits: cookies keep a longer lifetime, and blockers filter out the request less often. We take care of the DNS setup and the certificate.

If the same purchase is sent from both the browser and the server, it can be counted twice, and your ad return on spend appears to double. To avoid this, every event gets a unique ID that both paths carry along, and the receiving system uses it to merge them. This is one of the most common mistakes in poorly implemented server-side tracking setups.

A server-side solution typically speeds things up: the browser has fewer scripts to download and run, because the server takes on the heavy lifting. The difference is most visible on mobile and on weaker devices, which is also where your Core Web Vitals scores are decided.

Server-side processing is invisible to the visitor, because it doesn't sit in the way of the page load. Part of the tracking audit is checking how many unnecessary tracking scripts are currently running on your site.

Google Tag Manager (GTM) is a tag management system: it lets you control, from one place, which measurement and advertising codes run on the site, without developer involvement. The traditional web container runs in the visitor's browser.

A server-side container (sGTM) is the same logic on a server: the browser sends a single request to your own subdomain, and the container distributes the event from there to GA4, Google Ads and Meta. The web container still stays in place, it just runs a lot less code.

Where the platform allows its own scripts and data layer, yes, but hosted platforms always have limits on which events and parameters can be extracted, especially at the checkout steps. On a custom or self-hosted system (Magento 2, WooCommerce, bespoke development) the measurement is complete, and we can even track back to the order's final status. In the assessment we always tell you what won't work on your particular platform.

Yes, and it's worth doing. Measurement based on the thank-you page captures the moment the order is placed, even though the real revenue is only decided later. Where the system allows it, we measure against the final order status or send a later correction, so the advertising algorithm doesn't end up optimising for cancelled orders. This matters especially for webshops with cash-on-delivery.

Both exist to make sure the conversion reaches the advertising system even if the browser-side path breaks. Google Enhanced Conversions sends an encrypted version of the email address given with consent, while the Meta Conversions API sends the purchase event from the server.

Used together, the two give the most accurate picture, and both respect the consent status. In WebPot's systems, the Meta CAPI integration is built in, not a separate development.

We compare three independent sources for a given period: the webshop's own order list, the GA4 data and the ad accounts' conversions. If these are within 5% of each other, the measurement is in good shape.

At handover you get this comparison in writing as well, and we show you how to run it yourself at any time. So you don't have to just take our word that it works, you can check it.

The data layer is the structured data package that the webshop hands to the measurement system: product ID, name, price, quantity, order number, total. GA4's e-commerce reports, Enhanced Conversions and dynamic remarketing all work from this.

If the data layer is incomplete or inaccurate, even the best server-side setup will pass on faulty data. That's why the first step of the setup is putting the data layer right in the webshop's code, which we do ourselves as developers.

The cost of the setup depends on the number of events to be measured, the platform and the number of advertising systems to connect, so we give you a written quote after an assessment, with a fixed price rather than an hourly rate. The ongoing cost on your own server is typically just the cost of the server itself; on a hosted service it's the provider's monthly fee, which grows with traffic.

For an average webshop it's three to four weeks from the tracking audit to going live, most of which goes into wiring up the events and checking them. It takes longer for a custom platform or with a lot of integrations. The old measurement keeps working the whole time, so there's no blind spot.

You do. The container, the server and the measurement accounts stay in your ownership, we only get access to do the work. At handover you also get the full configuration in writing, so any developer can pick it up later. We don't build in dependency.

This happens several times a year, and poorly maintained tracking quietly breaks when it does: the report keeps showing numbers, they just aren't the real ones any more. That's why it's worth keeping it monitored: we watch the rate of failed events and platform changes, and make adjustments when something changes, before any data is lost.