Catalogue, stock and orders: the three data domains that decide whether your e-commerce AI works or fails

Picture this situation: a recommendation engine identifies the most relevant product, but offers a variant that is no longer available. The model processed the information it received; the problem is that this information did not represent the current state of the operation.

Catalogue, stock and orders are three critical domains for certain AI applications in e-commerce. The catalogue has to identify products, variants and attributes; stock has to represent availability that is interpretable and current enough; and orders have to preserve lines, statuses, dates and history.

When those relationships do not match across systems, recommendations, assistants, forecasts and reports may work with incomplete or outdated context.

These domains are not enough on their own to guarantee an application’s performance. The model, its configuration, the context of use, operating processes and evaluation all play a part too. Even so, if the underlying data does not represent the operation correctly, the application starts from a constraint it can hardly compensate for without additional information or controls.

AI can process data well that represents the operation poorly

A company can have every system running and still feed an application unsuitable information.

The catalogue may show a variant with incomplete attributes. Inventory may hold a physical quantity that does not match commercial availability. The e-commerce platform may consider an order “processed” while one line is still pending.

None of these situations necessarily means the model is broken. The application may run its logic correctly on data that does not contain the context needed to answer the business question.

Preparing data for AI is not just about enabling access or copying information. It also requires agreeing on what each field represents, how records relate to each other, which system owns each piece of data, what lag is acceptable and how errors are detected.

The NIST AI Risk Management Framework proposes choosing metrics and evaluation methods according to purpose and context. Applied to e-commerce, a recommender, an assistant, a forecast and a report do not need exactly the same data, nor do they tolerate the same kind of error.

• We also recommend reading: “Selling online and your inventory never matches? This is the solution”

Catalogue: AI needs to know which product it is interpreting

The catalogue is far more than a list of names and prices. It is the structure that makes it possible to tell apart products, variants, attributes, categories and publication statuses.

An application may need to know that two SKU codes belong to the same product, that a size corresponds to a variant, or that an item is no longer published on a channel. If those relationships are unclear, the system may group, filter or recommend items that do not represent the real offer.

In the AI Commerce Search documentation, Google explains that imported catalogue data influences the quality of its models and results. Accuracy, detail and freshness are part of preparing catalogue data.

This is one specific technical case, not a universal rule, but it shows that the catalogue plays an active part in certain applications.

Identifiers and variants have to preserve their match

An identifier makes it possible to relate a product to events, orders, availability and answers. If the same item uses different codes in the e-commerce platform, the ERP and analytics, those relationships need an explicit rule.

Consistency does not require every system to use the same internal field. It requires a controlled, verifiable match.

Google documents that products mentioned in AI Commerce Search events must exist in the catalogue in order to be associated. While an event remains unlinked, it is not used to train its models.

Recording an event does not prove it can be related to the product the application needs to interpret.

• You may also find this worth reading: “Time to market: the competitive edge lies in integrating technology before your competition”

Attributes have to answer the use case

Brand, colour, size, category or availability may all feed search, filters and recommendations, depending on the configuration.

An attribute delivers operational value when it has a defined meaning, is filled in consistently, relates to the right product or variant and is relevant to the application.

A fashion recommender may need size and colour. An assistant handling technical compatibility may need model and version. A report may prioritise categories. Preparation depends on the question the system has to answer.

Loading the catalogue does not prove it is ready

A successful import confirms that a process finished under certain conditions. It does not prove that every product is complete, that identifiers match, or that attributes represent the operation.

Google separates upload status, errors, quality metrics and unassociated events. Its monitoring and error reporting documentation makes it possible to review what was processed, rejected or left unlinked.

It is worth tracking which records were processed, which were rejected, which products lack required attributes, which events found no match, and when they were last updated. An available catalogue may still be insufficient for a specific application.

• This reading may also be useful: “Business profitability and technology: how systems integration cuts operating costs and errors”

Stock: availability is not just a quantity

Stock is usually presented as a number. An application, however, may need a more precise definition.

Is it physical stock, sellable units, or the quantity available after reservations? Does it apply to one store, one warehouse, or the whole network? Does it hold for any delivery method?

Commercial availability may depend on variant, location, channel, reservations and delivery promise. That is why “there is stock” does not always fully answer the question.

Variant, location and delivery method change the answer

A product may appear available in general and not be available in the size, colour or format requested.

In its Merchant Center documentation, Google distinguishes the availability of a product from that of its variants. It also allows for differences by region and delivery method.

That does not turn its model into a universal definition of inventory. It does show that a binary flag can fall short when commercial context changes the answer.

Frequency has to match the decision

Not all data needs the same update frequency.

A descriptive attribute can be managed through periodic uploads. The availability of a fast-moving variant may call for a higher frequency. The decision depends on the pace of change and the impact of the lag.

Google allows for both periodic and API updates for certain inventory changes. That does not mean every retailer needs real time.

The useful question is: how stale can this piece of data get before it stops being adequate for the decision that consumes it? A recommendation, an after-sales query and a monthly report may each tolerate different windows.

Two systems can show different states without being technically down

Google describes scenarios in which the site and Merchant Center temporarily hold different values because of their update cycles.

Both systems may be operational. The problem is the window during which they represent different states. What is more, a fast API does not on its own prove that the data is current: response speed, the moment the source changed and total end-to-end time are different dimensions.

To go deeper into this symptom, see inventory inconsistencies across channels.

Orders: a status does not explain the whole transaction

An order relates products, quantities, customer, payments, picking, delivery, cancellations, returns and refunds. Reducing it to a single label can produce ambiguous answers.

In the Shopify API, an order relates customer, lines, payments and fulfilment, and models several processes separately.

