Google Ads now accepts a customer's IP address, and the time of an interaction from that address, in Customer Match file uploads, with both values passed to Google unhashed, according to a revised Google Ads Help Center page that Search Engine Land reported on September 25, 2026. The documentation permits lists built from IP addresses alone, bars matching for people located in the European Economic Area, the UK and Switzerland, and gives three different names for the column that carries the timestamp.

In Short

Google now lets advertisers add people's internet addresses, and the time each address was seen, to the customer lists they upload for ad targeting. Unlike email addresses, these internet addresses reach Google unscrambled, and they cannot be used for people in the EU, Norway, Iceland, Liechtenstein, the UK or Switzerland. If you upload an address without a time, Google links it to whoever used that address most recently. Google's own instructions name the time column three different ways, so the exact format is still unclear.

What the file now holds

Customer Match is the Google Ads feature that turns an advertiser's own customer records into audiences for targeting and exclusion. The Help Center page governing manual uploads, titled "Create a Customer Match list by uploading a data file," now lists eight English column headers: Email, Phone, First Name, Last Name, Country, Zip, User IP address and User interaction timestamp. Files must be CSV, encoded in ASCII or UTF-8, and UTF-16 is not supported, according to the page.

Anu Adegbola, paid media editor at Search Engine Land, published the report at 12:46 pm on September 25. The Google page itself carries no publication or revision date, so neither document establishes when the two columns first appeared.

The IP field is described in a single line: "The IP address of the customer's device is captured at the exact moment of interaction." IPv4 and IPv6 values are both accepted as strings. IPv6 is treated as case-insensitive, leading and trailing whitespace must be trimmed, and the instruction on hashing is blunt: "Pass as a plain, unhashed string (don't hash)." The page offers 192.168.1.1 and 2001:0db8:85a3:0000:0000:8a2e:0370:7334 as examples. The first falls in a range reserved for private networks, which a website's server never sees; the second uses the IPv6 prefix set aside for documentation.

Timestamps get their own entry, defined as "The time of the recorded interactions from the corresponding IP address." Two values are described: an earliest user timestamp, marking the first recorded interaction from the address, and a last user timestamp, marking the most recent. Of five sample formats, only two carry time zone information - UTC (2012-08-15T00:01:54Z) and an offset (2012-08-14T17:01:54-07:00) - while looser forms such as "Aug 14, 2012 17:01:54" carry none. Which zone Google assumes for those is not stated.

The most consequential sentence concerns a missing timestamp. "If an IP address is uploaded without a timestamp, the system defaults to the 'latest known' user of that IP," the page states. A customer record holding an address captured months earlier, uploaded bare, would therefore resolve to whoever Google most recently associated with that address, who may not be the customer the advertiser recorded. Internet service providers reassign addresses, and one public address can sit in front of an entire household or office. How recent "latest known" must be, and whether stale addresses are discarded, is not defined.

Lists without contact details

The file rules also loosen an old assumption about what a Customer Match list contains. According to the page, an IP address can be sent "with or without PII data," and contact data can be sent with or without an IP address. Only a timestamp on its own, with no IP address and no contact details, triggers an error. In practice, that permits a list made of nothing but IP addresses and interaction times. Mobile device identifiers remain a separate case: "Mobile Device ID" must be the only column in a file of that type.

By setting the IP address against "PII data," the page groups email addresses, phone numbers and names as personal information while leaving the IP address outside that label. The legal status of IP addresses is still being litigated in Europe. Germany's Federal Court of Justice referred questions to the Court of Justice of the European Union on August 28, 2025, in case C-654/25, asking whether dynamic IP addresses count as personal data when the recipient cannot reasonably identify the user.

Hashing stops at the IP address

For the other identifiers, the page keeps the hashing regime Customer Match has long relied on. Advertisers can hash data themselves with SHA256 after normalising it, including formatting phone numbers to the E.164 standard, or let Google Ads do the hashing. When a plain-text file goes through the interface, Email, Phone, First Name and Last Name are hashed on the advertiser's own computer before transmission, while Country and Zip travel as they are. The IP address and the timestamp now join mobile device IDs, country codes and postal codes among the fields sent unhashed.

Google does not explain the choice, though one technical constraint is well known. The IPv4 address space holds roughly 4.3 billion possible values, few enough that a hashed address can be recovered by hashing every candidate and comparing results. The US Federal Trade Commission made a broader version of that point in July 2024, when it warned that hashing does not make personal data anonymous.

