User-provided data not hashed
Google Ads shows User-provided data not hashed when an email, phone or location column breaks Google's hashing rules. Clean the source first: lowercase emails with no spaces and a valid domain, phones in E.164. Hash email, phone, first name, last name and street address with SHA-256. Leave country and ZIP unhashed. Fix the source before you resend.
At a glance
- Where it shows
- The offline data diagnostics page in Google Ads, and the Uploads page for file imports.
- What stops
- The hashed identifiers are refused, so the row relies on its click ID alone or is not credited.
- How serious
- No policy risk. The cost is conversions matched less often than the form could support.
What it means
Email, phone, names and street address are sent as SHA-256 hashes, after the value is cleaned to Google's format. A value that breaks one of the format rules, or a column hashed that should stay plain, produces this error. It is a formatting failure on the way to a hash, not a privacy failure.
Every rule has to be applied before hashing. Once a value is hashed, a stray space or capital letter cannot be seen or fixed in the file, so the cleanup belongs in the system that builds the upload.
What actually triggers it
An email with spaces, double dots or no valid domain
Google's page says emails need an at sign and a period followed by a top-level domain, with no spaces, no consecutive dots, no accents, and no period at the start or end. Accents are allowed in first and last names, not in emails.
A phone not in E.164 format
Google's page asks for E.164 phone format before hashing. A number with spaces, brackets or no country code is not in the format the hash needs.
Country, state, city or ZIP hashed
Google's import page says not to hash the country or zip columns, and its leads page adds state and city. A hashed location column is a formatting error on the row.
Gmail dots left in
For gmail.com and googlemail.com addresses, periods before the domain are removed before hashing. A Gmail address with dots left in hashes to a value that matches nothing.
Fix it in this order
- Open the upload file and read a few refused rows against the hashing rules. Look for spaces, doubled dots and missing domains in emails.
- Lowercase each email, trim spaces, remove accents, and check the at sign and top-level domain. For gmail.com and googlemail.com, remove the periods before the domain.
- Convert each phone to E.164: the plus sign, the country code, then digits only.
- Hash email, phone, first name, last name and street address with SHA-256. Do not hash country, state, city or zip.
- Resend the corrected rows and read the action's totals after a day, not only the upload summary.
Fix the source before resending. Resending the same bad value under the same identifier gets the same refusal.
Often confused with
No user-provided data matches
The data is accepted and matches nothing on the form. Here the value is refused before it is matched.
Setup issues detected
A tag or diagnostics alert about the send. This one is the import file's own format.