Customer Match IP Matching in 2026: Eight Upload Columns, Raw IPs and New Limits

In late September 2026 Google quietly rewrote the Customer Match upload documentation: a data file may now carry eight columns, two of them new — user IP address and user interaction timestamp. Customer Match IP matching is the first case where the platform accepts an identifier that must not be hashed. This article covers exactly what changed in the file format, which field combinations are valid, where the feature is unavailable entirely, and whether handing Google raw IP addresses is a trade worth making for a match-rate bump nobody has quantified yet.

Customer Match IP matching: what changed in the upload format

Google built Customer Match on contact data: email, phone, name, mailing address. The two new fields describe something different — not a person, but a technical event: which address interacted with you, and when.

The eight headers the uploader accepts:

Column	Hashing	Notes
Email	SHA256 after normalization	can be submitted in the clear; the UI hashes locally before transmission
Phone	SHA256, E.164 format	no spaces, country code included
First Name	SHA256	only meaningful alongside the other address fields
Last Name	SHA256	same
Country	unhashed	two-letter code
Zip	unhashed	postal code
User IP address	unhashed	IPv4 or IPv6 as a string, trim surrounding whitespace
User interaction timestamp	unhashed	time of the interaction from that address

Mobile Device ID sits outside this set: a file containing device IDs must contain that column and nothing else.

File requirements are unchanged — CSV encoded as ASCII or UTF-8. The uploader does not support UTF-16, which is a common reason exports from older CRMs fail with an unhelpful error.

Raw IPs: why that detail matters

Google has always explained Customer Match the same way: you hash the contact data, Google never sees the original values, matching happens on hashes. That story does not extend to IP addresses. The documentation is blunt — pass it as a plain, unhashed string.

The reason is well understood. IPv4 has roughly 4.3 billion possible values, few enough that a hashed address can be brute-forced in reasonable time. Hashing here would offer no protection, only the appearance of it, so Google does not ask for it. For an advertiser that means one thing: the IP arrives at Google as-is, and the decision to send it is a privacy decision, not a file-format decision.

Email and phone were always framed as data Google does not see in the clear. That framing does not apply to the IP column. If your organization has a policy governing what identifiers leave for a vendor, this field belongs in that process — not in a campaign setup checklist.

The timestamp field, and the trap in leaving it out

Google defines the field as the time of recorded interactions from the corresponding IP address. Conceptually Google describes two values — the earliest and the most recent interaction — yet the CSV offers a single header, and the documentation does not reconcile that.

The uploader accepts several formats. Only two are unambiguous:

• 2026-08-15T00:01:54Z — UTC;
• 2026-08-14T17:01:54-07:00 — with an offset.

Looser forms such as Aug 14, 2026 17:01:54 also pass, but they carry no time zone, and nothing states which zone Google assumes. Practical rule: always send UTC with the Z suffix. It is the only form that reads identically regardless of account settings.

Now the part that bites. If an IP is uploaded without a timestamp, the system falls back to the “latest known” user of that address. That sounds harmless until you remember how addressing works: providers reassign dynamic IPs, and one public address can front an entire household, an office floor or a coffee-shop network. A six-month-old export with no timestamps is not a list of your customers — it is a list of whoever sits behind those addresses today.

Which combinations are valid

• IP with contact data — the intended case; it supplements matching.
• Contact data without IP — classic Customer Match, unchanged.
• IP and timestamp only, no email or phone — permitted.
• Timestamp alone, with no IP and no contact data — upload error.

The third option looks tempting for companies without a contact database. It is also the weakest on quality, for reasons covered below.

Where it does not work: EEA, UK and Switzerland

Google states the restriction plainly: IP matching does not work for end users located in the EEA, the UK or Switzerland. Because a timestamp cannot travel without an IP, the whole mechanism is closed for those markets — 30 EEA states plus two.

What the documentation does not explain: whether Google discards such rows itself, rejects the file, or leaves the obligation entirely with the advertiser. Nor does it say how Google determines location — by geolocating the IP, by the Country column, or by the account. For teams working European markets the safe reading is to filter those rows out before export rather than trust validation on receipt.

