Model attribute variations

Learn how to create an advanced data model for a product with multi-unit representations.

After completing this page, you should be able to:

Configure the product data model for a footwear company that handles an inventory of shoes with sizes based on several different international and metric measurement units.

To wrap up this module, let’s look at a slightly different product data modeling scenario. In this business use case, we will manage the complexities of handling multiple shoe size units within a Composable Commerce architecture.

We will walk through this scenario by focusing on a fictional Australian company called Shoes for Feet.

Problem Statement

Shoes for Feet manages an inventory based on Australian shoe sizes (which is referred to as the 'base size') within their Enterprise Resource Planning system. However, they want to offer customers the flexibility to select sizes by using various international and metric measurement units such as US, UK, EU, Inch, and Centimeter.

It would be an ineffective approach to map each unit of measurement to a unique Product Variant. This method would result in a substantial increase in the number of variants per product (from 17 to 85 in this scenario), negatively impacting performance, data management, and overall system maintainability.

It’s important to understand the relationship between sizes and Stock Keeping Units (SKUs) in this scenario. While customers can choose shoe sizes based on different units, the physical SKU representing the actual product remains constant. For instance, an Australian size 7, a European size 39/40, and a US size 9 all correspond to the same physical shoe.

Creating separate variants for each unit of measurement is unnecessary and inefficient. Variants should primarily represent distinct sellable products, not different unit representations of the same product.

Objective

The goal in this scenario is to implement a solution that empowers customers to select shoe sizes in their preferred unit of measurement while simultaneously minimizing the number of Product Variants, ensuring accurate inventory tracking, and simplifying integration with existing systems.

Proposed solutions

Instead of generating redundant variants, we propose the following approaches:

Product Attributes (Recommended)

This approach involves introducing dedicated Product Attributes for each unit of measurement, thereby enabling the storage of all size equivalents directly on the product itself.

size_au (Number): the primary Australian size (for example, 7).
size_us (Number): the equivalent US size (for example, 9).
size_uk (Number): the equivalent UK size (for example, 7).
size_eu (Number Set): the equivalent EU size(s) (for example, "39-40"). Here, a Number Set can store multiple values.
size_inches (Number): the equivalent length in inch (for example, 9.9 in).
size_cm (Number): the equivalent length in centimeter (for example, 25.1 cm).

The primary benefit of using this method is that even though it adds data to the Product, it uses lesser data as compared with the approach of creating 85 variants.

JSON Product Attribute (Less Recommended)

This alternative method involves storing size conversions within a single JSON object inside a text Product Attribute. Example values:

"{
  "sizes": [
    {"au_uk": 2, "us_can": 4, "eu": 35, "inches": 8.2, "cm": 20.8},
    {"au_uk": 2.5, "us_can": 4.5, "eu": 35, "inches": 8.3, "cm": 21.3},
    {"au_uk": 3, "us_can": 5, "eu": "35-36", "inches": 8.5, "cm": 21.6},
    {"au_uk": 3.5, "us_can": 5.5, "eu": 36, "inches": 8.8, "cm": 22.2},
    {"au_uk": 4, "us_can": 6, "eu": "36-37", "inches": 8.9, "cm": 22.5},
    {"au_uk": 4.5, "us_can": 6.5, "eu": 37, "inches": 9.1, "cm": 23},
    {"au_uk": 5, "us_can": 7, "eu": "37-38", "inches": 9.3, "cm": 23.5},
    {"au_uk": 5.5, "us_can": 7.5, "eu": 38, "inches": 9.4, "cm": 23.8},
    {"au_uk": 6, "us_can": 8, "eu": "38-39", "inches": 9.5, "cm": 24.1},
    {"au_uk": 6.5, "us_can": 8.5, "eu": 39, "inches": 9.7, "cm": 24.6},
    {"au_uk": 7, "us_can": 9, "eu": "39-40", "inches": 9.9, "cm": 25.1},
    {"au_uk": 7.5, "us_can": 9.5, "eu": 40, "inches": 10, "cm": 25.4},
    {"au_uk": 8, "us_can": 10, "eu": "40-41", "inches": 10.2, "cm": 25.9},
    {"au_uk": 8.5, "us_can": 10.5, "eu": 41, "inches": 10.3, "cm": 26.2},
    {"au_uk": 9, "us_can": 11, "eu": "41-42", "inches": 10.5, "cm": 26.7},
    {"au_uk": 9.5, "us_can": 11.5, "eu": 42, "inches": 10.7, "cm": 27.1},
    {"au_uk": 10, "us_can": 12, "eu": "42-43", "inches": 10.9, "cm": 27.6}
  ]
}"

Although this approach might seem like a compact solution, it presents several disadvantages:

Data type handling: requires custom parsing in your application because the size object is stored as a string.
Lack of validation: no schema validation is available for this field, increasing the risk of data inconsistencies and errors. Your application must handle data validation independently.
Limited search functionality: this attribute cannot be enabled for search operations.
Difficult management: viewing and editing the JSON data within the Merchant Center can be cumbersome. And you might need a Custom App or Views for a usable interface to manage the data within the Merchant Center.

Custom Object with Product Reference (Recommended)

This approach recommends storing size conversion data in a dedicated Custom Object, creating a single source of truth. Each shoe product then references this Custom Object by using a Product Reference attribute.

Benefits: eliminates data duplication and provides a centralized management of size conversions.
Considerations: requires reference expansion or an additional API call to retrieve the Custom Object data.

Frontend experience and Cart handling

After implementing one of the data storage solutions explained earlier, consider these key user experience aspects:

Product display: create a user-friendly interface, enabling customers to view and select sizes in their preferred units. Provide clear controls (for example, a dropdown menu) to switch between different units and display corresponding size values dynamically.
Cart and Order management: introduce a Custom Field on the Cart Line Item (for example, selectedSize) to store a customer's selected size and unit of measurement (for example, eu:40). This preserves the selected size information throughout the checkout process and in order confirmations. Use LineItemDraft and CustomFieldsDraft to populate this Custom Field during the add-to-cart process.

Order integration

A significant advantage of using Product Attributes or a Custom Object is the seamless integration with existing order processes and Enterprise Resource Planning systems. By maintaining the original SKU and variant structure, order synchronization remains simple. No complex mapping logic is required within the integration middleware.

Even if external systems require variant-level size attributes, these solutions provide the necessary flexibility. Both the base Australian size (size_au) and the customer's selected size (selectedSize Custom Field) can be easily accessed from the order record, simplifying integration and preventing data discrepancies.