四、人工维护模式

这是最为基础的模式，也是其它模式都必然会支持的功能。即使是一些看上去可以通过算法获得真实的数据

（如Also Buy）的交叉销售，在实际运营中也有人工维护数据的需要。一般而言，人工维护的数据总是在最上面/

最前面的，后面才是自动搜索/统计获得的数据。当然，如果结果集是定时搜索出并将关联持久化的，

那也可以再维护两类数据（人工维护+自动生成）的数据位置。

单纯人工维护方式设计比较简单：

•  关联类型：

  # 业务类型：交叉销售 或 向上销售

  # 二级分类：基于业务类型继续细分。

  # 关联模板ID：该类型在前台显示时是作为片段显示在产品详细页面，所以需要关联一个模板。

• 产品关联推荐

  # 排序号：人工调整，为空则通过ID排序。

五、人工维护 + 自动算法

如果只提供人工维护的方式，对于产品数据量大的网站，这类数据维护的工作量也会很大，而且在人工

未维护到的情况下，在前台的产品详细页面的这些关联推荐栏目下将没有显示（或者数量不足）推荐的产品，

这必然导致用户体验的不佳和营销的失当了。对于这种情况，则有必要引入自动搜索作为补充。

比如某个栏目下显示4个产品（页面模板设计决定的），如果没有人工维护，那么会根据该推荐类型

对应的算法搜索出4个产品来显示。如果人工关联了2个产品，则剩余的2个产品由自动的来补充。

从前面第一节的举例来看，读者也应该看出，产品关联推荐的不同类设计的数据来源比较复杂，搜索算法

也各有不同。比如Also Buy是根据订单+订单子项+当前产品关联查询得出，而Also View却根据产品浏览统计数据。

所以固化常见的若干条算法成了一种不错的选择，而且也能够满足大部分的业务。

基于前面第二节的表设计，调整一下关联类型表：

• 关联类型

# 是否自动：当该字段=Y时，表示该推荐类型支持自动算法。

# 算法配置：可以通过接口 + 若干实现（即策略模式）进行设计。

但如果需要对算法进行某种成都的配置，则可以在界面进行维护。

六、案例：Magento的基于规则推荐实现

基于规则来进行推荐，这个规则是自定义的，而不是硬编码。

至于自定义的灵活度能够支持到程度，则看系统的各类业务支持和规则数据的设计了。

目前实现了这种模式的我只看到Magento有，笔者用过，但感觉并不是十分的好，反而觉得是过分复杂了。

分为三部分：

• Rule Information：基础信息。包括名称/优先级/状态/适用于/有效期/最高限制推荐数量
  • Apply to：关联到系统预设的三大类推荐上（Relate Product/Up Sells/Cross Sells）
• Products to Match：即当前产品匹配条件。符合这些条件的产品，在它的详细页面中，这个推荐规则才会有效。
• Products to Display：在匹配的“当前产品”详细页面的该类推荐下会显示这些产品
• （也是通过规则来设置）

举例：比如在Apply to中选择了Up sells类型，那么在Products to Display中就可以设置为“

大于匹配产品价格110%的产品”，如图：

诚然，的确比较灵活，但笔者更喜欢直接在产品详细页面的“关联推荐”Tab页中设置

各推荐类型的关联产品，这样更加直观，

可以清楚的知道每个产品究竟会推荐那些产品。而不是如这样，通过规则推荐，对于运营也不知道系统

究竟会推荐那些产品给匹配的产品。

对于这种模式，magento并没有通过直接表来管理（估计是通过它的EAV结构来实现的），笔者尚未分析出。

而且笔者对这种模式也还没有一种很好的设计方案，所以暂时就不提供了。