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
Data Integration is the process of transferring retailer data into Apptus eSales Enterprise. Retailer data is usually derived from several sources such as an ERP (product stock and price data), a PIM (product and promotion data), a CMS (editorial data), and a CRM (customer data). The data format used for imports into Apptus eSales is XML. Before importing any XML into Apptus eSales, the data from the retailers' data sources must be transformed according to a defined data model.
A well-defined data model and XML transformation lays the groundwork to a successful integration with Apptus eSales to the retailer's site. The choices and decisions made while creating the data model will also affect how the XML data imports will be managed in the integration.
The data model is based on the retailer's business type, products, variants, and markets, and should support the business goals and needs of the retailer.
Data entity types¶
There are three main data entity types in Apptus eSales: Products, Categories, and Ads. Each entity type has a set of predefined/required attributes, as well as other attributes that can be configured during the Site Integration. The attributes tell Apptus eSales how to treat the data in that entity type in terms of search, sort, filters, and facets.
The product is the core data entity type. It is how content is mainly represented in Apptus eSales together with variants. Variants are items that represent a product but due to different characteristics or business reasons must be accounted for separately.
Categories are modelled as a tree structure that is defined during imports. There is always a root and all categories have an identifying parent category. Categories and products are tightly coupled as a category contains products and a product is a part of one or more categories. This relationship is also defined during the imports.
Ads are a way of managing banners and campaigns on a site that already has a completed Apptus eSales integration.
The product (with variants) and category data entity types are crucial to the data modelling while ads is recommended to work with at a later stage.
The data model is to be considered as the design specification of the XML that is to be imported into Apptus eSales. Modelling data entities appropriately is crucial for Apptus eSales to perform at its best and to deliver the desired data.
A key to achieving a good data model is to have knowledge of the desired business outcome. This will make it easier to decide what attribute set-up is needed for the different data entities, for example what needs to be a product or a variant, or how product stock is described.
As Apptus eSales use these attributes to construct relationships between products, the more it knows about a product the better. In general, the more high-quality data Apptus eSales have to work with the better the system will work, given that the data model is suitably defined.
Once a data model is defined, the retailer or their implementing partners must develop a method of exporting and transforming the data from the retailer data sources into XML for Apptus eSales to use.
For more information, see Data Modelling.
Products and variants¶
In the data model, a product can contain zero or more variants. Not all businesses need variants in their data model, but variants are useful when items in the retailer's PIM/ERP share many properties but differ with a few.
What should be a variant or not is commonly based on the business type of the retailer. In general, when using products and variants, the variants are the items that are displayed to the customer. For fashion, a recommendation is to treat colours as separate products and sizes as variants of the parent colour. For home furnishing, a couch of the same product series can have different number of seats and colours. The number of seats of a couch can define the couch as a separate product and the colour options as variants of that couch.
If products have variants, then the behaviour is tied to the variants and not the parent products as it is the variant the visitor interacts with.
Variants can be placed in two different ways in a data model. Either the variant is nested inside the product or it is a stand-alone entity that has a product key link that connects it to its parent product.
For more information, see Products and variants.
A market can be view as data containment area that separates behaviour data from different sites. A market can have several different locales for sites where multiple languages are needed. This, together with site currency and more, can be configured with the Apptus eSales Apps.
There are two main approaches that can be taken when modelling the product data with markets. One is to use a product on all markets, the other is to use one product per market. Each one has their advantages and disadvantages.
Using one product for all markets enables the sharing of visitor behaviour across different languages on that market. However, as all attributes for all markets and languages must be in one product entity, the mapping of product data to import templates becomes more complex. This approach is commonly only relevant and useful for retailers with extremely large product catalogues.
Using one product per market is an approach that allows for easier configuration. Behaviour connections that facilitate recommendations and product listings are segmented per market, but may result in problems where markets have multiple locales.
The different functions of the Apptus eSales apps are divided and managed by market.
A locale identifier usually consists of at least a language identifier and a region identifier e.g. English (en) and United Kingdom (GB) gives us (en-GB). This identifier tells Apptus eSales what language attribute text is written in.
Locales enables not only the use of language specific product information, but also synonyms for search, recommendations, and did-you-mean functions in Apptus eSales. Locales set on attributes and products are used for search, stemming, and synonyms while a locale set in a panel query is used for the alphabetical sort order in the returned result. In the Apptus eSales Apps the locale is used to manage synonyms.
For example, languages with special characters such as å, ä, and ö will be sorted differently if used in different locales. If a locale is not correctly set a visitor may see sorting they are not expecting.
For more information, see Locales and languages.
Attributes are a part of each entity type (products, categories, and ads) and are a way to tell Apptus eSales how to treat data in terms of search, filtering, and sort. Each entity type has a set of predefined and required attributes.
All entity type attributes can be used for search and filtering but only products support sorting. The attributes must be configured once they have been imported to be presented as results.
For more information, see Product and variant attributes.
XML data is imported into Apptus eSales through a post using the Web API. The post includes a unique Web API ID that is provided by Apptus, an import type and a request body consisting of the import XML. The XML must be encoded using UTF-8 and include the operations that is to be performed and all other data type related information.
Imports can be performed in three different ways; Full imports using the Clear and Add operations, Partial imports using the Add and Remove operations, and Partial Imports using the Update and Remove operations. Imports can also be scheduled in two different ways, either as batch based imports at a set time interval or as event based imports.
Each import type and schedule have its advantages and disadvantages regarding system performance and implementation difficulty. For example, a full import is easier to implement than an update and remove import, but the system performance is better when only updating data that has changed rather than updating all the data.
The same is valid for batched imports in comparison to event based imports. Batch based imports are easier to implement with high performance, but there will be a delay before product changes are visible on a site. Event based imports demand much more of the data model to avoid too many updates slowing the system down. However, if done correctly there is practically no delay of product updates on a site.
Implementation and management of imports is the responsibility of the retailer or their implementing partner.
For more information see Working with Imports.