Match Rate, Issue #4
Identity, data and measurement from someone who runs it.
Wednesday, October 21, 2026 · By Geetha Neelakantiah
This week Apple stopped letting people guess what Safari 27 blocks. It wrote it down, and identity resolution is named as the target. Then Google, on a quieter channel, told advertisers it will stop requiring hashed customer data on Nov 16. Two of the biggest platforms changed the rules on matching in the same week.
The two that matter
1. Apple names the target: "identity resolution infrastructure"
What happened
On Oct 19, Apple's WebKit team published a post called "Blocking Identity Resolution Infrastructure," written by John Wilander, Charlie Wolfe and Matthew Finkel. It is the first time Apple has explained, in public and in its own words, what the Safari 27 blocklist is for.
Apple defines the practice this way: a third party, not the website owner, collects a user's email address at login or newsletter signup, creates an opaque ID tied to that address, and returns the ID to the website. Over time, that third party builds an identity graph from more data. Apple says Safari and WebKit now block network access to companies that provide this infrastructure, across the iOS, iPadOS, macOS and visionOS 27 releases.
Three points in the post matter most:
- The block is by domain. "The blocking is done on the domain level," so vendors can't get around it by changing how their requests are built.
- Single-company graphs count too. Apple says a central identity resolver is a third party with cross-site capabilities even when it only works on one company's data, because it can do something "each first party does not have on their own."
- First-party personalization is out of scope. "First party personalization is not tracking," Apple writes. Sites can still personalize for their own users.
The post doesn't name companies, list criteria, or describe any way for a vendor to appeal or be removed. AdExchanger names the early targets as The Trade Desk, LiveRamp, Experian's Audigent, ID5 and Permutive, and reports that some of them have already set up new domains that aren't on the list. A Permutive source called that "a temporary Band-Aid, not a solution." AdExchanger also reports that The Trade Desk has set up a backup domain, TTDCDN.org, in case adsrvr.org is blocked again.
Separately, Apple released the iOS 27.2 release candidate on Oct 19. The 27.2 betas removed The Trade Desk's ad domain from the list. Apple hasn't given a public release date. Apple-focused sites expect it within about a week.
What it changes
For three weeks the industry treated the block as something it might negotiate. One bug report got one DSP unblocked in beta, and that looked like a path. Apple's post closes that path for identity vendors. It describes the business model itself as the problem, not a specific endpoint.
The line about single-company graphs matters most for brands. A lot of "first-party" identity setups still send the email to a vendor's domain from the browser, and the vendor does the resolving. In Apple's framing, that is third-party identity resolution with a first-party label on it. If your login or signup page calls an identity vendor's script, assume Safari 27 users aren't being resolved.
New domains won't last. Apple says it blocks by domain, and a list maintained by Apple can add a new domain as easily as the old one. Plans that depend on a workaround domain should have an end date.
A fair point on Apple's side: the post is consistent with what Apple has said since 2017, and nobody was surprised by the direction. The surprise was doing it at the network level without notice. A fair point on the industry's side: Apple publishes no criteria and no appeal process, and it also runs its own ad business. Both can be true.
What to do this week
- Find every place your sites send an email address, hashed or not, to a third-party domain from the browser. That includes login, newsletter signup and checkout. Those calls are the ones Apple is describing.
- Ask each identity and onboarding vendor, in writing, whether its domains are blocked in Safari 27, whether it is using a new domain, and what happens when that one is blocked.
- If you buy through The Trade Desk, keep treating Safari reach as reduced until iOS 27.2 is public and adopted. A release candidate is not a release.
- Report Safari separately in measurement and match-rate reporting for the next quarter, so a drop isn't mistaken for a campaign problem.
Sources: WebKit, "Blocking Identity Resolution Infrastructure," Oct 19 · AdExchanger, Oct 20 · iPhone in Canada on the 27.2 RC
2. Google will stop requiring hashed customer data on Nov 16
What happened
Google has told Data Manager users that from Nov 16 it will no longer require customer data to be hashed with SHA-256 before upload. Instead, Data Manager will accept encrypted data by default. Google says it will decrypt, normalize and match the data inside a trusted execution environment, a hardware-isolated system that Google and its cloud provider say they can't see into. The email names Customer Match and enhanced conversions, across CRM connections, cloud storage imports, file uploads and the Data Manager API.
Google's reason: matching is more accurate when formatting is cleaned up before matching rather than before hashing. It gives no figures.
The setup isn't new. Google's help pages show that "confidential matching" in a trusted execution environment has been on by default for some Customer Match uploads, with encryption optional. What changes on Nov 16 is that encryption becomes the default and hashing stops being required. It also follows a September change that lets Customer Match take unhashed IP addresses and timestamps, outside the EEA, UK and Switzerland.
A caution on sourcing. The Nov 16 change comes from a Google email to advertisers that ADSQUIRE CEO Anthony Higman posted on LinkedIn on Oct 18, and that PPC Land reported. As of this morning I haven't found a Google blog post or help page that announces it.
What it changes
Hashing has been the industry's standard answer to "is it safe to upload our customer file." It was always a weaker answer than it sounded. A hashed email is still a stable identifier, and anyone with the same email can produce the same hash. Hashing does one thing well: it lets two parties match without showing each other the raw value.
It also has a cost, and Google is now saying so. A hash locks in every formatting difference. "Jon.Smith@mail.com " with a trailing space and "jon.smith@mail.com" produce different hashes and don't match. Phone numbers with and without country codes don't match. So a lot of match loss happens before the platform ever sees the file, in how it was cleaned and hashed.
Google's fix is to take the raw data, encrypted, and do the cleaning itself. That should raise match rates inside Google. It also means you're trusting Google's secure environment instead of a hash you computed yourself. That may be a reasonable trade, but it is a different one, and teams should decide it on purpose.
Open questions the email doesn't answer: whether this is optional, who holds the encryption keys on each upload route, what happens to existing hashed lists, how an advertiser can verify the environment, what happens to unmatched records, and whether Google's customer data terms change. Display & Video 360 and Google Analytics aren't mentioned.
What to do this week
- Ask your Google rep, in writing, whether the change is opt-in or automatic, and what happens to hashed uploads already in place.
- Ask your legal and privacy team whether your data agreements and privacy notices assumed hashing. Some do.
- Before Nov 16, record your current Customer Match rates by list. If Google's claim is right, you'll see it. If you don't record the baseline, you won't know.
- Fix your own normalization regardless: lowercase and trim emails, use E.164 format for phone numbers, and standardize addresses. It helps on every platform, not just Google.
Sources: PPC Land, Oct 18 · Higman's LinkedIn post with the Google email · Google Ads Help: Confidential matching · PPC Land on IP matching, Sep 26
Quick hits
Researchers say an ad vendor used targeted ads to deliver spyware. Citizen Lab reported on Oct 15, with "high confidence," that Israeli ad vendor Discover-Tech used targeted ads to deliver Candiru spyware, including in attacks on at least 45 devices at Al Jazeera in 2024 and 2025. Simply displaying the ad was enough. Targeting used mobile ad IDs, IP addresses and cookie IDs, and the vendor ran ID syncing with Beeswax, Yandex and Xandr. From March to June 2026, its DSP won about 442 million impressions, and ads with attacker code ran in more than 75,000 apps and 120,000 websites. Google had listed the vendor since 2020 and removed it in early October, as did IAB Europe. Discover-Tech didn't respond to Reuters. It's the clearest public case yet of the bidstream being used to find specific people, and the kind of example regulators and Apple will point to. Citizen Lab · Reuters via Times of Israel · PPC Land
Meta's new terms let it crawl advertisers' websites for AI training, from Oct 30. Meta's revised Commercial Terms let it access, copy and re-crawl websites linked to a business's products, using automated tools and test credentials, and use that content to train its products. There's no opt-out; continuing to advertise counts as acceptance. Meta says the clause is narrower than critics claim and is for getting accurate product information. If you're in a regulated category, have legal read it before Oct 30. PPC Land · PPC Land on the clause still being in the terms
Meta starts selling reserved reach. Meta's Ads Super Burst lets advertisers reserve a 3 to 24 hour window on one day across Facebook and Instagram, agree on price and reach upfront, and get delivery within 5% of the forecast, with frequency fixed at one. A reach guarantee moves risk to the seller, which is good for buyers. After last week's WBD study, the question to ask is who counts the reach. Here it's Meta. AdExchanger
EU cookie reform stalls again. EU ambassadors were due to vote on the Council's Digital Omnibus position on Oct 11. Agence Europe reports the text "wasn't even discussed," mainly over German objections on Data Act trade secrets. No new date has been set. The proposed cookie consent exemptions for measurement remain a draft. Agence Europe
The explainer: hashing, encryption and where matches get lost
When you upload a customer file to an ad platform, three things can happen to each record.
Hashed. You turn each email or phone number into a fixed string with a function like SHA-256 and send the string. The platform hashes its own data the same way and compares. Neither side sees the other's raw values. But the same input always gives the same hash, so a hashed email works as a stable ID, and any formatting difference means no match.
Encrypted. You lock the raw values with a key and send them. Only a system with the key can read them. In Google's new setup, that system is a trusted execution environment that decrypts, cleans up and matches the data, which Google says nobody, including Google, can look into.
Raw. Some keys, like IP addresses in Google's September change, are sent as-is.
Where matches get lost, in rough order:
- Formatting. Capital letters, spaces, missing country codes, "St" vs. "Street." With hashing, each of these is a miss.
- Stale data. Old emails, moved households, disconnected phone numbers.
- No overlap. The platform doesn't know that person by that key, or doesn't know them at all.
- Policy. Some records can't be used, by region or by consent.
The short version: a match rate measures your file and the platform's data together. The first loss is the one you control.
This month's spotlight: financial services
This section reflects my company's view. Everything above it is vendor-neutral.
In Issue #1 I promised a financial services spotlight. This week is a good time for it. Apple is blocking browser-based identity vendors, and Google is changing how it takes in customer files, so it's worth knowing which audiences depend on neither.
Semcasting's Retail Banking Briefs score 139.6 million US households from 0 to 100 across eight segments: everyday banking, mortgage and home lending, small business, wealth and private banking, auto and consumer lending, credit cards, digital-direct banking, and insurance. Scores are ranked by state, metro and ZIP code against the national average. Separate briefs cover five acquisition outcomes, including banking-switch potential and direct deposit potential. Both combine household signals with public market data from the FDIC, HMDA, BLS and CFPB, and lift is measured against a fixed 10% holdout.
What to ask any financial audience partner, including us:
- Which inputs drive the score, and do any come from credit bureaus?
- Has anyone reviewed the targeting for fair lending, and if so, who?
- Is lift measured against a holdout, and how big is it?
The segments are at semcasting.com/financial.
That's Issue #4. If your team has already checked which of your vendors are blocked in Safari 27, hit reply. I'd like to know how many you found
Geetha
Match Rate is written by Geetha Neelakantiah, SVP Business Development, Marketing & Operations at Semcasting. The views are my own. Sections labeled "The Semcasting Angle" reflect my company's perspective. Nothing here is legal advice.
