How to Strip Sensitive Data Before It Leaves Your Server
Server side tracking lets you control exactly what reaches each platform. Here is how to redact what should never be sent.
Once you run a server side container, every event passes through infrastructure you control before it reaches any vendor.
That is a genuine privacy capability, and most implementations never use it. Events arrive at the container and get forwarded to Google, Meta and everyone else exactly as they came in, including things that should never have left your building.
What ends up in events that should not
More than you would think. Common offenders:
Query parameters in page URLs. Email addresses in a password reset link. A search query containing a customer name. A session token.
Form field values. Auto event tracking that captures input values indiscriminately.
Page titles. Some applications put customer names in the title of account pages.
Referrer URLs. Carrying parameters from wherever the person came from.
Full addresses and phone numbers. Passed for matching but sent unhashed by mistake.
Internal IDs. Order IDs are fine. Customer database IDs sent to an ad platform are a different matter.
Most of this is accidental. Nobody decided to send email addresses to Meta. A URL parameter was there and the tag sent what it saw.
Transformations, the built in mechanism
Server side GTM has a feature called transformations. They sit between your incoming event and your outgoing tags, and they modify the event data before it is forwarded.
You can apply a transformation to all tags, or to a specific subset, which is the important part. You might send hashed email to Google Ads for Enhanced Conversions and strip it entirely from a less trusted destination.
Find them in the server container under Transformations. They are configured much like variables and are applied per tag.
What to build
A URL sanitiser
Strip query parameters from page location and page referrer, keeping only an allowlist of parameters you actually need. UTMs, click IDs, and nothing else.
Allowlist, not blocklist. A blocklist means you are protected only against the parameters you thought of, and the one that causes a problem will be one you did not.
A hashing check
If email or phone appears in an event without being hashed, hash it before forwarding, or drop it.
This is a safety net for the case where someone changes the browser side implementation and forgets the hashing step.
A field allowlist per destination
For each destination, define what it is allowed to receive. Everything else is stripped.
More work to set up, and it is the version that actually holds up, because it fails closed rather than open.
An IP handling rule
Decide deliberately what happens to IP addresses per destination. Some platforms need it for matching. Some regions treat it as personal data. The container is the right place to make that choice once.
Redaction is also a quality tool
Not only a privacy measure. A few things worth doing for correctness:
Normalise currency codes, because one platform receiving GBP and another receiving gbp causes real problems.
Strip whitespace and lowercase before hashing, since inconsistent normalisation destroys match rates.
Round or cap conversion values, if a data error can produce absurd numbers that would poison bidding.
Drop events from known internal IPs, so test traffic never reaches an ad platform at all.
What this does not do
Be clear about the limits, especially when explaining this to a legal or compliance team.
Redacting data in the container does not make collecting it lawful. If you should not have collected it, redacting on the way out is a mitigation, not a cure.
It also does not replace consent. A transformation strips fields. It does not decide whether a tag should fire at all, and that decision still belongs to your consent gating.
The two work together: Consent Mode advanced versus basic.
Testing transformations
Use the server container preview mode. Send a test event containing something that should be stripped, and inspect the outgoing request for each destination.
Check the outgoing request, not the incoming event. Transformations apply on the way out, so the incoming event will still show the original data and that is expected.
Test each destination separately if you have applied transformations selectively.
A sensible starting point
Log a day of incoming events and actually read them. You will find something you did not expect.
Build a URL parameter allowlist transformation and apply it to everything.
Build a per destination field allowlist for your ad platforms.
Verify in preview mode, per destination.
Document what each destination receives, because somebody will ask.
Step one is the eye opening part and takes about twenty minutes.
Need this built properly?
Controlling what leaves your infrastructure is the part of server side tracking people forget they bought. I set up and repair tracking for ecommerce stores and lead generation businesses, so the numbers in your ad accounts match the money in your bank account.
Have a look at what I do, or book a call and we can go through your setup together.
