Google Customer Match now takes raw IP addresses. Should you send them?

In September 2026 Google Ads added two columns to the Customer Match upload format: User IP address and User interaction timestamp. Both go in unhashed, which makes them the first identifiers in Customer Match that Google asks you to send in the clear. The promised benefit is a better match rate, with improvements expected from October 2026. The promised figure does not exist.

What changed, precisely

The Customer Match upload format now accepts eight documented identifiers: Email, Phone, First Name, Last Name, Country, Zip, User IP address and User interaction timestamp. Google's help documentation sets out the handling rules, and the important asymmetry is in the hashing:

Two constraints are already documented and both matter more than the feature. IP and timestamp matching is not supported for end users located in the European Economic Area, the United Kingdom or Switzerland, and Google expects advertisers to add logic that conditionally excludes IP values for users in those regions rather than uploading everything and assuming Google will filter it. Separately, the new identifiers landed in Google Ads and not across the stack, with Display & Video 360 reported as excluded at launch. If your audience strategy spans both, you are now maintaining two different list specifications.

The benefit nobody has quantified

Google's documentation says to send both new fields to help improve match rates, and that improvements from these signals are expected to begin in October 2026. That is the whole of the public claim. There is no percentage, no range, no segment breakdown, and at the start of October 2026 no independent dataset either.

Treat that honestly. A new matching signal plausibly helps most where your primary keys are weakest: long-lived accounts with stale emails, phone-first markets, B2B lists where people change employers, and anything assembled from form fills with typos. It plausibly helps least where you already have clean, recent, verified email addresses, which is also the situation most advertisers asking about this feature are in. "Expected improvements" with no number attached is not a reason to rebuild a data pipeline in the middle of Q4.

Measure the lift yourself: the split upload

You can test this without a holdout on spend, because Google reports a match rate per list. The design is simple and takes about an hour once the data exists.

1. Pick one list of at least 10,000 records where you have both hashed primary keys and sourceable IP plus timestamp pairs. Lists much smaller than this will not produce a readable difference, and Google applies its own minimum size before a list is usable for targeting.
2. Split it randomly in half. Random, not by date or source: splitting by signup date confounds the test with data freshness, which is the exact thing you are trying to isolate.
3. Upload half A with your existing columns only. This is your control, and it tells you what your current match rate genuinely is rather than what you remember it being.
4. Upload half B with the same columns plus IP and interaction timestamp. Same normalisation, same hashing, one difference.
5. Wait for both lists to finish processing, then compare the reported match rates. Matching is not instant and a partially processed list reads low.
6. Decide on the delta, not on the feature. Our threshold: under roughly two percentage points is not worth a new data pipeline and a new category of personal data leaving your systems. A larger delta justifies the engineering, and you now have a number to put in front of whoever has to approve the privacy side.

Repeat on a second list before generalising. Match rate varies enormously by list provenance, and one result from your cleanest list tells you little about your messiest one.

The plumbing problem: most CRMs cannot do this

This is where most implementations will fail, and it is barely mentioned in the coverage. The field is not "an IP address for this customer". It is the IP address observed at a specific interaction, paired with the time of that interaction. Those are different data objects, and the first is far more commonly stored than the second.

There is a second trap in the data itself. An IP identifies a network connection at a moment, not a person. Shared office networks and household NAT put many people behind one address; carrier-grade NAT puts thousands of mobile users behind one; VPN use attaches a datacentre address to a real customer; and dynamic allocation reassigns residential addresses on a schedule you do not control. The timestamp exists precisely to narrow that ambiguity, which is why sending IP without it is worse than sending neither.

The compliance question the PPC coverage stops too early on

Almost every write-up of this change notes the EEA, UK and Switzerland exclusion and then moves on, which leaves US and other advertisers with the impression that the absence of a ban is the absence of an obligation. It is not, and the gap has widened this year.

Under the CCPA as amended, an IP address is personal information where it can reasonably be linked to a consumer or household. Disclosing personal information for cross-context behavioural advertising is defined as "sharing" even where no money changes hands, which is a reasonable description of uploading identifiers to an ad platform to target people. And from 1 January 2026, revised regulations tightened the mechanics: businesses must not only honour an opt-out preference signal such as Global Privacy Control, they must also show the consumer that the signal has been recognised and processed, a shift from "may" to "must" in the rule text. California's Delete Request and Opt-out Platform also opened to consumers on 1 January 2026, with data brokers required to check it on a 45-day cycle from 1 August 2026.

