Google Ads Customer Match Now Matches on IP Address: What Indian D2C Brands Should Do

The Customer Match file just grew two new columns

For years, a Customer Match upload looked the same: hashed emails, hashed phone numbers, maybe a mailing address and a mobile device ID. Google matched those against signed-in users and built your audience. Simple, and a little frustrating, because a chunk of every list never matched anything.

That file just changed. Google's help pages picked up the update around Sep 25, 2026: Customer Match now accepts two more identifiers, the user's IP address and the interaction timestamp (the moment a customer took an action, like placing an order). The file format now stretches to eight columns with English-language headers.

The one detail that matters most

Here's the part worth reading twice. Every other Customer Match identifier is hashed before it leaves your system. IP address and timestamp are the exception: they go up un-hashed. That's not a footnote. Raw IP data is more sensitive than a hashed email, so the feature that's supposed to make targeting easier also raises the bar on how carefully you handle customer data. More on that below.

Why your match rate has been quietly capping your results

Most D2C founders never look at their Customer Match "match rate", the share of uploaded records Google can actually tie to a real user. It's easy to ignore because Google still builds an audience either way. But a low match rate is a tax you pay on everything downstream.

What a weak match rate actually costs

Say you upload 50,000 past buyers and only 30,000 match. That 60% match rate means:

• Your "exclude past purchasers" list is leaky, so you keep paying to show ads to people who already bought.
• Your retention and win-back audiences are smaller than they should be, so lookalike-style expansion has less to learn from.
• Smart Bidding gets a thinner first-party signal, which matters more every quarter as Google leans harder on your data instead of third-party cookies.

IP and timestamp are Google's attempt to rescue some of those unmatched records, the ones where the email you have is an old work address or the phone number has a typo, but the IP still lines up with a signed-in session. You won't match everyone. You should match a bit more than you did last month.

A quick example from an Indian store

Picture a Bengaluru skincare brand with 80,000 buyers in its Shopify export. Roughly 20,000 of those checked out as guests with rushed details, a Gmail alias here, a mistyped number there. Under the old rules those records were dead weight in the upload. With the timestamp of each order and the IP captured at checkout added to the file, a share of them can now tie back to a signed-in Google account. The brand doesn't magically double its audience, but it does stop treating a quarter of its own customers as strangers. That's the whole promise: not a new audience, a fuller view of the one you already earned.

The value compounds as third-party cookies keep shrinking. Google leans on your own data more with each release, so the size and accuracy of your first-party lists is slowly becoming the thing that separates a well-run account from a lucky one.

Who can use it, and why India's on the right side of the line

Not every market gets this. Google carved out end users in the European Economic Area, the UK and Switzerland; advertisers there have to exclude those users from IP sharing. Early reporting also suggests the exclusion list runs wider than those three, and that Display & Video 360 is left out of IP matching for now, so treat anything beyond the official carve-out as "confirm before you rely on it".

India, importantly, is not on the exclusion list. For a Shopify D2C brand shipping across Indian pin codes, your customer records are eligible.

The practical read for an Indian founder: this is a feature you can genuinely use, not one you have to work around. But "can" and "should" aren't the same word, which brings us to the consent question.

The un-hashed IP problem, and what DPDP expects of you

India's Digital Personal Data Protection framework treats an IP address as personal data. Uploading it to Google, un-hashed, to build advertising audiences is a processing activity you need a lawful basis for, and for most D2C brands that basis is consent.

Where brands get this wrong

The mistake isn't collecting the data. It's assuming an old, vague consent checkbox covers a new use. A tick-box that said "I agree to receive updates" at checkout two years ago was not consent to share a raw IP address with an ad platform for matching. Google itself now describes this customer information as data you "collected", and quietly nudges the responsibility for disclosures and consent back onto you.

So before you add IP columns to your upload:

• Check that your privacy policy and consent language actually mention sharing identifiers with advertising partners for measurement and audiences.
• Make sure the consent was collected clearly, not buried, and that customers could have said no.
• Keep a record of what you collected and when, because "we think they agreed" is not a defence.

If your consent flow doesn't stretch to this yet, the right move is to fix the flow first and skip the IP columns until it does. A slightly smaller match rate is a much smaller problem than a data complaint, a grievance officer notice, or the reputational hit of a customer finding out you handed their raw IP to an ad platform without asking. None of that is worth a few extra matched rows.

It also helps to keep the two jobs separate in your own head: collecting data with consent is a product-and-legal task your whole team owns, while uploading it to Google is a marketing task. When the same person quietly does both in a hurry before a festive push, corners get cut. Slow that handoff down by one day and most of the risk disappears.

A rollout plan that won't get you in trouble

You don't have to flip everything on at once. Treat this like any other data change: small, measured, reversible.

Step by step

1. Audit your consent before you touch the upload. This is the gate. If it doesn't pass, stop here and rewrite your checkout and policy language.
2. Start with one clean list. Your last-180-days purchasers, with real order timestamps, is the ideal first upload, because the timestamp signal is genuinely populated.
3. Add the new columns to a copy, not your live file. Keep your existing upload untouched so you can compare match rates before and after.
4. Upload through Data Manager and read the match rate. Note the number against your old file. A meaningful lift tells you the signals are doing work; a flat result tells you your data hygiene was the real bottleneck.
5. Watch your exclusion and retention audiences, not just the raw match rate. The point is fewer wasted impressions on past buyers and stronger win-back pools, so judge it there.

If cleaning and connecting customer data across Shopify, your CRM and Google Ads sounds like more plumbing than your team has time for, that groundwork is exactly what our performance marketing work is built on.

A note on COD-heavy brands

If a big slice of your orders are cash on delivery, your email quality is often patchy, people give a throwaway address to check out fast. That's precisely where IP and timestamp can recover matches you were losing. It's also precisely where consent tends to be weakest, because the customer was rushing. Both things are true at once, so tread carefully.

Should you switch it on?

Here's a straight decision table. Find the row that sounds like you.

The honest summary: this is a useful, low-drama upgrade for Indian D2C brands that already run their first-party data properly. It rescues some of the records you were quietly losing, and it feeds the parts of Google Ads that increasingly run on your own data. But it rewards brands that have their consent and hygiene sorted, and it politely exposes the ones that don't. Get the boring parts right first, and the extra match rate is yours to keep.