Table of content
Your server-side tracking worked perfectly on launch day. A few weeks later, cost per acquisition is climbing and nobody knows why. More often than not, the server is still running: it is the conversions that have stopped arriving, without a single error message.
In short
An sGTM host monitors its infrastructure, not your configuration: a "healthy" server can happily receive zero purchases.
Most outages start on your own website: a release, a theme change, a rebuilt checkout, a CMP update.
Three levels are enough: automatic volume alerts, a weekly log review, a full audit every six to eight weeks.
Monitoring also lets you prove that your tags respect the consent you announce (Art. 7 FADP).
This article is for Swiss SMEs, web agencies and marketing agencies that have already invested in a server-side Google Tag Manager container (sGTM) and want that investment to deliver accurate data over time, not just on launch day.
Why does server-side tracking that used to work break without warning?
Server-side moves data collection to a server you control. That is a major step forward, as explained in our article on owning your data in Switzerland. But the server only receives what the browser sends it. As long as your website, your CMP and your web tags keep changing, the chain can break upstream of the server.
In an article published on 2 September 2026, Stape sums it up: server-side tracking "doesn't stay fixed". We see the same causes again and again in our audits across French- and German-speaking Switzerland.
Website releases
This is the most common cause. A developer ships a new version of the site and unintentionally changes something the tracking depends on:
the GTM snippet missing from a page template, such as the order confirmation page;
the setting that routes GA4 requests to your own collection subdomain removed from the Google tag;
a CSS class or button ID renamed while a GTM trigger relied on it;
a rebuilt checkout whose dataLayer no longer pushes the purchase event, or pushes it without a value.
In the last three cases, tracking does not stop: it loses a piece. Page views keep coming in, dashboards look normal, only conversions disappear. This is the most expensive kind of outage, because Smart Bidding and Meta's algorithms keep optimising on a signal that has become wrong.
The CMP and consent
A cookie banner is a living component: vendor updates, new wording, new categories, a change of provider. Every change can disrupt two mechanisms.
The first is execution order. Google's Consent Mode documentation is explicit: if your consent code is called out of order, consent defaults won't work. The default state must be set before any measurement data is sent, then updated with the update command as soon as the visitor makes a choice.
The second is the update event. Not every CMP pushes a separate event to the dataLayer when a visitor changes their preferences. On 9 September 2026, Stape published a guide on exactly this case: Google tags that support Consent Mode react to the new consent state on their own. Third-party tags fired in GTM (LinkedIn, TikTok, Microsoft Ads, CRM tools) need an event to know that consent has changed. Without it: lost conversions, or tags firing at the wrong moment.
If your Consent Mode setup still feels unclear, start with our Google Consent Mode v2 guide.
Platform and browser changes
Meta, Google, LinkedIn and Apple regularly change their APIs, their parameter requirements and browser behaviour. Your configuration has not moved, yet what it produces has. A tag template that is no longer maintained, a parameter that has become mandatory, a new identifier format: these changes rarely throw a visible error. You simply see a lower match rate or fewer attributed conversions.
Configuration drift
Finally, there is wear and tear. Over the months, several people work in the container: the ads agency adds a tag, an intern duplicates a trigger, a vendor tests an integration and forgets to remove it. Without documentation or regular review, the container becomes hard to read, and every outage takes longer to diagnose.
Managed hosting or monitored measurement: what is the difference?
This is the most frequent misunderstanding among our clients. Many assume that managed hosting (Stape, another provider, or a properly configured Google Cloud Run) also covers data quality. It does not.
What your host monitors: server availability, scaling, certificates, response times, container image updates. Stape, for example, states that a dedicated team monitors its infrastructure around the clock.
What nobody monitors for you: the volume of events your site sends, whether conversions arrive, whether order values make sense, whether consent is respected, the errors returned by Meta, Google Ads or LinkedIn, and deduplication between pixel and API.
In other words, a perfectly healthy server can receive zero purchases. Monitoring your measurement is a separate task, and it needs a named owner.
Example: a typical outage at a Vaud SME
Here is a fictional scenario, built from the situations we meet most often in audits. An online shop in the canton of Vaud selling regional products switches themes on a Thursday evening. The new theme rewrites the order confirmation page. The GTM snippet is still in the header, but the block that pushed the purchase event to the dataLayer was not carried over.
Without monitoring: page views arrive as usual, traffic reports look reassuring, and Google Ads and Meta campaigns keep spending. Several weeks later, someone notices that ROAS has collapsed. Finding the cause takes days more, and the conversion history for that period is lost to the algorithms.
With monitoring: on Friday, the daily alert flags zero measured purchases while the shop has recorded orders. The fix goes live the same day and the impact is limited to one day.
The difference is not the technology. It is whether a check exists, and whether someone reads it.
Which signals should you monitor first?
There is no need to monitor everything. Six indicators cover most of the outages we see.
Incoming events per hour. A sudden drop in GA4 requests or page views received by the server signals a total outage: snippet removed, collection domain misconfigured, blocking CMP.
Server errors (5xx) and spikes in client errors (4xx). 5xx errors come first: the server could not process the request. A 4xx spike often points to a malformed request or one rejected by a platform.
Success rate per destination. Meta, Google Ads, GA4, LinkedIn: each destination should accept the vast majority of outgoing requests. A single destination dropping off points to a token, parameter or tag template issue.
Key conversions per day. Purchases, leads, appointment requests: compare each day with the same weekday of the previous week. A conversion falling to zero while traffic is stable is the classic symptom of a partial outage.
Consistency with your source of truth. Once a week, reconcile measured orders with actual orders in your shop or CRM. There is always a gap: what matters is how it moves.
Consent behaviour. Share of visitors who accept, refuse or do not choose, and no advertising requests before consent wherever your policy promises that.
How do you organise monitoring day to day?
Our method builds on Stape's post-launch guide and adapts it to the volumes of Swiss SMEs. It comes down to three levels.
Level 1: automatic volume alerts
The principle: set a minimum number of events per hour and get an alert when it is not reached. In Stape's guide, the author describes an alert that fires below ten page views per hour and warned her within the hour after a release broke the tracking.
The key is calibration. Base the threshold on your quietest hours, not your average. A B2B site in Romandy with very few night-time visits will trigger false alarms if it copies the threshold of a national e-commerce site. We recommend:
a "total outage" alert on incoming events, set against the quietest hour of the week;
one alert per critical destination (Google Ads, Meta, GA4) on the success rate of outgoing requests;
a daily alert on your main conversions, compared with the same weekday of the previous week.
Level 2: a weekly log review
A few minutes a week is enough. Scan incoming and outgoing requests, look for 5xx errors first, then 4xx spikes, and check that every destination accepts requests.
The weekly rhythm is not arbitrary. According to Stape, logs are kept for 3 days on the Pro plan and 10 days on the Business and Enterprise plans. If you look once a month, you will never see the outage from three weeks ago. On Google Cloud Run the logic is the same: logs exist, but someone still has to read them and set up alerts.
Level 3: a full audit every six to eight weeks
This is the cadence Stape recommends for manual maintenance. The audit means replaying critical journeys in preview mode, in both the web and the server container:
a complete purchase or contact journey, with and without consent;
the parameters sent to each platform (value, currency, transaction ID, hashed user data);
deduplication between the browser pixel and the conversion API;
checks inside the platforms themselves, not just in GTM preview.
That last point matters: a tag firing in preview does not prove that the platform received and accepted the data. To structure the audit, use our 15-point tracking audit checklist.
A-Track tip
Add one rule to the web agency's process: after every release that touches a template, the checkout or the cookie banner, test the main conversions before closing the ticket. A quick test saves weeks of lost data.
Why is monitoring also an FADP and GDPR compliance issue?
An update can also make your site inconsistent with what you publicly state. A common example: after a CMP or theme change, the default consent state is no longer set before the tags. Requests go out to advertising platforms before the visitor has chosen anything. Your privacy policy promises the opposite.
Art. 7 FADP requires controllers to put technical and organisational measures in place from the design stage, and to use default settings that limit processing to the minimum the purpose requires. Regularly checking how your tags actually behave is part of those measures: it lets you show that what you announce matches what happens. For visitors in the European Union, the GDPR sets comparable requirements (data protection by design, Art. 25) plus prior consent for non-essential cookies. In an investigation, what counts is how the site really behaves, not just what the banner says.
There is no need to turn every alert into a legal file. But a simple log of the checks you run (date, journeys tested, issues fixed) is a useful document the day a client, an auditor or the FDPIC asks questions. For the full framework, see our FADP and GDPR compliance guide, and our in-depth article on server-side tracking to see why this architecture makes such checks easier.
Who should own monitoring: the web agency, the marketing agency or the business?
This is often where things fall apart: everyone thinks someone else is watching. We recommend a clear split of roles.
The web agency gives notice before any release touching templates, the checkout or the CMP, and tests the main conversions after going live.
The marketing agency tracks conversions in the ad platforms and flags any unexplained drop, without editing the server container itself.
The tracking owner (in-house or external) receives the alerts, reads the logs every week, runs the periodic audit and keeps the log of checks.
The business names an owner for access rights (GTM, sGTM hosting, platforms) and signs off on CMP or privacy policy changes.
For an agency, formalising this split is also a sales argument: you are selling reliable measurement over time, not a one-off installation.
How A-Track can help
Setup: server-side architecture, CMP, Consent Mode and API connections, with our Tracking & Compliance service.
Monitoring and maintenance: calibrated alerts, log reviews, periodic audits, technical and regulatory watch, with our Annual Maintenance service.
For agencies: white-label work or support for your teams, so your clients keep reliable data without your team spending its weeks on it.
Conclusion: going live is only the beginning
Well-built server-side tracking remains one of the best decisions you can make for your marketing data. But its value depends on how reliable it stays over time. The most expensive outages are not the most spectacular ones: they are the partial, silent breaks nobody sees for weeks.
Check today whether anyone gets an alert when your conversions drop to zero. If not, start there.
Block a weekly slot to read the logs before they expire.
Schedule your next full audit and name an owner for each role.
To place this routine within a wider measurement strategy, read our marketing performance measurement guide.
Sources: Stape, Server-side tracking doesn't stay fixed (2 September 2026); Stape, How to push a consent update event to dataLayer (9 September 2026); Google, Consent Mode documentation; Fedlex, Federal Act on Data Protection (FADP, SR 235.1).
Are all your conversions still reaching their destination?
A-Track checks event volumes, sGTM logs and consent compliance after every site update, to catch a silent failure before it costs you.
Start with a free tracking and compliance audit, delivered within 48 hours.
