Sellers and agencies monitoring competitor prices on Wildberries, Ozon, and Avito often choose polling frequency "by eye" — every 5 minutes, "to ensure no price change is missed." As a result, the proxy traffic bill skyrockets, while the actual benefit from such monitoring speed is minimal. In this article, we will explore how polling frequency affects traffic volume and how to set up monitoring so that the data remains relevant and expenses predictable.
Why Polling Frequency is the Main Cost Factor
Price monitoring on marketplaces is straightforward: a script or service periodically opens a competitor's product page, retrieves the price, availability, and ranking, saves the data, and repeats the process at a set interval. The shorter the interval, the more requests to the Wildberries or Ozon servers per day — and the more traffic passes through the proxy.
The problem is that many sellers set polling frequency intuitively, driven by the fear of "missing the moment," rather than the actual price dynamics in their category. Prices for household appliances or furniture change a couple of times a day, or sometimes once a week. Monitoring such products every 5 minutes is like checking the mailbox every minute in anticipation of a letter that arrives once a month. Traffic consumption increases, while the usefulness of the data does not.
Another point: Wildberries and Ozon actively detect automated requests from a single IP address. The more frequent the polling, the higher the risk of encountering a CAPTCHA, temporary IP block, or distorted data (the platform may show a "placeholder" instead of the actual price if it suspects a bot). Thus, aggressive polling frequency is not only more expensive but also less reliable in terms of data quality.
How Much Traffic One Product Page Polling Consumes
To understand where the bill difference comes from, let's break down one monitoring cycle into its components. A product page on Wildberries or Ozon is not just an HTML page: images, scripts, rating data, reviews, and recommendations are loaded. If the parser retrieves the entire page (and not just the API response with the price), the traffic volume for one request can range from 300 KB to 1.5 MB.
Here are average figures for one product page using different data collection methods:
| Data Collection Method | Traffic per Request | Comment |
|---|---|---|
| Full Page Load (with Images) | 800 KB – 1.5 MB | This is how some ready-made parsers "out of the box" work |
| HTML without Media Files | 150–300 KB | Images and styles disabled |
| Request to Internal Product API | 10–50 KB | The most economical method, requires parser configuration |
The difference between the "heavy" and "light" data collection methods is already 15-30 times in traffic volume per request. Now multiply this by the number of products being monitored and the polling frequency — and you will get the actual bill for the month.
Calculation: 12 Times Difference Between Monitoring Modes
Let's take a typical scenario: a seller monitors 500 product pages from 10 competitors on Wildberries. We will compare two modes — "aggressive" (polling every 5 minutes, 24/7) and "reasonable" (polling once an hour during working hours, with enhanced checks in the morning and evening).
| Parameter | Polling Every 5 Minutes | Polling Once an Hour |
|---|---|---|
| Polling Cycles per Day | 288 | 24 |
| Requests per Day (500 Pages) | 144,000 | 12,000 |
| Traffic per Day (at 150 KB/request) | ~21.6 GB | ~1.8 GB |
| Traffic per Month | ~650 GB | ~54 GB |
The difference in traffic volume is exactly 12 times, while the actual benefit from polling every 5 minutes for most product categories is negligible: prices on marketplaces typically change no more than a few times a day, and even less frequently during working hours. Paying for traffic based on actual usage makes this difference a direct reflection of the bill: 650 GB of traffic per month versus 54 GB — this is a significant overpayment for data that physically cannot change that often.
A similar logic applies to residential proxies with traffic-based billing — there, the 12 times difference literally translates into a 12-fold difference in the bill. Even if you have a fixed plan with a set pool of GB, aggressive monitoring simply depletes it faster, and you either purchase more traffic or switch to a more expensive plan.
What Polling Frequency is Needed for Different Product Categories
The optimal monitoring frequency depends on the price volatility in a specific category and how quickly you are ready to respond to changes. Below are practical recommendations by category, based on typical seller behavior on Wildberries and Ozon.
| Product Category | Typical Price Dynamics | Recommended Polling Frequency |
|---|---|---|
| Electronics, Gadgets | Changes several times a day, especially during promotions | Every 30–60 minutes |
| Clothing, Footwear | 1–2 changes a day | Every 2–3 hours |
| Furniture, Large Household Appliances | Once every few days | 1–2 times a day |
| Products During Sale Periods (11.11, Black Friday) | May change every hour | Every 15–30 minutes only during the promotion |
A practical approach is to use dynamic polling frequency: a base interval (e.g., every 2 hours) for most products and increased frequency only for "hot" items — bestsellers or participants in current promotions. This hybrid mode reduces traffic by 60-70% compared to uniformly aggressive polling of all pages without losing data relevance for key products.
Which Proxies to Choose for Price Monitoring
The type of proxy affects not only the stability of monitoring but also the final cost of traffic. For scraping catalogs on Wildberries and Ozon, one of three options is most commonly used.
| Proxy Type | When to Use | Features |
|---|---|---|
| Datacenter Proxies | Mass data collection with low anonymity requirements | High speed, low cost, higher risk of blocking with frequent requests |
| Residential Proxies | Regular monitoring with IP rotation, bypassing bot detection | IP of real users, lower risk of blocking, important to monitor traffic |
| Mobile Proxies | Checking prices and results as seen by a mobile user | Useful for checking the mobile app of the marketplace, more expensive traffic |
For daily monitoring of a large number of product pages on Wildberries and Ozon, residential proxies usually provide the optimal balance of price and reliability: they are less likely to trigger CAPTCHAs with regular requests and allow distributing the load across different IP addresses, reducing the risk of temporary blocking. Moreover, due to traffic-based billing, the principle "polling frequency directly affects the bill" is particularly evident here — saving on the number of requests leads to direct budget savings.
Datacenter proxies make sense to use where speed and volume are important, and the marketplace does not aggressively detect automated traffic — for example, during a one-time price collection from a large catalog before launching a new product category.
Monitoring Tools Without Programming
Sellers do not necessarily have to write scripts themselves — there are plenty of ready-made solutions for monitoring prices on marketplaces, where polling frequency is configured through an interface, without a single line of code. Most of these services allow:
- Setting a custom polling interval for each group of products or competitors
- Connecting your own proxies through a simple field "IP:port:username:password" in the settings
- Configuring notifications in Telegram when a competitor's price changes by a specified percentage
- Automatically reducing polling frequency at night and on weekends when prices change less frequently
When choosing such a service, it is worth checking whether it allows setting different frequencies for different product groups — this is a key feature for traffic control. If the service only supports a single polling frequency for the entire catalog, you either overpay for excessive monitoring of "calm" categories or lose data relevance for hot items.
Also, pay attention to whether the tool retrieves the full page or only the necessary data via the marketplace's internal API — this is the very factor that provided a difference of 15-30 times in traffic volume per request in the traffic calculation section.
Polling Frequency Optimization Checklist
Before launching or reviewing price monitoring, go through the following points:
- Group products by price volatility (high, medium, low)
- Set different polling frequencies for each group instead of a single interval for the entire catalog
- Disable loading images and unnecessary media files when collecting data, if possible in the parser settings
- Use requests to the internal product API instead of full HTML loading, if the tool supports it
- Increase polling frequency only during promotions and sales, not continuously
- Monitor actual traffic consumption weekly, not just at the end of the month
- Check if placeholders instead of real prices are coming from the marketplace — a sign that the frequency is too high for one IP
- Distribute requests across multiple IPs through proxy rotation to reduce the load on each individual address
Conclusion
Polling frequency in price monitoring on Wildberries, Ozon, and Avito is not a technical detail, but a direct budget factor. The difference between polling every 5 minutes and once an hour can result in a 12-fold difference in traffic volume with absolutely identical data usefulness for most product categories. A reasonable approach is to segment products by price volatility, use a hybrid polling frequency, and retrieve only the necessary data instead of the entire page.
If you are setting up regular price monitoring on marketplaces, consider residential proxies — they reduce the risk of blocks with frequent requests and allow flexible load distribution across IP addresses. For one-time bulk catalog dumps, where speed is more important than anonymity, it makes more sense to consider datacenter proxies — they are cheaper and faster at handling a large volume of requests in a short time.