Best Practices for B2B Implementations

When implementing Relewise for a B2B solution, there are a few things to keep in mind for an optimal integration. This article aims to help you get the most out of your Relewise services when using a B2B setup - including using the B2B features available in Relewise.

For the most part, a B2B implementation is similar to any other Relewise setup. You will want to follow the standard installation guide and the best practices overall, to ensure that you have an implementation that contains:

• Entity integration, either push or pull, which covers:
  • Standard data such as DisplayName, Prices (for Products), Category Paths.
  • Any data you want to be searchable (Product details, descriptions, pertinent variant data).
  • Any data you want returned in search or recommendation requests.
  • Any data you might need for meta reasons, such as integration date, entity creation date.
  • Any data you need to use for filtering, faceting, or merchandising, such as what Assortments the entity belongs to.
• Behavioral tracking of:
  • Entity views.
  • Add to cart events.
  • Orders.

With all of this implemented, you can begin to build the actual services that you want to use with Relewise, such as Search or Recommendations. These services build on top of the entity integration and the behavioral tracking, and it is within the implementation of the services themselves that the majority of the B2B specific features will be made relevant. Below are some things to consider, and how you should work with them.

Company Entities

Relewise operates with several different types of Entities, with Users standing out as the entity type that helps define a user's experience based on popularity and relevance. For Relewise customers using the B2B module, however, there is another layer built on top of this, namely the Company Entity.

Company Entities function similar to Categories for Products and Content Entities, by serving as a nexus for connections between other entities on a dataset. For the Category, it serves as a way to group Products or Content together. For Companies, it serves as a way to group Users together, and allow each User's behavior to affect the behavior of the other Users belonging to the same Company.

In essence, the Company entity allows for a scenario where one company has several different users performing actions and making purchases on your website. By linking these separate users to the same Company entity, you are able to let each User have their own behavior intact, while simultaneously causing the behavior of their shared Company users to influence what they are shown and recommended. Similar to how a User's own behavior will shape the Relevance of their search results and recommendations, with a Company entity in play, the other Users belonging to that Company will also have an effect on what the individual user sees. This helps steer them in the same direction, and reinforces the kind of business that they are likely to make.

Tracking a Company ID is similar to tracking a Category, wherein you may specify it as part of the user object during a UserUpdate tracking event. This could, for instance, happen during user creation, where the user will specify what company they belong to. The Company Entity will be implicitly created if it does not already exist, and the User will remain associated with the Company without the need for additional tracking. That is to say, you only have to track a User's Company association once, and the association will be saved in Relewise.

Classifications

Classifications allow you to tailor your searches and recommendations to the type of customer that is using your site, which can be invaluable for B2B scenarios. For instance, a hardware store that caters to several different professions can use Classifications to tailor the relevance of search results to better match the user's profession - plumbers will get plumbing equipment, while masons will get products related to masonry. This works by identifying the user's type (their Classification) as part of the user registration process, and assigning that value to the User object in Relewise. Once the Classification has been noted on the User, all behavior associated with this user goes into the classification "bucket", and all relevance is drawn from that same bucket.

In essence, this allows you to partition your users into smaller sub-segments, where the behavior is more directly relevant to the user's own experience. A classic use of Classification is with Country, where it may be assumed that consumer behavior differs between, e.g., Danish and Spanish users. For B2B cases, being able to segment your users into smaller sub-segments allows you to more directly cater to their individual needs and tendencies.

Using classifications is contingent on you being able to identify the salient parts of the User's Classifications. Relewise does not inherently know any of this data, nor can it be inferred, so it is up to you to gather the relevant data - such as business type, country, region, etc. - from the user directly, and send it to Relewise as part of the User object. Typically, this is done during the creation of an Authenticated User, or by asking the user upon entering the storefront what kind of business they want to conduct.

Be aware that a user's Classification may change, if you send a new Classification identifier to Relewise. Please refer to the article about Classifications for more info on how to work with Classifications in detail.

Assortments

Similar to Classifications, Assortments can be used to specify what products are visible to specific customer segments. This can be implemented alongside Classifications to specify via Filters that a certain User segment is allowed or disallowed from seeing certain product groups. It can also be used in Merchandising or Relevance Modifiers to boost or bury product groups instead, allowing you to handily group products belonging to a specific trade together under a specific assortment, and push their relevance for the associated User Classification group.

