A residential proxy flag doesn't necessarily mean bad ad traffic

Written by Claude (AI) · research signals and editing by Nathan Pankowsky · see AI usage at the end

A residential-proxy flag on an IP says little about whether a paid visitor will buy. On two days of traffic at one small Israeli store, flagged IPs reached product pages, checkout and purchase about as often as clean ones. Flagged IPs produced 3 purchases, clean ones 4.

What the flag mostly tracked was the visitor's ISP. The labels that can point to automation, VPN and datacenter hosting, covered only 5% of IPs. Over half of the hosting group turned out to be iPhones on iCloud Private Relay.

This matters because IP-reputation feeds are a cheap first rule in many anti-bot and click-fraud setups. On this store, a rule that blocked or excluded flagged IPs would have removed 3 of the 7 buying IPs. And on three sites, 85–96% of the IPs that clicked an ad never clicked again. On a UK shop we also monitor, flagged ad visitors did browse less, so the flag is worth checking, not trusting.

Our data

The main data is every page load our script recorded on one Israeli e-commerce store. The counterpoint and Result 4 add two UK sites: a jewelry-packaging shop (10–14 October) and a commercial-property lettings site (9–13 October). We withhold all three names.

A few definitions:

• The unit is the IP. An IP counts as reaching a page if any beacon from that address did. Each page view sends one beacon before fingerprinting and one or two after it, so we count page views by the first kind.
• Categories come from ipinfo's privacy fields. Each IP gets one label from the flags on any of its beacons, checked in this order: VPN, hosting, residential proxy, clean. Eleven IPs had no ipinfo record and are left out.
• Purchase means the payment-success page. We also count the payment page itself, because three times as many IPs reach it.
• Crawlers are removed whether verified or self-declared. That removes 17 IPs. Seven are Google and Ahrefs crawlers our classifier verified against the operators' published IP ranges. The other 10 announce themselves as Baidu's rendering crawler (Baiduspider-render) from China Unicom. Our classifier labels them as request bots, and Baidu publishes no IP ranges to verify them against. None reached a page other than the home page.
• One staff IP is removed. A desktop on a flagged Hot-Net address placed 7 paid orders across 153 sessions, only in office hours and never from an ad. It looks like the store's own staff taking orders. The rule: 3 or more paid orders and no ad click.

Result 1: flagged IPs shop like everyone else

Residential-proxy IPs reached every step of the funnel at least as often as clean ones.

The VPN row mostly reflects a gap in our logging, not VPN users' behaviour (see Result 3).

The differences between flagged and clean IPs are within noise. Flagged IPs had odds 1.6 times those of clean IPs of reaching payment (Fisher p = 0.30) and 0.86 times of purchasing (p = 1.0). Results are the same when only IPs with an ad click are counted: 3 of 397 clean IPs purchased, against 2 of 363 flagged.

This is the second time we have seen it on this store. In May, IPs with any ipinfo flag converted at 0.68% (7 of 1,023), against 0.28% for never-flagged IPs (6 of 2,120).

Result 2: the flag follows the ISP

Whether an IP is flagged depends mostly on which ISP it belongs to. On Pelephone, Bezeq and Hot-Net, more than 80% of IPs carry the flag. On Partner and Cellcom, about 5% or fewer do.

Chart: the residential-proxy flag follows the ISP: 84% of Pelephone IPs, 3% of Partner. Share of each ISP's IPs that ipinfo labels residential proxy (ISPs with 20+ IPs, VPN and hosting IPs excluded); dashed line: all ten ISPs. Source: store page loads, 10–12 Oct 2026, 1,227 IPs on these ten ISPs.

It is not a mobile-versus-fixed split either. Bezeq, a fixed-line ISP, and Pelephone, a mobile one, are flagged at the same rate.

Within a single ISP, flagged and clean IPs still look the same. Stratified by ISP (Mantel-Haenszel), flagged IPs had odds 1.11 times those of clean IPs of reaching a product page (p = 0.69), 1.68 of reaching payment (p = 0.79) and 0.52 of purchasing (p = 0.95). The purchase figure rests on 7 buyers.

The flag's own detail fields separate them little:

