Filtering Personal Data Before Sending It: Privacy Controls in Server-Side GTM

Email addresses, telephone numbers and access tokens can accidentally reach analytics systems through URLs, page titles or form fields. Server-side Google Tag Manager (ssGTM) adds a filtering point before configured tags send data onward. This reduces exposure, but does not automatically make a collection anonymous or compliant.

1. Prevention at the source

Personal data should not enter analytics URLs. PII stands for personally identifiable information, such as an email address or telephone number. Google Analytics prohibits PII in ordinary URL and event fields; hashing an email address does not turn a custom parameter into an approved customer-data channel. Dedicated user-provided-data features have separate fields, configuration and policy requirements.

Hashing, encryption and anonymisation serve different purposes. A hash used to match a customer can remain personal data. The GDPR does not impose a blanket rule that every permitted disclosure must first be hashed; lawful processing, data minimisation and appropriate security remain necessary.

POST avoids placing form values in the URL, but still transmits a request body. HTTPS, restricted logging and control over analytics collection remain necessary. An ssGTM filter cannot retrospectively remove information already stored in browser history, proxies or vendor systems. An incident requires stopping collection and assessing deletion in each affected system.

2. The boundary of the filter

The ssGTM client converts an incoming request into event data. Transformations can modify, allow or exclude event parameters before selected tags read the data. Affected Tags and Matching Conditions determine coverage; defaults cover all tags and events, but later configuration changes can narrow that scope.

This is not a global rewrite of the HTTP request. A template with permission to read request headers or the raw body can access a separate data source. Browser pixels, server logs, client code and other outbound integrations need their own review. Different transformations or tag mappings can also produce different outbound payloads.

3. Explicit fields and known routes

A regular expression detects a pattern, not the meaning of data. An email pattern can miss encoded or unusual addresses. A 9–15 digit pattern also matches order IDs and timestamps; eleven digits do not establish a valid PESEL number. A checksum test would still not establish that a number is safe to disclose.

A smaller data model is easier to check: no arbitrary form text, only approved parameters, and canonical page routes without identifiers. The following illustrative variable accepts three exact URLs and discards the query string after ? and the fragment after #. Unknown routes and non-string inputs return undefined. The example domain and routes require replacement with reviewed site values.

const getEventData = require('getEventData');
const getType = require('getType');
const value = getEventData(data.parameter);
if (getType(value) !== 'string') return undefined;
const base = value.split('#')[0].split('?')[0];
const allowed = [
  'https://www.example.com/',
  'https://www.example.com/products',
  'https://www.example.com/checkout/complete'
];
for (let i = 0; i < allowed.length; i++) {
  if (base === allowed[i]) return allowed[i];
}
return undefined;

The template needs a text field named parameter and read_event_data permission limited to the relevant URL field. The return value always comes from the static list; encoded parameter names and double-encoded query values cannot pass through that output. This is deliberately restrictive and also removes campaign parameters. It is not a general-purpose PII detector.

4. The rule without a raw-value fallback

1. Separate variables evaluate page_location and any other approved URL field. The same allowlist is unsuitable for arbitrary external referrers; an unknown referrer must be omitted or handled by its own reviewed policy.
2. An Augment event transformation supplies accepted canonical URLs to the intended tags. Unneeded free-text fields are excluded; a parameter allowlist must retain the technical fields required by the selected tags.
3. A rejected value must explicitly block the affected tag or cause explicit field exclusion. Returning undefined alone is not proof of removal: a tag can fall back to a raw URL or another source.
4. Transformation order, affected tags, conditions and template permissions need review. A later transformation must not restore the raw value.

GA4 and Meta require separate outbound inspection. Meta customer-data fields do not all use SHA-256: email and phone matching differ from fields such as client IP, user agent and browser identifiers. A cleaned URL neither authorizes those fields nor anonymises the complete event.

5. Tests of outbound requests

Test data should be synthetic: uppercase and encoded parameter names, %40, double encoding, fragments, repeated keys, invalid types, unknown paths and token-bearing URLs. A known route such as https://www.example.com/products?email=test%40example.com must return only https://www.example.com/products. An unknown path must fail the allowlist.

The variable logic can be tested separately, but publication also requires ssGTM preview checks of every destination and the actual outgoing payload. The incoming preview still contains the original request. Log retention and access therefore require separate controls.