Skip to main content
Back to E-commerce Dictionary

Canonical Data Model

Data managementIntermediate Level

A canonical data model (CDM) is a shared, application-independent format for business data, such as products, customers and orders. Every system translates its data to and from this one model instead of to every other system.

Image by · CC BY 4.0

What is Canonical Data Model?

A canonical data model (CDM) is a common data format that sits between systems. It defines the shared business entities, such as Product, Customer and Order, with their fields, data types, units, allowed values and relationships, independent of any one application. Each system maps its own data to the canonical model once, and integrations exchange data in that format. The benefit is in the number of translations. If six systems all talk to each other directly, you need up to 30 one-way mappings, because N systems need N(N-1) of them. With a canonical model, each system needs one mapping into the model and one out of it, so 2N, or 12 for those six systems. Adding a seventh system then means two new mappings instead of twelve. The pattern comes from enterprise application integration and is often implemented in middleware or an integration platform. A canonical model in this sense is the same thing: the agreed reference version of the data that every integration speaks. It is a contract for data exchange, not a database, and it does not replace each system's own data model.

Why Canonical Data Model matters for e-commerce

In e-commerce, product data is where a canonical model pays off first. The ERP calls a field item_desc_2, the webshop calls it description, a marketplace wants bullet_point1 to bullet_point5, and the supplier file uses its own column names and units. Without a shared model, every new channel or supplier means another custom mapping, and a small change in one system breaks several integrations. A simple product CDM defines one name for each attribute, one unit per measure (for example weight in grams and dimensions in millimetres), fixed value lists for things like colour and material, and clear rules for identifiers such as SKU and GTIN. Supplier data is mapped into that model on import, and each channel gets its own mapping out of it through attribute mapping. In many stacks a PIM effectively becomes the canonical store for product content: WISEPIM, for example, keeps one set of attributes with their rules and maps them to each channel's fields on export. The pattern has real costs. Agreeing on one model takes time, the model needs versioning and an owner, and a model that tries to cover every edge case becomes too complex to use. Keep it focused on the entities and fields that actually cross system boundaries.

Examples of Canonical Data Model

  • 1Product data between ERP, PIM and webshop: a retailer defines a canonical Product with sku, gtin, brand, title, weight_g and dimensions in millimetres. The ERP, the PIM and the webshop each map to it once, so adding a marketplace needs only one new mapping.
  • 2Supplier onboarding: a distributor receives files from 200 suppliers in different layouts and maps each one into its canonical product model, so the rest of the stack only ever sees one format.
  • 3Customer data across CRM, marketing and ERP: a B2B company uses one canonical Customer entity, so the CRM, the marketing platform and the ERP agree on the customer number, legal name and addresses.
  • 4Order flow in an integration platform: orders from the webshop, Bol.com and Amazon arrive in different formats and are translated into one canonical Order before they reach the warehouse system.
  • 5Units and value lists: a furniture brand stores all dimensions in centimetres and all colours from one value list in its canonical model, then converts to inches or channel-specific colour names only on export.
Image by · CC BY 4.0

How WISEPIM Helps

  • One attribute model for product content: define attributes once, with type, unit and validation rules on the field, and every product is checked the same way.
  • Map in and map out: map supplier and ERP columns into WISEPIM on import, and map WISEPIM attributes to each channel's fields with a saved template on export.
  • Fewer one-off integrations: connected webshops and channel feeds all read from the same product record, so a new channel needs one mapping, not a new copy of the data.

Common mistakes with Canonical Data Model

  • Trying to model every field from every system, which makes the canonical model too large to agree on or maintain.
  • Using one system's internal field names as the canonical names, so the model is tied to that system after all.
  • Changing the model without versioning, which breaks integrations that still expect the old structure.
  • Leaving units and value lists open, so 10 cm, 100 mm and 0.1 m all appear in the same field.
  • Treating the model as an IT project only, without the product and sales teams who know what the data means.

Tips for Canonical Data Model

  • Start small. Model the few entities and fields that cross system boundaries most often, usually products, customers and orders.
  • Fix units and value lists in the model, such as weight in grams and one colour list, and convert only at the edges.
  • Give the model an owner and a version number, and document every system's mapping to it.
  • Do not copy one system's structure into the model. Use business names that make sense without knowing the ERP or the webshop.
  • Review the model when you add a system or channel, rather than adding one-off exceptions to individual integrations.

Trends around Canonical Data Model

  • AI-driven mapping: Using machine learning to automatically map disparate source data into the canonical format.
  • Headless commerce integration: CDM providing the unified data layer for multiple frontend experiences (web, mobile, IoT).
  • Sustainability data inclusion: Incorporating Digital Product Passports (DPP) requirements directly into the canonical model structure.

Tools for Canonical Data Model

  • WISEPIM
  • MuleSoft Anypoint Platform
  • Apache Camel
  • Microsoft Dataverse
  • Akeneo

Related Terms

Attribute CollisionCircular Economy Data ModelCross-Border Trade (CBT) AttributesData ContractData DecayData Deduplication

Also Known As

Common Data ModelMaster Data SchemaUniversal Data FormatCDM

Frequently Asked Questions

A canonical data model is a shared, application-independent format for business data such as products, customers and orders. Every system maps its own data to and from this model, so integrations exchange data in one agreed format instead of translating between every pair of systems.

In data integration, a canonical model means the same as a canonical data model: the agreed reference version of a business entity that all systems use when they exchange data. The word canonical means standard or authoritative.

A retailer defines one Product entity with fields such as sku, gtin, brand, title, weight in grams and dimensions in millimetres. The ERP, PIM, webshop and marketplace connectors each translate to and from that entity, instead of each system translating directly to every other system.

It cuts the number of integrations. N systems connected point to point need up to N(N-1) mappings, while a canonical model needs 2N. It also gives one place to define data rules, which makes data more consistent and new systems faster to connect.

Designing and agreeing on the model takes time, it needs an owner and versioning, every message is translated twice, and a model that tries to cover every system's edge cases can become large and hard to change. Some teams use smaller, domain-specific models instead of one enterprise-wide model.

No. A database schema describes how one application stores its data. A canonical data model describes how data is exchanged between applications. Each system keeps its own schema and maps it to the canonical model at its boundary.

A canonical data model is a general integration pattern that any organisation can design for itself. The Common Data Model is a specific set of standard entities published by Microsoft and used in its Dataverse and Dynamics 365 products. Both are often abbreviated as CDM, which causes confusion.

Master data management decides which record is the trusted version of a product or customer and keeps it clean. A canonical data model defines the format in which that data is exchanged. The two often work together: the MDM or PIM holds the golden record and publishes it in the canonical format.

Start with the entities that cross system boundaries most often, usually products, customers and orders. List the fields each system needs, agree on names, types, units and value lists, document the mappings from each system, assign an owner, and version the model so changes do not break existing integrations.

A PIM is not the model itself, but it often acts as the canonical store for product content. It holds one agreed set of attributes, units and value lists, maps supplier data into it and maps it out again to each channel's format.

Still have questions?

Can't find the answer you're looking for? Please get in touch with our team.

Contact Support

Keep exploring

Hand-picked next steps to go deeper.