Enabling sorting by Price when Price is fetched dynamically
I am working on a Coveo Hive result page where we want sorting by price. The problem is prices are being pulled in real time dynamically and we cannot index prices. I assume this should be common problem and am looking for some approaches. Has anyone here solved this problem or have approach to do that?
This question is quite complex because the use case differs from company to company, so I will try to explain some of the concepts and one way to solve them.
Those are based on experiments I have done on my side to support this. If you have a better idea, go for it!
Indexing Prices in a field and pushing them often
Say your prices are only updated twice a day and you have 10 000 products. Rebuilding your index twice per day will be more than enough to keep your fields up to date. If your products are changing individually, you can also re-index the documents individually.
The following recommendations assume that you _at least_ have a base price in your index (say `@baseprice` field. There is no way for an index to give you a specific order of results if you don't have the data in your index.
This one can be achieved either client-side by adapting the `baseprice` and multiplying by a factor, or by recomputing the value using a query function expression.
Specific rebates on some items
This one is a little trickier. For instance, you might want to have a category of product that has a 20% rebate for your own employees. The trick is to index a field `employeerebate` and set it to a value like `20` or `0.2`
Then, you can leverage a query function that computes the total price with the following expression:
`$qf(function: '@baseprice * @employeerebate', fieldName: 'finalprice')`
This logic can be reused for customer-specific prices or region-specific rebates.
You could combine all of the features above to get an _estimate_ of the price (and show it as such) until you actually fetch the real price in the background and update it.
Done well, this will give you a "sort by price" that is _mostly_ accurate, and you will get the benefits of your dynamic pricing model.
Most users will want to sort by Relevance by default, so for the others that want to sort by price, maybe the estimate would be fine.
In a more advanced fashion, you could even detect major discrepancies and updates those items back in the index in real time!
In the best case, a search index would need to replicate *the exact same price logic* as the commerce engine to be able to sort its own results by price.
Calling the external API would be way too expensive in time for both the commerce engine and the search engine, so there is no easy way to get an "always dynamic" price, for any engine.
I hope that this will cover some of the topics that you wanted to implement, but I want to stress that it is not easy, regardless of the index used for it.