Google Customer Match Now Matches on IP Address and Time

Google Ads Customer Match, the feature that turns an advertiser’s own customer list into an audience, now accepts two more pieces of data: the IP address of a customer’s device and the time they interacted with you. Trade press first reported the change on September 25. The rules below come from Google’s own help pages.

This matters most to advertisers who hold plenty of site or app activity but few email addresses. An IP address is something your server logs already record. It is also personal data in much of the world, which is why Google has switched the feature off for people in Europe, the UK and Switzerland.

Until now, a Customer Match file carried contact details: email, phone, name, country and postcode, with the personal fields scrambled using the SHA-256 hashing standard before they reach Google. The new columns sit outside that scheme. Google’s upload guide asks for both as plain strings and says not to hash them.

The details are in Google’s Customer Match upload guide. It describes the IP address as the one recorded when the customer interacted with you, and the timestamp as the time of that interaction. It also lists the earliest and the most recent recorded interaction as the two moments a timestamp can describe.

• No timestamp on its own. Google says a timestamp cannot be sent without an IP address, and a row with only a timestamp returns an error.
• Header names must match exactly, in English. The same page uses two names for the time column: “User Engagement timestamp” in the column list and “User Interaction timestamp” in the combined-file template.
• Do not hash the new fields. If your pipeline hashes every column by default, the IP and time columns will be unusable.

Google also points new integrations away from the Google Ads API for this job. The same guide recommends Data Manager, in the interface or through its own API, as the path forward for Customer Match. If you maintain an API integration, our note on Google Ads API versions and sunset dates covers the deadline that arrives first.

Google’s guide says IP matching is not supported for end users in the European Economic Area, the UK or Switzerland. Google’s Customer Match policy goes further: it tells advertisers to leave IP data for those regions out of uploads, be open about how the data was collected, and obtain whatever consent the law requires.

The general Customer Match rules still apply on top. The list must come from a first-party context, meaning people shared the data with you directly, and your privacy policy must say you share customer data with service providers. For a UK or European advertiser with a mixed audience, the practical job is filtering rows by the customer’s location before upload. Our Consent Mode v2 guide covers the consent side of that pipeline.

An IP address often belongs to more than one person. A household shares one. So does an office, and mobile networks commonly put many phones behind the same address. Google’s rule for an IP sent without a time is to match whoever most recently used it, which may not be the customer on your list.

That is the reason to send the timestamp. It tells Google which moment you mean, so the match can point to the person using the address then. Google has not published how much either column lifts match rates, so treat any improvement as something to measure on your own lists, not assume.

Match quality is where audience work quietly succeeds or fails. Our write-up of identity errors and campaign returns shows how much a bad match can cost, and our first-party data playbook covers collecting session data server-side in the first place.

The two new columns are easy to add and easy to misuse, and the misuses follow from Google’s own rules. The illustrative uploads below each break one of them. They are patterns, not accounts we have run.

The hashed columns: a pipeline that hashes every field by default hashes the IP address and timestamp too, as it does for email and phone. Google asks for both as plain strings, so the two columns are unusable and the list matches on nothing new. The office list: a B2B advertiser uploads IP addresses captured from a client’s office traffic with no timestamps. Google’s rule for an IP sent without a time is to match whoever most recently used the address, so the matches are the last people on the office network, not the contacts on the list. The mixed-region file: a UK advertiser with customers across Europe and elsewhere uploads session IP data for everyone. Google does not support IP matching for end users in the EEA, the UK or Switzerland, and its policy tells advertisers to leave that data out, so the rows for most of the audience should never have been in the file. The renamed header: the time column is labelled with a close paraphrase of Google’s name. The page itself uses two names for the column, and Google requires header names to match exactly; the guide does not say whether a near-miss header is rejected or ignored, which is why the test file comes first.

None of these failures is guaranteed to produce a clear error, which is the reason the callout above asks for a small test file before any production feed is rebuilt.

The conclusion asks for one test list with IP address and time, compared with the email-only version, and the test has a shape. Start from customers outside the EEA, the UK and Switzerland, filtered by the customer’s location before the file is built, so no excluded-region IP data is uploaded. Pick sessions where you logged both the address and the moment, such as checkout, sign-up or app sessions, which is the stronger case in the grid above. Build two files from the same customers: one with the usual hashed contact fields, one with the IP and timestamp columns added as plain strings under Google’s exact column names.

Make the test large enough to read. Google’s guide says match rates are shown only for uploads through the new Google Ads API with at least 100 rows matched to unique users, so a file of a few dozen rows will show nothing either way; check where your upload method reports a match rate before relying on the comparison. Upload the email-only file first and record its match rate, then the combined file, and compare. Google has not published how much either column lifts match rates, so the difference you see is the only evidence you have, and it is specific to your lists.

Record the result with the date, the header names that were accepted, the regions included and the share of rows that carried a timestamp. If the combined file matches more, the router’s advice applies: keep email as the main key and add IP data for the rows that have no email. If it matches the same or less, the IP data is not helping on this list, and the record says why the pipeline work was not done.

Build the two test files this week from customers outside the excluded regions, with the time column named exactly as Google’s upload guide names it. The comparison takes one upload each, and it is the only measurement of the new columns that applies to your audience.