Industry / Retail & ecommerce
Data and AI for retail and ecommerce connects order, customer and inventory data across channels into one reconciled view, so commercial and planning teams stop working from conflicting numbers. Quorlytic models transactions, returns and promotions separately, resolves customer identity with visible match confidence, and scopes the first data product around one operational decision.
By QuorlyticUpdated
Retail decisions are made in hours against data that arrives on different clocks: a sale is known at the till, an inventory position is known at the next sync, a return is known a fortnight later. This page sets out the lifecycle those decisions sit in, the data each one needs, and what has to be true before analytics or AI can support them.
Lifecycle
Eight stages, each producing the data the next one depends on. The loop matters more than any single stage: a pricing decision taken without knowing what fulfilment did to margin is a guess wearing a number.
Sense demand
Read what customers are actually buying, at the grain replenishment works in. Sales are not demand: a line that sold zero because it was out of stock reads identically to a line nobody wanted.
Plan the assortment and the inventory position
Decide what to carry, where, and how much. The constraint is rarely the forecast — it is lead time, minimum order quantity and shelf space, which the forecast must be expressed in terms of.
Price and promote
Set price, plan markdowns, design promotions. Every promotion also contaminates the demand history it runs against, which is why promotional periods have to be flagged in the data rather than reconstructed later.
Acquire and recognise customers
Bring customers in and work out who they are across guest checkout, multiple accounts and offline purchases. Identity resolved badly is worse than identity left unresolved, because everything downstream inherits the error silently.
Sell across channels
Take the order wherever it happens. The same physical unit can be promised to a store shopper and a web basket in the same minute, so the timeliness of the inventory position is a commercial decision, not a technical preference.
Fulfil, ship and absorb returns
Pick, ship, deliver — then handle what comes back. Returns arrive weeks after the sale and after the reporting period that recorded it, which is why net and gross measures have to be modelled separately rather than reconciled by hand.
Retain and grow customers
Work out who is worth keeping and what to offer them. A lifetime-value figure that cannot be reproduced next quarter is a number, not a decision input.
Measure and correct
Close the loop: compare what was planned against what happened, and change the plan. This is the stage that is skipped most often, and it is the one that makes every earlier stage improvable.
Where it breaks
These are the failures that appear in retail data estates repeatedly. None of them is solved by a dashboard.
Guest checkout, a second account with a work email, a loyalty card used by a household and an in-store purchase with no identifier all describe one person, and the estate has no rule that says so.
What it costsSegments are wrong in a direction nobody can quantify, lifetime value is understated for exactly the customers worth keeping, and suppression lists miss the person who asked not to be contacted.
Merchandising, finance and the ecommerce catalogue each maintain a category tree, and a variant that is one item in one system is three in another.
What it costsCategory performance cannot be compared across channels, forecasts are built at a grain that replenishment cannot order in, and margin analysis silently mixes variants with different costs.
The position a planner sees is the position at the last sync, and the sync interval was chosen by the integration rather than by the decision it feeds.
What it costsAvailability promises are made against stock that has already sold, and the resulting oversells are attributed to demand volatility rather than to latency. The fix is usually matching the ingestion pattern to the decision rather than refreshing a dashboard more often.
Promotional periods are not flagged in the transaction record, so a model trained on the last two years learns promotional demand as baseline demand. Evaluating a forecast on the wrong measure hides the effect for another quarter.
What it costsForecasts overshoot after every campaign, planners lose confidence in the model, and the override becomes the process.
Store margin excludes fulfilment cost, digital margin includes shipping but not returns processing, and finance restates both at period end.
What it costsChannel comparisons drive range and investment decisions that reverse the moment the definitions are reconciled — the pattern described in why two dashboards disagree.
A return is recorded weeks after the sale, in a different system, sometimes without the original order reference.
What it costsGross and net sales diverge by category, cohort profitability is overstated for the highest-return lines, and repeat-purchase measures count a returned item as a purchase.
Functions
Retail organisations are structured by function, and each function owns a different question. The data foundation has to serve all six without forcing them into one definition of everything.
| Function | The question it owns | Data it needs | Analytics | Decision |
|---|---|---|---|---|
| Customer and loyalty | Who is this customer, what are they worth, and what are we permitted to do with that? | Resolved identity, transaction history, consent and channel permissions, service contacts | Identity resolution, segmentation, retention and value modelling | Which customers receive which offer, and through which channel |
| Merchandising and assortment | What should we carry, where, and in what depth? | Product hierarchy, sales and margin by location, space and capacity constraints, supplier terms | Performance analysis by category and location, assortment and space planning | Range, depth and store-cluster allocation |
| Pricing and promotions | What should this cost, and what did the last promotion actually do? | Price and cost history, promotion calendar and mechanics, competitor price where licensed, volume response | Elasticity estimation, promotion evaluation against a comparison group, markdown optimisation | Price points, markdown timing, and which mechanics to repeat |
| Inventory and supply | What do we need, where, and by when? | On-hand and in-transit positions, supplier lead times and reliability, order multiples, demand forecast | Hierarchical forecasting, safety-stock and replenishment policy, exception detection | Order quantity, timing and allocation across locations |
| Store and fulfilment operations | Can we serve this order profitably from here? | Stock accuracy, labour and capacity, carrier performance, fulfilment cost by node | Availability and fill-rate analysis, sourcing cost comparison, exception workflows | Where each order is sourced from and what is shown as available |
| Marketing and performance | Did that spend cause incremental sales, or describe them? | Platform spend and exposure, orders under a resolved identity, comparison groups, margin after returns | Attribution, incrementality testing, contribution modelling | Budget allocation across channels and campaigns |
Decisions
Four decisions, traced from the question a buyer asks to the measure that says whether the answer worked. The caveat on each one is part of the map, not a disclaimer attached to it.
Data required
Analytics
Decision
Order quantity and timing per product and location, with the exceptions a planner should review first.
Measurement
What this does not settleA forecast does not improve availability on its own. It improves availability when replenishment can turn it into an order quantity inside the lead time, and when the exceptions it raises reach someone who can act before the window closes.
Data required
Analytics
Decision
Whether to repeat the mechanic, at what depth, and on which lines.
Measurement
What this does not settleWithout a comparison group this analysis describes what happened during the promotion, not what the promotion caused. Where a holdout is commercially impossible, say so in the output rather than presenting the uplift as an effect.
Data required
Analytics
Decision
Which segment receives which offer, on which channel, at what frequency.
Measurement
What this does not settleA lifetime-value number computed on revenue rather than margin, or on an identity that cannot be reproduced next quarter, will rank the wrong customers first. Keep match confidence visible in the output and treat low-confidence merges as unresolved rather than joining them anyway.
Data required
Analytics
Decision
Budget allocation across channels, and which campaigns to stop.
Measurement
What this does not settleAttribution distributes credit within the population the platform already targeted, which is optimised toward people likely to convert. It answers a different question from incrementality, and the two should be reported next to each other rather than one being presented as the other.
Illustrative interface
A fictional screen showing the shape of a replenishment exception queue. No real retailer, product, supplier or figure is represented, and every value here is invented.
| Line and location | Signal | Constraint | Suggested action |
|---|---|---|---|
| OK: Core line · 40 stores | Demand steady, cover within policy | Order multiple respected | Release without review |
| Watch: Seasonal line · 12 stores | Sell-through ahead of plan | Supplier lead time exceeds remaining cover | Review before the cut-off |
| Risk: Promoted line · all stores | History contains an unflagged promotion | Forecast trained on distorted demand | Hold — correct the history first |
| Watch: Long-tail line · 3 stores | Intermittent demand, several zero weeks | Percentage error undefined on zeros | Evaluate on a volume-weighted measure |
Data foundation
Retail data arrives from a dozen systems, each with its own identifier, clock and definition of a completed transaction. The foundation's job is to make them comparable without flattening the differences that matter.
Source systems
Different clocks, different identifiers. The ten systems are enumerated in the table below.
Ingestion
Pattern chosen per source, from the decision it feeds
Cloud platform
One place the reconciled history lives
Identity & hierarchy
The layer most retail estates skip
Quality & contracts
A breach fails a build, not an inbox
Semantic layer
One definition, not one dashboard
Decision surfaces
Where the work is actually done
Action
A decision with an owner and a measurement
Ingestion pattern follows the decision, not the other way round. Where a source is an operational database and the decision needs same-day positions, log-based change data capture reads the transaction log instead of querying the table, which keeps load off the system of record. Where a supplier sends a file once a night, a nightly batch is the honest answer and a streaming pipeline is expensive theatre. For stock-position feeds that genuinely need event-level updates, scope streaming ingestion and correction handling around the replenishment decision rather than treating every retail source as real time.
Store transactions, tender, discounts applied at the till, voids
Check before trustingLate store polling and offline periods; discount reasons recorded inconsistently between chains
Baskets, orders, sessions, promotional codes, guest and account checkouts
Check before trustingOrder state changes after capture; a basket is not an order and both are often exported to one table
Order lifecycle, allocation, cancellations, partial shipments
Check before trustingThe authoritative state of an order usually lives here, not in the channel that took it
On-hand, reserved, in-transit and in-store positions
Check before trustingSync interval versus the decision the position feeds; reserved stock counted as available
Cost, purchase orders, supplier terms, financial postings
Check before trustingCost is restated at period end, so a margin figure has a version as well as a value
Hierarchy, attributes, variants, lifecycle status
Check before trustingThe hierarchy finance uses and the one merchandising uses are frequently not the same tree
Accounts, loyalty identifiers, contact and consent preferences
Check before trustingConsent has a scope and an expiry; carrying the flag without the scope is not consent
Spend, impressions, clicks, platform-attributed conversions
Check before trustingEach platform attributes with its own model and window, so summing them double-counts
Availability, lead times, marketplace orders and fees
Check before trustingArrives on the supplier's schedule and format; lateness is normal and must be modelled, not treated as an outage
Return authorisations, receipts, disposition and restocking
Check before trustingOften lacks the original order reference, which has to be recovered before net measures are possible
Analytics & AI
The order below is not a maturity badge — it is a dependency chain. Each rung is unreliable until the one above it holds, which is why an AI programme that begins at the bottom usually ends up rebuilding the top.
One definition of net sales, margin and availability, reconciled with the people who own the process. This is unglamorous and it is the thing that stops two meetings using different numbers.
RequiresAgreed metric definitions, a source of record per measure, and a published refresh time
Explaining a movement: which categories, locations and customer groups drove it, and how much of it is a data artefact such as a restated cost or a late return batch.
RequiresConsistent hierarchies, period-correct history, and the ability to separate restatements from trade
Predicting demand at the grain replenishment orders in, with uncertainty exposed rather than hidden behind a single number.
RequiresStockout-aware history, flagged promotional periods, and an evaluation metric matched to what an error costs
Turning a prediction into a recommended quantity, price or offer, inside the constraints the business actually operates under — order multiples, shelf space, margin floors.
RequiresEncoded constraints, a named owner for each recommendation, and an override path that is recorded
Letting a merchant or analyst ask a question in language and get an answer grounded in governed data, with the source shown. Useful when the corpus is governed; misleading the moment it is not.
RequiresPermission-aware retrieval, a curated corpus with owners, and an evaluation set that tests refusal as well as answers
Letting a system take a bounded action — raising a replenishment exception, drafting a supplier query — with a human accountable for the outcome and a log of what it did.
RequiresEverything above, plus explicit action boundaries, reversibility, and monitoring that a human reads
Maturity
Most retail data estates sit between the second and third stage. The useful question is not which label applies but what specifically is missing before the next stage is worth funding.
Reports exist, are late, and are rebuilt in spreadsheets before anyone presents them.
Ready for the next stage whenA source of record is agreed for sales, inventory and cost, and the refresh time is published rather than assumed.
One number per measure, reconciled with finance and merchandising, and the differences between channels are explained rather than argued about.
Ready for the next stage whenDefinitions are owned by a named person, tested in the pipeline, and a breach fails a build instead of generating a message.
Forecasts exist at the planning grain and are evaluated by product group and location rather than in aggregate.
Ready for the next stage whenHistory is stockout-aware and promotion-flagged, and planners can see the uncertainty rather than a single number.
Predictions arrive as recommended quantities and prices inside real constraints, with overrides recorded and reviewed.
Ready for the next stage whenConstraints are encoded, exceptions route to an owner, and the override rate is monitored as a signal rather than ignored.
Retrieval and bounded automation support the people making the decisions, and every action is attributable.
Ready for the next stage whenPermissions are enforced at retrieval time, the corpus has owners, and there is an evaluation set that would catch a regression.
Measurement
A measurement framework for the decisions above. What matters is the pairing: a measure with no decision attached becomes a number somebody defends rather than uses.
| Measure | What it captures | Decision it informs |
|---|---|---|
| Weighted forecast error | Forecast accuracy weighted by volume, so the lines that matter commercially dominate | Whether the forecast is fit to place orders from |
| Forecast bias | Signed error over time — persistent over- or under-forecasting that absolute measures hide | Whether to adjust the model or the planner's default behaviour |
| Stockout rate | How often a line is unavailable where demand existed | Safety-stock policy and replenishment frequency |
| On-shelf availability | Whether stock recorded as held is actually sellable at the point of demand | Store process and count-cycle investment, not just ordering |
| Inventory turns | How hard working capital is working, by category and location | Range depth and allocation |
| Gross margin after returns | Margin once returns, funding and fulfilment cost are deducted | Range, channel and promotion economics |
| Promotion incrementality | Volume and margin caused by a promotion, against a comparison group | Which mechanics to repeat and at what depth |
| Repeat purchase rate by cohort | Whether acquired customers come back, by the period they arrived in | Acquisition spend and retention programme design |
| Contribution per customer | Margin after returns attributable to a resolved identity over a defined window | Which segments justify which offer |
| Return rate by line | Proportion of units returned, and the disposition they receive | Range decisions, sizing guidance and product-detail accuracy |
These are common retail measures and their usual reading, not results Quorlytic has produced for a client. Definitions vary between organisations — agree yours before comparing anything.
Principles
Orders, payments, returns and shipments arrive at different times. Model them separately and reconcile net sales before comparing stores or channels. Map product variants, promotions and currencies so a dashboard does not mistake an accounting difference for a commercial trend.
Build identity rules that account for guest checkout, multiple accounts and consent. Keep match confidence visible and avoid combining records simply because two customers share a name. Connect permitted customer views to meaningful service and marketing workflows.
Forecast at a grain and horizon that match replenishment. Stockouts hide demand, promotions distort history and new products lack observations. Evaluate by product group and location, expose uncertainty and retain planner overrides.
Choose one operational question, such as which products need replenishment review. Identify the source owner, available history, action cadence and acceptance metric. Expand only after the first output has a dependable owner and is used in a real decision.
Price and promotion analysis describes what happened under earlier decisions, which is not the same as what will happen under a new one. State the assumptions, set guardrails for margin, service level and customer impact, and prefer a controlled test where one is possible. A model that only explains history should not be presented as a forecast of a price change.
Segment and lifetime analysis break when identity is guessed. Decide how guest checkout, multiple accounts, shared devices and consent are handled, keep match confidence visible, and connect each segment to an action with an owner. A customer view that cannot be reproduced or explained is worse than no view at all.
Engagement
A typical engagement can progress through these stages. It is a sequence, not a proprietary method, and each stage produces something you keep whether or not the next one happens.
Discover
OutputAn inventory of the decisions in scope, who makes them, on what cadence, and what they currently use
Audit the data
OutputA source and quality map: what each system carries, how late it arrives, and where the definitions disagree
Design the architecture
OutputA target-state design with the ingestion pattern chosen per source and the identity rules written down
Build the foundation
OutputPipelines, models and quality gates for the sources the first decision needs
Build the decision layer
OutputThe forecast, segmentation or measurement the decision requires, evaluated the way the business will read it
Operationalise
OutputMonitoring, named ownership, an exception path and a runbook for when a source fails
Measure and improve
OutputA decision-level measurement framework, and the next decision prioritised against it
Where this connects
Identity resolution with confidence retained, which everything in the customer and marketing columns depends on
Forecasting at the grain replenishment orders in, evaluated by product group and location
Elasticity and markdown decisions with guardrails, separated from what history alone can support
Attribution and incrementality reported next to each other rather than conflated
The ingestion, modelling and quality layer the four decisions above all read from
One definition of net sales, margin and availability, owned and tested
Why the metric you evaluate a retail forecast with decides which errors you stop caring about
The difference between describing credit and establishing cause, and when each one is appropriate
How to diagnose the channel-margin disagreement described above rather than arbitrate it
Choosing the ingestion pattern per source from freshness, load and replay rather than preference
Making a metric definition something a build can fail on, not a document
What has to be true of the estate before the assisted-retrieval rung is worth attempting
Technical references
Questions
These are engineering and analytics engagements scoped around your environment. Existing retail systems are inputs to the architecture; a new application is not automatically required.
Your next data decision
Bring the business question.
We'll help shape the engineering brief.
