In e-commerce you are rarely short of data, you are short of a coherent picture of it. The storefront knows one thing, the ad platform another, the warehouse and ERP something else, and the CRM yet another version. The result is that the most important calls on assortment, margin and acquisition spend are often made on gut feel rather than numbers. For a head of data, e-commerce or growth, the takeaway is simple: e-commerce analytics needs to be a maintained product in its own right, not a pile of drifting reports.
In our experience, the hard part is not drawing a chart but getting the data into a state where the chart can be trusted. That takes people who understand storefront events, data modelling and the realities of an online business at the same time. Even if we don’t have a case study in your exact niche, we provide the skills to build that analytics end to end, from the raw event to the forecast, as team augmentation or a dedicated team.
Why is e-commerce data so scattered?
Because every system was built to run an operation, not to report on it. The e-commerce platform records orders but knows nothing about ad cost. The ad platform knows cost per click but not whether the customer returned the item. The warehouse knows stock levels but doesn’t tie them to margin. So the same sales show up differently in four places.
On top of that sits a technical layer: different definitions of a “session”, a “conversion” and a “user”, events lost to blockers and browser changes, and customer IDs that won’t stitch together across devices. Until there is one agreed definition of metrics and one source of truth, every team defends its own version of the numbers. Our first job is usually exactly that cleanup, before any pretty dashboard exists.
Which commerce reports and dashboards do we build most often?
We start with the layer that actually changes the team’s daily decisions, not with impressive but dead screens:
- a sales and margin dashboard over time, split by channel, category and device,
- an acquisition view (cost, ROAS, CAC) set against real customer value, not clicks alone,
- a returns and complaints report, because in many shops that is what eats the margin,
- alerts and anomalies that flag a drop in conversion or a spike in cost before a human notices.
The key is that every dashboard computes its metrics against one shared definition. So we keep business logic in the data-modelling layer, not baked into a single BI tool where no one but the author can reproduce it.
What does the event pipeline and store telemetry look like?
A good report starts long before the chart, at the point where events are collected. We design a telemetry layer that captures what the customer actually does: product view, add to cart, checkout started, purchase, return. That stream of events is the foundation for everything else.
Technically we wire this into a pipeline that collects events from the front end and the backend, validates them against an agreed schema, loads them into a warehouse or lake, and only there turns them into analysis-ready models. We favour an event-based, server-side approach wherever possible, because browser-only collection is unreliable today. The whole thing goes under CI/CD and monitoring, so that a broken tag or a change on the storefront doesn’t quietly break weeks of data.
How do you run funnel and cohort analysis that actually leads somewhere?
Funnel analysis only earns its keep when it shows where exactly you are losing money, not just that “conversion dropped”. We build funnels that can be broken apart and compared across segments:
- step by step from landing, through the product page and cart, to payment,
- split by traffic source, device and customer segment, because a mobile funnel from an ad looks nothing like a desktop one from a newsletter,
- with cohort analysis that shows how customers acquired in a given month behave over the following weeks,
- with retention and repeat purchase, not just the first conversion.
It is the cohorts and retention that answer whether you are growing healthily or just pouring ad budget into a leaky bucket. These are the views that most often change decisions about where it is worth investing.
How do you report on assortment and margin, not just revenue?
Revenue can rise while profit falls, and without good reports no one spots it in time. So we build assortment analytics around margin, turnover and item-level profitability, not the number of units sold. We join sales data with purchase cost, logistics cost and return rates to show the real result per product and category.
That picture answers the questions that truly move the result: which products make money and which only drive traffic; what is sitting in the warehouse tying up capital; where a promotion lifted sales and where it simply gave margin away. An assortment report is good when buyers and finance look at the same numbers and draw the same conclusions from them.
How do you forecast demand and stock with ML?
Once the data layer is in order, you can move up to demand forecasting. Models learn from sales history, seasonality, promotions and trends to predict demand at the product and location level. A good forecast maps straight to money: fewer stockouts on bestsellers and less capital frozen in goods that won’t move.
Our competence in AI and data covers building such models and, more importantly, wiring them into a real purchasing and inventory process. We watch the things that decide whether a model gets adopted at all:
- matching the horizon and granularity of the forecast to how you actually place orders,
- honest backtesting on historical data, instead of impressive metrics with nothing behind them,
- clear communication of uncertainty, so a planner knows when to trust the model and when not to,
- ongoing monitoring of forecast quality, because the market and the assortment keep changing.
We treat a model as part of a product that has to be maintained, not as a one-off experiment in a notebook.
How do you reconcile analytics with privacy and consent?
E-commerce analytics now has to work in a world of real user consent and fading third-party cookies. In our experience that is not a blocker but a matter of good architecture. We lean on first-party data and server-side collection, which is more resilient to blockers and gives a fuller picture than browser tags alone. At the same time we respect user choices, carrying consent through the whole pipeline so that events without consent don’t end up where they shouldn’t.
In practice that means designing the collection layer with privacy in mind from day one: minimising personal data, pseudonymising identifiers and setting clear retention rules. Well-designed analytics is both compliant and useful, and that is the baseline we start from, not something bolted on at the end.
Which skills do we provide for an analytics project?
We shape the team around the specific stage and the specifics of the shop, not “just in case”. Most often our specialists step into roles such as:
- a data engineer building the event pipeline, the warehouse and the data models,
- an analyst / BI engineer designing dashboards and agreeing metric definitions with the business,
- a data scientist / ML engineer for demand forecasts, segmentation and recommendations,
- a data architect who ties it all together and guards quality and compliance.
Behind this sits our real experience in Big Data and AI/data projects, including solutions built on LLMs and predictive models. That lets us staff not single “pairs of hands for SQL” but roles that own the whole chain, from event to decision.
How do we do it at RITS?
We do it as a nearshore partner from Poland that adds skills where they are missing, rather than selling a closed, ready-made product:
- we design the data layer from the raw event to a business-ready model, not just plug in another tool,
- we agree metric definitions across marketing, sales and finance, to end the arguments about numbers,
- we verify skills before the start and shape the team around the project stage and the client’s stack,
- we work in a close time zone, so we join your meetings, reviews and releases without a long ramp-up.
Most often we deliver this as custom software built by our team and, where headcount needs topping up fast, as team augmentation.
Where to start with building e-commerce analytics?
Start from one decision that today is made on gut feel (say, how much of a bestseller to order, or where to cut ad spend) and from the question of what data you really need for it. That defines which events to collect, how to model them and which report has to change behaviour. It is better to ship one trustworthy view the team actually uses than ten beautiful dashboards no one believes. We covered the differences between engagement models in our article on IT engagement models.
Building sales and behaviour analytics in e-commerce? Let’s talk - we’ll match a team and an architecture to your data and your decisions.