• Persistence. ipinfo's percent_days_seen is the share of the last seven days an address showed up in a proxy pool, so it moves in sevenths. On the Israeli store it tracks the line type, not behaviour. All 81 addresses seen on all seven days were fixed lines, and none of the mobile ones reached that level. Product-page visits, purchases and ad arrivals show no trend across the seven levels (Kendall's tau 0.04, p = 0.23 for product pages). The always-seen addresses reached a product page 86% of the time, against 74% of clean IPs. On the lettings site there is a weak downward trend (tau −0.16, p = 0.04): 67% of its 18 always-seen addresses reached a listing, against 78% of clean IPs. That is too few to act on.
• Pool name. ipinfo names 55 pools on the Israeli store, led by 711Proxy, Proxies.Fo, FlashProxy, KooKeey and DataImpulse. Across the 17 pools with 8 or more IPs, product-page rates differ a little more than chance would explain (chi-square p = 0.03). They run from 50% for PlainProxies and Lightning Proxies and 55% for ProxyScrape, up to 92% for DataImpulse and IPRoyal. Pools also split by network: KooKeey and IPFoxy sit mostly on Pelephone's mobile network, 711Proxy and FlashProxy mostly on Bezeq and Hot-Net. One test across 17 small groups is a lead, not a rule, and the lettings site's pools show no difference (p = 0.49).

Our reading, which this data cannot test: residential pools recruit exit nodes through apps installed on ordinary phones and home routers. An ISP that rotates addresses among subscribers spreads one node's history over many households. The flag then marks the address pool more than the visitor.

Result 3: VPN and "hosting" are small, and not what they seem

Together, VPN and hosting IPs are 61 of 1,338 labelled IPs (5%). Neither group's row in the table means what it seems to.

Most VPN visits are hidden by our own logging. Our classifier marks most VPN IPs as untrusted. For those page loads it records only the home URL and no fingerprint. 24 of the 30 VPN IPs were logged only this way, so we cannot see which pages they visited. That is why the VPN row shows 13% reaching a product page. Of the 6 VPN IPs logged in full, 4 reached a product page and none reached payment. That is too few to conclude anything.

There is earlier evidence that VPNs are where automation hides on this store. In a larger sample from earlier in the year, 31 of 32 page loads that leaked a headless-browser header came from VPN IPs. They are still only a sliver of traffic.

Over half the "hosting" IPs are iPhones. 17 of the 31 belong to iCloud Private Relay, Apple's privacy feature that routes Safari through Akamai, Cloudflare and Fastly. All 47 of their page views came from Mobile Safari, and our browser check passed 117 of their 164 beacons. 14 of the 17 reached a product page and 10 arrived from an ad. A rule that blocks hosting IPs would block these shoppers.

The other 14 hosting IPs look like actual datacenter traffic: Google, Microsoft, Hetzner, Netskope and similar. Our browser check failed 31 of their 66 beacons, and 3 of the IPs rendered graphics in software (SwiftShader), a sign of a virtual machine with no GPU. This is the group where an IP rule does some good, and it is 1% of IPs.

Counterpoint: a shop where flagged ad clicks looked worse

On a UK jewelry-packaging shop we also monitor, the same flag picked out weaker ad traffic. The data covers 10 to 14 October 2026.

• Flagged IPs were ad-heavy and left early. 14 of the 31 came from a Google ad, against 50 of 233 clean IPs. Only 3 of those 14 reached a product page (21%), against 58% of clean ad visitors. 8 of the 14 left after a single page, and none reached the cart.
• The gap is borderline. Across all IPs, 32% of flagged IPs reached a product page against 52% of clean ones (Fisher p = 0.05). The cart comparison rests on 1 flagged IP and isn't significant.
• Most of the bad traffic wasn't paid. 1,062 datacenter IPs, mostly M247, HostRoyale, Mod Mission Critical and Tencent, made up 79% of labelled IPs. 98% of their beacons failed our browser check, and 86 of them rendered graphics in software. None reached the cart, and only one came from a Google ad. Another 16 hosting IPs were iCloud Private Relay and are left out of that row.

