Learn · How-To

How to Verify Your Server-Side Tracking Is Actually Working

Setting up server-side tracking is a project with an obvious end. Verifying it keeps working is a habit nobody builds, and server-side failures are quiet by nature — no console error, no broken page, just a slow divergence between what happened and what was recorded. This is the companion to our setup guide. It assumes the implementation exists and asks a different question: can you prove it is doing what you think it is doing?

1. 1

   Prove events are arriving at all

   Start at the destination rather than the source. In each platform receiving server-side events, confirm events arrived in the last twenty-four hours and that the volume is in the range you expect. An implementation that silently stopped three weeks ago looks identical, in your tag manager, to one that is running.

2. 2

   Check client and server counts against each other

   For any event sent by both routes, compare the two counts over the same window. They should be close but not identical — server-side typically captures somewhat more. A server count far below the client count usually means events are being dropped; far above usually means deduplication is failing.

3. 3

   Verify deduplication with a real transaction

   Complete one genuine conversion yourself and follow it through. Confirm the shared event ID is present on both the client and server event, and that the destination counted it once. Deduplication that works in testing and fails in production is almost always an event ID that is generated in the wrong place.

4. 4

   Confirm your first-party subdomain still resolves

   Check that the tracking subdomain still has a valid certificate and is still pointed where you think. Certificate expiry and DNS changes are among the most common causes of a working implementation quietly stopping, and neither announces itself in your analytics.

5. 5

   Test what happens when consent is withheld

   Load your site, decline whatever consent mechanism you run, and watch what still fires. Server-side containers can continue sending data after a client-side refusal if the consent state is not propagated to the server. This is the failure mode with consequences beyond inaccurate numbers.

6. 6

   Check match quality, not just delivery

   Where the destination reports a match or data quality score, read it. Events that arrive but cannot be matched to a user are delivered and useless. A falling match score is usually a parameter that stopped being populated after a site change.

7. 7

   Look at the server bill

   Compare your container hosting cost against the previous month. A sharp rise often means a loop or a misfiring tag sending far more than intended, and cost is frequently the first place that becomes visible.

8. 8

   Put the whole check on a calendar

   Run this list monthly and after every site deployment. Server-side tracking does not break loudly, so the only reliable detection method is looking on a schedule rather than waiting to be told.