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

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 data key 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 (categoryPath)
• Brand
• Display Name (multilingual)
• Pricing (multicurrency)
• 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 data keys 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](../support/faq/index.md#entity-data---are-data keys-case-sensitive).

Category Paths

Products and content in Relewise can belong to multiple categories, to mirror the way they might exist within a webshop or Content Management System. This association between entities and entity categories are created through the implementation of Category Paths onto the entity itself.

Notably, category paths belong to the entity, and not to the entity category. This means that while an entity can refer to its parent category/categories, the categories cannot be queried to return what entities exist within them. In order to identify entities by their associated categories, a ProductCategoryId or ContentCategoryId filter should be used within a productSearch or productQuery request (or their content equivalents).

An entity can have as many or as few category paths as necessary. Implementing category paths allows you to perform filtering and faceting on your searches, build breadcrumbs, and more.

A category path in My Relewise

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 faceting?
• 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

Product Variants are treated exactly like a regular product as far as Relewise is concerned. The only difference is that a Product Variant is tied to another product, and so carries both the superordinate product's ProductId, as well as its own VariantId. The Data Dictionary for Product Variants, 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 Product Variant 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 Use case

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 faceting?
• 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 data keys 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](../support/faq/index.md#entity-data---are-data keys-case-sensitive).

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 product_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.

Orphaned Categories

Product and Content Categories are maintained independently from the products and content pages that refer to them. As a result, a category can be both Enabled and Orphaned at the same time.

A category is considered orphaned when it is no longer associated with any products or content through a native CategoryPath. An enabled category can therefore be orphaned even though it is still visible in My Relewise.

Ordinary data fields do not create category associations

Storing category IDs or parent IDs in ordinary data fields does not create a native relationship between the entities. Datakeys such as product_parents or parents can still be used as regular data, but they do not prevent the referenced categories from being considered orphaned.

Use CategoryPaths when the relationship should be understood and maintained as a category association by Relewise.

Cleanup Lifecycle

By default, an enabled category that remains orphaned for 90 days is disabled. If the category remains disabled for another 90 days, it is deleted.

In other words, the default lifecycle is:

1. The category becomes orphaned.
2. After 90 days, the category is disabled.
3. After a further 90 days, the disabled category is deleted.

Any update to the category resets its inactivity period, including an update that resends the same data. Updating a category does not, however, create an association with a product or content page. If the category should remain active because it is part of the entity structure, the relevant relationship should be supplied through CategoryPaths.

Deleted Categories Cannot Be Recovered

When a category is deleted, its associated tracking metrics and entity relations are also removed. This data cannot be recovered.

Preventing Unexpected Cleanup

To prevent a category from being treated as orphaned:

• Include it in the native CategoryPaths of the relevant products or content pages.
• If the category is intentionally maintained as a standalone entity, resend the complete set of standalone categories regularly so their inactivity periods are reset.
• Do not rely on category IDs stored in ordinary data fields to preserve category associations.

When moving products or content between categories, make sure that the complete set of category paths is restated. This removes obsolete relationships and preserves the relationships that should remain.

Re-enabling a Category

If an orphaned category has been disabled but not yet deleted, first restore its intended CategoryPaths or resume its regular standalone updates. Once the category data is correct, re-enable it using the relevant Product Category or Content Category administrative action.

Restoring the data before enabling the category prevents it from remaining orphaned and entering the cleanup lifecycle again.

If the category has already been deleted, it can be created again by importing it or by reintroducing it through a CategoryPath. Previously deleted tracking metrics and entity relations will not be restored.

Brands

Brands in Relewise are self-living entities created as part of product imports. See Provide Entities for product import options. They group related products for filtering, faceting, and recommendations, and are visible in My Relewise.

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 data key. Consult the list below for use case 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 My Relewise.

Datakeys are Case Sensitive

Most data keys 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](../support/faq/index.md#entity-data---are-data keys-case-sensitive).

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.

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.