# Product Recommendation
**URL:** https://discuss.tryton.org/t/product-recommendation/1328
**Category:** Feature
**Tags:** sales
**Created:** [April 15, 2019, 4:28pm UTC](https://discuss.tryton.org/t/product-recommendation/1328 "2019-04-15T16:28:08Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 15, 2019, 4:28pm UTC](https://discuss.tryton.org/t/product-recommendation/1328/1 "2019-04-15T16:28:08Z")
## Rational
Product recommendation is a powerful selling tool. The goal is to upsell addition product.
There are many ways to design the recommendation feature (e.g. based: on product in cart/sale, on current product, on browsing history, search result etc.). But we can see that most of the case are based on two main data:
- products related to a product
- product popularity
## Proposal
I propose to design two tables to collect those data:
`product.product.related`
It stores the ordered related products for a product.
- `origin`: `Many2One` to `product.product`
- `target`: `Many2One` to `product.product`
- `weight`
- `manual`: `Boolean`
It is filled by a cron job using the result of a customizable SQL query.
The job delete all non manual record before inserting new one.
By default, the SQL query count the number of times a couple of products are present a confirmed sale order. The count result is used to fill the weight.
(The query must be customizable to allow other couple input like browse history etc.)
A `One2Many` is added on `product.product` to list the related products ordered by weight descendant.
`product.product.popularity`
- `product`
- `popularity`
It will also be filled by a cron job using a customizable SQL query which returns the count per product on the sale line (at least confirmed).
It will be the base of a `popularity` `MultiValue` field (which could be extended to support company or web-shop criteria).
The period on which the cron job operate will be a configuration parameter.
In order to be fast, both jobs will perform at SQL level (skipping) the ORM.
I propose also to have the same tables but for product category: `product.category.related` and `product.category.popularity`.
## Implementation
- [Recommend products on sale (#11528) · Issues · Tryton / Tryton · GitLab](https://bugs.tryton.org/issue11528)
---
### Author:  [@albert](https://discuss.tryton.org/u/albert)
#### Post date: [April 15, 2019, 5:09pm UTC](https://discuss.tryton.org/t/product-recommendation/1328/2 "2019-04-15T17:09:11Z")
> [@ced](#):
>
> It stores the ordered related products for a product.
>
> - `origin` : `Many2One` to `product.product`
> - `target` : `Many2One` to `product.product`
> - `weight`
> - `manual` : `Boolean`
I would add the possibility of having more than one relationship. This would look like:
- `origin` : `Many2One` to `product.product`
- `target` : `Many2One` to `product.product`
- `weight`
- `manual` : `Boolean`
- `type`: `Selection`
The reason is that in many cases you want to show customers not only products with one kind of relationship but several of them. For example, Amazon shows:
- Sponsored related products
- Products browsed by customers that browsed this product
- Products purchased by customers that purchased this product
Or for one of our customers we implemented (in the same website):
- Products usually purchased together
- Similar products
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 15, 2019, 6:03pm UTC](https://discuss.tryton.org/t/product-recommendation/1328/3 "2019-04-15T18:03:58Z")
> [@albert](#):
>
> The reason is that in many cases you want to show customers not only products with one kind of relationship but several of them. For example, Amazon shows:
>
> - Sponsored related products
> - Products browsed by customers that browsed this product
> - Products purchased by customers that purchased this product
I do not see the point. Why does the customer need to know based on what you are recommending. It does not chance the behavior to select or not. More over, it does not have to be true neither.
> [@albert](#):
>
> Similar products
They will not be filled the same way. Indeed such link is more about category.
---
### Author:  [@albert](https://discuss.tryton.org/u/albert)
#### Post date: [April 16, 2019, 9:43am UTC](https://discuss.tryton.org/t/product-recommendation/1328/4 "2019-04-16T09:43:54Z")
> [@ced](#):
>
> I do not see the point. Why does the customer need to know based on what you are recommending. It does not chance the behavior to select or not.
For me it is pretty clear that it is not the same that some recomendations are based on sponsorization or not.
The products recommended because they were purchased by people that purchased the product will probably link to products that complement this one. For example, some headphones for an iPod.
Whereas “browsed by those who browsed” will probably bring you to competing products. Not necessarily in the same category. Or with finer granularity than category-level.
> [@ced](#):
>
> More over, it does not have to be true neither.
Of course, but I don’t see why that is important here.
Building a successful online shop is a lot about trial and error and seeing what works best. The fact that top salers like Amazon, Zalando and many others use not one but several recommendation lists most probably means that it is something that helps improving sales.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 16, 2019, 4:14pm UTC](https://discuss.tryton.org/t/product-recommendation/1328/5 "2019-04-16T16:14:16Z")
In this case, I would recommend to create a new model which inherit from this one as they will not be filled the same way nor at the same time.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 24, 2022, 6:00am UTC](https://discuss.tryton.org/t/product-recommendation/1328/6 "2022-10-24T06:00:13Z")
This topic was automatically closed after 12 days. New replies are no longer allowed.