Study first
Review the ideas behind the questions
Review the audience data plan before Customer Match goes live in Google Ads. Focus on access, first-party collection, consent signals, list freshness, upload quality, and claims that could reveal sensitive personal information.
Check access before planning reach
Customer Match access is not the same for every Google Ads advertiser. Compliance history, payment history, account age, and lifetime spend affect which features can be used.
- Customer Match access requires a good history of policy compliance and payment history.
- All policy-compliant advertisers can use Customer Match in Observation and Exclusions, but Targeting needs higher account history and spend.
- Google may remove Customer Match access for abuse risk, poor user experience, or repeated policy violations.
In Practice
Observation is not the same as targeting
A newer policy-compliant account may be allowed to observe or exclude a list but still be blocked from using Customer Match as the active targeting setting.
Access can be lost
A list that uploads today can still become unusable later if the account creates policy or user-safety risk.
Common mistakes
Assuming an account that can add Customer Match as Observation can also use it for Targeting.
Check the account's history and lifetime spend before promising Customer Match Targeting.
Q&A
Can every policy-compliant Google Ads account use Customer Match as Targeting?
No. Targeting requires stronger account history and lifetime spend than Observation or Exclusions.
Why review policy history before a Customer Match launch?
A poor policy history can make the account ineligible or lead to access removal.
Prove the data can be used
Customer Match data should be first-party, disclosed, consented where required, current enough, and uploaded through an approved path.
- Customer Match uploads may include only customer information collected in a first-party context.
- The advertiser's privacy policy should disclose sharing customer data with third parties for services on the advertiser's behalf.
- For EEA users, Customer Match ad personalization needs granted ad user data and ad personalization consent signals.
In Practice
Purchased lists are a blocker
If the team cannot prove customers shared the information directly with the advertiser, the list should not move into Customer Match.
Consent is part of the upload design
For EEA users, the audience process needs to carry the required consent signals before the list is used for personalization.
Common mistakes
Uploading a purchased email list after adding it to the CRM.
Use only customer information collected in a first-party context where customers shared it directly with the advertiser.
Q&A
What should the privacy owner check before a Customer Match upload?
Check first-party collection, privacy-policy disclosure, required consent, approved upload path, and legal compliance.
What happens if required EEA consent signals are missing?
The data is treated as not consented and cannot be used for Customer Match ad personalization.
Fix upload and freshness issues before blaming performance
List size and low volume can come from formatting, hashing, freshness, user opt-outs, and matching limits. Those are data-quality checks before campaign conclusions.
- Customer Match list memberships older than 540 days stop being eligible, and a list needs at least 100 members added or updated within the last 540 days.
- Google Ads can hash private customer data with SHA256, but country and zip data should not be hashed.
- Uploaded record count may not equal the targetable Customer Match list size.
In Practice
Freshness can block use
A large old list can still fail the usable-list check if too few members were added or updated inside the 540-day window.
Formatting is a match-rate issue
Incorrect headers, hashing, encoding, and phone formatting can lower the number of records that pass upload and matching checks.
Common mistakes
Calling a Customer Match campaign weak because the uploaded CSV had 80,000 rows but the list size looked much smaller.
Check matching, opt-outs, formatting, hashing, and freshness before treating list size as media performance.
Q&A
Why can a Customer Match list be smaller than the upload file?
Some records may not match active Google users, may be opted out, or may fail data quality, formatting, hashing, or freshness checks.
Should country and zip be hashed in a pre-hashed Customer Match file?
No. Private identifiers can be hashed, but country and zip should remain unhashed.
Keep personalization claims inside policy limits
Customer Match can use customer data, but the ad and audience plan still need to avoid sensitive categories, narrow personal claims, and unsupported data-use assumptions.
- Customer Match ads should not imply knowledge of personally identifiable or sensitive information about customers.
- Customer Match cannot use sensitive interest categories to target ads or promote products and services.
- Google says uploaded Customer Match files are used to create audiences and ensure policy compliance, not to build customer profiles or add more detail to them.
In Practice
Avoid personal callouts
A campaign can speak to an offer without telling users the advertiser knows their exact purchase, health status, or financial condition.
Data use has a boundary
Customer Match data can support the audience workflow and policy checks; it should not be described as a way to enrich customer profiles inside Google.
Common mistakes
Writing ad copy that says, 'We know you bought diabetes medication last month.'
Remove the personal and sensitive claim; Customer Match ads must not imply that kind of knowledge.
Q&A
Can Customer Match copy mention exactly what the advertiser knows about a user?
No. Avoid copy that implies knowledge of personally identifiable or sensitive information.
How does Google describe its use of uploaded Customer Match files?
Google uses them to create Customer Match audiences and ensure policy compliance, not to build customer profiles or add more detail to them.