代码改变世界

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

2012-02-10 23:48  颜超敏  阅读(5550)  评论(2编辑  收藏  举报

一、业务概述

# 交叉销售 Cross Sell

  • 定义

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

的"ESK ipad2鳄鱼纹皮套"。

  • 原则

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

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

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

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

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

# 上销售 Up Sell

  • 定义

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

品牌的产品给顾客。

  • 原则

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

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

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

  •  常见类型
    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数据库结构图 (右键点击下载)

  

颜超敏的电子商务博客,企业级电子商务软件系统研发顾问和资深Java架构师,通过本博客分享电子商务软件研发经验和Java架构设计和开发经验
广义的电子商务的范围很广,国际商会认为,电子商务是指对整个贸易活动实现电子化。从涵盖范围方面可以定义为:交易各方以电子交易方式,而不是通过当面交换或直接面谈方式,进行的任何形式的商业交易;从技术方面可以定义为:电子商务是一种多技术的集合体,包括交换数据(如电子数据交换、电子邮件)、获得数据(共享数据库、电子公告牌)以及自动捕获数据(条形码)等。 电子商务涵盖的业务包括:信息交换、售前售后服务(提供产品和服务的细节、产品使用技术指南、回答顾客意见)、销售、电子支付(使用电子资金转账、信用卡、电子支票、电子现金)、组建虚拟企业(组建一个物理上不存在的企业,集中一批独立的中小公司的权限,提供比任何单独公司多得多的产品和服务)、公司和贸易伙伴可以共同拥有和运营共享的商业方式等。