Leverage Variants and Availabilities

The way you define your commerce catalog data will determine which fields of the catalog object types you create can be associated to a filter when using facets.

When the structure of your queried catalog is simple (i.e., contains only products), then understanding which fields are available for facets is straightforward. You can create facets on all facet-enabled fields populated by items identified as products in the catalog.

However, if the structure of the queried catalog is more complex (i.e., contains products, variants, and/or availability channels), facets can affect multiple object types (see Facet Association).

Tip

Ensure that a given field on which you want to create a facet is only defined for one type of object in the catalog.

This can be verified in the Content Browser (platform-eu | platform-au). For example, to test the color field, in the content browser search bar, enter @color and ensure that there’s only one value in the Object Type facet (e.g., Variant)

Facet Association

The Facet Association tab lets you quickly view which facetable field names exist for each object type. The percentage shown represents the ratio of each field by object type. By hovering over the percentage shown, you can see the number of documents that contain the associated field name.

Note

Depending on your specific use case, if the percentages deviate from what you expect, this could be an indication that your data isn’t properly structured.

In advanced use cases, your data structure may require having the same facetable fields on multiple object types. For example, you may want to use the same language field across all your items. In this case, the value @language would need to appear on all object types (Product, Variant, and Availability) to return matching results.

To access the Facet Association tab:

  1. On the Catalogs (platform-eu | platform-au) page, click the catalog used by your search interface, and then click Edit in the Action bar.

  2. Select the Facet Association tab.

    You can edit the string options or advanced settings by selecting the desired field and clicking Edit Field.

The catalog automatically detects the fields that you can use to generate facets and checks for updates every 15 minutes. The last update time appears at the bottom right of the Field Association tab in your catalog.

Retrieve the Available Variant and Availability Fields

Use the GET endpoint to retrieve the variant.fields and availability.fields for a specific catalog. The variant and availability fields you’ll see in the response are fields you can create facets on, which are automatically selected by the catalog.

Example

You’ll get a response like this one:

{
  "availability": {
    "availableSkusField": "availableskus",
    "fields": [
      "availabilityid",
    ],
    "idField": "productid",
    "objectType": "Availability"
  },

// ...

  },
  "variant": {
    "fields": [
      "productsize",
      "width"
    ],
    "idField": "sku",
    "objectType": "Variant"
  }
}

Product Filters for a Specific Channel

When filtering on products, users may want to locate a specific store that carries a certain product. Using the method of your choice, your site will need to determine which stores are the closest to the user. You must then retrieve the identifier associated to this store that matches the value from your catalog availability identifier field.

You can leverage this store identifier (i.e., store-123) in your search interface to filter on products that are only available in this store. Ensure you have properly configured your availability channels. The identifier must match the value set in the catalog’s availability identifier field.

Example

You’ve configured your catalog with the field availabilityid as the availability.idField in the following fashion:

{
   "name": "Multiple Channel Catalog",
   "product": ...,
   "variant": ...,
   "availability": {
       "idField": "availabilityid",
       "availableSkus": "availableskus"
   }
}

You then pushed availability items where the availabilityid field contains a unique identifier (i.e., store-123):

 {
    "availabilityid": "store-123",
    "lat": 45.4975,
    "long": 73.5687,
    "availableskus": ["001-red-8_wide","001-red-9_wide","001-red-10_wide","001-red-11_wide", "001-blue-8_wide"],
    "objecttype": "Availability"
 }

With both your items and catalog on the same availabilityid, you can therefore add the @availabilityid==store-123 query to filter on all products that are available in this store.

Availability Constraints

If you have any availability constraints defined in your availability channel and in your data format from the source, it means you may want to filter on that specific channel. For instance, in a business-to-business scenario (B2B), we commonly see this availability constraint as being a price list, group, or entitlement. In a business-to-consumer scenario (B2C), this availability constraint could be a store.

Important

For this filter to work properly, your search interface must use a catalog configured with multiple channels.

Example

The following code adds a filter in the query to only retrieve products that are available in your channel:

 <script>
   document.addEventListener('DOMContentLoaded', function () {
     var root = document.body;
     Coveo.$$(root).on('buildingQuery', function(e, args) {
       args.queryBuilder.advancedExpression.addFieldExpression('@availabilityid', '=', [<AVAILABILITY_ID>]);
     });
   });
 </script>

Support Multiple Prices per Product

It’s important to understand that Coveo can filter on product data from other related objects.

Dynamic pricing occurs in commerce catalogs with multiple dimensions, where an availability will determine who has access to an item, and at what price. Products and variants can be present in multiple availability items (stores or buyer groups). This can happen in B2C, and more commonly B2B scenarios.

In the following scenario, we will consider a 2-dimensional pricing structure that contains products and availabilities.

Example Scenario

Your business sells office supplies to 500 retailers. Each retailer will have a specific price for each product. When a client performs a query, they should only be able to see a specific price for the product at a given location.

In a commerce environment, you would commonly see a 3-dimensional relationship between a product, its variants, and their availabilities. To simplify, we will ignore the product-variant relationship, and consider both object types as a product that will vary depending on the catalog level.

Solution 1: Average Price

You have a list of products and each have an average price. The average price will be used for sorting and facets, while the exact price will be shown to the user. You fetch the correct price from the Commerce platform when the page renders.

Average Price Example
Pros Cons
  • Simple to implement.

  • Works well if you have a small variation in price.

  • Possible lag to get the actual price to appear.

  • Additional logic required at indexing time to calculate the average price.

  • If the price variation is large, this can create confusion.

Solution 2: Dictionary Field on the Product

Adding a dictionary field on the Product object that contains the key (availabilityid) with value (price).

Dictionary on Product Example
Pros Cons
  • Always displays the exact price for the product.

  • The facets created for sorting the product will be precise, because of the catalog Related Object Attribute Filtering feature.

  • Only the price for the current availability is returned in the payload.

  • No query lag as the price to display is extracted from the dictionary.

  • You’ll need to index your price information as a dictionary field. In other words, in your data structure, you will need to have your price information at the product level.

What's next for me?