一、业务概述

# 交叉销售 Cross Sell

• 定义

商家根据客户已经选择的产品推荐其它产品。例如在客户浏览苹果iPad时（或者加入购物车后），推荐适合iPad配套

的"ESK ipad2鳄鱼纹皮套"。

• 原则

交叉销售的原则是基于客户在购买当前产品的前提下购买更多产品。这些产品有可能是相关的（如附件类产品/配套产品），

也有可能是基于统计或者从众的购买建议（如Also Bought，即购买了该产品的顾客也购买了...。We guess you would like...

我们猜你可能会喜欢...）

 　　交叉不会推荐同类和相似的产品，而是推荐一些完全不同的产品和服务（如周边产品）。

• 常见类型

1. 1. Also Bought：购买了当前产品的顾客也购买了...。通过分析订单信息获得。
   2. Also View：浏览过当前产品的顾客也浏览了。
   3. View and Bought：浏览了该产品最终购买了。通过分析浏览数据和订单数据获得的数据，并显示百分比。（见京东）
   4. 配件型产品：如在单反相机下面显示电池/三脚架/镜头等。
   5. 互补型产品：如在外套产品下显示裤子/鞋子等凑成合适的一套（需要较高的搭配水平）
   6. 经常一起购买的/最佳拍档：关系很紧密的两个或者多个产品，通过分析订单获得。并非产品包，只是一种推荐。（见卓越/当当）
   7. 和你兴趣相似的顾客还关注了：当当的一种类型。我觉得倒不如改成关注了当前产品的顾客还还关注了。

# 向上销售 Up Sell

• 定义

商家基于客户选定的产品推荐更好的产品（对客户或者对商家自己）。例如客户浏览某款平板电视时，推荐更高型号/进口

品牌的产品给顾客。

• 原则

向上销售的原则是替换式，即建议购买我们推荐的，而不是当前浏览的。向上销售如果不是基于足够的统计数据，一般不好

处理。只有在熟悉当前客户的各种消费喜好的前提下，这样的推荐才比较精准和不会引起客户的不快。

向上推荐会推荐同产品分类下的或相似的产品，但更贵的或者对商家更有价值（推广/利润高）的产品。

•  常见类型

1. 1. 同品牌的更高档产品：由于是同品牌的推荐，兼顾了顾客的品牌忠诚的可能性。
   2. 不同品牌的更高档产品：一般是推荐更好的品牌，但如何界定“更好”需要考虑。
   3. 价格相似：这里不一定是向上了，但由于满足替换原则，所以也归入向上销售类。
   4. 替换推荐：当当前产品缺货时，推荐其它有货的相似产品。（减少因为缺货导致顾客流失）

      实现交叉销售和向上销售（或其它一些扩展的业务类型）的关联推荐常见有三种模式，下面分别做阐述：

二、人工维护模式

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

交叉销售，在实际运营中也有人工维护数据的需要。一般而言，人工维护的数据总是在最上面/最前面的，后面才是自动搜索/统计获得

的数据。当然，如果结果集是定时搜索出并将关联持久化的，那也可以再维护两类数据（人工维护+自动生成）的数据位置。

      人工维护的表设计最为简单，如果关联推荐类型也是固化的，甚至只需要一张“产品关联推荐表”即可。

      如果希望推荐类型可以灵活定义，那么可以增加一张表“产品关联类型”表，用于方便维护推荐类型。

注：只设计了核心和常规的字段，读者可自行扩展。

三、人工维护+固化的自动搜索

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

在前台的产品详细页面的这些关联推荐栏目下将没有显示（或者数量不足）推荐的产品，这必然导致用户体验的不佳和营销的失当了。

对于这种情况，则有必要引入自动搜索作为补充。

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

显示。如果人工关联了2个产品，则剩余的2个产品由自动的来补充。

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

是根据订单+订单子项+当前产品关联查询得出，而Also View却根据产品浏览统计数据。所以固化常见的若干条算法成了一种不错的选择，

而且也能够满足大部分的业务。

      基于前面第二节的表设计，在产品关联推荐类型表增加一个字段：是否支持自动。

 当该字段=1时，表示该推荐类型支持自动算法。只有系统预设的推荐类型该字段才可能是1（系统预设的不一定支持自动）

四、前面的方式 + 基于规则推荐（Base Rule）

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

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

      目前实现了这种模式的我只看到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结构来实现的），笔者尚未分析出。而且笔者对这种模式

也还没有一种很好的设计方案，所以暂时就不提供了。

       有兴趣的读者可以研究一下Magento的Demo和它的文档：

       http://www.magentocommerce.com/wiki/modules_reference/english/enterprise_targetrule_adminhtml/targetrule/index

B2C电子商务系统研发——对交叉销售和向上销售的产品关联推荐分析和设计

       这份是它的官方提供的数据库结构图，读者也可以参考一下：Magento V1.3.2.4数据库结构图 (右键点击下载)