Other parts of the page have not caught up. Its section on match rates still describes a process in which a secure hashing algorithm "turns the data into codes," adding that Google "doesn't receive or view actual email addresses." Accurate for email, the passage is silent on IP addresses, which by the page's own instructions arrive in readable form. The same section states: "After processing, the data file is deleted. Google doesn't keep or use this data for any other purpose." Whether IP rows are processed inside the trusted execution environments that Google made the default for Customer Match when it brought in confidential matching in September 2024 is not addressed.

Europe is excluded, and the mechanics are not described

The restriction appears as one note beneath the IP field: "IP matching isn't supported for end users located in the EEA, UK, or Switzerland (CH)." Because a timestamp cannot travel without an IP address, the timestamp column is effectively closed to the same people. Taken together, the carve-out covers the 30 states of the European Economic Area plus the UK and Switzerland.

According to Search Engine Land, advertisers using the feature "need to exclude those users from IP address sharing and ensure their data collection practices include the appropriate disclosures and consent." The Google page does not say whether Google discards rows it attributes to European users, rejects them outright, or relies entirely on the advertiser to filter them first. Nor does it say how location is judged: from the address itself through IP geolocation, from the Country column, or from the matched account. When PPC Land examined the API version of the feature in June, Google's developer documentation left consent handling and regional exclusion to integrators.

The carve-out sits awkwardly beside Google's own plans for the same territories. On June 17, 2026, Google told AdSense publishers it would begin using IP addresses for ad measurement and personalisation in the EEA, the UK and Switzerland on or shortly after August 3, citing privacy-enhancing technologies and updating its IAB Europe registration. Google's own IP-based measurement in the region therefore runs under safeguards the company selected, while advertiser-supplied addresses for European users do not enter Customer Match at all. The wider shift began on December 18, 2024, when Google said it would permit IP addresses and device fingerprinting in advertising from February 16, 2025, a decision the UK Information Commissioner's Office criticised as irresponsible.

The API route came first

The file columns follow a change made on the developer side four months earlier. On May 28, 2026, the Data Manager API's version 1.7 added IP address ingestion for Customer Match through a CompositeData structure that bundles UserData, holding hashed contact details, with IpData, holding the address. In that version the ipAddress field is required and two timestamp fields, observeStartTime and observeEndTime, are optional, with Google recommending both. Display & Video 360 was left out, with only Google Ads eligible at the start.

That release carried a dated promise. Google said IP addresses supplied with observation timestamps would help drive higher match rates for Customer Match beginning in the third quarter of 2026. The quarter closes on September 30, five days after the file-upload documentation surfaced, and neither the Help Center page nor Search Engine Land's report contains a single figure to show whether that promise has been met.

The route matters because Google has spent 2026 closing older pipes. The Data Manager API, presented on December 9, 2025, became the required path for new Customer Match integrations from April 1, 2026, when uploads through the Google Ads API began failing for developer tokens without recent Customer Match activity. Earlier, Google had stopped the Google Ads API from accepting new implementations of IP address and session attribute data in conversion imports from February 2, 2026. IP data left the general-purpose API for Data Manager, where Google controls validation and consent settings, and has now reached the manual upload screen too.

Where the documentation contradicts itself

The Help Center page is inconsistent on points that decide whether a file uploads cleanly.

Three names for one column

The page insists that headers use "the exact names specified in English." Yet the timestamp column appears three ways. The basic formatting section lists "User interaction timestamp." The bullet on timestamp matching instructs uploaders to use "User Engagement timestamp." The bullet on combined matching lists "User Interaction timestamp," with a capital I. Two of the three differ only in capitalisation; the third uses a different word entirely. Whether headers are case-sensitive, and which spelling the uploader actually parses, is not stated. Search Engine Land's report uses "User Interaction timestamp."

Two timestamps, one column

The page describes an earliest and a last user timestamp but supplies only one header. The API handles the same idea with two separate fields. How a CSV conveys a start and an end through a single column - two columns sharing a name, a range inside one cell, or just one of the two values - is not explained.

Mandatory or optional?

The combined-matching bullet says a file "must contain these 8 column headers." Two sentences later, the same bullet says only the fields an advertiser finds relevant need to be included, and that a single field such as email addresses may be uploaded alone. Separately, one note says timestamps "can't be sent without an accompanying IP address," while the combined-matching bullet says an error follows when a timestamp is sent "without an IP address or PII." That leaves open whether a timestamp paired with contact details, but no IP address, is accepted.

Rules that no longer apply

