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

Customer Match has accepted the same six columns for years: email, phone, first name, last name, country and postcode. Google's file-upload documentation now lists eight. The two new ones are the user's IP address and the timestamp of their interaction, and unlike every other identifier in the file, Google wants them sent unhashed. That is a meaningful change in what you are handing over, which makes it worth deciding rather than defaulting.

What changed, and what did not

Precision matters here, because the feature has arrived in two stages and the headlines have blurred them. IP address support first appeared in the Google Data Manager API on 28 May 2026, which made it available to advertisers with the engineering resource to use the API. What changed in late September 2026 is that IP address and interaction timestamp now appear as accepted column headers in the standard Customer Match data-file upload path, the one documented in Google Ads Help for building a list from a CSV.

That second step is the one that matters commercially. It moves the capability from "a thing your data team could build" to "a thing your media buyer can do this afternoon with a spreadsheet". Reporting around the change also indicates improved match rates from October 2026 onwards, which is a forward-looking claim from Google rather than something anyone has measured yet.

What did not change: the hashing rules for the original identifiers, the Customer Match policy requirements, or your consent obligations. The new columns are additive and optional. Google's guidance is that you include only the fields relevant to your customers, and a row can carry an IP with or without personal data, or personal data with or without an IP.

The full eight-column reference

This is the part most write-ups leave half-finished, and it is the thing you actually need open in front of you when you build the file. Note that the hashing rule is not uniform across the file, which is the most common source of a failed upload.

The accuracy trap in an IP without a timestamp

This is the single most important technical detail in the change, and it is easy to miss. An IP address uploaded without a timestamp is matched to the latest known user of that IP address. Not the user who was on it when you captured it. The latest one.

Think about where that goes wrong. A residential IP reassigned by the ISP. A mobile carrier running NAT, where thousands of subscribers share an address. An office, a university, a café, a hotel. A VPN exit node. In every one of those cases, an undated IP is an invitation to match your customer record to a stranger, and you will never see the error, because a wrong match looks exactly like a right one in your reporting.

The practical rule is short: never upload an IP without the interaction timestamp. If your source data does not carry a reliable timestamp for the IP capture, leave the IP column out of that row entirely. A missing identifier costs you a bit of reach. A wrong identifier costs you spend against the wrong person and corrupts the signal your bidding is learning from, which is the more expensive of the two.

The geography problem is a list-splitting problem

Google does not support IP and timestamp matching for people located in the European Economic Area, the UK or Switzerland. That is the 30 EEA states plus two, which is where the frequently-quoted "32 countries" figure comes from. Because a timestamp cannot travel without an IP, the timestamp column is closed to the same population.

The obligation that follows sits with you, not Google: you need to exclude those users from IP sharing, and ensure your data collection includes the appropriate disclosures and consent. In practice that means the decision is not "do we upload IPs" but "can we reliably split our customer list by user location before upload". Two things make that harder than it sounds:

• Billing country is not user location. A customer with a UK billing address browsing from Dubai, or a US-billed customer resident in Berlin, will be mis-segmented by the obvious field.
• The IP itself is the best location signal you have, and you are not allowed to use it that way for these users. You can geo-resolve an IP to decide whether to exclude the row, but your lawful basis for processing it at all still has to hold up for the European users you are excluding.

If you cannot split your list with confidence, the defensible position is to leave the IP column empty across the whole file and keep uploading the six fields you always have. That is a legitimate outcome, not a failure. This is the same calculus we walked through for first-party data under signal loss: the compliant subset of a technique is often where all of its value sits anyway.

Is the uplift worth the work? A model

Nobody outside Google has credible published numbers on how much IP matching lifts match rates, and anyone quoting a precise figure in October 2026 is guessing. So rather than borrow someone's number, work out what the uplift would need to be for the project to pay for itself. That calculation you can do with your own data today.

The arithmetic is straightforward. Incremental matched users equal your list size times the match-rate gain in percentage points. The value of those users is whatever they are worth to you in the channel you will use them in.

At those inputs it clears, but not by a margin that survives a smaller list. Run the same table with 20,000 uploadable records and a 1-point gain and you get 200 incremental users and £800 of value against the same legal review. That is the real finding here, and it is the one nobody writing about this change says out loud: IP matching is a large-list feature. The engineering and compliance cost is close to fixed, so the economics are driven almost entirely by how many records you have on the non-European side of the split.

A rough threshold from the structure of that maths: below roughly 50,000 uploadable records, the uplift is unlikely to repay a proper legal review, and your match-rate effort is better spent on email and phone hygiene, which is free and helps every list you own.

Where the data has to come from

One more constraint that rules some advertisers out entirely. IP data has to be uploaded unhashed, which means it has to exist, unhashed, in a system you control, captured against a timestamped interaction, with a lawful basis and disclosure covering this use.

Work through your sources honestly:

1. Server logs. Technically the cleanest source of IP plus timestamp, and usually the one with the weakest consent story, because log retention is typically justified on security grounds rather than advertising.
2. Form submissions and CRM. Often carries an IP, frequently without a usable event timestamp, and the privacy notice rarely mentions sharing it with an ad platform.
3. Transaction records. Usually has a solid timestamp. The IP captured is the checkout IP, which is a genuine interaction and a reasonable thing to match on.
4. Analytics or tag-manager data. Frequently IP-truncated or IP-anonymised by your own configuration, which makes it useless for this and is generally a setting you should not reverse to enable it.

