Experience Cloud Product Description needs work

[trieloff]

I'm working on the product schema for experience cloud right now and I need some help in making sure the descriptions are accurate.

1. Is this the schema for a product variant or a master product?
2. What is the difference between a product variant and a master product?
3. Are these the only product relationships that matter?
4. Should product be auditable, i.e. would it make sense to include the date when the product record was created or last modified?
5. Should category, department, and fabrication be controlled vocabularies or free text as they are right now?
6. Given that the name and description is to be localized, would it make sense to include the language in the schema?

[mhaack]

Looking at the product schema with the commerce hat on there are some more things which I think require some clarification/adjustment:

7. attributes like size, gender, brand etc should not be hard defined and moved to an attribute list
8. attributes must support meta data (like units)
9. attributes must be localized

[trieloff]

@mhaack thanks for the feedback.

attributes like size, gender, brand etc should not be hard defined and moved to an attribute list

Attributes that are common enough should be hard defined, although a separation of customer-visible and customer invisible attributes might make sense. We do have the ability to define custom attributes through the XDM extensibility mechanism, but would benefit from defining things that are common to enough products. Right now, it looks very fashion-centric, and we might come up with a more extensive list of attributes that are common.

attributes must support meta data (like units)

Do you think the approach we have taken for Metrics should be copied here?

attributes must be localized

This is tying back to two questions:

A. What is the difference between a master product and a product variant? One viewpoint could be that every product variant is localized in exactly one language. B. #19 – @lrosenthol proposed a solution, not for localizing XDM itself, but for localized expressions within XDM

[mhaack]

Attributes that are common enough should be hard defined, although a separation of customer-visible and customer invisible attributes might make sense.

I agree, using a flexible attribute list to me makes most sense here. That is also the approach almost all commerce vendors follow. Regarding customer-visible vs. customer invisible, this is any important use case I agree. I think this could be done as a meta information setting to flag each attribute. But I would not make it mandatory.

For attribute meta using the Metrics approach seems logical to me, as long as we not limit it to units only and support all kinds of meta attributes.

master product to product variant relationship

For the master product to product variant relationship there are different view points. Thats why we think it is very flexible for customers. One idea is to always have the product object and >1 variant. So even simple products like a water bottle always have one product variant. T-Shirts of course have multiple variants. With that approach also more complex product types like product bundles, product sets, subscriptions, etc. could be implemented. But in any case the consumer of that data can always be sure there is the product and it has minimum one product variant. Implementing clients is much easier since they do not need to add checks what kind/flavor of product type they get, the can treat all the same.

[mhaack]

The product data model we use for the CIF commerce services we are currently building on I/O Runtime is described here:

• Swagger UI https://git.corp.adobe.com/pages/CQ/commerce-ccif-api/ (Scroll down to the data models at the end of the page)
• Swagger JSON https://git.corp.adobe.com/pages/CQ/commerce-ccif-api/swagger.json

[cdegroot-adobe]

Good discussion. This is a starting subset of properties and patterns that we see looking at customer implementations in different areas. Product variant is not used by all customers we see, so we cannot enforce that pattern on them. The model as it currently stands does support a master product, so allows a master:variant option as well as a sale-able master which soem customers do use. I do support tho proposal to list common attributes that are used depending on the product characteristics and making those standard.

[mhaack]

@cdegroot-adobe, I'm working with @martinbuergi to suggest some minor changes for the attribute list.

[mhaack]

@martinbuergi as discussed #310 is the PR for the updated product data model.

@trieloff, @cdegroot-adobe please have a look.