The legal position is unsettled too. Whether dynamic IP addresses count as personal data when the recipient cannot reasonably identify the user is currently before the Court of Justice of the EU. Until that is answered, the conservative stance is not to send European IPs at all.

The API path: Data Manager, not the Google Ads API

The file upload is the visible surface; the capability landed earlier. In May 2026, Data Manager API v1.7 added IP ingestion for Customer Match through a composite structure that pairs the usual hashed contact data with an address object. The address field is required; two observation-time fields, start and end, are optional but recommended. At launch only Google Ads was eligible — Google left Display & Video 360 out.

This fits the broader direction. Since spring 2026 Data Manager has been the required route for new Customer Match integrations, and new implementations sending IP addresses and session attributes through conversion imports in the Google Ads API were cut off even earlier. If you are building a first-party pipeline now, build it on Data Manager — how it is structured is covered in our piece on feeding in-store purchases through the Data Manager API.

There is also an encryption layer. For contact data, matching can run inside a trusted execution environment; we describe the mechanics in confidential matching in Google Ads. Google does not state whether that protection extends to rows carrying IP addresses — one more argument for caution.

Match rate: what to expect and what not to

The promise attached to the API release was that IP addresses supplied with observation timestamps would drive higher Customer Match match rates beginning in Q3 2026. That quarter has closed, and no public figure confirming the effect appears in the documentation.

There is also a caveat in Google’s own help: a match rate is not an indicator of list performance. A high share of matched rows tells you profiles were found, not that they are the right people. With IP-based matching that distinction stops being academic.

Independent research into IP-to-person accuracy is sobering. Treat these as directional — none of them tests Google’s own matching, for which Google has published no accuracy data:

• IP-to-postal links proved correct roughly 13% of the time; IP-to-email around 16%;
• six data providers agreed on the same household link only 6.4% of the time;
• in a separate study, about 23% of residential IPs reached their intended geographic target.

None of that means ignore the feature. It means IP is a supplementary signal layered on contact data, not a substitute for it. A list assembled from addresses alone probably describes someone other than your customers.

The 100-user floor and list lifetime

• Minimum audience size for serving across networks is 100 users.
• Google only displays match rate for uploads through the current API, and only when at least 100 rows match unique users.
• Membership duration: Google caps it at 540 days. Note that other sections of the help still repeat an older line about unlimited default duration — work to 540.
• Enhanced Matching, introduced in August 2026, pairs consented users and caps membership at 60 days rather than 540.

Why lists shrink over time, and how that interacts with the 100-user floor, is the topic of Customer Match and first-party data.

A working sequence

1. Settle consent before you touch the file

Google requires advertisers to exclude users in restricted regions and to ensure their collection practices carry appropriate disclosures and consent. The checkbox in every upload flow still reads that the data “was collected and is being shared with Google.” If your privacy policy does not describe sending technical identifiers to advertising platforms, amend the policy first and export second. For how the consent signal interacts with measurement, see Consent Mode v2.

2. Build the export properly

• One row equals one interaction from a specific address — not “the customer’s last known IP.”
• Timestamps in UTC with the Z suffix, always.
• Filter rows with European geography on your side.
• Do not send addresses older than a few weeks; the older the row, the likelier someone else now has the address.
• Check encoding: ASCII or UTF-8, never UTF-16.

3. Test on a segment, not the whole base

Build two lists: a control with contact data only, and a test with the same users plus IP and timestamp. Compare audience behaviour rather than match rate — cost per conversion and volume. If the matching metric moves and the money does not, you added noise rather than reach.

4. Look at data density as a whole

One list is not how you judge a first-party setup. Google Ads exposes a metric for how many conversions your data configuration recovers; what it means and how to read it sits in our breakdown of Data Strength. In parallel, make sure the measurement floor is not leaking — enhanced conversions and server-side delivery return more than any exotic identifier will.

Building the export: the query logic

This looks simple until you sit down with SQL. The mistake in most first attempts is pulling “the customer’s last known IP” from the user table and attaching it to the contact row. That is precisely the pattern the documentation flags as unreliable.

The correct shape is closer to an event log than a customer record:

