What margin analytics for Wildberries and Ozon costs
The budget for a profit-per-SKU analytics system: an MVP with dashboards in 5–8 weeks, a full system with forecasts in 2–3 months. Why an honest cost price is more expensive than any visualisation.
In short. An MVP of an analytics system with its own data store and profit-per-SKU dashboards takes 5–8 weeks. A full system with forecasts, alerts and advertising analytics takes 2–3 months and costs about twice as much. This is the cheapest entry point among the directions we work in, and also the one where the price depends most on a single thing: whether the company can calculate its own cost price.
We quote in roubles, so the figures below are given as proportions and timelines rather than converted amounts — convert at the rate of the day if you need an absolute number, or ask us for a quote.
Why the marketplace dashboards are not enough
A marketplace dashboard shows revenue and deductions, but not profit. The deductions do not include the purchase price, packaging, delivery to the marketplace warehouse, the cost of a return, or advertising attributed to a specific item. As a result an item with healthy revenue can be running at a loss, and the marketplace report will not show it. What exactly is missing is covered in why the marketplace dashboard is not enough.
So the budget for this kind of project is first of all a budget for collecting and reconciling data, not for charts.
What the budget is made of
| Line | Share of budget | What is inside |
|---|---|---|
| Collecting marketplace data | 25–30% | Orders, deductions, returns, advertising, retries and API limits |
| Cost price and expenses | 20–30% | Link to the accounting system, batches, logistics, packaging |
| Data store and calculations | 20–25% | Data marts, recalculating history, report speed |
| Dashboards | 10–15% | Profit per SKU, trends, breakdowns, exports |
| Launch and reconciliation | 10–15% | Agreeing with the accounts, resolving discrepancies |
The most underestimated line is the second. Marketplace data can be obtained, it is public to the seller. The purchase price by batch, the logistics to the warehouse and the packaging live in the accounting system or in spreadsheets, and reconciling those is what takes the time.
Two scenarios
MVP, 5–8 weeks. A data store, loading orders and deductions from two marketplaces, pulling the cost price from the accounting system, a dashboard of profit by SKU and by category. That is enough to see the loss-making items and make the first decisions.
Full system, 2–3 months. This adds advertising analytics, alerts on margin drops, demand forecasts and a two-way link with the accounting system. On forecasts, the realistic benchmark: for stable items the error is usually 10–20% over a four-week horizon, while seasonal and promotional items need hybrid models with manual correction, and promising accuracy there would be dishonest.
What moves the estimate most
The state of the cost price. If the purchase price is tracked by batch in the accounting system, profit is calculated correctly almost immediately. If the cost price is kept as an average per item in a spreadsheet updated once a quarter, any analytics will be approximate, and that has to be agreed at the start rather than at the end of the project.
The depth of history. Recalculating a year back costs more than starting from the current month. Sometimes that is needed, often it is not. The question belongs before the estimate.
The number of legal entities and fulfilment schemes. Fulfilment by the marketplace and by the seller are calculated differently; two entities with different commission terms mean two calculation models, not one with a parameter.
What inflates a project quietly
Advertising. Attributing ad spend to a specific SKU is harder than it looks: the data arrives with a delay and each marketplace has its own attribution model. If profit has to include advertising, that is a separate line of the budget.
Disagreement with the accounts. Sooner or later the numbers in the system will be compared with the accountant’s report, and they will not match. A reconciliation mechanism and a discrepancy log planned in advance turn that from a row into a routine task.
Wanting to measure everything. Every additional breakdown costs money and slows the reports down. It is more useful to start with one question: which items are loss-making right now.
What brings the cost down
Start with one marketplace and one legal entity. The second connects to an existing architecture more cheaply.
Calculate profit before advertising in the first stage. That already delivers most of the value, and ad attribution can be added later, once it is clear which decisions depend on it.
Do not build your own BI interface. Off-the-shelf visualisation tools cover the job while the reports are read by a handful of people inside the company.
What ownership costs
The benchmark is 15–20% per year, plus the data store infrastructure. Budget separately for adapting to marketplace API changes: they happen regularly, and analytics breaks first because it depends on more methods than plain synchronisation does.
Common questions
Why not use an off-the-shelf analytics service? It is worth starting there. Ready services calculate by their own rules and from the data they can see. Your own system is needed when the cost price is complicated, when there are several fulfilment schemes, or when you need a link to the accounting system with your own rules.
How soon is the first result? 5–8 weeks to a dashboard with profit per SKU. The result is measured not by how the dashboard looks but by the number of items that were dropped from the range or repriced after it.
Can it be done on a small budget? If the cost price is already calculated and only one marketplace is needed, without advertising, sometimes yes. But then it is a data load and a report, not a system.
Do we need ClickHouse? You need it when the data volume and the depth of history make an ordinary database slow. At the start that shows up in report response times, and the decision is made from a measurement rather than in advance.
Where to start
Inside the range, the price is set not by the analytics but by the cost price: how reliably the company knows what each sold item actually cost it.
So the first step is not choosing a tool but answering the question of where the purchase price comes from. After that the estimate can be calculated on specifics.
How we do it: marketplace margin analytics.
Facing a similar problem?
Tell us what you are building. We will walk through the architecture and give you a budget range in one call.