Data integration¶

Data integration is the process of transferring retailer data into Voyado Elevate 3. Retailer data is usually derived from several sources such as an ERP (product stock and price data), a PIM (product and boost data), a CMS (editorial data), and a CRM (customer data). The data format used for imports into Voyado Elevate is XML. Before importing any XML into Voyado Elevate, 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 Voyado Elevate 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 Voyado Elevate: 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 Voyado Elevate 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 Voyado Elevate 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 modeled 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 Voyado Elevate 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.

Data modelling¶

The data model is to be considered as the design specification of the XML that is to be imported into Voyado Elevate. Modelling data entities appropriately is crucial for Voyado Elevate 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 Voyado Elevate use these attributes to construct relationships between products, the more it knows about a product the better. In general, the more high-quality data Voyado Elevate 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 Voyado Elevate 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 colors as separate products and sizes as variants of the parent color. For home furnishing, a couch of the same product series can have different number of seats and colors. The number of seats of a couch can define the couch as a separate product and the color options as variants of that couch.

If products have variants, then the behavior 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.

Markets¶

A market can be view as data containment area that separates behavior 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 Voyado Elevate 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 behavior 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 catalogs.

Using one product per market is an approach that allows for easier configuration. Behavior 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 Voyado Elevate apps are divided and managed by market.

Locales¶

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 Voyado Elevate 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 Voyado Elevate. 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 Voyado Elevate 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¶

Attributes are a part of each entity type (products, categories, and ads) and are a way to tell Voyado Elevate 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.

Importing data¶

XML data is imported into Voyado Elevate through a post using the Web API. The post includes a unique Web API ID that is provided by Voyado, 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.