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

Customer Match has quietly grown two new columns. Alongside the hashed email and phone number you have been uploading for years, Google Ads now accepts a customer's IP address and the time of the interaction it came from, and it wants the IP unhashed. Match-rate gains from the new signals are expected through the back half of 2026. What Google has not published is a single number showing how much they help, which makes this a decision you have to make on your own evidence.

What actually changed in the upload file

Google's Customer Match help documentation now lists eight column headers for a data file upload: Email, Phone, First Name, Last Name, Country, Zip, User IP address and User interaction timestamp. IP support landed in the Data Manager API on 28 May 2026, and reporting through the autumn has pointed at improved match rates from these identifiers arriving around October 2026.

Four mechanics matter more than the announcement.

• The IP is not hashed. Email and phone are still uploaded SHA-256 hashed and normalised. The IP address is passed as a plain string, IPv4 or IPv6. Every other identifier in the file follows the opposite rule, which is why this is the single most common implementation mistake on a first attempt.
• The timestamp only exists to disambiguate the IP. It records when the address was observed, so Google can attribute it to whoever was using it then. It cannot be sent without an IP.
• Without a timestamp, Google uses the latest known user of that address. On a shared office connection or a carrier-grade NAT range, that is close to a guess.
• The exclusions are hard, not advisory. IP matching is not supported for people located in the European Economic Area, the United Kingdom or Switzerland, which is 32 countries. The data is also unsupported for Display & Video 360 Customer Match uploads.

Why Google wants this, and what that tells you

Customer Match has one failure mode: the identifier you hold is not the identifier Google holds. A customer who bought using a work email and signs into Google on a personal account is unmatchable on email alone. Phone numbers close part of that gap. An IP address plus a timestamp closes a different part of it, because it describes a moment and a network rather than an account.

That is also the reason to be sceptical of large expected gains. An IP is a weaker identifier than an email address, not a stronger one. It is shared, reassigned, proxied and increasingly masked by the privacy features in iOS and in Chrome's own roadmap. The signal is useful at the margin, for records where the strong identifiers failed, and the margin is where your lift will come from. Anybody promising a transformation here is selling something.

It is worth naming what this move says about the direction of travel. Google is adding weaker, noisier identifiers to a product that used to rely on strong ones, at the same time as it restricts them in every jurisdiction with a privacy regulator. That is what signal loss looks like from the platform's side of the table.

Should you populate the new columns? A decision matrix

This is not a universal upgrade. The honest answer depends on three things: where your customers are, how good your IP data actually is, and whether anything downstream will notice an improvement.

How to measure the lift yourself

Google has published no figure for how much IP and timestamp data raises match rates, so treat any number you read as someone's inference. You can get your own in about a week with a split upload. The protocol matters, because match rate is noisy enough to fake a result if you are careless.

1. Take one extract, one day. Pull a single list from your warehouse and split it into two random halves. Same extract, same timestamp, same cleaning rules. Two lists pulled a week apart are not comparable.
2. Make both halves large enough. Customer Match needs a minimum list size before Google will report a match rate at all, and small lists produce unstable rates. Aim for a comfortable multiple of the minimum in each half, not the minimum itself.
3. Populate IP and timestamp on half A only. Every other field stays identical in both. Exclude EEA, UK and Swiss records from the test entirely, in both halves, so the exclusion is not silently doing the work.
4. Wait for processing to settle. Upload both on the same day, then leave them alone for several days. Reading a match rate the morning after an upload is the most common way to get a wrong answer.
5. Compare matched users, not percentages alone. Record the absolute matched-user count for each half. A percentage point on a 40,000-record half is 400 people, and 400 people is what you will actually be bidding on.
6. Repeat once. Run the same split a month later with a fresh extract. If the direction holds twice, it is a finding. If it flips, your IP data is not good enough to be worth the plumbing.

What a match-rate point is worth

Before committing developer time, convert the expected gain into money. The arithmetic is simple enough to do on paper, and it usually settles the argument faster than any debate about identity resolution. Working through an illustrative case, with every input a number you should replace with your own:

Then the break-even question, which is the one that actually decides it: if adding two columns to your upload pipeline costs a developer two days, and two days costs you $1,600, you need roughly a quarter of that illustrative gain to justify the build. That is a low bar, and for most retailers with clean session data it will clear easily.

The same arithmetic kills the project in two situations. If your list is small, the percentage gain lands on too few people to matter. And if nothing downstream is using Customer Match for bidding or exclusion, a better-matched list improves a number nobody acts on. A match rate is not an outcome. Check that these audiences are feeding bidding, exclusions or budget decisions before you spend anything improving them.

