Filtering and sorting based on a generic price

A single price is communicated in the feed, typically a retail price or “starting from” price. These prices are used for sorting and filtering.

In case of sorting on price, this can result in a slight difference because we sort on retail-price, while the customer can have a different price.

The actual customer specific prices on the product tiles can be retrieved and displayed on the e-commerce platform.

Filtering and sorting based on segmented pricing

Customers are divided into groups, every group gets a dedicated price attribute:

<item>
  <id>TSH0123</id>
  <name>Shirt Colin</name>
  <!-- omitted for brevity -->
  <attributes>
    <attribute>
      <name>price_group_1</name>
      <value>10.50</value>
    </attribute>
    <attribute>
      <name>price_group_2</name>
      <value>10.75</value>
    </attribute>
    <attribute>
      <name>price_group_3</name>
      <value>9.99</value>
    </attribute>
  </attributes>
</item>

These attributes can be used in dedicated filtertemplates and sort options (or added to a generic filtertemplate, the frontend should filter out the non-relevant attributes).

For every group a dedicated sort option should be created. The platform should target the right dedicated sort option template.

Note: this is a pretty complex setup, which can be a nightmare for maintenance. We recommend keeping this to a maximum of around 5 - 10 segments.

Do not use price-based filtering or sorting

The easy way out. Many of the B2B companies we serve, choose for this option where price filtering and sorting are omitted due to the complexity involved.

Display of the pricing is still possible, as that is part of the ecommerce platform.