Google Ads adds IP address and timestamp matching to Customer Match, and it must be uploaded unhashed

Google Ads has added two new fields to Customer Match, its first-party audience-matching tool: a customer's IP address and the timestamp of their interaction, giving advertisers a way to build match lists from raw connection data instead of email, phone or mailing address alone. Search Engine Land reported the change on September 25, and Google's own Customer Match upload documentation confirms the mechanics.

What changed

Customer Match lists let advertisers upload data they already hold — a lead's email, phone number, or mailing address — so Google can match it against signed-in Google accounts and target or exclude those people across Search, Display, YouTube and Shopping. Until now, the file format topped out at six identifiers built around personally identifiable information, and everything except mobile device ID could be hashed with SHA256 before it left your servers.

The new file format adds two columns, "User IP address" and "User Interaction timestamp," bringing the combined-match file to eight possible fields. According to Google's documentation, a timestamp can't be uploaded without an accompanying IP address, and unlike email or phone data, both new fields must be sent as plain, unhashed strings — IPv4 or IPv6 for the address, a raw time value for the interaction.

Search Engine Land's Anu Adegbola frames the upside plainly:

"Better matching can mean larger, more accurate Customer Match audiences, giving advertisers more usable reach from the customer data they already collect."

The logic is that IP and timestamp data catches people whose PII you don't have yet or can't confidently hash-match — a demo visitor who filled a form with a work alias, or an account that logged in from a shared device — by pinning the match to when and where the interaction happened instead.

The part that doesn't travel to Europe

Google's own help page is explicit: IP address matching "isn't supported for end users located in the EEA, UK, or Switzerland." That's not a minor caveat for a B2B software company running one global Google Ads account. If your lead list includes European prospects, you can't rely on IP and timestamp matching to catch them, and you now need to filter those rows out of any file that uses the new fields before upload, on top of whatever consent language your data-collection flow already requires.

The unhashed requirement raises the same question from a different angle. Email and phone fields have let marketing teams treat Customer Match as a one-way handoff: hash locally, upload the hash, never expose the raw value to Google's ingestion pipeline. IP address and timestamp break that pattern — they arrive as plain text by design, because Google says hashing them isn't supported. That's a meaningful difference for any privacy or legal reviewer signing off on your ad stack, and it's worth flagging before someone on the growth team quietly turns the fields on.

Who this actually affects

The feature matters most to software companies that already run Customer Match for account-based marketing, competitive conquesting, or trial-and-lead remarketing — anyone building audiences from a CRM or product-analytics export rather than from Google's own pixel data. It's less relevant if your Google Ads program leans on Smart Bidding signals and broad match rather than uploaded lists, or if your buyer base sits mostly in the EEA, UK or Switzerland, where the new fields simply won't apply.

• Confirm whether your CRM or CDP export can already capture IP address and interaction timestamp alongside existing Customer Match fields
• Check with legal or privacy counsel before uploading unhashed IP data, since it bypasses the hash-before-upload pattern used for other identifiers
• Build a filter step that excludes EEA, UK and Swiss rows from any file using the new fields
• Watch match-rate reporting in Google Ads after adoption to see whether the new fields actually move the number, rather than assuming they will

The bigger signal

Google's documentation also steers advertisers away from building new Customer Match integrations directly through the Ads API, pointing them instead to Data Manager, its newer hub for connecting first-party data sources with a few clicks rather than a hand-formatted CSV. Read alongside the new fields, it looks less like an isolated format tweak and more like Google widening the on-ramp for first-party data generally, at a moment when cookie-based signals keep eroding and every ad platform is competing for direct access to advertisers' own customer records.

For a software marketer, that's the part worth tracking past this one release. The specific fields will help some accounts and do nothing for others, but the direction — more identifiers, less hashing friction, a push toward Google-managed data pipes — is one every team running paid acquisition should expect to keep moving in.