Product and Content Data

Without products or other content (collectively known as entities), there would be nothing to search for or recommend, so naturally this is important data. Most likely, you already have this data on your website, PIM or ERP, and Relewise will need to be given an 'up-to-date version of this (sent via the API or the feeds feature in My relewise).

To get started with providing Entity Data via the API, click here

A Note on Disabled Entities

All entities in Relewise can be disabled, typically by using an Administrative action (ProductAdministrativeAction or ContentAdministrativeAction). A disabled entity will not be shown in Relewise results, and as such will never be returned in Search or Recommendations powered by Relewise.

It is important to note that disabled entities will be removed from Relewise after a period of time, to save on storage space. For this reason, you should never disable an entity that you are not willing to lose. Keep in mind that deleted entities also lose their associated tracking metrics, such as sales statistics, entity relations etc. This data, once deleted, cannot be recovered.

Disabling an entity should be used as a "soft delete", and not as a way of removing entities from Relewise results while keeping the entity stored. Relewise is not a data storage space, and we take active steps to keep the data we save to a minimum - to ensure that our prices remain as low as possible.

To keep certain elements out of your search or recommendation results, you should use a merchandising rule to filter out entities you do not want shown. For rules that need to target more than a few entities, adding a datakey such as filterOut = True to the entities can allow for quick and easy maintenance of the filter list, entirely within your PIM or CMS system.

Product Data

Product data is the products you sell. We do not need every single detail about a product, only the subset that is relevant to your type of searches and recommendations. Common examples of such metadata are: Name, Id, Product Group, Variant, and Brand, but you can send and configure any kind of data. For example, if you sell wine, country, wine type, and year would be relevant extra data.

Our product model supports the following

• SKU
• Variants
• Categories
• Brand
• Display Name (multi-lingual)
• Pricing (multi-currency)
• Assortment information
• Data (Key/Value) - Value can be a number, a string, a boolean, a currency, a data object, or any list of the former.

You can read more about the types of data we support here.

Datakeys are Case Sensitive

Most datakeys in Relewise are case sensitive. Ensure that your data adheres to this case sensitivity to avoid unnecessary issues during implementation.

To learn more, click here.

Importing Products

When importing data into Relewise, it is advisable to include as few fields as possible to ensure optimal performance. To help ensure that you get the correct data imported, consider these criteria when evaluating the data fields on your products:

• Should the field be text searchable?
• Should results be able to be filtered on the basis of this field?
• Should results be able to be sorted on the basis of this field?
• Is the field necessary for facetting?
• Is the field necessary for boost/bury rules or similar Merchandising rules?
• Do you need this field to be returned in results from Relewise (e.g. for displaying on the website)?

If you can answer yes to at least one of these, the field should be included. Otherwise, leave it out.

Variant Data

ProductVariants are treated exactly like a regular product as far as Relewise is concerned. The only difference is that a ProductVariant is tied to another product, and so carries both the superordinate product's ProductId, as well as its own VariantId. The Data Dictionary for ProductVariants, however, is identical to a non-variant Product, and should contain the same kind of data that you want to be used for search and recommendation purposes.

A subset of the data inserted in the ProductVariant Data Dictionary can be selected as Specification data through the Search Index configuration for variants. Specifications are designed to identify the dimensions of a variant product, such as size, color, vintage etc. Specifically, Specifications are designed to correlate between products, allowing for cross-referencing on the basis of variant-specific data.

Example of Specifications Usecase

A User is looking at a Red shirt in size Medium. Specifications allows Relewise to recommend the User other shirts of the same color and size, ensuring that they are more likely to find a product that fits what they want to buy.

Content Data

Content data covers your content pages, such as blogs, articles, support pages etc. Integrating this data into Relewise allows it to be presented in your user's searches or recommendations, similar to how it is done for products.

Content Data can contain a number of different types of data depending on what you need. When importing data to Relewise, consider what is the least amount of fields you can import, and forego the rest.

• Should the field be text searchable?
• Should results be able to be filtered on the basis of this field?
• Should results be able to be sorted on the basis of this field?
• Is the field necessary for facetting?
• Is the field necessary for boost/bury rules or similar Merchandising rules?
• Do you need this field to be returned in results from Relewise (e.g. for displaying on the website)?

If you can answer yes to at least one of these, the field should be included. Otherwise, leave it out.

Datakeys are Case Sensitive

Most datakeys in Relewise are case sensitive. Ensure that your data adheres to this case sensitivity to avoid unnecessary issues during implementation.

To learn more, click here.

Categories

