Scraping Marketplaces: Wildberries and Ozon

Marketplaces are the most common collection target among Russian platforms, and they have quirks that make a naive approach produce wrong data.

How they differ

Personalisation. Price and search results depend on region, browsing history, device and subscription status. A collected value is correct for its collection conditions and need not match what any particular buyer sees.

Dynamic pricing. Prices change often, sometimes within a day. A daily snapshot may not reflect reality.

Search position is not fixed. The same product for the same query sits at different places for different users. Any position measurement here is approximate and should be treated as an estimate.

Serious protection. Platforms of this scale invest in anti-scraping measures, and getting past them is an ongoing race rather than a one-time setup.

The rules explicitly forbid automated collection. That is part of the user agreement, and the consequence is losing access - for a seller, with additional risk to their account.

What is available officially

Before building a scraper, check whether the task is solved through supported channels.

Platforms provide seller interfaces: your own products, orders, stock, financial reports, some analytics. Anything concerning your own data is better taken from there:

• The data is official and complete.
• No rules are broken.
• It does not break when markup changes.
• There is support.

The practical conclusion: scraping marketplaces is justified where the official interface provides nothing - mostly competitor data and the general picture of a niche.

What sellers actually need

Competitor price monitoring. The most common task - see scraping competitors.

Position tracking. Where a product sits for key queries, with the caveat that the figure is approximate.

Niche analysis before launch. How many sellers, what the price spread is, how listings are presented.

Collecting reviews. Your own, to work on quality; competitors’, to understand complaints about the category.

Checking your own listings. What the listing actually looks like: whether an image was replaced, whether the description disappeared, what price the buyer is shown. This often matters more than everything else, because a seller sees their listing in the seller portal while a buyer sees it in search, and the two differ.

Technical notes

Data often arrives as a structured payload. The page calls internal endpoints and receives ready structures. No markup parsing needed - see the scraping guide.

Region is mandatory. Without specifying one you collect data from an unknown city. Region is set both by the exit address and by request parameters - see the proxy guide.

Volume is large. A category with tens of thousands of items requires a queue, resumption and a sensible pace.

Structures change. Platforms revise internal formats regularly. The scraper needs maintenance - see cost.

Pace matters. Aggressive collection triggers restrictions quickly.

For ongoing platform work, some tasks fit well in Browser Automation Studio, where collection sits alongside authentication, proxies and concurrency in one tool.

The limits

Three things to keep in mind:

Platform rules. Automated collection is forbidden. For a seller that is an additional risk: complaints can reach their working account.

Personal data. Reviews contain names. Collecting reviews to analyse complaints is one thing; building a database of their authors is another, and the second is regulated - see scraping contacts.

Listing content. Competitors’ photographs and descriptions are copyrighted works.

The sensible stance: take your own data through official interfaces, take competitors’ data only in the volume analysis requires, and do not move their content onto your own listings.

What this looks like on real projects: the portfolio. The overview is in the scraping guide.