The pixel you can’t see: server-side tracking

A traditional ad pixel is a piece of code in the visitor’s browser. It sends a request straight to Meta, Google or TikTok, and anyone who opens the browser’s developer tools can watch it happen. Ad blockers stop many of those requests. Browsers limit the cookies that go with them.

Server-side tracking moves that work off the page. The browser sends events to a server you control, usually on a subdomain of your own site. That server then forwards them to whoever you choose. To the visitor, and to anything watching from outside, it looks like your site talking to itself.

What it looks like in practice

There are a few common forms, and they are often combined.

• Server-side tag managers. Google Tag Manager offers server containers that receive events and pass them on through “clients” and “tags”. Google recommends running them on your own first-party domain. Google tag gateway for advertisers goes further, serving Google’s tags through your own domain via a CDN or load balancer.
• Conversion APIs. Meta’s Conversions API, TikTok’s Events API and Google’s enhanced conversions take events, and often hashed emails and phone numbers, directly from a server. Shopify’s channel apps switch these on through their “Enhanced” and “Maximum” data sharing levels.
• Gateways. Meta’s Conversions API Gateway runs in your own AWS or Google Cloud account. It receives the pixel’s events and forwards them to the Conversions API, so events reach Meta by both routes.
• “First-party tracking” services. Several vendors sell hosted server containers, custom domains and plug-ins that do all of the above for you.
• Cookie extension. Cookies set by your own server can outlast cookies written by scripts, which Safari deletes after seven days without a visit. WebKit has responded: Safari’s tracking prevention now detects CNAME and IP-address cloaking and caps cookies set in those responses to seven days. Vendors in turn advise matching server addresses to get around it. The arms race is the point. The work exists to keep identifiers alive longer than browsers intend.

Why it’s sold as privacy-friendly

The pitch has some truth in it. Google says of server-side tagging that “only you have access to the data in the server until you choose to send it elsewhere,” and that you control how it is shaped and where it is routed. You can strip IP addresses, drop fields and block tags. Fewer third-party scripts in the page can mean a faster site and less leakage to vendors you never meant to include.

But look at the phrase “until you choose to send it elsewhere”. In most commercial set-ups the reason for the server is to send it elsewhere, more reliably than before. Shopify’s help page puts the selling point plainly: data sent server to server “can’t be blocked by browser-based ad blockers”. The same visitor who installed a blocker to stop the pixel is now sent to Meta anyway, with their email and phone number attached.

So “privacy-friendly” usually means friendlier to the business’s control over the data. It rarely means the customer is shared with fewer companies.

Why the Standard treats it the same

Our rule is about destination, not method. Customer data, including visitors, prospects and subscribers, doesn’t go to an ad platform or any recipient that uses it for its own purposes, targeting or measurement. The route doesn’t matter.

A pixel event and a Conversions API event carry the same kind of information to the same company for the same purpose. The server version often carries more, because it can attach details from your order system that a pixel never saw. If a browser pixel is out (ruling R-003), the server version of that pixel is out too. Conversions sent back from a server are covered by ruling R-004, and the Shopify data sharing levels by ruling R-010.

A consent banner doesn’t change this either (clause NFS-1.3). And if an agency or a “first-party tracking” vendor set it up, it’s still your responsibility (clause NFS-1.7).

Why scanners can’t see it

The Standard provides for a weekly outside scan of every member’s site, and we’d encourage anyone to try tools like The Markup’s Blacklight or Webbkoll, run by Sweden’s 5th of July Foundation. They load your site in a browser and record what it does: which third parties it contacts, what cookies it sets, whether it runs known trackers. They are good at that.

They can only see what happens in the browser. A request from the page to data.yourshop.co.uk looks first-party. What your server does with it afterwards, and whether it passes events on to Meta a moment later, happens where no outside tool can look. A shop can score perfectly on a scan and still send every order to three ad platforms.

That is why we don’t certify on scans alone. Scans catch the easy cases and anything that creeps back in. They can’t prove absence.

What a Nullware review asks for instead

For the verified part of the Standard, a clean scan is the start. The review then looks at the places a server-side handover leaves traces.

• The data map (clause NFS-4.1). Every system that touches customer data, including any server container, gateway or tracking service, and where each one sends data.
• A director’s declaration (clause NFS-5.1). A named director signs that the data map is complete and that no customer data goes to an ad platform by any route. A signature from someone accountable changes how carefully a map gets checked.
• Read-only access to ad accounts. Events Manager shows whether a dataset is receiving server events and from which integrations. Google Ads shows conversion actions, their sources and whether enhanced conversions is on. Audience manager in Google, and Audiences in Meta, show any uploaded lists. These are hard to fake from the outside and easy to read from the inside.
• Settings evidence. Screenshots or exports of the data sharing settings in your shop platform, tag manager configuration, and any gateway or server container, showing where events are forwarded.
• The audit right (clause NFS-5.3). Members agree that we can take a read-only look in their ad accounts on 14 days’ notice.
• Reports. Employees, contractors and agency staff are often the only people who know what a server container does. We accept reports and follow them up under our process, with the member’s right of reply.

None of this is perfect. A determined business could hide a server route from a reviewer for a while. But the ad platform’s own dashboard is where server events have to show up to be useful, and that is where we look.

Fine and Never