Server-Side Tagging implementation
Client-side measurement was designed for conditions that no longer exist.
I implement Server-Side Tagging that recovers the events you lose and feeds them to Google’s and Meta’s algorithms.
The same store,three states of measurement
At every stage the number means the same thing. How many paid orders from the store admin reach GA4 as a purchase event in the same period. Each stage closes a different gap.
baseline
30%Seven purchases in ten never reached GA4, because measurement lived in the browser alone.
after moving to the server
63%Blockers and ITP stopped cutting events. What still went missing were the purchases where the customer never came back from the payment page.
after adding the webhook
~100%WooCommerce reports the paid order straight to the measurement server, whether or not the customer came back from the payment page.
A gap in measurementmakes ads more expensive
Who sees your ad is decided today by Google’s and Meta’s algorithms, and that decision is built on conversion data. A gap in measurement stopped being a reporting problem. An event that never arrived, or was never matched, takes no part in deciding who sees the next ad. When conversions from an entire group of users never reach the algorithm — people browsing in Safari, for example — it concludes that the group does not convert and limits how often it shows them ads. In your dashboard you see it as a higher cost per acquisition, not as a measurement error.
Blockers
They were built to block ads, but their filter lists cover measurement scripts as well. A conversion from a user running a blocker reaches neither GA4 nor the ad panel. On desktop, 38% of internet users in Poland run one.
Expiring cookies
Safari caps the life of a cookie written in the browser at seven days. A customer who comes back two weeks later counts as a new user from direct traffic, and the campaign that brought them in gets no credit.
Browser limits
Measurement in the browser only works while the browser is in play. A purchase where the customer never returns to the confirmation page leaves no event behind at all.
Not sure what that gap costs you? The calculator works it out on your numbers.
Calculate your SST potential// CASE STUDY
E-commerce store,EMQ 9.3/10.
WooCommerce. The same GA4 tag installed in three places at once: in GTM, in a plugin and in code from a developer. One purchase reached the reports several times. The ad budget was based on numbers with no cover in sales.
CHALLENGE
A soup of tags
- A hidden gtag in the template of the "multi-pack" module, findable only by reading the code
- Meta Pixel from a black box plugin: it never saw events on the page paid traffic landed on
- TikTok Pixel loaded outside GTM ignored consent
- Cookies written in the browser expired in Safari after seven days
- The same purchase counted several times: ad algorithms learned on inflated conversions
SOLUTION
One source of truth + SST
- The stack cleaned down to a single source: GTM
- A custom Data Layer script for the "multi-pack" module
- Server-Side Tagging in a same-origin architecture
- GA4, Meta CAPI, Google Ads and TikTok through the server, all behind one consent gate
- Contact data normalised for each ad system's requirements
- Cookies set from the server, with no seven-day cap
RESULT
EMQ 9.3/10 and clean data
- 41.2% of transactions recovered
- One purchase, one event in GA4
- Event Match Quality 9.3/10 for the Purchase event in Meta
- A full set of user parameters on every purchase
- All tags fire in line with consent
- First-party cookies from the server, with no seven-day Safari cap
Three levels of SST,three kinds of recovered data
The first level recovers data you are losing today. The second completes what arrives incomplete. The third reaches events the browser will never report.
Data recovery
Measurement moved to your own domain stops looking like a foreign script to blockers, and cookies written from the server do not expire after seven days. Events that used to go missing come back, along with the attribution the browser was writing off as direct traffic.
Data completion
The server knows more about a transaction than the browser does. It adds parameters that raise the chance of matching an event to a user account, plus data that does not exist on the page at all, such as product cost. Google and Meta then receive, together with the purchase, how much you earned on it.
Accepting data from outside the browser
A webhook from the store reports a paid order in the same second its status changes. Events from other systems on your side arrive the same way, with no browser involved.
„When Mateusz started work, the tracking in Google Analytics and the transaction data in my store were essentially completely incorrect. […] He took on not only the reporting itself, but also the things that matter most for data quality — including implementing and cleaning up Server Side Tagging.”
How a Server-Side Taggingimplementation runs
From an audit of your current setup to documentation the next specialist can pick up.
Step 01: Audit of the current implementation
I go through the whole measurement layer: GTM, GA4, ad pixels and any code loaded outside them.
Step 02: Implementation plan
I design the measurement architecture and set the order of the work.
Step 03: Server configuration
I launch a GTM Server container under your domain, on infrastructure matched to your traffic and to what the plan sets out.
Step 04: Tag migration
GA4, Meta, Google Ads and the remaining systems move to the server side. The old setup keeps running in parallel throughout.
Step 05: Data completion
I run this stage only where we agreed on it in the implementation plan.
Step 06: Testing and handover
Verification of data completeness in GA4 and in the ad dashboards. Finally, documentation written so the next specialist can take the system over without guessing.
The platform only changes how the data layer is integrated; the server architecture is independent of it.
Your measurement never stopsduring the switch
I clean up the configuration and move it to the server, while your current measurement keeps collecting data right up to the switchover.
Parallel run
The old and the new tag setups run at the same time. Your current tracking collects data without a break for the whole implementation.
Consistency gate
The new measurement takes over data collection only once both streams report the same events and values.
Rollback in minutes
If anything deviates from expectations, we go back to the previous configuration without losing the data collected so far.
My standard, rated by Stape
I run a Stape audit on every implementation. It rates, among other things, how correctly the setup was built, how well the measurement holds up against blockers and how long cookies survive.
wdziecznopis.pl
96/100Top 10%- Analytics
- 100/100
- Ads Tracking
- 100/100
- Cookie Lifetime
- 100/100
Ready for full data infrastructure?
We start with an audit of your current implementation, and I will show you how much data you can recover and what you can enrich.