Skip to content

Retail & Consumer Goods

The register, the online shop and the marketplaces know the same item under different numbers and calculate revenue in their own way. We put the figures on a common footing so that stores, channels and assortments can be compared.

Overview

The same jacket has one number at the register, a second in the online shop and a third in buying. Stores are grouped by region in one system and by sales banner in another. And when someone asks which channel earns the most gross margin, everyone calculates it differently and everyone is a little bit right.

We build the data foundation that reports, dashboards and forecasts run on for retailers and consumer goods companies. AI and machine learning come in where they prove themselves on the company’s own data.

Matching items and locations

The technology is rarely the problem. Registers, shop systems and marketplaces have interfaces or deliver exports. The effort goes into matching: which register item number belongs to which shop variant, how are sizes and colours represented, which store belongs to which region? Where a well-kept PIM exists, that is a good starting point. Where it does not, you end up with a mapping table that someone in buying has to maintain, otherwise it is out of date again after three months.

Only once this matching is in place is a channel comparison more than an estimate. That is why we start here and not with the dashboard.

What revenue and gross margin mean

Finance, buying and the online shop often quote the same figure and mean different things: gross or net, before or after returns, by order, delivery or invoice date. For gross margin there is the further question of whether markdowns, supplier terms and bonuses have already been deducted. Questions like these decide whether a store looks good per square foot or only on paper.

We agree each of these definitions once with the people involved and store it in the data model. Every report calculates from it, including the weekly reports for store managers that someone currently builds by hand in a spreadsheet.

Evaluating promotions

“The promotion brought in revenue” is quickly said. What gets measured instead is the sales you would have expected without the promotion, minus pull-forward effects, shifts to other items and the discount’s effect on margin. That only works if the period, discount and placement of every promotion were recorded. In practice that is where it fails more often than on method.

A legal duty fits in here and is worth using for analysis too. Anyone advertising a price reduction has to state the lowest price of the last 30 days under the German Price Indication Ordinance (Preisangabenverordnung). A price history per item has to exist anyway, and it makes promotion analysis more reliable as well.

Forecasting demand without fooling yourself

A forecast estimates sales by item and location from history, season, price, promotions and calendar, and turns that into order suggestions. For items with enough history this works well. For novelties, special lots and erratic demand it is less certain, and the suggestion should say so.

There is a trap in the data itself. Where goods were missing, nothing was sold, and a model that learns from that underestimates demand. Stockouts therefore need to be flagged in the history. Before go-live we test the suggestions on periods the model has not seen and compare them with the current approach. In operation, buyers and planners stay responsible. They know about the supply bottleneck and the weather forecast that appear in no table.

We treat generated product texts from PIM data just as soberly: spot checks before anything goes live.

Online shop, returns and data protection

For returns, the average tells you little. Broken down by item, size or supplier, it shows where cut, description or quality is the problem. Since 19 June 2026, online retailers must offer a withdrawal button for consumer contracts. Withdrawals and returns should be recorded separately in the data, otherwise two different processes get mixed together.

We measure behaviour in the shop with server-side tracking so that it can be linked to orders and returns. In Germany, the TDDDG applies to cookies and similar access to the device, and the GDPR applies to personal data. That includes loyalty cards and customer accounts. Many analyses, such as assortment and basket, work with pseudonymized or aggregated data. The changes to these rules proposed in the Digital Omnibus are so far only a proposal and have not been adopted.

Typical use cases

  • Store and channel comparison

    Sales per square foot, gross margin and basket size for stores, online shop and marketplaces, calculated with the same definitions and shown side by side.

  • Assortment and promotion analysis

    Which items earn money, which only tie up capital, and what did the promotion really deliver once pull-forward and cannibalization effects are removed?

  • Inventory and availability control

    Inventory turnover, weeks of supply, markdowns and stockouts by item and location, derived from ERP, warehouse and supplier data.

  • Demand forecasting and order suggestions

    The model estimates sales by item and location. Buyers and planners see the suggestion together with its uncertainty and accept or change it.

  • Returns and online shop analysis

    Return rate by item, size and channel, plus the path from visit to purchase, measured with consent-based server-side tracking.

  • Automated store and weekly reports

    Store managers, buying and executives get their figures on a schedule, without anyone pasting them together in a spreadsheet first.

Matching services

  • Tracking & Data Integration

    Learn more
  • Data Intelligence & Architecture

    Learn more
  • Advanced Analytics & AI

    Learn more

Frequently asked questions

How do we get POS, online shop and marketplace data into one report?
The data is loaded automatically from each system and mapped to a common structure, with the same item IDs, locations and time periods. After that, stores, online shop and marketplaces can be compared using the same metrics. The most time-consuming part is usually mapping items and categories across all systems.
Why do revenue figures differ between finance, buying and the online shop?
Usually because the definitions differ: gross or net, with or without returns, by order date, shipping date or invoice date. We define each metric once and store it in a central data model that every report calculates from.
How do we measure whether a promotion paid off?
Revenue during the promotion is not enough. The result is compared with the sales expected without it, and pull-forward effects, shifts to other items and gross margin after discount are part of the calculation. How reliable the result is depends on how many comparable promotions exist in the data.
Can we use loyalty card and shop data without violating data protection rules?
Yes, when the legal basis, consent and purposes are clear and the data stays personal only as far as necessary. Many analyses, such as assortment or basket analysis, work with pseudonymized or aggregated data. With loyalty cards it pays to involve your data protection officer before the data model is fixed.
When does demand forecasting pay off?
When ordering runs on experience and spreadsheets and there are regular stockouts or markdowns. It requires a clean sales history by item and location and information on promotions, prices and out-of-stock periods. We first test whether a model pays off on a limited part of the assortment.
Do we need a data warehouse, or are the reports in our ERP and shop enough?
As long as a question involves only one system, its own reports are often enough. Once stores, shop, marketplaces and supplier data need to be analyzed together, or metrics have to stay comparable over years, a shared data foundation is the more stable choice.

More industries

All industries