Assortments are frequently used in scenarios where a site serves both B2C and B2B customers, to help delineate between products available to one user group or the other.

Prices and Data Objects

If your B2B solution relies on differentiating prices between customer groups, you may create a Data Object that contains the price for each customer group, and retrieve the relevant data during your Search or Recommendation requests. By default, Relewise operates with just two price fields, namely ListPrice and SalesPrice. We do, however, support additional price fields by using the Multicurrency data type, which can let you integrate prices across different countries or markets.

Say you have three customer groups: Hotels, Restaurants, and Cafes. Each of these operate in the Eurozone as well as in the UK, leading you to have two currencies, EUR and GBP.

Using a Data Object, you may create a list of prices that covers all three customer groups, each one represented in both relevant currencies. This can then be queried when you perform a Search or a Recommendation, to retrieve the correct price for the relevant customer group and currency, ensuring that your customers always see the price that is relevant to them. Here, we might correlate customer group with Classification. If you want to add additional data to each customer group in this way, you will want to use a Data Object List instead, which can contain as many pieces of customer-group specific data as you want.

Click here to see an example of the Data Object

DataObject data = new(new Dictionary<string, DataValue?>()
  {
    ["Hotel"] = new MultiCurrency(
      new Money(new Currency("GBP"), 34),
      new Money(new Currency("EUR"), 40)
    ),
    ["Restaurant"] = new MultiCurrency(
      new Money(new Currency("GBP"), 34),
      new Money(new Currency("EUR"), 40)
    ),
    ["Cafe"] = new MultiCurrency(
      new Money(new Currency("GBP"), 34),
      new Money(new Currency("EUR"), 40)
    )
  });

An example of a Data Object that correlates customer types and prices.

Note that if you want to be able to merchandise on your User group-specific prices, we recommend that you integrate each separate customer group's prices as individual Data Keys, rather than collect them in an object, as it will make it substantially easier to work with them in the Merchandising interface that way. Also note that the Merchandising interface cannot create rules based on data found in Data Object Lists at all.

Popular Products by Line Revenue

By default, the PopularProducts recommendation type shows the products that have been sold the most within a given time frame, typically 30 days. This is useful for most B2C setups, but for B2B use cases, Relewise has developed the ability to instead perform the popularity calculations based on Line Revenue.

Specifically, this means that the system looks at the amount of revenue generated by the products within the timeframe, as specified in the order tracking events, and uses it to determine what counts as popular. This is useful in scenarios where you might have products that are small and cheap, but sell in large quantities, versus products that are larger and more expensive, but sell in lower quantities.

This setting is defined in the recommendation call itself, by changing the basedOn value to LineRevenue.

SimilarProducts

Most Relewise implementations of Recommendations will focus primarily on the PopularProducts, ProductsViewedAfterViewingProducts, and PurchasedWithProduct logics. This fits neatly into most B2C customer journeys, but may not be sufficient for B2B scenarios. Since all of these recommendation types are predicated on customer behavior, there can be a benefit to instead implementing a recommendation type that directly compares products to one another, to offer a discerning B2B customer the best options. For this, we have the SimilarProducts Recommendation type.

Similar Products works by defining a series of traits, based on Data Keys on the products, that should be used as the basis of comparison. This can be anything that you want, and is limited only by what you find useful; for some, it will be the size and material of the product, such as metal sheets, screws, etc. For others, it may be things like color, size, Product Category, display name, or any other product feature you can think of.

When you define the parameters for comparison, you also define the weight with which the engine should compare them. So, for a garment shop, product type may be weighted higher than material, material may be weighted higher than color, and color may be weighted higher than price. But all of these parameters will be taken into account, and play a role in determining the products that are ultimately displayed in the recommendation.

Because Similar Products is completely powered by product data, it does not consider a product's popularity or direct user relevance. This may help newer or lesser-known products to rise to the top, if they are more directly comparable to the product a user is looking at. This can also be useful for offering direct product substitutes or alternatives for users, to assist in driving additional sales.

To learn more about Similar Products recommendations, we recommend that you read our comprehensive guide here.