Google's Customer Match upload page now lists IP address and timestamp columns

Google's Help Center page for building a Customer Match list from an uploaded file now lists eight accepted column headers, and two of them are new kinds of data: "User IP address" and "User Interaction timestamp". The page, Create a Customer Match list by uploading a data file, says the IP address goes in as a plain, unhashed string, that IP matching is not supported for end users in the EEA, the UK or Switzerland, and that an IP uploaded without a timestamp is matched to the "latest known" user of that IP. For advertisers in Thailand, the column is available on paper, but it raises data-quality and privacy questions that deserve an answer before anyone adds it to a file.

What the Customer Match upload page now says

The Google Ads Help page for Customer Match file uploads lists these column headers: Email, Phone, First Name, Last Name, Country, Zip, User IP address and User Interaction timestamp. The first six are the familiar contact-data fields that Customer Match has used for years. The last two are the addition.

For the IP column, the page gives a one-line definition: "The IP address of the customer's device is captured at the exact moment of interaction." The format is a string holding either an IPv4 or an IPv6 address. The formatting rules are short. Trim all leading and trailing whitespace. IPv6 addresses are case-insensitive, so uppercase and lowercase both work. And, in a departure from every other personal field in the file, the page tells advertisers to pass the address "as a plain, unhashed string (don't hash)".

The page also sets a geographic limit in plain words: "IP matching isn't supported for end users located in the EEA, UK, or Switzerland (CH)". Thailand is not on that list, and neither is any other APAC market.

How the timestamp column works with IP addresses

Google's page defines the User Interaction timestamp as "The time of the recorded interactions from the corresponding IP address". In other words, the timestamp is there to pin an IP address to a moment, because the same address can belong to different people at different times.

Three rules on the page govern how the two columns relate:

• "Timestamps can't be sent without an accompanying IP address." A timestamp on its own has nothing to anchor to.
• "If an IP address is uploaded without a timestamp, the system defaults to the 'latest known' user of that IP." So the timestamp is optional, but leaving it out changes who the row is matched to.
• The page says advertisers can send an IP address with or without PII data, and PII with or without an IP address, but that sending only a timestamp, with no IP and no PII, will trigger an error.

That second-to-last point matters more than it looks. It means a list made only of IP addresses, with no email or phone, is allowed by the stated rules. On the page's own wording, an IP row can now stand alone, without any hashed contact field beside it.

Accepted timestamp formats

The Help page lists five example formats for the timestamp column. Only the first two carry time-zone information. The page labels the first as UTC and the second as a format with a time-zone offset. For the other three it does not say which time zone Google assumes, which is worth keeping in mind if your data comes from systems that log in local Bangkok time.

Customer Match columns at a glance

The table below sets out each accepted column and how the Google Ads Help page says it should be prepared, based only on what the page states.

The five timestamp examples the page gives are 2012-08-15T00:01:54Z, 2012-08-14T17:01:54-07:00, "Aug 14, 2012 17:01:54", 08/14/2012T5:01:54 PM and 2012-08-14 5:01:54 PM.

What changed compared with the usual Customer Match file

Customer Match has always worked by matching first-party contact data to Google accounts. The file format reflected that: emails, phone numbers and name-plus-address combinations, normalised and hashed. The Help page still describes that route. It says the private customer data in the file will be hashed on your computer using the SHA-256 algorithm when you upload through the Google Ads interface, and it still tells advertisers not to hash Country and Zip.

The IP column breaks that pattern in two ways. First, it is not contact data that a customer typed into a form. It is a network identifier recorded by a server at the moment of a visit or transaction. Second, it goes in unhashed. Every other identifying field in the file is either hashed before upload or hashed in the browser.

When did the IP columns appear?

The Google page itself carries no revision date, so the date the two columns were first added is not established. The trade press picked it up in late September. Search Engine Land reported on 25 September 2026 that the columns were listed, and PPC Land covered the change on 26 September 2026, citing that Search Engine Land report. PPC Land's reading was that IP data can be sent with or without contact data, which matches what the Help page says.

Analysis: why "latest known user" is the part to worry about

This section is analysis, not a statement from Google.

An IP address is not a person. Home broadband connections are shared by everyone in a household. Office networks put hundreds of staff behind one or a few public addresses. Mobile carriers commonly use carrier-grade NAT, where many subscribers share one public IPv4 address at the same time. And most consumer IP addresses are reassigned over time, so the address a customer used in March may belong to a stranger in September.

Google's timestamp rule is the answer to part of that problem: tie the IP to the moment of the interaction and the match can, in principle, look at who held that address then. But the page says that when there is no timestamp, the system defaults to the "latest known" user of that IP. For a static business line that may be fine. For a mobile customer behind shared carrier NAT, or a household where a teenager and a parent share one connection, the "latest known" user may simply not be your customer. The practical reading is that an IP row without a timestamp is a weaker signal than one with a timestamp, and an IP row from a shared network is weaker still.

The help page does not say how Google resolves a single IP that maps to several Google accounts at once, how far back a timestamp can be, or how a timestamp from a system without a time zone is interpreted. Those gaps are real, and advertisers should not fill them with assumptions.

Analysis: why the IP address is not hashed

Google gave no reason on the page for the "don't hash" instruction. One plausible explanation is arithmetic. The whole IPv4 address space is roughly 4.3 billion addresses. That is small enough that anyone could hash every possible IPv4 address in advance and reverse a SHA-256 hash by lookup. Hashing an IPv4 address therefore gives little real protection, and it would only add a normalisation step that can go wrong. This is a reasonable inference, not a stated rationale, and it does not change the fact that the file now carries raw network identifiers.

