Complete technical guide to collecting first-party data via dataLayer, normalizing, hashing, and sending through server-side GTM to Google Ads and Meta.
In the first part of our series on using first-party data in online advertising, we explained why first-party data is important for media targeting and improving campaign performance. In this part, we will take a closer look at how to collect first-party data correctly and send it to media systems. We will go through the full journey of first-party data, from the dataLayer through normalization and hashing to sending it via server-side Google Tag Manager (sGTM) to Google Ads and Meta. The goal is to give you a practical guide that you can implement right away, including code snippets, edge cases, and the places where things most often break in practice.
The good news is that sending first-party data to advertising systems is not technically difficult in itself. The catch is that the details that matter are hidden in normalization, hashing, and the exact way you package the data before sending it. If you know how to do it, it is a one-afternoon task. If you do not, you will spend far more time debugging why a hash does not match, why data is missing in the platform, or, in the worst case, you may not even realize there is a problem at all.
This article will save you both. We will go through the full technical flow, from collecting data in the dataLayer through normalization and hashing to sending it to Google Ads and Meta:
1. A user performs an action on the website, such as a purchase or form submission, during which they provide their personal data. The website pushes this data into the dataLayer object user_data.
2. The browser GTM container captures the dataLayer event and, for example, a GA4 tag, although other trackers and templates can also be used, sends the hit to your sGTM endpoint, not to Google servers, together with these details.
3. On the sGTM side, the hit is received by the GA4 Client, a special component in sGTM whose role is to recognize the format of incoming data and process it correctly. It receives the incoming payload and transforms it into the so-called Event Data Object, a structured data object. This object contains all fields sent from the browser, including the user_data object.
4. Then the relevant tags are triggered:
a. The Google Ads Conversion Tracking tag on a specific conversion event, such as purchase, automatically parses user_data from the Event Data Object, performs SHA-256 hashing of the fields in the user_data object, and sends the conversion hit to Google Ads servers. To be honest, the setup is actually hybrid: the Google Ads tag in sGTM returns an instruction in the HTTP response for the GA4 library in the browser to perform a redirect to the DoubleClick domain for third-party cookie stitching.
b. The Meta (Facebook) CAPI template, whether you use the official Meta one or, for example, the Stape.io template, also automatically takes user_data from the Event Data Object. Be careful here: it does this even if you do not set the data manually and directly.
Collecting first-party data starts on your website, specifically at the moment when the user gives you their details: during registration, order submission, or newsletter sign-up. The standard approach is to push the data into the dataLayer. Even here, you can run into the first pitfalls.
A few key best practices:
- user_data must be part of the same push as the event, because GTM processes data in the context of a specific event. Data pushed separately may not be available when the tag is triggered.
- Before pushing new ecommerce data, the previous state or contents of the data layer should always be cleared: dataLayer.push({ ecommerce: null });. This prevents data from “leaking” from previous events.
- Even though Google documentation claims otherwise, it is not enough to add user_data only to the Google tag (the configuration tag). Add it to individual GA4 event tags as well, such as purchase, generate_lead, and so on. Several specialists agree that adding it only to the config tag is not always reliable.
- If a value from user_data is not available, simply omit the field. Never send a placeholder, such as an empty string, "unknown", "N/A", and so on. The systems will hash the placeholder and use it as a valid identifier, effectively merging all users without that value into a single profile. The result is distorted analytics both in advertising platforms and in GA4.
A fundamental element of first-party data implementation is hashing. In the world of advertising platforms such as Google or Meta, one specific algorithm is used as the standard: SHA-256. It is a one-way hashing algorithm that converts any input into a 64-character hexadecimal string. Google, Meta, as well as Reddit, X, Pinterest, TikTok, and others use SHA-256 to match first-party data against their database of logged-in users. The key decision is where to hash. On the client side, in the browser, or on the server side, in sGTM?
The good news: if you want to save yourself work and avoid unnecessary complications, from a practical perspective you do not have to handle hashing manually. All tags and templates for Google Ads and Meta Pixel/CAPI perform hashing automatically, whether in the browser or on the server. The Google Ads tag automatically hashes user_data fields before sending them, and the Meta CAPI tag, both the official Facebook template and the Stape template, does the same. In addition, they can detect whether the data is already hashed, and in that case they do not hash it again.
However, the question is not only technical, but also security-related. Do you want to entrust the protection of sensitive data to an automated script from Google or Meta? If not, there are essentially three possible levels of protection:
1. Hash the data before sending it to the data layer, so the raw email or phone number never appears in the browser.
2. Omit personal data in the browser and send it from your CRM, then hash it using a function in server-side GTM.
3. Hash the data on your own server or backend before sending it to sGTM.
Each of these options has different implementation requirements and a different security impact. We will cover the question of when and where to hash in more detail in one of the next parts of this series.
Normalization is the step that determines whether your data will be useful at all. A poorly normalized hash will not match the platform’s database, and the conversion will not be attributed. In addition, Google and Meta have different rules in several areas, so one function for both is not enough.
Google documentation: https://developers.google.com/google-ads/api/docs/conversions/upload-offline#prepare-data
Meta documentation: https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters/#formatting-the-user-data-parameters
Both platforms require conversion to lowercase and removal of leading and trailing spaces, meaning trim. The key difference is how Gmail addresses are handled. Google Ads Enhanced Conversions requires dots to be removed from the username part of addresses on gmail.com and googlemail.com, as well as removing everything after the + sign, meaning plus-addressing. Meta CAPI does not require this. Its documentation explicitly states only trim and lowercase. Removing dots from a Gmail address for Meta would result in an incorrect hash.
Both platforms require a format with a country prefix:
- Google requires E.164 format with a leading +.
- Meta requires practically the same thing, but without the + sign, only digits including the country code.
No spaces, hyphens, or brackets. Always include the country code, even if all your data comes from one country.
Both platforms: lowercase, without punctuation. Meta additionally requires removing special characters, but Czech diacritics are OK and should be preserved.
Meta hashes all address fields, meaning city, state, ZIP code, and country, while Google hashes only first name, last name, and street address. City, region, postal code, and country are sent in plaintext. For Google, the country must be in ISO 3166-1 alpha-2 format, such as CZ, SK, DE, while Meta expects lowercase, such as cz, sk.
Ideally, normalization should already happen on the website, meaning your developer should send normalized, and potentially already hashed, personal data directly into the data layer. If that is not possible for some reason, you can write your own normalization function in GTM. It might look something like this:
Google:
function normalizeEmail(email, platform) {
email = email.trim().toLowerCase();
if (platform === 'google') {
const [user, domain] = email.split('@');
if (['gmail.com', 'googlemail.com'].includes(domain)) {
let cleanUser = user.replace(/\./g, '');
if (cleanUser.includes('+')) {
cleanUser = cleanUser.substring(0, cleanUser.indexOf('+'));
}
return cleanUser + '@' + domain;
}
}
return email;
}
function normalizePhone(phone, platform) {
let digits = phone.replace(/[\s\-\(\)]/g, '');
if (!digits.startsWith('+')) digits = '+' + digits;
// Meta: without +
return platform === 'meta' ? digits.replace('+', '') : digits;
}
Meta:
function normalizeEmailMeta(email) {
return email.trim().toLowerCase(); // no gmail dot-stripping
}
function normalizePhoneMeta(phone) {
let digits = phone.replace(/[\s\-\(\)]/g, '');
if (!digits.startsWith('+')) digits = '+' + digits;
return digits.replace('+', ''); // no +: 420234567890
}
Minimum requirement: at least one identifier, meaning email, phone, or a complete address: first name + last name + postal code + country. If you send only first name and last name, it will silently fail, so it is better not to send an incomplete address.
Implement fallback logic: if a phone number is not available, send at least an email. If you have neither, the conversion will still be sent. The platform will not match it, but it may count it as an unattributed conversion and use modeling.
Meta hashes all customer information fields: email, phone, first name, last name, city, state, ZIP code, and country. In Meta Ads, your events receive an Event Match Quality (EMQ) score, which is Meta’s score on a scale from 0 to 10 that evaluates matching quality.
Your goal should be to reach 6+ for key conversion events, ideally 8+ for purchase. Adding a hashed email brings roughly +4 points, while a phone number adds about +3 points. It is better to send fewer accurate, correctly normalized parameters than many poorly processed ones.
Prerequisites
- First-party data in the data layer
- A GTM container deployed on the website
- Server-side measurement with sGTM set up, either through your own server in GCP or a third-party provider
1. Assume you have data deployed in the data layer with the purchase event
window.dataLayer.push({
event: 'purchase',
ecommerce: {
transaction_id: '78342916504217',
value: 249,
tax: 43.21,
shipping: 0,
currency: 'CZK',
coupon: '',
items: [
{
item_id: 'ALZMNTB01',
item_name: 'Alzament PLA Basic 1kg Black',
item_brand: 'Alzament',
item_category: 'Počítače a notebooky',
item_category2: '3D tisk',
item_category3: 'Filamenty pro 3D tiskárny',
price: 249,
quantity: 1,
index: 0
}
]
},
new_customer: true,
customer_type: 'new',
user_data: {
email: 'jan.novak@example.cz',
phone_number: '+420731458920',
address: {
first_name: 'Jan',
last_name: 'Novák',
street: 'Hlavní 456',
city: 'Brno',
region: 'Jihomoravský kraj',
postal_code: '602 00',
country: 'CZ'
}
}
});
2. In GTM, create a Data Layer Variable for each data point
3. For Google Ads, use these variables to populate the “User-Provided Data” variable
4. In browser GTM, you can configure first-party data sending for Meta tags using the official Meta template, Meta Pixel. Simply check “Enable Advanced Matching” and then fill in the relevant fields:
5. To send first-party data to the server, you need to add the User-provided data variable to your transport GA4 tag as part of the config parameters. Alternatively, you can send individual first-party variables separately using another type of transport tag, such as a Data tag.
6. In sGTM, thanks to the previous step, you will receive the user_data object together with the purchase event. This will happen whenever the data is available in the data layer. For measuring conversions in Google Ads, you are done: the tag automatically takes the data from the user_data object. At this point, Google Ads conversion measurement is taken care of: the tag automatically reads the data from the user_data object.
Now all that remains is to configure the sending of user data for Meta Ads server-side tags, whether you use the Meta template or the Stape template.
After deployment, it is a good idea to validate that everything is working as expected: that the data is arriving in the correct format and being sent correctly.
In GTM preview mode:
-> web GTM
-> Check that user_data is being populated correctly, both as individual values and as an object:
-> Also check that the data is being sent to the Meta tag and to sGTM in conversion tags:
With this, you have the basic architecture ready: data flows from the dataLayer through sGTM into both Google Ads and Meta, and it is correctly normalized and hashed. That is the harder part.
But how do you know whether it actually works?
A low match rate can have three different causes, and each one requires a different solution. In the next part, we will go through debugging: how to read signals in GTM preview, what Google Tag Diagnostics can tell you, and how to interpret the Event Match Quality score in Meta. In other words, how to verify that all the work you have just done is actually producing results.
How do you get data from multiple ad platforms into a single data warehouse, typically BigQuery? We’ll walk through the core architecture and key decisions before you start exporting data from Google Ads, Meta Ads, Sklik, and other platforms.
Part 3 of our first-party data series gets technical again – we'll show you how to check that data is correctly reaching each system and doing what it should. We'll look at outgoing hits in DevTools and at checks directly in the ad platforms.
A detailed guide to sessionizing the GA4 BigQuery export — from identifying sessions and reliably ordering events to two attribution models (First Event Available and Session Start), their limitations, and validating agreement between them.
Take a look at our ClickUp backup solution. Automated exports, a GitHub repository, and a practical guide to keeping your company data under control.
Learn how to deploy server-side tracking on Google Cloud Run. Compare Stape vs Cloud Run, configure load balancers, choose billing types, and test your setup.
Complete technical guide to collecting first-party data via dataLayer, normalizing, hashing, and sending through server-side GTM to Google Ads and Meta.
Testing ClickUp MCP: hands-on experience with AI-powered automation, security concerns with access tokens, practical limitations, and who should use it.
Learn how first-party data improves campaign performance, measurement accuracy, and cross-device tracking. Discover practical ways to collect and use it.
Learn how we migrated 250 media tags (Facebook, Google Ads, Sklik, Bing) to server-side GTM. Practical tips, templates, and lessons learned.
Workshops on advanced digital analytics: BigQuery, cookieless tracking, consent, attribution, and building data warehouses for reporting and activation.
Why analytics is an excellent career for women, including those returning from maternity leave. A personal story about transitioning into data analytics.
Learn how to transfer historical GA4 data between BigQuery projects using Data Transfer Service. Step-by-step guide for dataset migration and billing.
A look back at Reshoper - advising e-shop owners on tracking and measurement, plus a roundtable on marketing automation with insights on self-hosted N8N.
From Idea to App in 48 Hours 🚀 Building AI-powered apps at #HackYourWeekend using Claude Code, tracking with BigQuery, and lessons from team development.
Recap of MeasureCamp Brno 2025: server-side tracking insights, legal tracking without consent, and Women in Analytics session by MeasureDesign team.
Recap of PPC Camp: my presentation on legally measuring data without user consent - cookieless tracking, sGTM, BigQuery, Facebook conversions, and Advanced Consent Mode risks.
Ready-to-use BigQuery SQL script to calculate Easter dates (2024-2100) using Computus algorithm. Perfect for filtering GA4 data and analyzing seasonal trends.
GA4 + BigQuery in practice: connecting analytics, CRM & media data, real-world use cases from IKEA, Shoptet, McDonald's & Česká spořitelna, and what it unlocks for marketing.
80-minute podcast with Vašek Jelen on GA4, server-side tracking, BigQuery, and connecting customer data with campaign performance for e-commerce.
Vašek and Anička presented at MeasureCamp Prague on using Google Ads export in BigQuery, combining it with GA4 and CRM data to solve attribution issues.
Learn how to extend GA4 data retention from 2 to 14 months. Understand what retention affects, how to change settings, and what happens after data expires.
MeasureDesign led a Google Analytics 4 workshop for Tereza non-profit, focusing on practical data use for their Učíme se venku program.
At the Reshoper conference, I had the opportunity to give a talk where I summarized new opportunities for e-commerce analytics.
Workshop on working with GA4 data in BigQuery and Google Cloud. Learn to move beyond the GA4 interface and unlock the potential of raw GA4 data.
Vojta works at MeasureDesign on developing technical and data solutions that are not only functional, but also practical and easy to use. He enjoys combining web development, automation, and data work to create solutions that make sense both from the user’s perspective and in terms of the technical foundations behind them. What he finds most rewarding is turning a more complex problem into a clean and reliable solution.
Jirka has been working in marketing for over 10 years, and if there is anything he enjoys more than numbers themselves, it is connecting them. He loves mathematics and data analytics, and thanks to his interest in exploring source code, he can easily communicate with developers in their own language. At MeasureDesign, he specializes in connecting new data sources - building custom connectors in Python, testing data quality, and exploring which data combinations make the most sense from a business perspective. He is completely at home in Looker Studio and also has extensive experience evaluating PPC campaign performance.
Lenka joined MeasureDesign at the end of 2025, bringing extensive experience from PPC marketing, where she spent many years working with Google Ads, Meta Ads, and other advertising platforms. While managing campaigns, she repeatedly ran into the same issue - poorly set up or insufficient web analytics, which made effective optimization nearly impossible. This challenge initially led her to analytics out of necessity, but over time she discovered that she enjoyed it even more than advertising itself. Today, she focuses primarily on implementing web analytics and data solutions that provide companies with high-quality, reliable data for strategic decision-making and performance marketing. She continues to work on selected PPC projects as well - not only because she still enjoys them, but mainly to stay closely connected to the reality of media platforms and the real needs of clients.
Marťa helps integrate AI into everyday work—making it faster, more efficient, and accessible to every team member. What excites her most is finding practical ways to use AI and turning new technologies into useful tools.
Anička has over 7 years of experience in the agency world, where she has managed social media ad campaigns for clients, and especially for content-driven websites, her favorite. Wanting to broaden her perspective beyond campaign data, she gradually shifted her focus toward web analytics. She joined our team in 2022 and now specializes in data analytics, using GA4, BigQuery, Looker Studio, and other tools to connect and dig deeper into data — delivering insightful analyses and valuable input for business decisions. Anička was a member of our team until 2026.
Zuzka's career path led her through corporate innovation and research management, running word-of-mouth projects, and later to a digital agency, where she managed website development projects. However, Zuzka is naturally curious and wanted to understand how a website actually works once it is launched into the world. That curiosity led her to study web analytics — and eventually to a key collaboration with Vašek. In 2019, they founded the company together.
Vašek has been working in digital analytics for over 15 years — from setting up tracking to data storage, visualization, and interpretation. He helps companies keep their data in order and make full use of it. He focuses primarily on data from digital platforms such as websites, apps, and client zones, and on connecting that data with other business data like media and customer data. After years of freelancing, he co-founded the analytics studio MeasureDesign, where, in addition to working on analytics projects and bespoke training sessions, he also mentors and educates new analysts.
Blanka joined our team in 2024 and has been responsible for back-office operations, including invoicing and administrative tasks, ever since. She draws on her experience from the Czech Post and her background in financial management to keep everything running smoothly. In her free time, she enjoys traveling with her two children and finds relaxation in working in her garden.
Markéta started out in marketing, but then came maternity leave — and with it, total chaos. In an effort to hold on to the last bits of sanity, she turned to data. After all, numbers don’t yell, spill cereal into your keyboard, and at least they make some sense. She completed a data analytics course at Engeto Academy, where she bonded with SQL, Power BI, Excel, and Python, and started looking for patterns outside the bounds of children’s coloring books. Today, at MeasureDesign, she helps clients understand what their numbers are really saying.
She joined MeasureDesign in 2023, specialising in measurement implementation and reporting. Her favourite moment is when, after all the setup and testing, the first data finally starts flowing in. Her biggest challenge? The unexpected (and often undocumented) changes from Google – those are the times when every analyst turns into a paranormal behaviour expert. 👻 She was a member of our team until summer 2026.
Klára has been with the company since 2019. She focuses mainly on web analytics but is not afraid to dive into data work in BigQuery. What she enjoys most is guiding clients through the entire process — from defining their needs to implementing tracking and creating the final data visualizations. She gets an almost suspicious amount of joy from a clean and well-organized GTM container or a report full of useful data.