In Relewise, categories are self-living entities similar to products and content. Typically, categories are created during the import of products and content pages, where you can specify the category of each entity using the CategoryPaths data field. With category paths specified on the entities, Relewise is able to create the categories and their respective hierarchical structures automatically.

Since searching is rarely relevant for Categories themselves, the most typical data for categories is simply an Id and a DisplayName. However, categories can theoretically contain as much data as any other entity, should it be relevant.

Click here for examples on importing Categories

Example of importing multiple CategoryPaths on a Product via API

If you import your entities via the API, make sure to use a Multilingual value, to ensure that the DisplayName fields are properly searchable.

product.CategoryPaths.Add(new CategoryPath(
	new CategoryNameAndId("4", new Multilingual(
        new Multilingual.Value(english, "Audio"))),
	new CategoryNameAndId("8", new Multilingual(
        new Multilingual.Value(english, "Headphones"))),
	new CategoryNameAndId("16", new Multilingual(
        new Multilingual.Value(english, "Ear Buds")))
));
product.CategoryPaths.Add(new CategoryPath(
    new CategoryNameAndId("2", new Multilingual(
        new Multilingual.Value(english, "Smartphones"))),
	new CategoryNameAndId("74", new Multilingual(
        new Multilingual.Value(english, "Accessories")))
));

Example of importing multiple CategoryPaths via Product Feed

When importing products via a Google Product Feed, be aware that Google only allows 5 repeated fields of prouct_type per product.

<g:product_type>Audio > Headphones > Ear Buds</g:product_type>
<g:product_type>Smartphones > Accessories</g:product_type>

Often, you will want to use Categories for faceting or filtering. For instance, you may want to filter results so that you only get products that are contained within a certain category to make a category page.

var request = new ProductSearchRequest(
    new Language("da-dk"), new Currency("dkk"), 
    User.Anonymous(), null, null, 0, 10);

    request.Filters.Add(new ProductCategoryIdFilter("8", CategoryScope.Ancestor));

Category information can furthermore be accessed directly from Products and Content as a part of its display properties if you specify that a request should return this. You can access the PathFromRoot from any of the CategoryPaths that will be a part of the ProductResults to get the breadcrumbs to that product.

Be aware that moving categories or moving entities within/between categories can prove tricky, because the relation between entity and category is maintained across changes. This means that if an entity is moved permanently from one category to another (or simply removed from a category), it requires an explicit decoupling of the category from the entity. In other words, the entity's relationship to its individual categories must be restated in its entirety to ensure that the removed category is properly removed.

Data Types

Relewise supports a number of different data value types, namely: String, StringList, Double, DoubleList, Boolean, BooleanList, Multilingual, MultilingualCollection, Multicurrency, Object, and ObjectList.

For optimal performance and to minimize bugs during your implementation, ensure that you are using the right data type for each datakey. Consult the list below for usecase examples, or reach out to us for help.

Read a detailed description of our Data Type here

After integrating your entity data, you can find it in the Entities section of MyRelewise.

Datakeys are Case Sensitive

Most datakeys in Relewise are case sensitive. Ensure that your data adheres to this case sensitivity to avoid unnecessary issues during implementation.

To learn more, click here.

Making Entities Searchable

Once your entities are imported into Relewise, it is important to remember to configure the Search Index with the chosen data fields. By default, a blank Search Index will only return hits on Id and DisplayName for Products, Variants, and Content Pages. Please refer to our in-depth guide for configuring the Search Index for a detailed walkthrough of the system.

Pushing and Pulling Data to Relewise

When integrating your entities into Relewise, consider the method by which you wish to do so. You can choose to either Push data via our API, or have Relewise Pull data from a product- or content feed.

Pushing Data to Relewise via API

Pushing data via the API is the recommended method of providing entity Data to Relewise.

Doing so offers you greater control of the data flowing into the system, is faster, and is potentially cheaper in licensing costs. Any time you need to update your entities with new data keys for use in your search and recommendations, it is made easier with the Push approach, since you control the exact detail of what is being sent to Relewise.

Any time you need to update your entities with new data keys for use in your search and recommendations, it is made easier with the Push approach, since you control the exact detail of what is being sent to Relewise.

Pulling Data to Relewise via Feed

Pulling data via a Feed entails providing Relewise with a data feed, from which we then retrieve data at regular, agreed-upon intervals. As a result, this imparts a delay between when entities are updated in your feed, and when they are updated in Relewise.

Relewise innately supports RSS 2.0 feeds, e.g. Google Shopping feed, as well as Shopify feeds. Other custom feeds can also be used, but will require billed work on our part to build the integration to consume your custom feed.

If you are interested in integrating your custom feed, please contact us for an estimate of time and cost to do so.