The practical consequence is simple: a Customer Match file with an IP column is more sensitive than one without it. Treat it that way in storage, transfer and access control.

What the source did not say

A fair reading of the Help page also means being clear about its silences. The page does not say:

• how IP rows affect match rates, or what match rate advertisers should expect from IP-only lists;
• whether minimum audience sizes for serving change for lists built from IP data;
• whether IP rows are processed in the same way as hashed contact data inside Google's matching systems;
• whether the columns are available through the Google Ads API, Data Manager or partner connectors as well as file upload;
• which time zone applies to the three timestamp examples that carry no offset;
• when the columns were added, or whether the feature is rolling out gradually by account.

If any of these matter to your plan, test in your own account and treat the results as your own data, not as a Google benchmark.

What to check before you add an IP column

If you run Google Ads campaigns that already use Customer Match, the new columns are an option, not an obligation. Nothing on the page says existing lists need to change. Before adding IP data, it is worth working through these checks in order.

• Where would the IPs come from? Useful sources are ones that record an IP with a reliable timestamp at a real customer interaction: server or CDN logs for purchases, form submissions that store the submitting IP, CRM events captured server-side. IPs scraped from analytics exports without timestamps are the weakest input, because the upload then falls back to "latest known" matching.
• Do you have the timestamp? Store the interaction time with the IP, and in a format with a time zone. The two formats on the page that include time-zone information are the UTC form ending in Z and the form with an explicit offset. For Thailand, that means either converting to UTC or writing the +07:00 offset.
• Is the data clean? Trim whitespace, keep IPv4 and IPv6 as plain strings, and do not hash them. Remove internal addresses, office IPs, VPN egress points and known bot traffic before upload, since those rows add noise rather than customers.
• Who are the end users? The page says IP matching is not supported for end users in the EEA, UK or Switzerland. If your customer file mixes Thai buyers with European visitors, segment before upload rather than hoping the system discards the rows you should not have sent.
• What does your privacy notice say? Customer Match already requires advertisers to follow Google's Customer Match policies, which the Help page references. Check whether your privacy notice tells customers that network identifiers such as IP addresses may be shared with advertising platforms for audience matching, and on what basis.
• Measure separately. If you test IP data, build it as a separate list rather than merging it into an existing contact list, so you can compare size and performance. A clean comparison is only possible if the new signal is isolated.

The quality of the timestamp depends on your tracking setup. If your site events and conversion data run through GA4 and server-side tagging, a GA4 and tracking review is the natural place to confirm which systems actually hold IP and time data you are allowed to use.

What this means for Thai marketers

Thailand is not in the list of regions where the page says IP matching isn't supported, so on the page's own terms, Customer Match IP matching is open to advertisers targeting Thai users. That is the platform side. The legal side is separate.

Thailand's Personal Data Protection Act (PDPA) treats online identifiers as personal data in many contexts, and an IP address tied to a customer interaction and a timestamp is exactly the kind of record that can identify a person when combined with other data. This is not a legal ruling on any specific use. It is a reason to check your privacy notice and consent or lawful basis with counsel before uploading IP addresses to an advertising platform. Advertisers who already rely on consent collected at checkout or sign-up should confirm that the wording covers this kind of sharing, not only email-based Customer Match.

There is also a data-quality angle. If a large part of your own traffic arrives on mobile networks, check that share in your analytics first, because shared mobile addresses are a known limit of IP-based identification. That makes the timestamp column more important, not less, for anyone who tests this.

For brands in Thailand that already use Customer Match for remarketing or exclusion lists, the sensible first step is an audit of what data you hold, not a rushed upload. The column will still be there next month.

Frequently asked questions

Can I upload a Customer Match list with only IP addresses?

Yes, the Google Ads Help page says you can send an IP address with or without PII data. It also says that a row with only a timestamp, and no IP address or PII, will trigger an error. The page does not say what match rate to expect from an IP-only list.

Should I hash IP addresses before uploading them?

No, Google's page says to pass the IP as a plain, unhashed string. Trim leading and trailing whitespace first. IPv6 addresses can be uppercase or lowercase. Email, phone and name fields are still normalised and hashed with SHA-256, or hashed in the browser on upload.

Is IP matching available for audiences in Thailand?

The page does not exclude Thailand; it says IP matching isn't supported for end users located in the EEA, the UK or Switzerland. The page does not say whether availability varies by account, and Thai advertisers should confirm their privacy notice and lawful basis under the PDPA with counsel before uploading IP data.

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

Google says the system defaults to the "latest known" user of that IP. Because IP addresses are shared and reassigned, that user may not be the customer who made the original interaction, so including the interaction timestamp is the stronger option.

When did Google add the IP address and timestamp columns?

That is not established, because the Help page carries no revision date. Search Engine Land reported the columns on 25 September 2026 and PPC Land followed on 26 September 2026, but neither date confirms when the page was changed.

The short version

Customer Match can now take raw IP addresses and interaction timestamps alongside the usual hashed contact data, with IP-only rows allowed and Europe excluded. The value of the new columns depends almost entirely on the quality of the timestamps and the consent behind the data. If you want a second pair of eyes on how your Customer Match lists and first-party data feed your Google Ads account, the Relevant Audience team can review the setup with you before anything is uploaded.