CMLS - Customer Match List for Google Ads & Meta Ads

Marketing teams optimize Google Ads campaigns per country. Mixing audiences degrades match-rate signals and wastes budget on irrelevant impressions. Each country file is independent and can be wired into its own Customer Match list. Google's Data Manager pulls each URL on its own schedule, so you can refresh some markets without affecting others.

In Google Ads → Tools and Settings → Audience Manager → Your data sources, set up a Customer Match audience and choose the HTTPS data source. Paste the country-specific URL from the plugin's admin page. Google Ads fetches the file on its own cadence; our plugin keeps the file fresh per the schedule you picked.

Yes — they complement each other. In 2026 Google began automatically enrolling accounts that use both Enhanced Conversions and Customer Match into conversion-based customer lists (enrollment emails went out from June 2026; data processing starts August 18, 2026). Those lists are built solely from what the Google Ads tag captures on your site from that point on: customers using ad blockers or declining your consent banner never enter them, and neither do phone, imported, or historical orders. This plugin builds Customer Match lists from the WooCommerce order database instead — every completed order, including full order history via backfill, split into one file per country, with a mailing-address fallback when an order has no email or phone. Keep both: attach the automatic conversion-based lists and the per-country lists this plugin feeds, and Google deduplicates matched customers on its side.

Yes. Meta Ads Custom Audiences use the same SHA-256 hashing of normalized (trimmed, lowercased) values, so a country CSV can be uploaded to Meta Ads Manager as a customer list — map the columns in Meta's upload screen. Note that Meta does not pull files from URLs; the pull-from-URL workflow is Google-specific, so on Meta use manual upload.

Roughly 10 seconds per 150,000–200,000 orders on typical hardware. The query path is direct SQL against wc_orders + wc_order_addresses (HPOS). For 1M+ orders the CLI is still the most reliable option because no PHP/web timeout applies; the admin Action-Scheduler-backed runner also handles 1M+ but each batch must complete within the host's PHP limit and if it does not then it won't finish.

In theory it's impossible as billing and shipping is country based; but in case this ever happens they are skipped. There is no correct file to route them to, and Google's per-country Customer Match campaigns can't use them anyway. The same applies to orders with an invalid country code.

They get written. Google Customer Match accepts a row with any one of: email, phone, or full mailing address (first name + last name + zip). The plugin includes a row as long as one of those identifiers is present alongside a valid country. Deduplication is still single-column: it uses email when available, otherwise phone, otherwise the mailing address. Google handles cross-identifier deduplication on its side after matching to a Google account — so a customer who orders once with email + phone and again with only their phone will appear as two rows in the CSV but as one user in your Customer Match audience.

Yes — but only if they actually ordered from multiple countries!

This is by design, as every (email, country) pair is recorded the first time it's seen and never re-written. To regenerate from scratch (for example after toggling debug mode or changing normalization), use WooCommerce → Marketing → Customer Match List → Danger zone → Delete all files & reset dedup or wp cmls delete-file, then run the backfill again.

Some security plugins ("Admin and Site Enhancements" / ASE has this option, Disable REST API, etc.) block all unauthenticated REST traffic. This plugin does not attempt to override those policies — that would be hostile to the security setting you deliberately chose. If you hit this error, whitelist the plugin's feed prefix in your security plugin's exclusion list: /wp-json/cmls/v1/feed/. Google Ads (and any other configured consumer) needs unauthenticated GET access to that prefix — the tokenized URL is the sole authentication mechanism.

For most countries (RO, DE, UK, FR, ES, US, NL, BE, PT, IT mobile, …) it's correct. The routine accepts +, 00, the country's national trunk 0, and bare national numbers (using the order's billing country to fill in the dialing code). There is a known limitation for Italian landlines: in Italy the leading 0 is part of the national number, not a trunk prefix, so the routine may strip a digit it shouldn't. Italian mobile numbers (3xx) are fine. If you need strict accuracy across all locales, swap CMLS_Writer::normalize_phone() for a libphonenumber-based implementation.

WordPress's built-in cron is request-triggered: it only fires if someone hits the site. On low-traffic stores it may drift. For predictable runs, configure a real system cron that calls wp-cron.php every minute — standard WordPress practice and recommendation.

Yes. use the integrated define CMLS_DISABLE_HASHING in wp-config.php: define( 'CMLS_DISABLE_HASHING', true );

Yes. The plugin declares custom_order_tables compatibility and queries wc_orders + wc_order_addresses directly when HPOS is enabled. On classic (postmeta) storage it falls back to wp_posts + wp_postmeta with a single conditional-aggregation query per batch.

The plugin itself makes no outbound HTTP calls — no analytics, no tracking pixels, no telemetry. All processing happens on your WordPress install. However, the whole point of the workflow is that Google Ads (or any other consumer you configure) will pull the CSV from your site at the tokenized URL. Anyone in possession of that URL can retrieve a file containing:

• SHA-256 hashes of the customer's email, phone, first name, and last name;
• the customer's billing country and postal code in plaintext.

wp-content/uploads/customer-match-list-google-ads/customer-match-{hash}-{country}.csv. The {hash} is a 16-character hex derived from the secret token, so filenames are not guessable. An index.php placeholder in the directory prevents listing if your host happens to have it enabled and then it notifies the shop owner (when visiting the dashboard).

The settings page does a one-second loopback HTTP request to the uploads directory URL (/wp-content/uploads/customer-match-list-google-ads/) when you open it, caches the result for an hour, and shows one of three banners:

• Green — safe. The server returned 200/401/403/404 with no listing markers (typically because the bundled index.php silence file is served, or because the webserver explicitly blocks directory listings).
• Red — exposed. The server returned 200 with Index of … or with our CSV filename prefix in the body. Anyone who guesses the directory URL can enumerate your country files. Fix it: Apache → Options -Indexes (or rely on the WordPress-shipped .htaccess); nginx → autoindex off; in the relevant location block.
• Yellow — could not verify. The loopback request failed within the one-second budget (NAT / split-DNS / firewall blocking PHP self-calls). Open the URL shown in the notice in a private/incognito browser window — if you see a listing, restrict it; otherwise you're fine.

Google Ads Customer Match uses data uploaded within the last 540 days. The plugin doesn't enforce this so you can decide how much history to include. The "Last 540 days" preset in the backfill range dropdown matches that window. Older data is still appended if you ask for it, but Google won't actively use it.

Yes. wp cmls backfill --statuses=processing,completed,on-hold for an explicit list, or --all-statuses for everything. The scheduled (incremental) writer is wc-completed only by design — Customer Match doesn't benefit from including pending or cancelled orders.

One row per unique (email_hash, country). At ~110 bytes per row, 1M unique customers across all countries is roughly 100 MB.

The plugin's admin page shows a notice and stops scheduling cron, but data isn't lost. Re-activate WC and the plugin resumes from the noted order. If you uninstall the plugin then the uninstall.php routine cleans up the option keys, database tables, and any generated files.

The files contain hashed personal information (email, phone, name) and plaintext country + ZIP. Treat the directory and its access URLs as sensitive data! If a customer requests deletion under GDPR / similar:

1. Delete or anonymize the WooCommerce order(s).
2. Run Danger zone → Delete all files & reset dedup (or wp cmls delete-file).
3. Re-run the backfill — the deleted customer is gone from the files.