Fulfilment here refers to the picking and logistics completion of the order: allocation, picking, dispatch and delivery.

Payment, fulfilment and return are related but distinct processes

An authorised payment does not mean the order has already been picked. A shipped order does not imply every line followed the same path. Nor does a refund prove the goods returned to inventory.

To answer “where is my order?”, an application needs to know whether the person is asking about payment, picking, dispatch, delivery, cancellation, return or refund.

In Shopify, those cycles keep their own statuses. Other platforms may represent them differently, but the operating principle holds: “order status” needs context.

An order can be split across lines and locations

An order can be processed from different warehouses, combine delivery methods, or have one line shipped and another pending.

Shopify allows it to be split into several fulfilment orders. Answering “your order has shipped” could therefore be incomplete if only part of it left the warehouse.

The application needs to identify the lines involved, their origin, the status of each path and the corresponding dates.

History needs interpretable dates, quantities and dimensions

Orders can also feed analytical processes.

In Demand Planning for Dynamics 365 Supply Chain Management, Microsoft explains how a historical demand table, such as sales orders, can be turned into a time series using a timestamp, a measure and relevant dimensions. The interval may be daily, weekly or monthly.

Finer granularity is not necessarily better. It has to match the horizon and the decision. Cancellations, returns, promotions, assortment changes or stockouts can also alter what the history means.

In the Forecast demand process, Microsoft separates collection, generation, evaluation and review before the forecast is used in planning. Generating a forecast is not the same as validating it.

What does each AI application need?

The three domains do not serve the same function in every application.

Application	Priority data	Question they have to answer	Operational risk
Recommendations	Product, variant, attributes and availability	Which product is relevant and can be offered?	Recommending an unavailable variant
Automated support	Order, lines, payment and fulfilment	What happened to this part of the order?	Answering with an incomplete status
Demand forecasting	Product, quantity, date and dimensions	Which historical pattern is being analysed?	Treating context-free transactions as demand
Personalisation	Events, identifiers, catalogue and availability	Which interactions can be related?	Fragmenting or overstating identity
Reporting	Products, orders, cancellations and returns	Are teams calculating the same metric?	Consolidating incompatible definitions

Recommendations and personalisation

Recommendations may need attributes, events, identifiers and availability. Personalisation may require continuity across interactions.

In AI Commerce Search, Google distinguishes a visitor identifier from an optional persistent one for authenticated users, which can help relate activity across devices.

That does not amount to a Customer 360. Relating sessions, events, products and orders is only part of the identity problem; it does not solve duplicates, shared accounts, permissions, governance or scope.

Automated support

An assistant needs to retrieve the right piece of data and interpret what it means.

To answer a question about a return, knowing an order exists is not enough. To answer one about a delivery, it may need to identify the line, the fulfilment and the latest available update.

The risk also appears when two systems use the same word for different processes.

Demand forecasting and reporting

Forecasting needs structured, evaluable historical data. Reporting needs consistent definitions.

Two teams may calculate “sales” as orders created, paid, shipped, not cancelled, or net of returns. Consolidating fields that share a name does not guarantee they represent the same metric.

How do you know whether the data is ready for AI?

There is no universal list covering every application. Six controls, however, turn the discussion into concrete decisions.

Six controls before scaling the initiative

1. Definition: what does each attribute, status and date mean?

2. Ownership: which system manages the data, and which team decides its rules?

3. Matching: how do products, variants, events, customers and order lines relate to each other?

4. Freshness: how much lag can the application tolerate?

5. Access: what history, permissions and fields are available?

6. Monitoring: how are failed uploads, rejected records or incomplete relationships detected?

What should be tested with operational data?

A controlled test may not surface the exceptions of day-to-day operation.

The NIST Playbook recommends evaluating systems under conditions close to their context of use and documenting differences between test and operation.

In e-commerce, that means testing discontinued products, incomplete variants, availability changes, partial orders, cancellations, returns, unmatched events and incomplete permissions or history.

Metrics and thresholds have to be defined before scaling. There also have to be owners and procedures for acting outside those conditions.

• We also recommend reading our article: “AI in ecommerce: stock automation and personalised recommendations”

What an integration layer can contribute

When catalogue, stock and orders originate in or are consumed by different platforms, an integration layer can exchange and transform information through defined flows and rules.

At Weavee we integrate e-commerce platforms, ERP, CRM, POS, SCM and payment gateways. Our platform includes a rules engine for working with formats, naming conventions and data structures.

Depending on the scenario, we can configure real-time flows or scheduled batch processing. The interface makes it possible to manage flows, configure mappings and monitor processes from a single dashboard. Weavee also allows for configurable alerts to keep watch on incidents.

A modular architecture makes it possible to add connections according to the scope and needs of the project. This does not mean every connection is immediate, that none requires configuration, or that any system is covered without assessing its conditions.

Integration makes exchange, transformation and monitoring easier, but it does not replace owners, meanings, quality criteria or authorised uses.

You can read more on what an iPaaS platform is and how it differs from other approaches to data integration between systems, such as consolidation, unification or deduplication.

Prepare the operation before scaling AI

An application does not use “the company’s data” as a uniform mass. It uses attributes, identifiers, quantities, statuses, dates and relationships.

The catalogue has to make it possible to recognise which product and variant is being interpreted. Stock has to explain what availability means in the relevant context. Orders have to preserve the processes and events needed to understand what happened.

Every application needs its own criteria: fields, relationships, lag, permissions, evaluation and response to failures.

Before scaling an AI, automation or reporting initiative, business and technology need to agree on those conditions. Integration can help operate the exchanges, but how useful the data is also depends on the organisation’s definitions, responsibilities and controls.

See how Weavee integrates the systems that produce and consume catalogue, stock and order data.

Request a trial!