1. Start from the interaction table — sessions, logins, checkouts — carrying user ID, IP and event time.
2. Filter by recency. A sensible window is the last two to four weeks. Drop anything older: someone else very likely has the address now.
3. Strip junk addresses. Internal ranges, your own office, monitoring and bot traffic have nothing to do with customers. An office IP will build an audience of your staff and everyone else in the building.
4. Drop addresses with abnormal density. If dozens of distinct users sit behind one address, you are looking at corporate NAT, public Wi-Fi or a mobile carrier. That row identifies nobody.
5. Filter by geography. Rows attributable to the EEA, UK or Switzerland do not get sent.
6. Join the contact data for the same user — normalized email and phone.
7. Format time in UTC with the Z suffix and verify file encoding.

A separate decision: what counts as one interaction. If a user visited ten times in a week, ten rows will not produce ten times the effect — they will inflate the file and push you toward the limits. A reasonable compromise is one row per user-plus-address pair, carrying the most recent interaction time.

Customer Match IP matching: risks worth stating out loud

• Legal. The IP leaves in the clear. If your privacy policy, customer agreements or internal rules do not cover sharing technical identifiers with vendors, this is a process violation, not a campaign setting.
• Quality. An address-built audience can include people who were never your customers — NAT neighbours, the next holder of a dynamic address, other patrons of the same café.
• Measurement. It is easy to read a match-rate increase as a performance increase. They are not the same thing: matching says a profile was found, not that it is the right one.
• Operational. A new column means a new pipeline and a new place for things to break. If you assemble the export by hand once a month, data freshness will be worse than the mechanism requires.

Should you do this at all?

Short answer: yes if your contact layer is already solid, no if you use IP to paper over missing data.

Situation	Decision
Solid email and phone base, want incremental reach	add IP and timestamp as extra columns, test on a segment
Primary markets are the EU, UK or Switzerland	do not use it — unsupported
No contact base, only server logs	do not build audiences from IPs alone; link accuracy is low
Privacy policy silent on identifier sharing	legal first, upload second
Data older than a month	skip it — addresses have been reassigned and “latest known” will be a stranger

The context matters as well. With Privacy Sandbox shut down and browser restrictions tightening, ad platforms are reaching for every durable signal available, and the IP address is the most accessible of them. For what that shift means for advertisers overall, see third-party cookies after Privacy Sandbox.

Where PPC Rebels fits

First-party data work depends on something duller than pipelines: an ad account that keeps running. Lists, API access and measurement are all moot if campaigns stall in review. For teams building across several markets, splitting the problem makes sense — the technical layer stays in-house while accounts and access go to people who handle them daily: agency Google Ads accounts and account verification. For groundwork on measurement and structure, see Google Ads training.

FAQ

What new columns were added to Customer Match?

Two: “User IP address” and “User interaction timestamp.” Together with email, phone, first name, last name, country and zip, a file can now carry eight columns.

Do I need to hash the IP address?

No. IP is passed as a plain unhashed string, as are the timestamp, country and zip. You hash only email, phone, first name and last name.

Which timestamp format should I use?

ISO 8601 in UTC — for example 2026-08-15T00:01:54Z. The uploader accepts formats without a time zone, but nothing documents which zone Google assumes for them.

What happens if I upload an IP without a timestamp?

The system uses the “latest known” user of that address. On older exports that means matching strangers, because providers reassign addresses.

Can I upload a list of IP addresses only?

Technically yes — IPs may be sent without contact data. Practically it is risky: independent research shows low accuracy linking an address to a specific person or household.

Does IP matching work in Europe?

No. It is unsupported for end users in the EEA, the UK and Switzerland, and a timestamp cannot be sent without an IP.

Is Display & Video 360 supported?

Not at the API launch — only Google Ads was eligible.

What is the minimum list size?

100 users to serve across networks. Match rate is shown when at least 100 rows match unique users and the upload runs through the current API.

How long does a Customer Match list live?

Google caps membership at 540 days. Enhanced Matching is stricter at 60 days.

Will this actually raise my match rate?

A lift was promised at the API release, but no public figures confirm it in the documentation — and Google itself notes that match rate does not indicate list quality.

What file format does the uploader accept?

CSV encoded as ASCII or UTF-8. The uploader does not support UTF-16.

Can Mobile Device ID be mixed with other columns?

No. A file containing mobile device IDs must contain only that column.