The primary identification code on bindCommerce is the SKU (Stock Keeping Unit) code, but other codes are also collected such as:

• barcode: the barcode (e.g. EAN, ISBN, UPC, ASIN) is used to identify a product on the market through a uniquely recognized identifier (mind the SKU is our code for internal use)
• MPN: Manufacturer Product Number, is the code assigned by the manufacturer of the item
• Code used by the supplier

To manage particular cases, where the sku used by the seller is heterogeneous, bindCommerce can apply a "recoding SKU", thanks to which different 1:1 matches can be obtained on the various sales channels (both in the product publication phase and in the download phase orders).

The title of the product page has strategic importance for research and SEO positioning. In general it would be advisable not to use the same title on the various sales channels, and in particular it would always be better to use an original title for your proprietary eCommerce site, in order not to cannibalize the visibility on search engines.

The structure of the title can be different depending on the sales channel; some marketplaces provide guidelines on its composition (e.g. brand + product description + color + size).

The maximum length of the title is also different on the various marketplaces, and it would be better to exploit it in full, in order to insert as many keywords as possible, and facilitate research.

The extended description, depending on the sales channel, can only be "flat text" or written in HTML (with layout tags). As for the title, it would be optimal (from an SEO point of view) to be able to insert different descriptions for the various sales channels.

Thanks to the management of "alternative descriptions", bindCommerce allows you to manage different titles, descriptions and images between the various sales channels, as well as between the linguistic variants for the various target markets.

Alternative descriptions can be obtained in several ways:

• importing different descriptions previously generated outside bindCommerce (from CSV file, Excel, OpenCalc, Google Sheet, via API, FTP or from an existing site)
• by importing descriptions generated by the IceCat service
• processing data already present in bindCommerce, through the use of templates; the platform allows you to generate alternative descriptions by concatenating data already present, possibly normalized ad hoc
• requesting machine translation through Google Translate

Note that due to the use of filters, the product rework rules can be different for different item groups.

Your eCommerce site and the various marketplaces rarely adopt the same categorization. bindCommerce allows you to reconcile these different structures through special normalization configurations (correspondence between different category trees).

It will thus be possible (for example) to match the categories of your administrative management system, not designed for online sales, to those of the various marketplaces where you can present the products.

Another peculiarity of bindCommerce's multi-category management is the possibility of defining different trees, marked with tags, and deciding, for a specific sales channel, to use only the categories with a particular marking.
Thanks to the "massive recategorization" connector it is also possible to assign (or unassign) new categories to products based on other known characteristics for the product (e.g. words contained in the title, attribute value, assignment to other categories).

Attributes can be used for any purpose: for example filtering, describing, varying the products in the catalogue.

Certain attributes are used to generate variants of the same article. Let's think for example of the size or the color; when these attributes are used the "parent product" is not salable as it is actually an aggregator (not a real product). Its variants, which are offered for sale, are real products, sometimes with a barcode.

Other attributes, on the other hand, are useful for describing the items in the catalog in a schematic way, adding structured information (think, for example, of information such as the material, the country of origin, or other technical information).

All the attributes acquired by bindCommerce can be used to complete the product sheets on the sales channels (where they can sometimes be included in the search filters), as well as to filter the massive processing actions. For example, it is possible to apply a different template based on a "line" attribute, or choose to publish only products with marketplace attribute = 1 on marketplaces.

Thanks to the normalization function, bindCommerce can send alternative values to the sales channels to those stored in its database. Let's think, for example, in the clothing and footwear sector, of the need to convert the European size scale with that of the United Kingdom.

Starting from the values of the attributes already present, it is possible to obtain values of new attributes, by concatenating or replacing certain terms.

On the bindCommerce database images are stored as absolute URLs (http:// or https://). These can arrive "ready to use" or starting from temporary URLs, perhaps of inadequate size.

Through an internal processing process, bindCommerce can acquire images from external sources, resize them (maximum parametric width and height) and send them to a designated web server node.

Images can be marked with tags, which can define the type of image, and therefore any filters on their use (for example, the vertical tag could indicate vertically developed photos to be used on a particular marketplace).

Thanks to the derivative products function, bindCommerce is able to manage the following cases:

• Packs, i.e. products sold in different sales units (e.g. 1, 6 or 12 pieces)
• Kits composed of different items

In these cases, the price of the derivative product can be calculated automatically (if it is not pre-established) and its potential quantity, based on the stock of the basic products that make up the derivative.

During the transmission of the orders, these can include (at the choice of the seller) the derivative products (without transformations) or the basic products that make up the derivative sold.