Data modelling is the process of defining what is the import format of entities into Apptus eSales Enterprise. To model the data, i.e. the eSales data entity types and their attributes, appropriately is crucial for eSales Enterprise to perform at its best while supporting a retailer's desired business outcome.
All retailers have product and customer data serviced from different systems. This data needs to be transformed and exported into an eSales ready format. What the best model is for a retailer depends on their business goals, product catalogue, multilingual needs, and more.
The decisions that must be taken for all data models are:
- What will be a product and what is a variant?
- What locale will be used and how?
- What attributes will be used for products in regards to search, sort, and facet navigation?
- How will products and variants be connected to categories and how will the category trees be designed?
Products and variants¶
What is a product and what is a variant is a core decision of the data model. This decision is commonly based on the business type of a retailer and what the actual SKU is. The key thing to have in mind when deciding this is that it is products that are shown in search results and recommendations, not variants. A good question to start with when deciding this is "What result would we want our visitors to see when searching for
For fashion retailers it is a recommendation to treat an item of a certain colour as an eSales product and its different sizes as the variants. Consider the question above using the search phrase
short sleeved top.
If colours are treated as variants the visitor would see a top in the colour of its best selling variant. A graphical implementation to allow a visitor to see all available colours of the product below the primary image is common. If colours are treated as products with sizes as variants the visitor would see a red top, blue top, and green top and so on. A graphical implementation of this approach is to show available sizes below the primary image. The best selling variant places the product in the result.
For media retailers, and retailers of electronic consumer products, the use of variants is more rare. These kind of products are often specification driven such as laptop computers and memory cards, or one of a kind by design such as a mobile phone or a console game.
Home furnishing and Do-it-yourself retailers usually have a wide variety in their product offerings that can range from coat hangers to kitchen appliances, and screws to garage doors. This wide range makes using variants suitable for many products. Following are a few examples of this.
- A coat hanger can be considered a product and its different colours as variants.
- The number of seats in a sofa distinguish them as separate products and their different fabrics and colours as variants of the individual products.
- A screw can be considered a product and its different sizes as variants.
- A garage door can be considered a product and its different dimensions and colours as variants.
Locales and languages¶
A locale is an identifier of both site language and region. The basic locale format usually consists of at least a language identifier and a region identifier e.g. English (
en) and Great Britain (
GB) gives us (
The locale is recommended to be set at the product level in an import file. Basically, the locale tells eSales what language all the attribute texts in the product are written in. This enables functions such as synonyms and alphabetical attribute sorting as well as define how attributes for filters, facets, and search are managed in regards to refinements such as word stemming and stop words.
Product and variant attributes¶
Properties that describe the product entities are called attributes. Some attributes are better to define at a product level, such as the name of the item, and some are better defined at a variant level, such as colour and stock level. All attributes in eSales must be configured in the eSales Manager before they can be used and an attribute can be configured for more than one use.
It is recommended to use as many common attributes as possible between the product types to minimise both configuration and the data model complexity. The retailer can use their own naming conventions for attributes with a few exceptions. See Data Entity Types for more information about reserved, mandatory, and recommended attributes and attribute restrictions.
Attributes that a visitor might search for should be configured as a search attribute. Common attributes to search for include product and brand names or titles, names of artists and authors, colours, product categories, items on sale or in campaigns, or product specifications and model designations.
A retailer with access to the search history of their visitors can utilise this data to build a product attribute model and select what attributes to use for search.
To optimise eSales performance attributes configured as filters are used. Similar attributes as for search are commonly used with filters. Additional attributes such as stock level, campaigns, price, size, product format, release date or upcoming products are also commonly used. Using release date as a filter attribute enables a retailer to create a product list sorted by new or old.
Filter attributes are not actively interacted with by visitors unless they are configured and used as facet attributes.
Facets allow for dynamic and contextually based multiple choice product filtering and navigation and is configured as a filter attribute. Both search results and category pages benefit from the use of facets.
What attributes to configure as facets is highly business and product type dependant.
|Business||Facet attribute examples|
|Fashion||brand, colour, price, product type, size, style, product type specific attributes (e.g. fabric, fitting, occasion, etc.)|
|Books||genre, format, language, age group, price, publishing date, publishing house, stock status|
|Music, Movies & Media||genre, media type, price, campaigns, stock status, rating|
|Electronics||brand, price, product type specific attributes (e.g. screen size, memory, power classification, connections, etc.), stock status|
|Home furnishing||brand, colour, price, material, dimensions, series, product type specific attributes (e.g. seating capacity, shape, mounting, etc.), stock status|
|Do-it-yourself||brand, price, colour, material, dimensions, series, product type specific attributes (e.g. treatment, capacity, power consumption, weight, etc.)|
Attributes used to sort products are needed when not using Apptus algorithms for relevance. Common attributes include price, product and brand names or titles, release date, popularity, and rating. Additional attributes are most often business dependant such as sort by author (books) or artist (music). Retailers can decide what sort attributes that are usable for the visitor.
Categories and navigation¶
Categories and category trees make up the foundation of the site's navigation and is imported into eSales. Products can be part of several categories and are coupled to them with a category reference attribute holding one or more category keys in a comma-separated list. To avoid over-categorisation, categories should be unique where possible.
Smart product and category breadcrumbs give visitors an easy way to keep track of where they are on the site. As a product can be part of more than one category in the same tree, eSales will personalise the breadcrumb by using session click data to determine what path the visitor has taken. If no relevant categories have been found in the session click data, the breadcrumb will default to the first category defined in the product attribute during the import of products.
Categories not only have user-defined attributes but can also have predefined attributes within their own namespace. This is to prevent name collisions with user-defined attributes.
Editorial content that visitors should be able to search for should be part of the data model. This type of content can include how-to information, locations of physical stores and their opening hours, and shipping information.
It is recommended to model editorial content as products with user-defined attributes. To avoid issues with product notifications and statistics when using editorial content, contact Apptus Support.
Export data model¶
Methods to transform a retailers data into eSales compatible XML must be set up when the structure of the data model is decided upon. This is part of the retailer's and/or their implementing partners' responsibilities during an eSales Integration.
When exporting products and variants it is generally recommended to use variants nested within products. All data that requires modifications must be modified before it is exported to XML. It is not recommended to include pre-formatted data in an export as this may result in post-formatting issues.
See Data Entity Types for more information about the file structures of products and categories.
Import into eSales¶
Importing data into eSales is a key action that has two conceptual parts, an import method and an import scheduling. The import method defines how an import of XML into eSales should be managed and the import scheduling defines when imports should be performed. For more information, see Working with Imports.
- The more data in eSales the better. Everything that should be found by a visitor using search and navigation should be in eSales.
- Use two price attributes for items, a selling price and a list price. This allows for easy changes in price when a product is on sale while retaining correct statistics for profit.
- If the cost of an item is available, include this as part of the attributes. Cost can be provided in the Secure payment notification, in which case the notification cost has precedence. It is used for calculating profit and for use with Exposure strategies.
- Do not include pre-formatted data, such as HTML, in an export.
This online publication is intellectual property of Apptus Technologies. Its contents can be duplicated in part or whole, provided that a copyright label is visibly located on each copy and the copy is used in conjunction with the product described within this document.
All information found in these documents has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither Apptus Technologies nor the authors shall be held liable for possible errors or the consequences thereof.
Software and hardware descriptions cited in these documents might be registered trademarks. All trade names are subject to copyright restrictions and may be registered trademarks. Apptus Technologies essentially adheres to the manufacturer’s spelling. Names of products and trademarks appearing in this document, with or without specific notation, are likewise subject to trademark and trade protection laws and may thus fall under copyright restrictions.CLOSE