What server-side conversion tracking actually does, and what it does not

When somebody buys from your website, a script in their browser tells Google and Meta that it happened. That message is how the platforms know which ads work, and it is how their bidding algorithms decide who to show your ads to next.

A meaningful share of those messages never arrive. An ad blocker stops the script loading at all. Safari's Intelligent Tracking Prevention caps the identifiers the script relies on. A slow connection means the visitor closes the tab before the tag fires. A site update breaks the tag and nothing announces it, because a tag that has stopped firing looks exactly like a quiet week.

The consequence is not that you lose sales. You lose the record of them. Your Stripe account and your order table know exactly what happened; the ad platform does not, and the ad platform is the thing spending your money.

So the first question is not what to install. It is how big your gap actually is, and that is measurable in an afternoon: compare what the ad platform reports as conversions against what your order table says, over the same period, and look at the difference.

In the ordinary setup, the visitor's browser talks directly to Google and Meta. In a server-side setup, the browser talks to a server you control, and that server talks to Google and Meta.

That server is usually Google Tag Manager's server-side container, running on Google Cloud Run, under a hostname on your own domain such as data.yourdomain.ie. The hostname matters more than it sounds: a request to your own subdomain is same-site rather than cross-site, which is the distinction Safari's tracking prevention turns on.

Separately, and often more valuably, your back end can send the conversion directly. When Stripe confirms a payment, your server calls the Meta Conversions API and the Google Ads or GA4 endpoint itself. That path involves no browser at all, so no blocker, no cookie policy and no closed tab can interrupt it.

Most real setups do both. The browser fires its copy, the server fires its own, and the two are matched.

If the browser sends a purchase and your server sends the same purchase, the platform receives two purchases. Unless it is told they are the same one, your reported conversions double and every cost-per-acquisition figure you have halves. This is the single most common way a server-side implementation goes wrong, and it looks like a spectacular success for about a month.

Both platforms solve it the same way. Meta's Conversions API requires an event_id sent identically on the browser and server copies, together with a matching event_name, and deduplicates on the pair. Google's tags use a transaction identifier for purchases in the same role.

So the test of an implementation is simple and you can run it yourself. Make a real purchase. Look at the platform's reporting. If it shows one conversion, the deduplication is working. If it shows two, stop and fix it before you make a single decision on the numbers.

The second thing to check is Meta's event match quality score, which the Events Manager reports per event. It tells you how well the identifiers you send are matching to real accounts. A server-side setup that sends fewer or worse match keys than the browser did can genuinely be a downgrade, and the score is where that shows up.

It has to be said directly, because it is how this is sold and it is wrong. Moving a tag from the browser to a server does not change your legal position. Consent is required by the ePrivacy Regulations, S.I. No. 336 of 2011, for storing or reading anything on somebody's device, and by the GDPR for the processing that follows. Neither rule cares which machine sent the request.

A setup that sends full identifiers for a visitor who declined is not clever tracking. It is processing without a lawful basis, done deliberately, with a server log proving you built it that way.

The correct arrangement is Consent Mode, wired to your banner, so that a refusal produces a cookieless signal rather than a full one. The platforms still receive a modelled or anonymous ping. They do not receive an identity.

This is worth being cheerful about rather than defensive. The losses that server-side fixes properly are not the consent ones. They are blockers, ITP, failed scripts and closed tabs, and those are people who agreed and whose conversion was lost anyway. That is usually the larger share.

To match a conversion to an ad click, the platform needs something identifying: usually an email address or a phone number. Sending those in the clear would mean handing a customer list to a US advertising company, which is a transfer you would then have to justify.

Both platforms require them hashed instead. Email is lowercased and trimmed, phone numbers are reduced to digits with a country code, and each is put through SHA-256 before it is sent. What crosses the wire is a 64-character digest.

Normalisation matters as much as the hash. A hash of "Name@Example.com " is a completely different string from a hash of "name@example.com", so an implementation that forgets to lowercase and trim produces digests that match nothing and a match quality score that quietly sits at the floor.

Hashing is not anonymisation, and it is worth being precise about that in your own records. A hashed email is still personal data under the GDPR, because it is a pseudonym that reliably identifies one person to anyone holding the same list. It belongs in your Article 30 record like anything else.

The tagging server runs on Cloud Run and is billed on requests and container time. For a small business site the bill is usually single-digit euro a month, and it sits on your own Google Cloud account, so you see it directly and can switch it off without asking anybody.

The setup work is where the cost is, and it is mostly not the installation. It is establishing the size of the gap first, wiring the consent state through both paths, getting the deduplication right, and then verifying it with real transactions rather than with a preview mode.

Performance usually improves slightly rather than degrading. The platform tags that were loading in the visitor's browser are precisely the ones being moved off it, and the server container is not in the page's critical path.

You probably do if you spend meaningfully on ads, sell online, and your platform-reported conversions are well below what your own systems record. The bigger the gap and the bigger the budget, the more a distorted signal is costing you, because the platforms are optimising against a picture of your customers that is missing a third of them.

You probably do not if your ad spend is small, or if you are a service business whose conversions are phone calls and emails that never had reliable browser tracking to begin with. In that case the useful work is different: getting the enquiry into a CRM and attributing it there, which is a smaller job.

And there is a case where it makes no difference at all, which is a business whose reported conversions already reconcile with its own records. That business has a working setup, and the honest advice is to leave it alone.