The em on a GA4 hit is not Enhanced Conversions

For years, an em parameter carrying tv.1~em.<hash> meant one thing: Google Ads Enhanced Conversions, on a conversion request to googleadservices.com. There is a guide on this site about reading it.

User-provided data collection puts the same parameter, with the same envelope, on the GA4 hit. So em now means one of two different things depending on which request you are looking at, and the request is the only thing that tells them apart.

Two products, one spelling

They are not variants of each other. They are separate features, with separate settings, feeding separate reports:

• Enhanced Conversions is a Google Ads feature. It rides on the conversion request — googleadservices.com/pagead/conversion/<id>/, or a first-party path once the Google tag gateway is in the way — and its job is to match a conversion to a signed-in ad click.
• User-provided data is a Google Analytics feature. It rides on /g/collect, is switched on in Analytics under Admin → Data collection and modification, and it feeds Customer Match, demographics reporting — and enhanced conversions, exported to the ad accounts the property is linked to.

That last clause is where the confusion is manufactured: the Analytics feature can end up feeding the Ads one. They are still not the same switch. Turning on enhanced conversions in Google Ads does not start GA4 collecting user-provided data, turning on user-provided data does not configure the Ads conversion tag, and each sends its own request whatever the other is doing.

Google also says outright that the two use the same normalisation and hashing algorithm, which is why the value looks identical. So em on a /g/collect hit is not evidence that the conversion tag is sending anything, and em on a conversion is not evidence that the property is collecting. Two requests, two answers, and you have to read the one you are asking about.

The envelope that went out empty

Google's own validation instruction is to find the /g/collect request and confirm the em value starts with tv.1~em followed by a long string. The reason it is worded that carefully is the case underneath it: a bare tv.1~em with nothing after it.

That is the tag having fired correctly and found nothing to collect. The envelope is written either way. Nothing in the container looks wrong, the parameter is present, a checklist that asks "is em there" passes — and no user data was sent.

It is almost always timing or selector: the tag fires on page view while the email is still behind a login step, or the CSS selector for the field stopped matching after a redesign, or the value only exists after a form submits and the event runs before it. The container cannot report any of those. The request reports all of them, immediately, as an envelope with nothing in it.

The field names are not the ones you hashed

On the way in, gtag takes plain values — email, phone_number and an address object with first_name, last_name, street, city, region, postal_code and country — and hashes them for you.

If you would rather hash them yourself, there is a parallel set of names for that: sha256_email_address, sha256_phone_number, address.sha256_first_name and address.sha256_last_name. The two sets are not interchangeable, and the expensive mistake is putting a digest you computed into email, where gtag hashes it again. Sixty-four perfectly formed hex characters, matching nobody — the same double-hash failure the Enhanced Conversions guide describes, wearing different field names.

What is hashed, and what is deliberately not

Not every field is a digest, and a reviewer who expects them all to be will report a bug that is not there. In the Measurement Protocol shape, sha256_first_name, sha256_last_name and sha256_street are hashed; city, region, postal_code and country are normalised and sent as they are.

That is the same split Google Ads uses, where country travels as a plain ISO 3166-1 alpha-2 code and is meant to. Plain text in those four is correct. Plain text in an email or a phone number is a policy problem.

Consent is on the same request

This is the part the browser makes easy and every interface makes hard. The gcs and gcd parameters ride on the very same /g/collect hit as em, so "customer data left the browser" and "under what consent state" are one line apart rather than two products apart.

If em is populated on a hit whose consent state says the visitor refused, that is a finding, and it is not one any Analytics report will surface. Reading the consent signals off the hits is the other half of this check, and it costs nothing extra once you are already looking at the request.

What Tag Master does and does not check here

Being straight about this matters more than claiming the feature. As of extension 2.0.0 the hashed field validation — the SHA-256, MD5 and plaintext badges, and the warning about personal data sent in the clear — runs on Google Ads conversion requests only. On a GA4 hit, em is decoded and listed like any other parameter — in the panel’s Other group, under its own name rather than a friendly one, because the GA4 entry’s dictionary does not carry it. Listed, and not graded.

So the reading here is done by eye, and it is not hard: the envelope is there or it is empty, and what follows tv.1~em. is hex or it is not. The GA4 parameter reference lists it with the rest of what a /g/collect request carries. Extending the grading to this request is worth doing and is not done yet. The figure above is the hit as the panel really draws it; a badge staged onto it would have been the easier page to write and the wrong one.

Questions

How do I check GA4 user-provided data is working?

Load the page, find the /g/collect request and read em. Google’s own instruction is that the value should start with tv.1~em followed by a long string. A bare tv.1~em with nothing after it means the envelope went out empty.

Is this the same as Enhanced Conversions?

Related, not the same. Enhanced conversions is a Google Ads feature travelling on the conversion request to googleadservices.com; this is Google Analytics, on /g/collect, with its own setting — though what Analytics collects can be exported to a linked Ads account and used there. Same parameter name, same envelope, two requests, two switches.

Which user-provided data fields have to be hashed?

Email, phone, first name, last name and street. City, region, postal code and country are normalised but sent unhashed — the same split Google Ads uses, where country travels as a plain ISO code.

Why is my em empty when the tag is set up?

Because the tag fired at a moment when no data was on the page to collect. The envelope is written either way, so an empty one is not a tagging error you will see in the container — it is a timing or selector problem, and the request is where it shows.

The rest of this group: GA4, server-side and attribution

• Debugging GA4 when DebugView shows nothing
• GA4 counting everything twice
• How to debug server-side GTM
• Google Tag Gateway: checking that it actually works
• When GA4 says the traffic came from somewhere else
• The email that left in plain text

More in GA4, server-side and attribution