What server-side conversion tracking 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.

Some 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.

The first question is how big your gap is, and it can be measured: 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 can be Google Tag Manager's server-side container, running on Google Cloud Run, at an address on your own domain such as data.yourdomain.ie. The address matters. Safari's tracking prevention treats a request to your own domain (same-site) differently from a request to someone else's (cross-site).

Separately, 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 browser tracking prevention and no closed tab can interrupt it.

A setup can 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. Deduplication is the part of a server-side implementation to test first.

Both platforms solve it the same way. Meta's Conversions API needs the same event_id and event_name on the browser and server copies, and counts a matching pair once. Google's tags use a transaction ID for purchases in the same way.

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 poorer details for matching than the browser did can make things worse, and the score is where that shows up.

Moving a tag from the browser to a server does not change what needs consent. Regulation 5(3) of the ePrivacy Regulations, S.I. No. 336 of 2011, requires consent before information is stored on, or read from, somebody's device, and the GDPR requires a lawful basis for the processing that follows. Neither rule depends on which machine sends the request.

A server-side setup can carry the visitor's answer through to the server, so that the server sends nothing for a visitor who declined.

Google's consent mode can load the tags before the visitor answers, with their cookies turned off. Until the visitor agrees, or after a refusal, they send Google cookieless pings in place of the full measurement. A ping still carries the visitor's IP address and browser details, so it is personal data, and the privacy notice has to describe it.

The losses that server-side fixes are not the consent ones. They are blockers, Safari's tracking prevention, failed scripts and closed tabs: people who agreed and whose conversion was lost anyway.

To match a conversion to an ad click, the platform needs something identifying, such as an email address or a phone number.

Both platforms require them to be hashed (scrambled one way) first. The email is put in lower case with spaces trimmed, and the phone number is reduced to digits with a country code. Each is then put through SHA-256 before it is sent. What is sent is a 64-character code (a digest).

Tidying the details first (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". A setup that skips that tidying sends digests that match nothing, and the match quality score quietly stays at the bottom.

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 record of processing (Article 30) like anything else. Sending it to a US platform is a transfer that needs the same basis as the address itself. Whether that transfer is lawful is set out separately.

The tagging server runs on Cloud Run and is billed on requests and container time. The bill 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: establishing the size of the gap first, wiring the consent state through both paths, getting the deduplication right, and verifying it with real transactions.

The platform tags that used to load in the visitor's browser move off it, and the page does not wait for the server container, so the page has less to load.

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 the missing data is costing you, because the platforms are choosing who sees your ads based on a picture of your customers with some of them missing.

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 advice is to leave it alone.