How Many IPs Do You Need for Price Monitoring and Drops per Metro?

Retail jobs come in two shapes. One is monitoring: a list of products, a set of stores, a refresh interval, and a need to keep pulling pages without tripping the store's rate rules. The other is the drop: one account, one cart, one checkout that has to succeed on the first try at a fixed minute. Both get asked the same question, which is how many IPs do I need, and both get the wrong answer if you start from a provider's headline pool. The right starting point is the store. Work out how many requests one address can carry at each store before friction appears, count your requests, and the number of lines follows. This page walks through that sizing, explains what one line in one metro actually yields, and says when a second metro is worth adding.

Start from the store, not from the pool

Every store has its own tolerance for repeat visits from one address. A big marketplace with heavy bot defences gets suspicious after a modest number of product pages in a short window. A regional grocer's site may not notice a few hundred. You find the number by watching: run your monitor from one address at a gentle rate, raise it until the store starts serving challenges, empty pages, or odd prices, then back off. That threshold, requests per address per store per hour, is the unit everything else is built on.

Once you have it, the arithmetic is plain. Multiply your product count by your refresh rate per hour, divide by the per-address budget the store tolerates, and you have how many distinct addresses that store needs from you in an hour. Do it per store, because a job hitting three retailers does not share one budget; each store counts on its own. What you get is a demand figure in fresh addresses per hour, which is exactly the thing a mobile line either can or cannot supply.

What one line in one metro actually supplies

A line is one modem with one SIM on one carrier in one of our eight metros. Its addresses come from that carrier's regional pool behind CGNAT, and each rotation, which is a detach and re-attach taking seconds, may return a new address or one the line has held before. As a rule of thumb, a line rotated many times a day turns up a few hundred distinct addresses in its first week and low thousands over a quarter. It finds new ones fastest in the first days and slows as it has seen most of what its gateway routinely hands out, though it never quite stops.

The number that matters for monitoring is not that total but the yield per rotation: how often a rotation lands on an address the line did not use in the last day. A line rotating every two minutes shows a far larger raw count than the same line rotating hourly, on the same pool, without giving you any more addresses to spread requests across. So when you compare lines for a monitoring job, compare freshness per rotation. The honest number depends on carrier, metro, and cadence. In our racks Verizon lines tend to hand out a fresh address readily, AT&T lines tend to be stickier and revisit addresses more often, and T-Mobile varies a lot from one metro to the next.

Monitoring wants fresh, checkout wants sticky

The two retail jobs want opposite things from the same hardware. A price monitor wants a line whose rotations land on fresh addresses, rotated between batches so each store sees a modest number of requests per address. A checkout wants the reverse: an account that logged in, built a cart, and paid from one consistent carrier address in the store's own region. Rotating in the middle of that path is the fastest way to get a cart wiped or a payment sent for review.

So do not run them on one line. Put the monitor on a line chosen for yield and rotate it on a schedule that keeps each address under the store's budget. Put the buying account on a separate sticky line, keep the session alive with a little traffic in the days before the drop, and never press rotate on it during the event. Sharing an address with many ordinary phones does not hide either job; stores attribute by account, device, and behaviour. What the carrier address gives you is a normal consumer origin that stores are reluctant to block, and a sticky session keeps that origin consistent for the account that needs it.

Per-metro pools and local pricing

The same carrier is a different pool in every metro. Verizon in Phoenix and Verizon in Miami hand out addresses from different gateways with different depth and different stickiness, and stores read those addresses as different places. That matters for retail more than for most jobs, because stores show regional prices, regional stock, and regional delivery windows based on where the address resolves. A monitor for a Houston store priced in Houston should run on a Houston line, and a drop at a store that ships from a New York warehouse is safer on a New York line.

Geolocation follows the carrier's gateway, not the rack. Our Boston hardware is the clean example: its Verizon addresses resolve as Boston while its AT&T addresses resolve as New York. Before you commit a monitor or an account to a metro, check where that line's addresses actually land, because a store's regional view is built on that answer.

When one line is enough, and when to add a second metro

Most retail customers start with one line and many stay there. The signals that it is time to add a second one are specific.

• One line is enough when your hourly demand in fresh addresses, summed across stores, sits comfortably under what the line yields
• One line is enough when every store you watch prices and stocks for a single region, and you have no checkout account to protect
• Add a second line in the same metro when you need a sticky checkout account alongside a rotating monitor
• Add a second metro when a store shows different prices or stock by region and you need to see more than one view
• Add a second metro when repeats on your first line are frequent and support confirms another city's pool is currently yielding fresher addresses

Repeats, cadence, and the drop-day plan

A rotation that returns the same address is not a fault. On a lightly loaded pool nobody claims the address during the few seconds the modem is offline, so the gateway hands it back. For the checkout account that is exactly what you want. For the monitor it means one more batch on an address that already has some requests against it at the store, so the sensible script pattern is: rotate, read the address, compare to the last day's list, and rotate again on a repeat before sending the batch. If repeats are constant, ask support to lengthen the detach gap or to move the monitor to a carrier in that metro that is currently handing out fresh addresses more freely.

For drop day, set up early. Log the buying account in on its sticky line days ahead, browse a little each day so the session stays active, and confirm the address still resolves in the store's region the morning of. Run the monitor from the other line at a rate under the store's per-address budget, and let it handle the watching so the buying account only touches the site when it is time to add to cart and pay. Speed is not the constraint here; a 4G line at typical 20-45 Mbps or a 5G line at 50 Mbps and up loads a product page many times faster than a store will let you refresh it.

What to do next with TigerProxies

Take a line in the metro that matches your main store's region and test it against that store, not against a checker. Find the per-address budget, size the monitor to it, and note how often rotations repeat over the first day. If you have a checkout account, put it on its own sticky line from the start rather than moving it later.

Then open live chat and tell us the stores and the cities. We can say which carrier in a given metro is currently rotating freshest and which is holding sessions longest, switch the carrier, or move a port to another of our eight metros, all at no charge. Adding a second line or a second city is a plan change, not a project, and the first line will already have told you whether you need it.

Frequently asked