Server-Side Tracking for Google Ads & Meta

The data loss you can't see: Apple ITP and ad-blockers

Right now, some of your sales never reach Google Ads or Meta. Nothing looks broken. Your reports just show fewer conversions than you really have.

Two things cause most of the loss:

Ad-blockers. They block client-side pixels in the browser. The visitor buys. The pixel never fires. The ad platform sees nothing.
Apple ITP. Safari's Intelligent Tracking Prevention deletes cookies set by JavaScript after 7 days. A visitor who clicks your ad and buys 8 days later looks like a new, unknown person. The ad gets no credit.

The business impact is direct. Profitable campaigns lose their credit. Ad algorithms get too few conversions, so they stay in the learning phase and bid blind. Your ROAS drops on paper, you cut budget on campaigns that work, and your CAC goes up.

The fix is a first-party server endpoint. Your own domain receives the events and sets the cookies from the server. It works within browser rules: it is your site collecting your own data, after consent. It also extends cookie life beyond the 7-day limit, so the ad platforms get the full picture.

Architectural choice: Cloudflare Zaraz vs. sGTM

There is no single right setup. I pick the one that fits your stack and your budget. These are the two I use.

Cloudflare Zaraz

Runs on the edge. Tags run on Cloudflare's network, not on your visitor's device. That means a faster site and better Core Web Vitals.
No third-party scripts in the browser. The main thread stays free. Your pages render faster and users interact sooner.
Safari 16.4 IP alignment. Safari caps the life of server-set cookies when the server IP does not match your site's IP. Zaraz runs on the same network as your site, so the IPs match and the cookies keep their full life.
Low cost. There is no server to run or maintain.

Google Cloud sGTM

More flexible. A large catalog of tags and templates. It fits complex setups with a CRM or many third-party tools.
Higher cost. You pay for cloud servers, and the bill grows with your traffic.
More setup. It needs a proxy or custom domain configuration to be truly first-party. I handle that, so you don't have to.

My rule: if Zaraz covers your tools, use Zaraz. It is cheaper and faster. If you need a CRM or a tool Zaraz can't reach, use sGTM. Either way, I keep the browser light.

Web Cryptography and Meta CAPI: the performance obsession

Meta rates how well it can match your events to real people. This is the Event Match Quality (EMQ) score. A low score means Meta can't tell who bought, so it can't find more buyers like them.

When you send first-party data, such as a hashed email, to Meta's Conversions API (CAPI), the EMQ score goes up. I aim for above 8.0. A higher EMQ means Meta matches more of your sales to real people. Better matching means better targeting, and that means a cheaper cost per acquisition.

Hash natively, keep the site fast

Meta requires emails to be normalized and hashed with SHA-256 first. Many marketers add a heavy library likeCryptoJS to do it. That adds kilobytes of JavaScript, blocks the main thread, and slows every interaction.

I don't ship a library. Every modern browser has the Web Crypto API built in. It is fast, it adds zero bytes to your bundle, and it keeps your INP (Interaction to Next Paint) under 200ms. This is the whole function:

async function hashEmail(email) {
  const normalized = email.toLowerCase().trim();
  const encoder = new TextEncoder();
  const data = encoder.encode(normalized);
  const hashBuffer = await crypto.subtle.digest('SHA-256', data);
  const hashArray = Array.from(new Uint8Array(hashBuffer));
  return hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
}

Here is what it does, step by step. It lowercases and trims the email, so[email protected] and [email protected]give the same hash. It encodes the text, hashes it withcrypto.subtle.digest, and converts the result to a hex string. The raw email never leaves the browser. Only the hash goes to your server endpoint, which forwards it to Meta CAPI.