之前和不少刚毕业的产品同学交流过，用户端是他们十分偏向选择的产品线。可在实际的工作过程中，由于不太了解中后台的情况加之逻辑上没有那么成熟的经验，很容易出现界面设计完成后无法和中后台的相关同学交流实现。所以用户端产品也需要了解基础的业务逻辑规则和关联。今天我们就分享下电商、020用户端“背后”的逻辑。
用户端的内部构造
用户端一直有着迷之尴尬的地位，既充当门面却深受各个系统的“牵连”。所有系统的最终表现都依赖于用户端的展现，所以说用户端是产品价值的最终体现。我们来看下用户端内部都有什么。
电商的用户端主要功能是提供购买和商品展示，并能够协助用户进行个人服务管理。从用户的阶段来划分，主要分成售前、售中、售后三个阶段。其中个人信息的管理属于贯穿整个使用过程。
售前环节：实现用户购买前的浏览和检索
- 首页（对接CMS、商品、类目、推荐、促销、广告、搜索）
- 频道页（对接CMS、商品、类目、推荐、广告）
- 专题页（对接促销、商品、CMS、广告）
- 搜索结果页（对接搜索、商品、推荐、广告）
- 搜索分类页（对接类目、商品、搜索、推荐、广告）
- 发现页(对接商品、搜索、推荐、促销)
售中环节：实现用户的购买
售中环节也叫购买流程，是实现用户从下单到完成支付的整个过程。这个流程是整个电商体系中最重要的环节。其中交易、订单和支付系统负责这个环节的核心逻辑。- 商品详情页（对接商品、促销、推荐、广告、CMS、会员）
- 购物车（对接商品、促销、交易、推荐、广告），其中库存部分可放入商品或交易中合并计算，也可单独由库存系统提供处理。
- 结算页，也叫订单确认页（对接商品、促销、交易、订单、会员）
- 收银台，也叫支付页（对接支付、订单）
- 支付完成页，也叫订单完成页（对接订单、推荐、广告）
配送逻辑判断：根据提供的配送方式结合仓配情况和移仓的逻辑来判断来预计送到的时间。此部分的物流配送的路程情况也会影响运费的计算逻辑。当无法单仓满足或者移仓满足时，有可能需要拆多个包裹从不同的仓发送。
运费计算：根据后台设置的运费模板来计算实际应该收取的运费。运费模板是指设定好的一套运费规则，比如满XX收多少等。
订单计算：订单计算主要涉及到交易单各个子单之间促销优惠的计算和金额分摊。
- 优惠计算主要包括优惠券和促销活动的金额计算。一般情况后台会有一定的计算优先级，比如计算促销活动的金额，完成后再看是否满足优惠券的满减金额。计算时需要考虑促销范围，如商家还是全场。
- 金额分摊，电商的支付类型发展到如今是越来越丰富。信用卡、汇款、支付宝、微信、白条、积分、礼品卡等等各种各样。考虑到订单逆向（整单退，部分退）的情况，需要将所有支付的金额包括优惠券都分摊到每一个商品上，以便退款时可以保证金额不错。分摊计算有两个要注意的事情，一个是各项支付方式退款的优先级，先退什么在退什么。原则上先退成本低的，在退成本高的。二是当分摊时金额除不尽的时候多余的部分如何分摊，小数后三位的时候四舍五入还是直接舍掉。这个规则要和后端、报表保持一致，避免出现一分钱误差的乌龙。
售后环节：提高信息透明和服务体验
- 订单详情页
- 订单列表页
- 在线客服
- 订单列表一般会保留三个月左右的用户显示数据，而用户端的删除不是物理删除只是订单上打标记而已。
- 在处理数据时考虑到历史数据较多，部分O2O的APP会使用历史订单数据和当日订单数据分开的读取的方式。
- 订单详情一般会有再来一单的功能，电商系统只需要判断是否存在可售卖的SKU即可。而O2O则需要增加判断区域属性。
- 在线客服要考虑是否是对接第三方应用，在嵌入对方的SDK时一些通用的标准要符合满足（比如IPV6）。另外对方SDK包是否会对自己APP的大小造成较大影响也需要注意。
个人中心：服务中转站
个人中心作为用户的统一服务中心，里面承载了所有涉及用户资产和服务的信息。大多数是信息汇总查看的页面（如我的订单、我的积分、我的优惠券等）。 这里强调一个小的细节，APP用户端有时候排查问题需要了解用户的基本信息，比如版本号，手机型号。用户的反馈很容易出现信息误差，他们大多会说已经是最新版了。所以获取版本信息的渠道可以在个人中心中。我以前的一个经验可以给大家借鉴。在意见反馈自动增加版本，手机型号信息回传，或通过关于APP的部分让用户一键复制以便提供给客服进行排查问题。用户端的“亲属关系”
用户端作为“门脸”，和各个系统有着错综复杂的关系，让我们看下他们之间的关系是如何。
在整个电商系统体系里面。用户端需要面对众多系统，而这些系统的数据又相互依存，他们之间通过API进行传输对接。
直接对接系统
页面系统- CMS系统
- 广告系统
- 交易系统
- 支付系统
- 订单系统
- 搜索系统
- 推荐系统
- 促销系统
- 会员系统
- 客服系统
间接对接系统
- 库存系统
- 商品系统
- 价格系统
- 物流系统
- 商家系统
API
API主要是传输通道，理论上不做逻辑运算。但现在很多实际的情况下API也需要夹杂很多业务规则的计算和处理。API主要包括几个部分的功能： （1）数据传输 API的基本功能，完成基本数据的传输，往往是以页面为单位计算API的数量。 （2）数据整合 由于数据可能涉及到多个系统之间的调用，所以API内部可能需要进行数据的整合。比如促销活动信息需要调用促销信息和商品基础信息。 （3）部分逻辑处理 在实际产品迭代过程中，考虑到APP发版时间限制等制约因素，一些处理逻辑可能需要放在API进行操作，比如部分信息项的筛选、ABtest、灰度发布切换逻辑。另外有些功能为了快速上线且后续可以进行延展，一些固定的逻辑也会考虑先不做后台，在API中通过配置文件的方式来实现。比如提示文案、icon等。 （4）缓存功能 提供给用户端的数据中，不是所有数据都需要实时更新获取的,所以API会将部分更新周期较长的数据放入缓存中定时去更新。比如用户信息、类目信息。数据统计系统
数据统计系统主要用来处理用户端埋点的信息，用于监测流量数据的情况。 一般数据统计重要分为使用第三方或者自建BI系统两种情况。用户端需要做的主要是进行埋点事件的命名和选择触发点。结言
用户端看似只是关注用户体验和界面功能设计，实则反应了整个电商生态下所有系统运作的最终结果。了解中后台的基本逻辑和流程有助于在构想界面时提高可行性和合理性。【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
