Written by ChatGPT (AI) · edited by Nathan Pankowsky · see AI disclosure at the end.
Ecommerce companies detect bot traffic hiding behind proxies by combining network information with browser signals, request patterns, and visitor journeys. A residential IP address can carry automated traffic, and an address flagged as a proxy can also carry legitimate shoppers. Neither label settles the question.
The useful question is whether several independent pieces of evidence point to automation—and what that activity is doing to your store.
That might mean scraping your catalog, repeatedly attempting checkout, or generating questionable visits from a paid campaign. Each needs a different investigation and response.
Why residential proxies make bot detection harder
A proxy forwards a connection through another machine. Your store sees the proxy’s public IP address instead of the original client’s address. Residential proxies use addresses associated with ordinary internet providers, making network origin alone a poor way to distinguish a shopper from a script.
Rotating those addresses also weakens rules built around requests per IP. A coordinated operation can spread activity across many addresses while keeping each one below a local rate limit. Cloudflare describes this problem in its research on residential proxy bot detection.
However, changing the connection’s exit address does not automatically change the software making requests, its browser characteristics, or the pattern of pages it visits. Those give investigators other evidence to examine.
Sophisticated automation can alter those signals too. Detection therefore needs multiple checks and a way to express uncertainty.
A proxy flag can also catch shoppers
In Button’s study of a small ecommerce store, 596 IPs labeled as residential proxies included three that reached the payment-success page. Among 681 unflagged IPs, four reached that page.
This comparison covers 1,277 IPs in the residential-proxy and unflagged groups. The source also reports 31 hosting IPs, 30 VPN IPs, and 11 IPs without an IPinfo record, bringing the total to 1,349; those other categories are outside this two-group comparison.
Blocking the flagged group would have included three of the seven IPs associated with that outcome.
This was a short observational study on this store, from October 10, 2026 at 18:48 to October 12 at 16:34 UTC—about 46 hours. The related three-site research used different observation windows for each site. The unit was an IP address, and “purchase” meant a recorded payment-success page, not an independently reconciled order. It does not establish that either group was human, or that proxy traffic is generally safe. It shows why the label alone was insufficient grounds for blocking on this store.
Four layers of evidence to examine
| Layer | What to examine | What it cannot establish alone |
|---|---|---|
| Network | Proxy and hosting flags, network operator, IP location | Whether this particular visit is automated |
| Browser | Automation indicators and consistency between reported browser properties | Whether a plausible browser has a human operator |
| Activity | Timing, repeated paths, endpoint use and related sessions | Whether similar visits belong to the same operator |
| Business context | Campaign source, product-page progression and verified outcomes | Whether an event represents a legitimate customer |
1. Use network reputation as context
Record the network classification alongside the visit. A hosting address, a known proxy exit, or a sudden concentration on one network can help prioritize an investigation.
At this layer, IPinfo’s Max API provides geolocation, network, and carrier information, along with VPN, proxy, Tor, relay, and residential-proxy detection. Its residential-proxy metadata includes when an address was last observed and how frequently it appeared within a rolling seven-day window. That adds useful context about recent proxy activity; it does not establish who made a particular visit or whether that visit was automated.
Check the scope and freshness of every label. An IP’s history is not a permanent identity: addresses can be shared or reassigned. DataDome’s published residential proxy research discusses shared traffic and the risk of false positives due to retaining flags too long.
Ask whether the suspicious pattern remains when you compare visits within the same network or device group. Otherwise, a network label may simply be dividing your customer population by internet provider.
2. Check whether the browser’s signals fit together
A user-agent string claiming to be Chrome is a claim to test. Browser-side checks can look for automation indicators and inconsistencies between the reported browser, platform, and available capabilities.
Commercial detection systems combine these kinds of signals. For example, Cloudflare documents heuristic, machine-learning, and JavaScript detection engines. This includes request, session, and browser information.
Time zone and IP location offer one understandable example. A mismatch can justify a closer look, but travelers, device settings and location errors provide alternative explanations. In Button’s clock-versus-IP study, the comparison method mattered: matching time-zone names could flag devices whose clocks actually kept the same local time.
Passing a consistency check also does not prove a visitor is human. Automation can run a real browser with plausible settings.
3. Look for repeated activity across addresses
When IPs rotate, investigate patterns across groups of visits. Useful questions include:
- Do many visits follow an unusually similar sequence of product pages?
- Does a burst repeatedly target the same search, login, or checkout endpoint?
- Do browser inconsistencies recur alongside the same path and timing pattern?
- Is the activity concentrated in a campaign, landing page, or product category?
Compare those patterns with an appropriate baseline. Visitors landing on the same advertised product will naturally share part of their journey. A promotion, scheduled integration, or authorized crawler can also produce repetition.
Similarity helps you find a group worth inspecting. A shared browser fingerprint does not establish that visits came from the same person or bot.
4. Connect the evidence to the business outcome
For an ecommerce team, identifying automation is only part of the job. You also need to understand its effect.
A catalog scraper can consume resources without ever touching a paid ad. A legitimate shopper can arrive from a paid campaign and leave without buying. A script can trigger a conversion event without producing a valid order.
Keep those observations separate:
- A campaign parameter describes attribution information carried by the visit.
- A browser classification describes the available technical evidence.
- A checkout event describes a recorded action.
- A reconciled order provides stronger evidence of a commercial outcome.
An ad click ID can help connect the landing visit to a journey. Its presence does not prove a charge occurred, that a platform considers the click valid, or that a refund is due.
A practical investigation workflow
Start with a specific change: a traffic spike, a conversion-rate drop, unusual catalog access, or repeated checkout failures.
Establish the baseline. Compare equivalent periods, campaigns, landing pages, and device groups. Record changes to promotions, tracking, and detection rules. Shopify’s guide to identifying bot activity notes that legitimate promotions, integrations, and testing can resemble bot activity.
Isolate the affected group. Break traffic down by source, campaign, network, browser classification, and path. Find where the unusual activity is concentrated before applying a store-wide rule.
Inspect supporting and contradicting evidence. Examine individual visits from the group, including visits with apparently successful outcomes. Check whether the classification has independent support or merely repeats the proxy label.
Account for missing visibility. Browser collection may fail, be blocked, or never run. A missing fingerprint is an observation gap. Server and edge logs are important for activity that never runs your storefront script, including direct API requests.
Choose a targeted response. Repetitive scraping might call for endpoint-specific limits. Checkout abuse may require payment and account controls. Questionable paid traffic may warrant investigation into the campaign health. A broad proxy ban needs stronger justification than a network flag.
Measure the result. Compare levels of abusive activity, legitimate order completion, challenge failures, and support complaints after a change. A lower session count alone does not show that abusive traffic fell or that legitimate shoppers were unaffected.
Where Button fits
Button helps teams investigate traffic quality across campaigns and visitor journeys. It brings classifications and inspectable evidence alongside the questions advertisers already ask: which sources look questionable, which pages those visits reach, and where the pattern changes.
For ecommerce teams, that opens a path to investigate a proxy-heavy group before deciding whether it deserves intervention. A storefront script provides visibility where it runs; checkout protection and server-side abuse controls still need coverage at the relevant endpoints.
Start seeing your traffic and inspect the evidence behind your campaign performance.
Frequently asked questions
Can ecommerce companies detect bots using residential proxies?
Yes. Changing IP addresses does not necessarily remove browser automation indicators or repeated activity patterns. Combining several signals can reveal automation that an IP-only rule misses, although no method detects every bot.
Should I block all proxy and VPN traffic?
A proxy or VPN label alone is insufficient evidence of abuse. Evaluate the activity, the affected endpoint, and the potential effect on legitimate shoppers before enforcing a rule.
Does a successful checkout prove a visitor is human?
No. Automation can interact with checkout, and a recorded success event can differ from a valid, fulfilled order. Use order and payment evidence to assess the outcome while retaining the technical evidence about the visit.
Does bot traffic from a campaign prove click fraud?
No. Attribution, automation, and advertising fraud are separate claims. Link the visit to its source, inspect the activity, and follow the ad platform’s evidence requirements before alleging fraud or requesting an adjustment.
AI disclosure: Written by ChatGPT (AI), with Nathan Pankowsky as editor, using the linked research and Button's published studies. This article reports no new traffic analysis or detection benchmark.