---
title: Test your product content type with real data
---

> Agent instructions:
> **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown.
>
> - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version.
> - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt).

## Test your product content type with real product data

Once you've finalized the content type design and gathered stakeholder approval, have your editors test it with real product data before full-scale implementation.

You can either use the admin UI to define the product-related content types necessary for testing, or you can use the [Management MCP server](https://docs.kentico.com/documentation/developers-and-admins/api/management-api.md) and build the content types in the XbyK database programmatically. The following image shows how a user provides a JSON definition from the [contemt modeling server mcp](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-mcp.md) , and the agent uses the [Management MCP server](https://docs.kentico.com/documentation/developers-and-admins/api/management-api.md) tools to analyze XbyK instance, including existing _admin form components_ and _data types_, before constructing the new content type in the admin interface.

![Creating content type via Content Type Management API](https://docs.kentico.com/docsassets/modules/test-product-content-type-with-real-data/agent_chat_building_content_types_via_content_management_api.png "Creating content type via Content Type Management API")

Ask editors to create sample products using real catalog data instead of placeholder text or simplified examples. Have them build complete product pages in the website channel, including selecting manufacturers, assigning categories, uploading images, and configuring all relevant fields. Have editors test variant-creation workflows by creating products with multiple sizes, colors, or attributes to ensure the process is intuitive and efficient.

The following screenshot of _Product SKU_ in admin UI and shows how editors add products to the system using collapsible _reusable field schemas_ that keep the form organized and easier to navigate. Product taxonomies, such as categories or materials, also stored as reusable field schemas, which simplifies querying and ensures consistent structure across the catalog. Product _manufacturer_ references a separate content type, while _product variants_ are defined via a dedicated content type.

![Sample Product SKU admin UI](https://docs.kentico.com/docsassets/modules/test-product-content-type-with-real-data/reusable_product_sku_content_item.png "Sample Product SKU admin UI")

Hands-on testing uncovers workflow issues, such as _confusing field labels_, _missing guidance text_, or _illogical field ordering_ that that may not be evident in diagrams or documentation, but slow down data entry.

Use this testing phase to validate that your product content type truly supports all identified business scenarios and doesn't introduce unexpected friction. Identify workflow pain points where editors get confused, make mistakes, or require excessive clicks to complete simple tasks. Ask developers to verify that _reusable schema fields_ appear correctly in content queries and that relationships between content types work as expected when retrieving data for display.

Address any issues discovered during testing. Refine field configurations, enhance editor guidance, adjust content structures, and even programmatically simplify complex workflows as needed.

Testing with real editors helps prevent costly rework, particularly after the product catalog is populated with hundreds or thousands of products. You can adjust the content model programmatically after the fact, but it creates additional work and costs that could have been easily prevented.

## Summary: Design scalable product model

Modeling _product SKUs_ in Xperience by Kentico requires careful planning of how products are stored and structured. The decisions of where to store products, how to model variants, which pricing patterns to implement, and how to organize related content (such as manufacturers and categories) will directly impact editor efficiency and the ability to scale.

Begin by understanding your commerce requirements and consulting standards like [Schema.org](https://schema.org). Model fields that repeat across different content types using _reusable field schemas_ to prevent duplication. This will help you create a flexible foundation that supports both current needs and future growth. Keep in mind that content modeling is an ongoing process that gets better with testing, validation, and regular feedback.

Xperience's [Content modeling MCP server](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-mcp.md) will help you prototype the content model and define output in machine-readable format. You can use it to create product model diagrams, validate them with key teams including developers, commerce managers, and SEO specialists, then test with real product data before full implementation.
Focus on building a solid foundation with the core _ProductFields_ and _ProductSKU_ _schemas_, rather than striving for perfection initially. Implement _variant approach_ that aligns with your store strategy, and choose pricing patterns that fit your current business model. As your commerce needs evolve, Xperience’s flexible content modeling lets you expand and refine your product structure without requiring a complete rebuild, ensuring your product catalog grows alongside your business.