If the honest answer is that your only clean source is server logs and your privacy notice does not cover advertising use, the project stops there. Rewriting a privacy notice to unlock a three-point match-rate gain is a poor trade, and it is the kind of change that attracts attention later.

A note on Display & Video 360

IP matching does not extend to DV360. The Data Manager API now supports sending offline conversion events to Google Marketing Platform products, which covers Campaign Manager 360, Search Ads 360 and Display & Video 360, but the IP-matching capability specifically is not available there. If your programmatic activity runs through DV360 and that is where your audience strategy lives, this change does not reach you yet. Plan around Google Ads and keep DV360 on the existing six identifiers.

What to do this month

1. Check your current match rates per list in Audience Manager and write them down. You cannot evaluate an uplift without a baseline, and most accounts have never recorded one.
2. Run the geo split on your largest list and count how many records sit outside the EEA, UK and Switzerland. That number decides whether the rest of this is worth reading twice.
3. Find out whether you have a real interaction timestamp for your IP data, not a record-updated date. This is usually where the project quietly dies, and it is better to find out in week one.
4. Get the consent and disclosure position reviewed before you build anything. The upload is unhashed personal data going to an ad platform; that is a question for whoever owns privacy at your organisation, not for the media team.
5. Test on one list, not all of them. Add IP and timestamp to a single large audience, hold the rest unchanged, and compare match rate and audience-level performance over a full conversion cycle before rolling it out.

Point five matters more than it looks. A match-rate increase is not the same thing as a performance increase, and the difference between them is the whole question. More matched users with weaker intent can lower the quality of what Smart Bidding learns from, in the same way that late offline conversion uploads degrade the signal while looking fine in reporting. Judge this on the audience's performance, not on the match-rate number that is easier to screenshot.

Frequently asked questions

What are the eight Customer Match columns in 2026?

The accepted column headers for a Google Ads Customer Match data file are now Email, Phone, First Name, Last Name, Country, Zip, User IP address and User Interaction timestamp. Email, phone, first name and last name must be SHA-256 hashed. Country and zip go in as plain text. The two new columns, IP address and interaction timestamp, must also be passed unhashed. All fields are optional: Google's guidance is to include only the fields relevant to your customers.

Does Google want Customer Match IP addresses hashed?

No. Google's instruction is explicit that the IP address and the interaction timestamp should be passed as plain, unhashed strings. This is the opposite of the rule for email, phone and name fields, which must be SHA-256 hashed, and it is the most common cause of a failed upload for advertisers adding the new columns to an existing pipeline. The IP field accepts either IPv4 or IPv6 addresses.

Can I use Customer Match IP matching for customers in the EU or UK?

No. Google does not support IP and timestamp matching for users located in the European Economic Area, the UK or Switzerland, which is where the figure of 32 excluded countries comes from. The obligation to exclude those users from IP sharing sits with the advertiser, along with ensuring appropriate disclosures and consent. Because a timestamp cannot be supplied without an IP in the same row, the timestamp column is closed to the same population. In practice this makes IP matching a list-segmentation project before it is an upload project.

What happens if I upload an IP address without a timestamp?

The IP is matched to the latest known user of that address rather than the person who was using it when you captured it. That is a significant accuracy risk on any shared or reassigned address, which includes residential IPs rotated by an ISP, carrier-grade NAT on mobile networks, offices, cafés, hotels and VPN exit nodes. A wrong match is invisible in reporting because it looks identical to a correct one, so the safe rule is to omit the IP entirely on any row where you do not have a reliable interaction timestamp.

Does Customer Match IP matching work in Display & Video 360?

No. IP matching is not available in DV360. The Google Data Manager API does now support sending offline conversion events to Google Marketing Platform products, a group that includes Campaign Manager 360, Search Ads 360 and Display & Video 360, but the IP-matching capability specifically does not extend to DV360. Advertisers whose audience strategy runs through DV360 should continue with the existing six identifiers there.

Is the match-rate improvement from IP matching worth the effort?

It depends almost entirely on list size, because the engineering and legal cost is close to fixed while the benefit scales with the number of records. Multiply your uploadable list size, after excluding EEA, UK and Switzerland users, by the match-rate gain in percentage points to get incremental matched users, then multiply that by what a reachable customer is worth in the channel you will use them in. Below roughly 50,000 uploadable records the uplift is unlikely to repay a proper privacy review, and effort is better spent on email and phone data hygiene.

When did Google add IP address support to Customer Match?

In two stages. IP address support first arrived in the Google Data Manager API on 28 May 2026, which made it available to advertisers working through the API. In late September 2026, User IP address and User Interaction timestamp appeared as accepted column headers in the standard Customer Match data-file upload documentation, which opened the capability to any advertiser building a list from a CSV. Reporting around the change indicates improved match rates from October 2026 onward.

The takeaway

This is a useful change wrapped in three constraints that decide whether it applies to you: the data must be unhashed, European users must be excluded, and an IP without a timestamp is an accuracy liability rather than an extra signal. Work it in that order. Count how many records you have outside the EEA, UK and Switzerland, confirm you hold a genuine interaction timestamp rather than a record-updated date, and get the consent position reviewed before anyone writes a pipeline. If your uploadable list is large and your data is clean, add the columns to one audience and judge it on that audience's performance rather than on the match rate. If it is small, this is not your lever, and your email hygiene almost certainly is.