解构电商O2O用户端“背后”的逻辑.docVIP

解构电商O2O用户端“背后”的逻辑 　　之前和不少刚毕业的产品同学交流过，用户端是他们十分偏向选择的产品线。可在实际的工作过程中，由于不太了解中后台的情况加之逻辑上没有那么成熟的经验，很容易出现界面设计完成后无法和中后台的相关同学交流实现。所以用户端产品也需要了解基础的业务逻辑规则和关联。今天我们就分享下电商、020用户端“背后”的逻辑。 　　 　　用户端的内部构造 　　用户端一直有着迷之尴尬的地位，既充当门面却深受各个系统的“牵连”。所有系统的最终表现都依赖于用户端的展现，所以说用户端是产品价值的最终体现。我们来看下用户端内部都有什么。 　　 　　电商的用户端主要功能是提供购买和商品展示，并能够协助用户进行个人服务管理。从用户的阶段来划分，主要分成售前、售中、售后三个阶段。其中个人信息的管理属于贯穿整个使用过程。 　　售前环节：实现用户购买前的浏览和检索。 　　首页（对接CMS、商品、类目、推荐、促销、广告、搜索） 　　频道页（对接CMS、商品、类目、推荐、广告） 　　专题页（对接促销、商品、CMS、广告） 　　搜索结果页（对接搜索、商品、推荐、广告） 　　搜索分类页（对接类目、商品、搜索、推荐、广告） 　　发现页(对接商品、搜索、推荐、促销) 　　售前环节主要功能是完成商品的展示,页面的信息布局和UI是此类模块的首要功能。由于电商平台商品、类目众多，所以数据多是由负责规则整合的系统完成数据处理，然后通过页面、内容生成系统完成前台的展示工作。 　　售中环节：实现用户的购买 　　售中环节也叫购买流程，是实现用户从下单到完成支付的整个过程。这个流程是整个电商体系中最重要的环节。其中交易、订单和支付系统负责这个环节的核心逻辑。 　　商品详情页（对接商品、促销、推荐、广告、CMS、会员） 　　购物车（对接商品、促销、交易、推荐、广告），其中库存部分可放入商品或交易中合并计算，也可单独由库存系统提供处理。 　　结算页，也叫订单确认页（对接商品、促销、交易、订单、会员） 　　收银台，也叫支付页（对接支付、订单） 　　支付完成页，也叫订单完成页（对接订单、推荐、广告） 　　（1）购物车 　　购物车环节要考虑库存是否需要做占用。购物车做预占库存可以第一时间通知用户库存状态，但有可能出现较多占用后但未生成订单的情况。而生成订单后占库存则能保证订单和库存匹配率最大，但用户在下单后才被告知无库存，用户体验相对较差。 　　常规做法会在购物车环节设置数量阈值，库存小于阈值显示用户库存紧张。然后在下单环节完成扣减库存的情况。如果是秒杀或者是类似唯品会的抢购模式，则可以在购物车扣减库存，增加倒计时（如15分钟）提示提高用户抢购感。 　　促销金额的计算也是购物车需要考虑的主要逻辑之一，由于商品详情页都是单品信息，所以组合促销的金额计算是在购物车体现的。 　　另外，作为电商的“近亲”020领域的购物车相比传统电商处理方法有所差异。020的购物车原则上很多是不跨店铺销售的，所以购物车是存在于单个店铺中且以浮层的方式展示。一般来说为避免对于服务器造成压力过大的问题，不是所有的添加商品的操作都是请求后端服务，在逻辑处理上为了保证一致需要前后端都考虑逻辑统一的问题。 　　（2）结算页 　　结算页可以说是电商用户端比较复杂的页面之一。这里面涉及到配送逻辑判断，送达时间计算，运费计算，订单计算及分摊等。 　　 　　配送逻辑判断：根据提供的配送方式结合仓配情况和移仓的逻辑来判断来预计送到的时间。此部分的物流配送的路程情况也会影响运费的计算逻辑。当无法单仓满足或者移仓满足时，有可能需要拆多个包裹从不同的仓发送。 　　运费计算：根据后台设置的运费模板来计算实际应该收取的运费。运费模板是指设定好的一套运费规则，比如满XX收多少等。 　　订单计算：订单计算主要涉及到交易单各个子单之间促销优惠的计算和金额分摊。 　　优惠计算主要包括优惠券和促销活动的金额计算。一般情况后台会有一定的计算优先级，比如计算促销活动的金额，完成后再看是否满足优惠券的满减金额。计算时需要考虑促销范围，如商家还是全场。 　　金额分摊，电商的支付类型发展到如今是越来越丰富。信用卡、汇款、支付宝、微信、白条、积分、礼品卡等等各种各样。考虑到订单逆向（整单退，部分退）的情况，需要将所有支付的金额包括优惠券都分摊到每一个商品上，以便退款时可以保证金额不错。分摊计算有两个要注意的事情，一个是各项支付方式退款的优先级，先退什么在退什么。原则上先退成本低的，在退成本高的。二是当分摊时金额除不尽的时候多余的部分如何分摊，小数后三位的时候四舍五入还是直接舍掉。这个规则要和后端、报表保持一致，避免出现一分钱误差的乌龙。 　　（3）收银台 　　订单生成后要通过支付系统完成支付操作，所以收银台的主要对接系统就是支付系统。对接第三方支