Many modern vendor Server-side Tags have built-in hashing capabilities. But there is a catch: they hash exactly what you give them. If you feed a vendor tag unformatted, dirty data, it generates a useless hash, and your match rates drop silently.

Furthermore, vendors have conflicting rules. Meta requires you to remove the + from phone numbers. Google and TikTok require you to keep it. Users submit emails with typos, frontend emails can be obfuscated data with asterisks (joh***@gmail.com), and so on.

I wanted a clean, centralized way to handle this. So, I built the User Data Formatter & SHA256 Hasher. It is a single, modular Server-side GTM variable template designed to give you absolute control over your data before it is sent off to third parties.

Why Centralize Formatting and Hashing in a Single Variable?

When sending user data, you could just pass the raw DataLayer Variable directly into a vendor’s tag and hope their built-in normalizer handles it. I built this template because I came across some edge cases, and want to be in control.

Centralizing this process provides three massive advantages:

• Total Pipeline Control: You dictate exactly how edge cases are handled. Instead of hoping a vendor tag knows how to drop a malformed string, you enforce the rules yourself.
• Cross-Vendor Consistency: By using one central variable, you guarantee that different vendors are all receiving the exact same standardized baseline data, preventing match-rate discrepancies across platforms.
• Ultimate Debuggability: Because the data is formatted centrally before reaching the vendor tag, you can use the sGTM Preview Mode to inspect the raw string, verify your formatting rules, and ensure the data is pristine before it turns into an irreversible hash.

Why Hash in Server-Side GTM?

When sending User Data to analytics or ad networks, you generally have three architectural choices. This template utilizes the third method, which provides the best balance of data security and agility.

1. Clear Text to Vendor: You send raw emails/phones directly from the browser to the ad network’s API, and they hash it on their end.
   • Risk: Clear text personal data leaves your owned infrastructure, and may violate strict corporate infosec policies and exposing data to third-party tracking scripts.
2. Pre-Hashed by the Web Backend: Your web server hashes the data before the page loads and pushes the hash into the frontend.
   • Pro: Highly secure as clear text never hits the browser.
   • Con: It is impossible to debug. If your backend hashes a poorly formatted phone number (e.g., missing a country code), you cannot see the error, and the ad network rejects it silently. Fixing formatting rules requires backend developer tickets.
3. Hashed in Server-Side GTM (This Template): Data is sent securely from the browser to your owned Server Container. SGTM normalizes it perfectly, hashes it, and forwards the opaque hash to the receiver.

Built for handling Complexity

1. Zero-Config Data Ingestion

The template can optionally extract data directly from the standard GA4 user_data object, meaning it can pull variables like first_name or country out of the payload automatically. No need to map Custom Variables (but you can if you will).

2. Advanced E.164 Phone Formatting & Dynamic Routing

Phone numbers can be difficult. This template intelligently strips formatting symbols ( - . ) and removes local leading zeros. More importantly, it supports Dynamic Country Routing. You can map ISO country codes from your Event Data (like NO, SE, US) directly to their specific dialing prefixes (+47, +46, +1).

3. MRZ Name Transliteration

If a user submits the name “Jørn Ærling”, sending that directly to an ad network could result in a rejected match. The template includes an optional hardcoded dictionary that safely transliterates standard European characters (e.g., æ ➔ ae, ø ➔ oe, ß ➔ ss) down to the standard English a-z alphabet recommended by Meta.

4. Obfuscation & Sanity Detection

Garbage in, garbage out. The template automatically detects front-end masked data and structurally malformed strings. Instead of hashing a useless string and sending it to an ad network, the template simply drops it.

It also includes double-hash prevention. If it detects that an email is already hashed, it safely passes it through untouched rather than hashing a hash.

The Opt-In Consent Gate

It is an optional, opt-in fail-safe. When enabled, the template natively parses Google Consent Mode v2 information to evaluate ad_storage or analytics_storage. If you aren’t using Google’s ecosystem, you can map your own custom CMP variable as a fallback.

If the user hasn’t consented, the template safely returns undefined. The data is never processed, never hashed, and the downstream Tag physically cannot send the data.

Try it out

If you are managing Server-Side GTM containers, feel free to test it out. It’s available both on Github and in GTM Template Gallery.