In this edition of My Data Looks Funny: A client came to us saying Google Ads was showing a warning on Enhanced Conversions for their main Purchase conversion action. Their Google rep had flagged it, the diagnostics page had a warning on it and they wanted to know what was wrong. Enhanced Conversions is how hashed first-party data (in this case, the customer’s email address) is matched to signed-in Google users, recovering conversions that cookies alone would miss. I’ve gone through how User Provided Data works in a previous post, so I won’t repeat it all here.
The Warning
The first message from Google said that some of the user-provided data fields were being sent empty. The usual suspects, according to the rep: either the data isn’t available on the conversion page, or the CSS selector or JavaScript variable isn’t configured correctly, or fails in certain browsers or devices This is verbatim from the documentation. In other words, Google Ads wasn’t receiving the email for some conversions.
Changes on the website, the backend, or other tagging may affect this, so we can’t dismiss it without checking first. On to…
Due Diligence
I made a test purchase with my own email address, and went through four checks, each one building on the last.
1 – The tag fires
In GTM’s preview mode, on the order confirmation page, the Google Ads Purchase conversion tag fired, with a firing status of Succeeded. No surprises here.
2 – The tag carries the information
Opening the tag details shows the user_data parameter populated with the email address from the dataLayer, in manual mode. The email capture is correct.
3 – Preview shows the information
On the Google Ads hit in Tag Assistant, the outgoing Purchase conversion carries the em parameter with a tv.1~em… value, and ec_mode set to m (manual). The email has already been normalised and hashed by the Google tag before it leaves the browser. No plain text email address is sent to Google.
4 – The network call shows the data
Finally, the browser’s network tab. The request to googleadservices.com carries exactly the same hashed email. This is what is actually sent to Google.
Tags fire. Tags carry the information. Preview shows the information. The network call shows the data. On every test purchase, and on every real one, the email was there for Google Ads to receive.
We sent all of this back, screenshots included. The reply was that diagnostics data can take 24 to 48 hours to refresh, so the warning might reflect the setup before the recent changes, and that we should use Tag Assistant to see what wasn’t being captured. We thanked them for the reply and mentioned that and mentioned that using Tag Assistant was exactly what we had done, and that we’d already shared the results.
Extra – Check every conversion
My test only proves EC is working for one conversion. To check every purchase, I created a GTM variable that returns ‘true’ if the email address passed to the tags is present and correctly formatted, and ‘false’ if not. I added it as an is_email_present parameter on the GA purchase event, which uses the same email variable as the Google Ads tag, and checked the results in BigQuery. Between then and now, is_email_present is ‘true’ on 100% of 574 purchases.
The New Warning
A day later, the status changed. New warning, new problem:
Enhanced conversions aren’t processed because your user email data field is incorrectly formatted. Make sure user email is correctly formatted and hashed using the SHA-256 algorithm.
Two things stood out. First, nothing had changed on our side between the two warnings. Same tag, same variable, same configuration. Different warning. Second, look at the dates in that screenshot: the last ping date is the 28th, but the last recorded conversion is the 30th. The diagnostic was judging an implementation from data that was already two days behind the conversions actually being recorded.
And then there’s the warning itself. Google’s own Enhanced Conversions documentation describes three ways to set it up in GTM. With manual configuration, which is what we’re using, you pass the email address to the tag and Google takes care of normalising and hashing it. The instructions to format and SHA-256 hash the data yourself only apply to the Code option, which we’re not using. The em=tv.1~em… value in the network call is the Google tag doing exactly what the documentation says it will do.
Our answer: We have provided proof of UPD being correctly collected and hashed according to Google’s documentation. If the documentation is wrong, please let us know.
Resolved (by doing nothing)
A few days later, the rep came back with a single line: they believed it was now set up correctly. The client opened Google Ads, and the red flags had disappeared. Enhanced Conversions showed as Excellent, active and fully optimised, Purchase included.
No further action on our part. Not a single change to the Purchase tag. Same tag, same variable, same configuration that had been flagged twice. Whatever changed, if anything did, changed on Google’s side, and we never got an explanation of what it was.
The Burden of Proof
I want to be clear about one thing: the warning was worth investigating. A diagnostic flagging a problem with your main conversion action is exactly the kind of thing you should look into, and quickly. Even if your setup was working yesterday, it may not be working today. But a warning is a reason to re-check, not proof that something is broken.
As implementation experts, when we implement something like Enhanced Conversions, the burden of proof is on us to show that it works. Once we’ve done that, and re-checked it when questioned, the burden shifts to whoever contests it to show what’s wrong. Platform diagnostics are black boxes, not proof. They’re useful signals, but often they create more alarm than insight. You don’t see the logic behind them, the data they’re based on, or when it was last refreshed. When a black box says one thing and the evidence says another, the evidence wins.
To clients: You hire experts so you don’t have to choose between an orange triangle and your gut feeling. If your experts show you the tags firing, the data in the payload, the hit in preview, the request in the network tab, and the documentation that backs it up, believe them. And if they can’t show you all of that, ask them to.
To fellow analysts: Do your due diligence, and when the evidence is on your side, say so, even when the person on the other end works at Google, Meta, Microsoft, or any other 3rd Party Platform. Believe in yourself, follow the docs, and make sure everyone does. (Last sentence stolen from credited to the ever so eloquent Doug Hall)
If your data looks funny, or a platform is telling you it does, give us a shout at Duga and we’ll take it from there.