What differs between the two stores is which addresses the flag lands on. On the Israeli store it covers most of three large ISPs. Here it covers 2% of IPs. 19 of the 31 are on mobile carriers, mostly in the UK and Ireland, and the rest on fibre lines and Starlink. Those IPs arrived from ads more often than anyone else. A flag that covers half your buyers is noise. A flag that covers a thin slice of your ad clicks may be worth a closer look.

Result 4: most IPs click once

85% of the 726 IPs that clicked a Google ad clicked only once in the 46 hours. An IP exclusion acts only on an IP's next click, so the only clicks a list can reach are repeats.

Chart: only 5% of Google ad clicks came from an IP that had clicked an hour or more earlier. Google ad clicks by time since the same IP's previous click, store, 10–12 Oct 2026 (832 distinct click IDs, counted once per IP they were seen on: 878).

Most repeats came back within ten minutes, too soon for a list built after the fact. A list refreshed every hour could have reached at most 45 clicks, 5% of the total, and only if every one of them deserved blocking.

• New IPs keep arriving. 381 new IPs clicked a Google ad each day. 500 addresses hold about 32 hours of them.
• Addresses change mid-visit. 36 of 894 Google and Meta clicks were seen on more than one IP during the same visit.
• One address, several people. 17 of the 106 IPs that clicked more than once did so from more than one browser.
• The flag doesn't pick out repeat clickers. 16% of flagged Google-clicking IPs clicked twice or more, against 14% of clean ones.
• Repeat clickers were shopping. 6 of the 106 reached the payment page, against 2% of all IPs. None purchased within the two days.

Two smaller UK sites show the same pattern. There, 500 slots would hold one to four weeks of new clicking IPs, and only 2–4% of clicks came back an hour or more after the same IP's last one.

Click-fraud tools describe how they work within the cap in their help pages. When the list fills, the oldest addresses are removed to make room for new ones. Some fill unused slots from public blocklists, some keep a few slots free for real-time blocks, and some merge addresses into ranges. One vendor's blog notes that a botnet can fill the list within an hour, and that most fraudulent clicks come once from each address. None that we found publishes how often an excluded address goes on to click again.

A trap we fell into first

An earlier cut of our data said the opposite: flagged IPs converted about twice as often. That cut covered 2,000 IPs across four stores. Flagged IPs converted 23% of the time and unflagged ones 12%; mobile-carrier IPs 25% against 10% elsewhere.

Two things inflated it:

• Conversions were matched to visits by IP, on any store. For 180 of the 341 converting IPs, the conversion happened on a different store from the visit we fingerprinted. Mobile carriers put many subscribers behind one address, so their IPs collect other people's purchases.
• Buyers and non-buyers came from different dates. IPs with a September proxy-list date converted 55% of the time; those dated 3–4 October, 3%.

Counted on one store, with purchases on that store only, the gap is gone. In the data above, mobile IPs purchased at 0.54% and fixed-line IPs at 0.55%. If you join conversions to clicks by IP, check that both happened on the same site.

Limits

• Seven buyers. The purchase comparison cannot show that flagged IPs buy at the same rate, only that there is no sign they buy less. Its 95% interval for the odds ratio runs from 0.12 to 5.1. The product-page comparison is the solid one: 0.92 to 1.56, which rules out flagged IPs browsing noticeably less.
• One IP excluded as staff. Kept in, it adds 7 paid orders to the flagged side and makes flagged IPs look better, not worse.
• Three sites, a few days each. The flag tracks ISPs, so its spread depends on how a country's ISPs assign addresses. Israel's pattern may not carry to the UK or US. Two to four days also shows only short-term stickiness: over weeks, more IPs would click again. The UK shop export leaves out the first request of each page view, which our classifier leaves unclassified and which carries no page or ad data. That doesn't touch its ad clicks or cart views. But on the other two sites, about 1 in 10 IPs sent nothing except that first request, so we never see where they landed or whether they came from an ad. On the lettings site that share is higher for flagged IPs (17%) than for clean ones (12%), so the shop table probably understates how many flagged IPs visited.
• The IP is the unit. People sharing an address merge into one row, and the flag applies to all of them.
• ipinfo's definitions, as of the visit. We did not check the flag against another vendor or against our own proxy tests.
• Goals are proxies. We count a payment-success page view, not an order in the store's back office. Nine order numbers in the period never appear in our log, so some orders were placed without passing our script.
• Untrusted visitors are partly hidden. The logging gap in Result 3 covers 56 beacons, all from VPN IPs. It does not touch the residential-proxy comparison, because none of those IPs were marked untrusted.

