Best practices

B2C vs. B2B pricing

Business-to-consumer and business-to-business models have very different pricing needs. In general, B2C tends to involve less complex pricing than B2B.

B2C businesses tend to use base prices with different characteristics defined. For example, they might have different base prices for different countries. B2C pricing also uses more product and cart discounting instead of tiered pricing. B2C sales are more driven by emotion than need, and promotions are more important. B2C pricing involves little complexity in base pricing with many active promotions.

B2B businesses, however, use more complex pricing models involving high precision and tiered pricing. For example, an electronic parts manufacturer might use high precision pricing to sell small parts at sub-cent prices, and tiered pricing to ensure their customers order in bulk. Promotions are not as important, as buying decisions are often made by a group rather than an individual.

Use prices as prices, not marketing

One of the most common pricing mistakes is using Composable Commerce prices outside of their intended use case. This could include:

• Using prices to store Manufacturer Suggested Retail Price, Recommended Retail Price, or Suggested Retail Price information.
• Implementing “Buy 2 get 1 free” scenarios using tiered pricing.
• Using prices to store discounts aimed at specific customer groups.

Price calculation is an expensive operation in Composable Commerce, due to the ability to store multiple prices per Product Variant and the complex price selection fallback logic. Therefore, prices should only be used to store actual purchase prices. Promotions should be modeled either as Cart or Product Discounts, and marketing information like Manufacturer Suggested Retail Prices should be stored as Attributes.

We can simplify this to the following rule: keep it simple. Only use Prices for pricing!

Always have a fall-back base Price

If Composable Commerce cannot find a Price for a Product, it will not be able to add that Product Variant into a Cart. Regardless of how you choose to price your products, you should always implement at least one Price in each currency you sell. This should not use scoping, tiered pricing, validity periods or other features. This will ensure that Product Variants can always be added to your Cart.

Use Product Discounts to show sale prices

We do not recommend using base pricing on a Product Variant when showing sale prices, due to the limit of 100 Prices per Product Variant. The better option is to use a Product Discount. It adds a special field to the Product Variant response, discountedPrice, which contains the discounted Prices for display in your storefront.

Keeping these best practices in mind will surely lead to you creating efficient and accurate pricing solutions for your business!

Example scenario: pricing efficiently

To illustrate the best practices described, let’s consider the following example.

An ecommerce business sells in three countries (Germany, England, and Denmark) each with their own currency. They sell a Product which has three Product Variants.

The product’s Manufacturer Suggested Retail Price (MSRP) for each country is as follows:

• DE: 49,99 EUR
• GB: 43.99 GBP
• DK: 369,99 DKK

The ecommerce business decides on a lower base price for each currency to sell the product at. We’ll call these the base price:

• DE: 44,99 EUR
• GB: 38.99 GBP
• DK: 329,99 DKK

The business also decides to implement a price tier: if a customer purchases 3 or more of the product in Germany or Denmark, or 4 or more in the UK, they receive a lower price as follows:

• DE: 39,99 EUR
• GB: 35.99 GBP
• DK: 299,99 DKK

An inexperienced price manager would set up these 9 monetary values as 9 Price objects, as follows:

As the example shows, this leaves an individual Product with a total of 27 Price objects, a huge amount of data to sort through when a Product is added to a Cart.

When selecting a Price for any Product Variant, Composable Commerce needs to evaluate each Price’s validity before selecting it. The more Prices we have the worse the performance when fetching a Price.

A more efficient way of setting this up would be to reduce the amount of Prices defined. You can do this in the following ways:

• Factoring out the Manufacturer Suggested Retail Price to an Attribute with type money.
• Using a combination of tiered and base prices for each currency.

Using this strategy, we end up with the following:

With one move, we reduce the total number of Prices from 27 to 18, increasing performance. Since each country uses its own currency, in actuality there’s only one Price available for each country, further improving performance. The two irrelevant Prices are automatically disqualified and the correct Price is then selected depending on the quantity being purchased.

We can extend this logic further when we think about pricing in the same currency for multiple countries. In Europe, many countries use a common currency, the Euro. Let's imagine a situation where we sell in three countries which use the Euro: Germany, France, and Spain. We want to sell our product in Germany and France for 44,99 EUR but in Spain for 42,99 EUR. We can do the following:

Instead of setting three base prices – one for each country – we can set a base price in Euros with no restrictions, and a base price for Spain only. If a customer is in Spain, Composable Commerce will show them the Spain base price. Otherwise, it shows them the Euro base price. The fallback logic in Composable Commerce allows us to define a base price, and then specify any exceptions to that base price as needed.

Test your knowledge