Behind the Residential Proxy Market: Six Insights from Massive CEO Jason Grad
ScrapeOps Blog10 min read
What sits behind a residential proxy endpoint, and how understanding supply networks, device types and sourcing evidence changes how you choose, combine and troubleshoot providers.
Buy from three proxy providers and you get three endpoints and three invoices.
You do not necessarily get three independent sources of residential IPs.
Most buyers can benchmark the things they see: price, latency and success rates. Far fewer can answer the questions underneath them:
- Where do the participating devices come from?
- How much supply do providers share?
- Why do the available exits change?
- Which sourcing claims have real evidence behind them?
Those answers decide whether your "backup" provider is really a backup, why a pool suddenly underperforms, and whether an ethical sourcing page means anything.
As Massive's co-founder and CEO Jason Grad put it during our recent Reddit AMA:
The industry doesn't seem to have changed, just the marketing message.
Jason runs a residential proxy network, so he sees the supply side that buyers usually only see through a dashboard.
In our r/WebScrapingInsider AMA, we asked Jason where residential IPs actually come from, how much providers overlap, and what evidence buyers should expect about sourcing.
One caveat before we start: these takeaways draw on his experience operating a network. His industry estimates are informed opinions, not independently audited market statistics.
Here are the six biggest insights from the discussion.
1. Three Proxy Providers Could Still Leave You Dependent on One Network
The standard reliability playbook is simple: if one proxy provider is critical, add a second and maybe a third.
That assumes each brand brings its own supply. Jason does not think there are many genuinely independent networks to go around. On how many exist, he said:
I believe less than 10 and if you want a supplier who doesn't mix or aggregate pools, it's even less.
Treat that as one operator's estimate, not a market census. But the implication is hard to ignore.
If the number of underlying networks is small and many brands buy, mix or aggregate supply, then your three providers may be routing through overlapping pools. A target that blocks one may already be blocking the others. An availability problem upstream may hit all three at once.
There is an important qualification. Seeing the same IP across two providers does not prove that one resells the other, or that they will perform identically. A single home device can participate in several networks through different apps or SDKs. Overlap is a signal worth investigating, not a verdict.
What matters for redundancy is not how many logos you pay, but whether your failures are correlated.
2. An Ethical Sourcing Programme Does Not Establish Where Your Traffic Comes From
If branding does not reveal the underlying network, the obvious next step is to look at how a provider says it sources IPs.
Many point to a bandwidth-sharing app: a visible programme where users opt in and get rewarded. That is reassuring. It is also incomplete.
Jason's rough ranking of where residential supply comes from, across the industry, runs:
- SDKs embedded in desktop, mobile and smart-TV apps.
- Dedicated bandwidth-sharing apps.
- Providers' own apps.
That is his unaudited assessment, and the categories can overlap. But if it is even roughly right, the channel providers most like to showcase is not necessarily where most traffic originates.
A participation programme demonstrates one way devices join a network. It does not tell you how representative that channel is of the traffic you actually receive. Jason acknowledged that an advertised programme could plausibly act as a shop window for supply acquired elsewhere.
That is not an accusation against any specific provider, and third-party sourcing is not inherently improper. It is a gap between what is shown and what is delivered. Asked whether providers could publish a breakdown by channel without naming partners, Jason said they could:
Ranges by channel, device type and direct-sourced share, published quarterly, would be safe.
There are real limits to how far that disclosure can go. When pressed on delivered traffic with logs behind it, Jason pointed to privacy problems in collecting data on users and commercial problems with sharing the traffic of partners who may have NDAs. But a breakdown by channel, backed by records, does not require naming anyone.
3. Your Best Exit for a Long Session Might Be a Smart TV
The acquisition channel matters. So does the type of device supplying the exit.
Proxy pools are usually marketed on size. Jason pointed to a case where a smaller pool of smart-TV exits can be the better choice:
When session length and stable home-broadband exits matter more than pool size.
The logic is about availability. Smart TVs tend to stay plugged in and connected to home broadband for long periods. Phones sleep, switch from Wi-Fi to mobile data and leave the house.
For a single request, that difference rarely matters. For a multi-step workflow, such as logging in, paginating, adding to basket and checking out, an exit that disappears halfway through costs you the whole job.
The trade-offs are real:
- Less rotation. A smaller pool gives you fewer distinct IPs to spread load across.
- Thinner geo coverage. Precise city or ASN targeting may have less depth.
- No fingerprint change. Routing through a TV changes the exit connection, not the browser fingerprint your scraper sends.
Device uptime is also not a session guarantee. For workflows that need the same IP over very long periods, Jason generally recommends ISP proxies instead.
4. Your Endpoint Can Stay the Same While the Supply Behind It Changes
Even after you choose the right pool, its composition can change.
When success rates fall, the usual suspects are the target's anti-bot system or your own scraper. Supply changes rarely make the list, partly because nothing on your side changes. The hostname, port and credentials all stay the same.
Jason described what happens at Massive when an app partner is suspended or terminated:
They are removed from the network. If it could impact performance, we would tell the affected clients.
Removing a partner removes the exits it supplied. The customer-facing API stays unchanged while availability behind it shifts. Depending on what that partner contributed, particular countries or device categories could be affected more than others.
The AMA gave no data on how often this happens or how large the impact typically is, so it should not be your default explanation for a drop. It is one more hypothesis to rule in or out.
What follows is our operational interpretation, not something Jason prescribed. You can only test that hypothesis if your logs are granular enough to show where the change happened.
5. The Proxy Business Runs on App Distribution, and Platforms Can Constrain It
Partner changes raise a broader question: who ultimately controls access to residential devices?
Jason was direct about where competitive advantage lies:
The moat is distribution.
A network is only as good as its ability to keep devices participating. That means owned apps, exclusive partnerships and the channels that put those apps on phones, desktops and TVs. Keeping that access is a core business capability, not a back-office task.
The same dependency cuts the other way. Apps reach devices through app stores and operating systems, and those gatekeepers set the rules. On where the external pressure comes from, Jason was unambiguous:
The answer is always the platforms and operating systems.
He referenced platforms including Google Play, WebOS and Tizen during the AMA, but did not detail specific policy changes or quantify their impact, so we will not speculate.
The structural point stands on its own. Two network operators with no shared supply can still share exposure to the same platform. A policy change in one app store could affect both at once, which brings back the redundancy problem from section 1 from a different direction.
6. Providers Can Protect Their Suppliers and Still Prove More Than "Trust Us"
You cannot eliminate every dependency. You can ask for better evidence.
Providers often answer sourcing questions with confidentiality. Some of that is legitimate. Naming partner apps invites competitors to poach them and helps targets block their IPs.
Jason drew a useful line between justified and unjustified secrecy. Withholding information becomes a concern, in his view:
When the withheld item wouldn’t help anyone poach a partner or block an IP, but it’s still secret.
That test separates what providers can reasonably protect from what they can reasonably share:
| Commercially sensitive | Useful evidence providers can disclose |
|---|---|
| Partner app identities | Consent wording |
| Granular partner volumes and payouts | Participant rewards and withdrawal procedures |
| Details that expose supply to targeting | Partner requirements and enforcement processes |
| Detailed routing logic | Broad sourcing breakdowns and audit scope |
Jason also described concrete consent checks that can be verified:
- No preselected acceptance. The user has to actively opt in.
- The app works after refusal. Declining does not break the product.
- Immediate opt-out. Withdrawal takes effect straight away.
- No SDK activity before consent. Including after the device reboots.
These checks establish how the software behaves. They do not, by themselves, prove that users understood what they agreed to. Wording and presentation still matter.
The same caution applies to badges. A SOC 2 report or similar certification covers a defined scope. It does not automatically mean every upstream sourcing channel has been independently verified.
Conclusion: The Right Questions Matter More Than the Pool Size
A residential proxy endpoint hides a supply chain: networks that may overlap, sourcing channels that may differ from the marketing, devices with different availability, partners that come and go, and platforms that can change the rules.
You do not need full visibility into that chain to buy well. You need to ask questions that expose the parts that affect you.
Take these five into your next provider evaluation:
- How independent is your supply from the providers we already use?
- What share of delivered traffic comes from each acquisition channel?
- Which device types best support our session and targeting requirements?
- How will you communicate material changes to supply?
- What evidence supports your consent and sourcing claims?
As Jason put it when explaining why sourcing breakdowns are not standard practice:
Until something requires disclosure, ‘trust us’ stays the default.
Put those questions to your current providers before your next renewal. The answers will give you more informed purchasing, stronger redundancy and faster troubleshooting.
Then check out ScrapeOps, the complete toolkit for web scraping.