What to do with it

1. Check your converters before you add an IP-reputation rule. Take last month's buyers' IPs and look up how many carry the flag. Here it was 3 of 7. If the share is close to the flag's share of all traffic, the rule is cutting buyers at random.
2. Measure how often an IP clicks again before you exclude it. Google allows 500 excluded IPs per campaign. On three sites, 85–96% of clicking IPs never clicked again, and 2–5% of clicks came back an hour or more after the same IP's last one. Check your own repeat rate before deciding what an exclusion list is worth, and don't spend slots on addresses that carry only a residential-proxy flag.
3. Take iCloud Private Relay out of your hosting rules. Apple publishes its egress IP ranges (Apple's guide). ipinfo also marks them with its relay field. Treat these visitors as the Safari users they are.
4. Use VPN and datacenter labels as a reason to look, not to block. Act when they combine with a second, independent signal: a headless-browser leak, software graphics, or a failed browser check.
5. Join conversions to clicks by click ID or session, on the same site. Joining by IP across sites credits carrier IPs with strangers' purchases.
6. Log what blocked or flagged visitors do. If your tool records less for them, as ours did, you cannot tell later whether the rule was right.

See it on your own traffic

Button records each ad click with its IP, browser fingerprint and the pages that follow. You can see which clicks come back and which reach your goal pages, before you spend an exclusion slot on them.

Sign up for Button →

Reproduce it yourself

Every number above comes from one script run on a scrubbed copy of the data. The data and scripts are on GitHub: buttonsolutions/public-studies: ip-quality-reproduction-oct-14-2026. The folder also holds the scripts for our follow-up posts, which use the same files.

• store_il_events.csv (9,901 rows), shop_uk_events.csv (4,929 rows) and lettings_uk_events.csv (4,277 rows): one row per beacon, with page type, ad source, browser family, classifier label and ipinfo's privacy fields.
• reproduce.py: prints every table and figure in this post. Python 3.11+; scipy is optional and adds the p-values and intervals.

Run it with python3 reproduce.py store_il_events.csv lettings_uk_events.csv shop_uk_events.csv.

The data and scripts are licensed CC BY-NC-ND 4.0: you may share them unchanged for non-commercial purposes, with credit to Button Solutions. If you reproduce or build on these figures, please cite this post and the dataset.

What we removed before sharing:

• IPs, session IDs, ad click IDs and order numbers are replaced with random tokens, and the mapping was discarded.
• URLs are reduced to a page type (home, product, cart, payment, payment success and so on). The store's domain, campaign IDs and click IDs are gone.
• Timestamps are rounded down to the minute, which the repeat-click timing needs.
• Location is kept only as the IP's country and the browser's time zone and language. Request headers and our sensor details are dropped, except two yes/no results: software graphics rendering and one browser-consistency check.

ISP names and ipinfo's proxy fields stay, because the post is about them.

Download: ip-quality-reproduction-oct-14-2026 on GitHub.

AI usage

• Author: Claude, Anthropic's AI model. Claude wrote the analysis code, ran it, and wrote this text.
• Checker: a second Claude instance. It recomputed every number from the raw data without seeing the first one's code. It found the staff IP, the gap between beacons and page views, and a claim about proxy-list freshness that the data couldn't support. All three are fixed above.
• Research signals and editing: Nathan Pankowsky. Nathan provided the research signals Claude drew its conclusions from: the detection sensors and classifier labels, the ipinfo enrichment, and the data they produced. He also chose the question and the angle, set the title, and challenged the conclusions along the way.

The data comes from Button Solutions' own monitoring of client stores.

References

• Exclude IP addresses — Google Ads Help
• Prepare your network or web server for iCloud Private Relay — Apple Developer
• iCloud Private Relay egress IP ranges (CSV)
• 98% of your visitors share a clock, our earlier study in this format