Google Customer Match Now Takes Raw IP Addresses: Why European Advertisers Should Mostly Leave It Alone

If you run Customer Match today, your lists are built from emails and phone numbers that are hashed before upload and matched against signed-in Google accounts. Many visitors never hand over either. Google has now added a route for some of them: a Customer Match file can carry the visitor's raw IP address and the time they interacted with you. For a Cyprus or UK advertiser the headline is simple. It does not apply to your home audience, and for everyone else it is a weaker identifier than it looks.

What changed

Google's help page for uploading a Customer Match data file now lists two extra columns: "User IP address" and a timestamp column, named "User Interaction timestamp" in one place and "User Engagement timestamp" in another. The page is undated; Search Engine Land reported the change on 25 September 2026. PPC Land traces it to version 1.7 of the Data Manager API, released on 28 May 2026, and reports that only Google Ads is eligible at launch, not Display & Video 360.

The rules on the help page are specific. The IP address is sent as a "String (IPv4 or IPv6 address)" and the instruction is to "Pass as a plain, unhashed string (don't hash)". The page also says "You can send an IP address with or without PII data", so a file can now consist of IP addresses and timestamps alone. What you cannot do is send a timestamp by itself: "Timestamps can't be sent without an accompanying IP address."

The geographic exclusion, in Google's words

The help page puts it in one line: "IP matching isn't supported for end users located in the EEA, UK, or Switzerland (CH)." Google's Customer Match policy repeats it with an instruction attached:

PPC Land counts that as 32 countries: the 30 EEA states, the UK and Switzerland. Cyprus, Greece and the UK are all inside it. Note the burden: the policy tells the advertiser to exclude those users. Neither Google page says whether such rows are discarded or rejected, as PPC Land also notes, so the split has to happen before the file is built.

Why an IP address is a weaker identifier than an email

An email address usually belongs to one person and stays with them for years. An IP address belongs to a network connection, and many people can sit behind one connection, while one person moves between many.

• Households. Everyone on the home router usually shares one public address, so a purchase by one family member looks the same as a visit from another.
• Offices. A company network typically sends all staff traffic through a few addresses: useful at account level for B2B, useless at person level.
• Hotels, cafes and airports. Guest Wi-Fi puts strangers behind one address for a few days and then hands it to the next set.
• Mobile carriers. Carrier-grade NAT, the arrangement RFC 6598 reserves address space for, lets an operator put many subscribers behind shared public addresses, and a phone's address changes as it moves between networks.
• Reassignment. Home broadband addresses can change over time, so the address you logged in March may belong to another customer by October.

None of this makes an IP worthless. It makes it a probabilistic signal about a connection at a moment, rather than a stable key for a person.

Why the timestamp matters

The timestamp is what ties the address back to a moment. Google's help page describes the IP column as the address of the customer's device "captured at the exact moment of interaction", and the timestamp as "The time of the recorded interactions from the corresponding IP address." Leave it out and the default is blunt: "If an IP address is uploaded without a timestamp, the system defaults to the 'latest known' user of that IP."

Say you upload an address recorded when a customer bought from you months ago. Without a timestamp, Google matches whoever it most recently associated with that address: a new tenant, a hotel guest or a stranger on the same carrier address. Your "existing customers" list fills with people who never bought, and a customer-exclusion list starts excluding prospects.

What an advertiser outside Europe still has to do

For users outside the excluded countries the feature is available, but the policy obligations that apply to every Customer Match upload still apply. Google's policy says you may only upload customer information "that you collected in the first-party context", and it requires you to:

• "Ensure that your privacy policy discloses that you share customer data with third parties to perform services on your behalf".
• "Obtain consent for such sharing where required by law or any applicable Google policies", including Google's EU User Consent Policy.
• Upload only through Google's approved API or interface, and comply with applicable law and industry codes.

That means four pieces of work before the first upload. Check that your privacy notice says plainly that you log IP addresses and interaction times and share them with advertising partners; most notices mention logging for security, not ad matching. Check what consent local law requires, because the policy defers to it. Decide how long you keep the logs, since an old address is exactly what the "latest known" default mishandles. And build the regional split: classify each row by where the user was, drop the EEA, UK and Swiss rows, and record how you did it. Classifying by IP location is itself imperfect near borders and behind VPNs, so err towards exclusion.

If your audience is in Cyprus, the UK or the EU

For those users you cannot use this route at all. The GDPR's recital 30 names "internet protocol addresses" among the online identifiers that can be used to profile and identify people, and Google's EU user consent policy already requires advertisers to obtain "legally valid consent" in the EEA, the UK and Switzerland for "the collection, sharing, and use of personal data for personalization of ads."

The work that does pay off here is the familiar list:

1. Collect first-party data people give you on purpose, such as account sign-ups, enquiries, bookings and loyalty schemes, with a clear consent record, and use it for standard email and phone Customer Match.
2. Set up enhanced conversions, which send hashed first-party conversion data such as email addresses and phone numbers, so measurement improves without IP matching.
3. Import offline conversions from your CRM so qualified leads and closed deals, not just form fills, feed bidding.
4. Keep the consent banner, the privacy notice and what the tags actually send in agreement.

We cover how to collect and organise that data in our guide to first-party data in 2026. If you run global campaigns from Europe, treat IP matching as something to test only on clearly non-European traffic, with timestamps, and only after your privacy notice has been updated.