Why is product data structuring important for a Marketplace?
The construction of a taxonomy is a central topic in the operation of a Marketplace. It is the reference structure for product categorization in a Marketplace. In other words, when the seller is onboarded, he uses this structure to create his catalog and then activate his products (or services) by posting his offers (prices/stocks).
The Marketplace Experts, Émilie Queste, Functional Consultant and Guillaume Bienfait, Product Manager at Marjory offer you their advice on taxonomy in a Marketplace context. Having both participated in the construction and evolution of Marketplace projects, Émilie and Guillaume offer advice on the classification of Marketplace product sheets.
Once the seller is onboarded, he must add his catalog in the Marketplace back-office. The Marketplace catalog must be clearly structured to allow third-party sellers to easily integrate their products. This categorization has several advantages such as:
- Allowing new sellers to quickly understand the product categorization used by the operator
- Making the “ordering of products in the expected categories more reliable
- To facilitate e-merchandising
However, the Marketplace operator must be careful about how he structures the product categorization, especially if he has his own offers. In a retail context, for example, it must be broad enough to allow sellers to sell products that are different from the Marketplace’s own offer : if the categorization corresponds exclusively to the operator’s own offer, third-party sellers may not find categories for their products.
Also, a very demanding categorization will have an impact on the effective integration time of the sellers’ catalogs, which can lead to friction and seize the time-to-market of the products on the front-end.
On the other hand, if the information requested by the taxonomy is not sufficient, the operator will have to optimize the information to ensure that the products are displayed correctly on the Marketplace front end. In this case, the integration time will also be impacted.
To avoid wasting time, our experts have several tips for you.
First of all, the categorization should be as stable as possible. That is to say, it should not be modified regularly. This will prevent the operator from having to manually rework the products and request changes from the merchants or their connectors.
Furthermore, the categorization must be different from the sales structure used on the marketplace’s front office. Indeed, the latter must be flexible and adaptable (creation of sale categories for instance), whereas the categorization must remain stable.
Finally, it is advisable to think of your taxonomy on a maximum of 3 levels: the product family, the category and the sub-category. You can also use the taxonomy of large Marketplaces as an example when creating your own.
As far as the quality of the product sheets is concerned, the best thing to do is to make an exhaustive list of the characteristics requested from the sellers. This will avoid problems with incorrect data or lack of harmonization between product sheets.
Finally, there is the question of the responsibility of the parties involved. A Marketplace is a space made available to third-party sellers, offering them visibility and traffic.
The operator cannot modify the product data without risk. Indeed, if the Marketplace operator modifies a product record, the responsibility is automatically transferred from the seller to the Marketplace operator. If a modification of the data by the Marketplace is necessary, it is recommended to formalize it by contract with the seller.
Points to remember:
- The creation of your product structure is an important step, which will allow you to optimize your work and the time it takes to put the sellers’ catalog online.
- You can use an existing taxonomy that your sellers already know and master to simplify the onboarding of new sellers in the Marketplace.
- You can automate all these steps, thanks to our partners’ solutions, already pre-integrated in Marjory.