Customer-specific prices with Algolia

Hi guys,

I´m developing an open source plugin for Algolia and Shopware (https://github.com/synonymous1984/SwAlgolia).

My problem now is, that we have the following Scenario:

Product prices are calculated based on different parameters like combinations of customer ID, customer group, article group, manufacturer etc. So this means that (in theory) each customer can have his own, unique price for every product.

Especially the plugin structure of Shopware allows developers to decorate the default price calculation in any way they prefer - so the calculation can be differ in each installation in theory.

Some examples:

  • Customer A belongs to group B and the discount for product C is -10% if the customer belongs to customer group B
  • Customer D get´s a special price for product E (€ 5,00 instead of € 10,00)
  • All products in product group F have base price - 15% as default price

As you can see there are many different parameters which affect the real price. The finest granularity is product ID + Customer ID = Price X.

As it´s impossible to get all prices pre-calculated to an Algolia index (or many indices) the way I plan to go is to only send product data to Algolia and do the price calculation as server-side Ajax request as soon as the search-result returns from Algolia.

I´m not really happy with this solution but I haven´t found another way to go at the moment.

Maybe someone of you have a better or another idea how to solve this problem??
Thanks for the email @Raymond - I´ve moved my question from Stackoverflow here (http://stackoverflow.com/questions/41298931/customer-specific-prices-with-algolia).

Thanks in advance, best, Synonymous

3 Likes

We had/have the exact same problem and for and now I went with the exact same solution, using the PHP client to make the request and decorate the results to a custom api endpoint which is used in the application.

The use case in which I encountered this problem is a B2B webshop, an inhouse solution only being used for the company I work at. So I have some control and insights in how pricing is being handled in practise for a few years now. Seeing that you are creating a plugin for uses cases unknown to you the solutions I tried/thought of probably won’t satisfy your needs either, since it doesn’t scale all that well.

Since your are asking for other ideas besides better/cost efficient idea’s as well, a workaround that crossed our minds;

Our situation: an active product catalog of 7.5k products and ~5k unique customers. So a specific index per user, per product, comes down to 37,5mil records on Algolia.

Even though it is possible for each customer to have an unique price for each individual product, in reality afting grouping everything together there were only 34 unique product catalogs left.
In the situation as it was over the past years I could get away with just creating a unique index for each of these unique product catalogs and tying it to the applicable users. We would end up with an acceptable 255k records on Algolia.

This has some serious downsides;

  1. A change means that we need to fire 34 update queries to Algolia.
    In the current situation on average there are ~200 product mutations per day. So we waste ~210k of operations per month just keeping our stuff updated and then I am not even taking stock mutations into account.
  2. I have no idea what sales has in store for me tomorrow, they might wake up deciding that every customer deserves their own tailored price and then I end up with 5.000+ indexes.
  3. The overal implementation was to complex to maintain for my liking.
  4. Subscription fee’s might increase causing Algolia to loose its cost/benefit ratio for us.

A varation of the previous idea, treating each specific price as a unique product as it were and add an extra field with an identifier of the specific catalog for the user that is making the request.
Algolia allows for api keys that have filters attached to them, so then we would be able to just filter on that extra field we added.

The implementation was slightly easier/neater, but issues 1,2 and 4 remain.

In the end this problem will always exist if you end up in the situation where every user has its own price for each product, either way a record needs to exist for Algolia to lookup.

It ended up with a simple cost/benefit analysis for us; Paying $3.990 for custom pricing using the Algolia javascript library which is a little bit faster or paying $49 decorationg the results ourself using their REST API and taking the overhead for granted.

Maybe you/someone thinks of something great we haven’t thought of yet based on this.

If you do, please let me know :wink:

3 Likes

Hi Dirkzz,

I’ve reduced the idea to the two following solutions where the second one is a wish for the future:

  • Using Algolia Pony only for the auto-suggestion (search as you type) in the main search field where no prices are needed.
  • Algolia is able to add sind kind of server-side join logic and scripting logic which allows us to maintain product data on one side and discount information on the other and join them according to scriptable rules.

As I think that’s a big requirement for nearly every ecommerce site I hope Algolia is also thinking about a solution in the near future.

Cheers

1 Like

Hey Synonymous,

Thanks for the feedback. It’s something we have occasionally heard from customers and Dirkzz generally has the right idea: first look for the commonalities and then group prices based off that. Often you’ll find the the number of groups is much smaller and you can then bulk update the prices. Then on the front-end you grab just the price you’re looking for. You’ll still be able to utilize prices in that scenario.

For the server-side join logic–it’s not on the roadmap at the moment. Doing so would negate a lot of the pure speed that we get from building the indices ahead of time. With that said, it’s something we’ll certainly keep in mind for future product iterations.

3 Likes