The governance part, which is not optional

You are about to send a third party a plain, unhashed identifier that European law treats as personal data. The EEA, UK and Swiss exclusions exist precisely because of that classification. Four things to confirm before the first upload, none of which your media team can sign off alone:

• Disclosure. Your privacy notice should describe sharing this category of data with advertising partners in terms a regulator would recognise, not as a generic reference to "partners". If you refreshed your consent and privacy setup for cookies and never revisited server-side data sharing, this is the gap.
• Lawful basis by region. Not all non-EEA markets are permissive, and the list of territories with meaningful data protection law has grown considerably since Customer Match launched. The 32-country exclusion is Google's floor, not your compliance boundary.
• Retention. Raw addresses sitting in a warehouse table forever, so they are available for a nightly audience sync, is a different risk posture from an IP in a web log that ages out in 30 days.
• Who approved it. Write down who made the decision and on what basis. This is a reasonable question to be asked in two years, and "the agency set it up" is not a satisfying answer.

None of this is an argument against using the feature. It is an argument against letting a two-column change to a CSV bypass the review that any other new data flow to a third party would get.

What this changes about how you buy media

For anyone managing paid media through an agency, the useful question this quarter is narrow: has anyone tested whether our Customer Match lists are matching better than they were in June, and do we have the number? Three answers tell you what you are dealing with. A tested figure from a split upload means the team is doing the work. "We've enabled it" with no number means nobody checked. And "Google says match rates improved" means your partner is quoting a platform claim back to you as evidence, which is the same error as trusting platform-reported ROAS without a cross-check.

Frequently asked questions

Does Google Customer Match accept IP addresses now?

Yes. Google Ads Customer Match data file uploads now list eight column headers: Email, Phone, First Name, Last Name, Country, Zip, User IP address and User interaction timestamp. IP support arrived in the Data Manager API on 28 May 2026 and Google has indicated match-rate improvements from these signals around the second half of 2026. Google has not published any figure for how much either column lifts match rates.

Do I need to hash the IP address for Customer Match?

No, and you must not. Email addresses and phone numbers are still uploaded SHA-256 hashed and normalised, but the IP address is passed as a plain, unhashed string. Both IPv4 and IPv6 are accepted. This is the opposite of the handling rule for every other identifier in the file, which is exactly why it gets implemented wrong on the first attempt.

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

No. Google's documentation bars IP matching for people located in the European Economic Area, the United Kingdom and Switzerland, which is 32 countries in total. If your list mixes European and non-European customers, the practical answer is to segment by region and only populate the IP column for records outside those 32 countries, rather than uploading a single mixed list and hoping the exclusion is applied the way you assume.

What does the user interaction timestamp do in Customer Match?

It tells Google when the IP address was observed, so the address is attributed to whoever was using it at that moment. Without a timestamp, Google falls back to the most recent known user of that address. The timestamp cannot be sent on its own: it is only valid alongside an IP. For shared and dynamically assigned addresses, the timestamp is what separates a usable signal from a coin flip.

Does IP matching work in Display & Video 360?

No. IP data is not supported for Display & Video 360 Customer Match uploads, so a list built for DV360 gains nothing from the new columns. If you run the same audience across Google Ads and DV360, expect the two to report different match rates from the same source file, and do not treat the gap as an error.

How do I measure whether IP matching improves my match rate?

Split one source list into two random halves, upload half A with the IP and timestamp columns populated and half B without them, keep every other field identical, and compare the match rate Google reports for each list once processing settles. Both halves must come from the same extract on the same day and both must exceed the minimum size for Customer Match to report a rate. This is the only way to get a number, because Google has published none.

Is uploading customer IP addresses to Google a privacy risk?

It is a decision to document rather than a box to tick. An IP address is personal data under European law, which is why the EEA, UK and Switzerland are excluded from IP matching at all. Before populating the column, confirm your privacy notice discloses sharing of this category of data with advertising partners, that you have a lawful basis for the regions you are uploading, and that your retention policy covers the raw addresses sitting in your warehouse. Take that question to counsel, not to your media agency.

The takeaway

Two new columns, one of them unhashed, excluded across 32 countries and unsupported in DV360, with no published figure for what they are worth. That is a feature to test rather than adopt. Run the split upload on a single extract, record matched users rather than percentages, multiply the difference by your own conversion rate and order value, and you will know in a fortnight whether it earns a place in your nightly sync. If your customers are mostly European, you already have your answer and can spend the quarter on something that will move.