Skip to main content
Back to E-commerce Dictionary

Canonical Data Model

Data managementIntermediate Level

A canonical data model defines one shared format for exchanging data. For example, an ERP may send weight in kilograms and a supplier feed in grams. Both can map to a common weight value and unit before the storefront reads them.

Image by · CC BY 4.0

What is Canonical Data Model?

A canonical data model (CDM) is one standard, system-neutral definition of business data, such as a product, order or customer, that all connected systems translate to and from. Instead of mapping every system directly to every other system, each one maps once to the canonical model. With five systems connected point to point you can need up to 20 one-way mappings; with a canonical model you need one mapping in and one out per system. The model defines entities, fields, data types, units and code lists, for example that weight is always stored in grams. It is not the same as a database schema, which describes how one application stores data, or Microsoft's Common Data Model, which is one specific published model. For product data, the attribute model in a PIM often plays this role. Our guide to attribute modeling shows how to design one.

Why Canonical Data Model matters for e-commerce

Ecommerce teams connect an ERP, a PIM, webshops, marketplaces and feeds. Without a shared model, each new channel means another custom mapping and another place where data can drift. A canonical model makes new connections cheaper and keeps the same product looking the same everywhere.

Examples of Canonical Data Model

  • 1Entity: Product, Canonical field: weight_g, ERP field: GEWICHT_KG, Shopify field: weight with unit.
  • 2Entity: Product, Canonical field: color (from a fixed list), Supplier A: Navy Blue, Supplier B: NVY, Canonical value: Navy.
  • 3Entity: Order, Canonical field: order_total incl. tax, used by the ERP, warehouse and invoicing system.
  • 4Integration: a middleware layer that converts every incoming message to the canonical format before routing it to other systems.

How WISEPIM Helps

  • One attribute model for product content: define attributes once in WISEPIM, with type, unit and allowed values, and every product follows the same structure.
  • Map in and map out: map supplier and ERP columns to WISEPIM attributes on import, and map them to each channel's fields on export.
  • Fewer one-off integrations: connected webshops and feeds 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

  • Copying one system's schema and calling it canonical, so the model inherits that system's quirks.
  • Trying to model every field of every system at once instead of starting with shared entities.
  • Skipping units and code lists, so the same field still means different things.
  • Changing the model without versioning or telling the teams that map to it.

Tips for Canonical Data Model

  • Start with the few entities every system shares, such as product, price and stock.
  • Define units, formats and code lists, not just field names.
  • Name an owner for the model who approves changes and documents them.
  • Keep channel-specific fields outside the core model and add them through mappings.

Trends around Canonical Data Model

  • Event-driven integrations publish canonical events, such as ProductUpdated, that any system can subscribe to.
  • Composable commerce setups use a canonical model to swap one service for another without rewriting every integration.
  • AI helps propose mappings between a source file and the canonical model.

Tools for Canonical Data Model

  • WISEPIM: PIM whose attribute model acts as the shared structure for product content, with import and export mappings.
  • MuleSoft and Boomi: integration platforms that often use a canonical model between systems.
  • Microsoft Common Data Model: a published set of standard entities used in Dataverse and Dynamics 365.
  • JSON Schema: a common way to document and validate a canonical format.

Related Terms

Also Known As

CDMCanonical modelCommon data formatEnterprise data model

Frequently Asked Questions

A canonical data model is a shared, system-neutral definition of data such as products or orders. Every system maps to and from it, so you avoid building a separate mapping between each pair of systems.

A retailer defines one product format: SKU, title, weight in grams, color from a fixed list, price excluding tax. The ERP, PIM, webshop and marketplace connectors all convert their own fields to that format, so a new system needs only one mapping.

Canonical model is the short name for a canonical data model: the agreed standard format for a type of data inside an organization. In integration work it is the format messages are converted to before they are routed onward.

No. A database schema describes how one application stores its data. A canonical data model describes how data is exchanged between applications, independent of how each one stores it.

It takes effort to design and agree on, it adds a translation step to every integration, and a model that tries to cover everything becomes slow to change. Starting small with shared entities keeps it manageable.

In data, canonical means the one agreed, standard form of something. A canonical record or format is the version every system treats as the reference, and other formats are converted to it. A canonical data model applies that idea to a whole set of business entities, such as products, orders and customers.

Keep it system-neutral, so no field names or codes from one application leak in. Model only the entities and fields that systems actually exchange, define types, units and code lists once, and version the model so connected systems can upgrade one at a time. In integration work, this is the canonical data model pattern: each system translates once to the shared model instead of to every other system.

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.