Google's own Customer Match policy already requires you to disclose your data collection clearly and to obtain consent where law or Google policy requires it. That obligation does not weaken because a field is optional.

We are an agency, not your lawyers, and this is a judgement call that belongs with your counsel and whoever owns your privacy notice. What we will say is that "Google added a field" has never been a defence, and that the teams most eager to send raw IPs are usually the ones whose consent documentation was last reviewed before the 2026 rules took effect. Our note on consent and privacy compliance covers the groundwork.

Where this fits in the wider signal problem

Read this change for what it is: another attempt to patch identity matching as the old identifiers decay. That is the same pressure behind hashed first-party uploads, enhanced conversions, consent mode and the rest, and we have written about the strategic version of it in signal loss and first-party data. The pattern worth noticing is that each patch asks you to send slightly more, slightly less protected data for a slightly better match.

That is not an argument for refusing on principle. It is an argument for pricing each step properly. For most advertisers, in most quarters, the larger win is still upstream of audience matching: getting the conversions you already send to be accurate, complete and timely. A campaign fed clean conversion data with a 60% match rate outperforms one fed late or partial conversions with a 70% match rate, which is the first thing we fix on any performance marketing engagement, and why we would point most readers at the seven-day offline conversion window before this feature. Bidding learns from conversions. Match rate only decides who can be reached.

Frequently asked questions

What did Google change about Customer Match in September 2026?

Google Ads added two identifiers to the Customer Match upload format: User IP address and User interaction timestamp. Both are sent unhashed, unlike email and phone, which must be hashed. Google says these signals are intended to improve match rates, with improvements expected to begin from October 2026. The documented header set is Email, Phone, First Name, Last Name, Country, Zip, User IP address and User interaction timestamp.

Is IP matching allowed in the EEA, UK and Switzerland?

No. Google's documentation states that IP and timestamp matching is not supported for end users located in the European Economic Area, the United Kingdom or Switzerland. Advertisers uploading mixed international lists are expected to add logic that excludes IP values for users in those regions rather than relying on Google to filter them.

How much will IP matching improve my match rate?

Google has not published a figure. Its documentation describes improved match rates expected from October 2026 but attaches no percentage, and no independent dataset existed at the start of October 2026. Any specific number quoted this month is an estimate, not a measurement. The practical answer is to measure it on your own lists with a split upload.

Does US privacy law affect sending IP addresses to Google Ads?

Yes. Under the CCPA as amended, an IP address is personal information where it can reasonably be linked to a consumer or household, and disclosing personal information for cross-context behavioural advertising counts as sharing even when no money changes hands. From 1 January 2026, California businesses must also show consumers that an opt-out preference signal such as Global Privacy Control has been recognised and processed. The absence of an EEA-style ban is not the absence of an obligation. Take this to your own counsel.

Can I build a Customer Match list from IP addresses alone?

Google's documentation permits lists that use IP as an identifier, but it is a poor idea in practice. An IP identifies a connection at a moment, not a person: shared office and household NAT, carrier-grade NAT on mobile, VPNs and dynamic reassignment all break the link. Use IP and timestamp as supplementary signals alongside hashed email and phone, which is how Google positions them.

What data do I actually need to send an interaction timestamp?

You need the IP address observed at a specific interaction and the time of that interaction, as a pair. Most CRMs store a last-seen or record-created IP with no reliable time anchor, which is not the same thing and degrades rather than improves matching. The usable sources are server or edge logs, your tag or data layer at the point of conversion, and authentication logs.

The takeaway

This is a small feature wearing a large headline. The identifiers are real, the EEA, UK and Switzerland exclusion is real, and the benefit is currently a sentence in a help article with no number behind it. So do it in this order: check whether you can source a true interaction IP and timestamp pair at all, because many teams cannot; run one split upload and read your own delta; and only then take the compliance question to the people who own it, armed with a measured benefit rather than a hoped-for one. If the delta is two points, the answer is no, and you will have spent an hour to avoid a quarter.