Server-side vs client-side tracking, and what changes in client reports.

Client-side tracking is the browser telling a platform what happened: a pixel or tag on the page fires when the visitor does something. Server-side tracking is the site's own server telling it instead, either through a server-side tag container or through a platform's conversion API.

The browser route loses events to ad blockers, browser privacy limits and pages that close before a tag finishes. The server route loses fewer of them, because nothing in the visitor's browser stands between the event and the platform.

Events that used to be lost start arriving. That is the whole of it. The client did not gain customers on the day of the change. They gained sight of customers they already had.

Which means the month you switch is a break in the series. Every chart that runs across it shows a rise that is partly real and partly measurement, and nobody reading it next year will know which part is which unless the change is marked on the chart.

Tell the client before the switch rather than after. A rise in reported conversions that arrives with no warning gets read as performance, and walking it back later costs more than explaining it up front.

Platforms commonly recommend running both routes at once, so the server catches what the browser misses. That only works if the platform can tell when the two are reporting the same event, which it does by matching an event identifier and an event name sent by both.

When the identifiers do not match, every sale both routes saw is counted twice. The symptom is distinctive: platform-reported conversions climb above the number of orders the client's own system recorded, which a genuine improvement can never do.

Consent still applies. Sending an event from a server does not make it lawful to send data the visitor declined to share, and a server-side setup that ignores consent has only moved the problem somewhere harder to audit.

Attribution does not change either. Each platform still decides which conversions to credit to itself, using its own windows and rules, so the platforms will still disagree with each other and with the client's store after the switch.

Four habits, all cheap, all easy to skip.

• Mark the date

  Annotate the switch on every trend that crosses it, per platform, because platforms are rarely switched on the same day.

• Compare against the client's records

  Track platform-reported conversions against the orders or leads the client's own systems recorded, before and after. A gap that widens past anything you can explain is the double count.

• Check each event type

  Purchases can deduplicate correctly while leads do not. Check every event type separately rather than assuming one result covers them all.

• Keep the browser side tidy

  Server events do not fix a pixel firing before consent or missing from a template. Both halves need auditing.

SightShark does not set up server-side tagging for a client. It is where the comparison above happens: platform-reported conversions beside the orders and leads in the client's store and CRM, in one modelled table in your own data warehouse, refreshed daily. An anomaly rule on percentage change catches the sudden jump a broken deduplication produces.

That comparison works the same whichever route an event took, which matters here: events a server sends never pass through the browser, so no amount of checking the page will show whether they were counted twice.