Several passages conflict with policies Google has already put in place. The create-list instructions cap membership at 540 days, the ceiling Google set in February 2025 with effect from April 7, 2025. The instructions for replacing, adding to or removing from an existing list each state: "The default membership duration is unlimited." A banner at the top of the page steers new Customer Match integrations away from the Google Ads API and toward Data Manager, yet the match-rate section says rates "are only shown for uploads using the new Google Ads API" with at least 100 rows matched to unique users. Another line says data sent through API uploads must be hashed, which cannot hold for the IP field, since the Data Manager API also takes addresses unhashed.

Search Engine Land's reading

Search Engine Land wrote that the new columns join "existing identifiers such as email, phone number, mailing address and mobile device ID" in files that can now include eight columns. The Google page does not support the last item. Mobile device IDs must be uploaded in a file of their own, and the eight headers the page lists are Email, Phone, the four mailing-address fields and the two new columns.

The report also said Google has "quietly changed language across several Customer Match help pages," describing customer information as data advertisers "collected" rather than data they "shared." The page reviewed by PPC Land partly bears that out, since its opening refers to data advertisers have collected. The consent checkbox in every upload flow, however, still uses both words: "This data was collected and is being shared with Google."

What the accuracy research measures

IP addresses have had a bruising year as an identity signal. Research commissioned by the Coalition for Innovative Media Measurement and Go Addressable, and conducted by Truthset across nearly one billion records, found IP-to-postal address linkages accurate 13% of the time and IP-to-email linkages 16%, with the six providers tested agreeing on the same household link only 6.4% of the time. In July 2026, Adstra and InterMedia Advertising reported that just 23% of residential IP addresses reached their intended geographic target. A Stanford study circulated in August found that 5% of IP addresses send 55% of web requests, and noted that client operating systems rotate IPv6 addresses at most every 24 hours by default.

Those figures need careful handling. The Truthset and Adstra work measured third-party graphs linking addresses to households, and the organisations involved sell identity products. None of it tests how Google matches an uploaded address against addresses it has observed for its own signed-in users, a process for which Google has published no accuracy data. What the research does illustrate is the role of timestamps. An address observed at a known moment is a much narrower clue than an address alone, and the "latest known" default applies precisely where that clue is missing.

The Help Center page is candid on one related point. A Customer Match match rate, it says, "isn't an indicator of list performance." More matched IP rows would not, by Google's own measure, show that a list reaches the right people.

Why it matters

Customer Match has changed repeatedly over the past year. PPC Land reported in December 2025 that Google had cut the minimum audience size to 100 users across its networks. In August 2026, Enhanced Matching appeared in Customer Match, pairing consented users with publishers' consented users under a 60-day maximum membership, against 540 days for standard lists. On September 10, Google added a Data Strength Uplift Metric that counts the conversions an advertiser's first-party data setup recovers. Each step widens what advertisers are invited to send.

Address-based matching extends that direction to a signal that usually sits outside the customer record. Email addresses and phone numbers live in a CRM; IP addresses and interaction times tend to sit in web server logs, analytics exports or form-submission records. A combined Customer Match file places them beside names and contact details, keeps them in list membership for up to 540 days, and sends them to Google in readable form. Google has moved the same way on the publisher side, where AdSense added a control on June 1, 2026 to share full IP addresses in bid requests, switched off by default.

What remains unanswered is practical. Which timestamp header does the uploader read? How are the earliest and last timestamps expressed in one file? What happens to rows that belong to European users? And did the promised third-quarter improvement in matching arrive? Google's documentation, as published, does not say.

Timeline

Summary

Who: Google Ads and the advertisers who upload customer lists to Customer Match, with Search Engine Land's Anu Adegbola reporting the documentation change.

What: The Customer Match file upload now accepts two new columns, a user IP address and a user interaction timestamp, both of which must be uploaded unhashed. Lists can consist of IP addresses alone. Without a timestamp, an address resolves to its "latest known" user. Matching on IP addresses is not supported for people in the EEA, the UK or Switzerland. The Help Center page gives three spellings for the timestamp header, describes two timestamps but one column, and contains several passages that conflict with current Customer Match rules.

When: Search Engine Land reported the change on September 25, 2026. The Help Center page is undated. The equivalent API capability arrived on May 28, 2026, with Google promising higher match rates from the third quarter of 2026, which ends on September 30.

Where: Google Ads Customer Match file uploads worldwide, excluding end users located in the 30 European Economic Area states, the UK and Switzerland.

Why: Google has been routing more first-party signals into its matching systems through 2026, and says IP addresses with timestamps will raise match rates. The change moves a signal that has fared poorly in third-party accuracy research, and that sits in contested legal territory in Europe, into the everyday upload workflow, sent to Google in readable form.