发布时间：2019-1-2 分类： 行业资讯
我之前与很多刚毕业的产品同学进行了沟通，客户是他们非常偏向的产品线。在实际工作过程中，由于对中后台情况缺乏了解，逻辑经验不够成熟，界面设计完成后，很容易实现与中，后台相关学生的沟通。完成。因此，客户端产品还需要了解基本的业务逻辑规则和关联。今天我们将分享电子商务的逻辑，020客户端“背后的“rdquo;
用户端的内部构造
客户总是有一个迷人的位置，作为一个外观，但深入参与各种系统。所有系统的最终性能取决于客户端的表示，因此客户端是产品价值的最终表达。让我们看看客户端里面有什么。
电子商务客户的主要功能是提供购买和商品展示，并协助用户进行个人服务管理。从用户的阶段，它分为三个阶段：售前，售中和售后。个人信息的管理贯穿于整个使用过程。
售前环节：实现用户购买前的浏览和检索。
主页（对接CMS，商品，类别，推荐，促销，广告，搜索）
频道页面（对接CMS，商品，类别，推荐，广告）
特色页面（对接促销，商品，CMS，广告）
搜索结果页面（码头搜索，产品，推荐，广告）
搜索类别页面（停靠类别，产品，搜索，推荐，广告）
发现页面（对接产品，搜索，推荐，促销）
售前链接的主要功能是完成商品的展示。页面的信息布局和UI是这些模块的主要功能。由于电子商务平台有许多商品和类别，数据主要由负责规则集成的系统处理，然后通过页面和内容生成系统完成前端显示工作。
售中环节：实现用户的购买
销售过程也称为购买过程，这是从订单到付款实现用户的整个过程。这个过程是整个电子商务系统中最重要的部分。交易，订购和支付系统负责此链接的核心逻辑。
产品详细信息页面（对接产品，促销，推荐，广告，CMS，成员）
购物车（停靠货物，促销，交易，推荐，广告），其中库存部分可以组合成商品或交易，或者它可以由库存系统单独处理。
结算页面，也称为订单确认页面（停靠货物，促销，交易，订单，会员）
收银员，也称支付页面（对接支付，订单）
付款完成页面，也称为订单完成页面（停靠订单，推荐，广告）
（1）购物车
购物车链接应考虑是否需要占用库存。购物车执行先发制人库存以在第一时间通知用户库存状态，但是可能存在占用更多但不生成订单的情况。生成订单后，可以保证库存和库存匹配率最大，但是在下订单后通知用户没有库存，并且用户体验相对较差。
通常的做法是在购物车链接中设置数量阈值，并且库存小于阈值以显示用户的库存紧张。然后，按订单的顺序，完成库存的扣除。如果它是尖峰或类似于唯品会的对齐模式，您可以扣除购物车中的库存并增加倒计时（例如15分钟）以增加用户的购买意识。
促销金额的计算也是购物车需要考虑的主要逻辑之一。由于产品详细信息页面是单项信息，因此组合促销金额的计算反映在购物车中。
此外，电子商务的“近亲”类别中的购物车与传统的电子商务处理方法不同。原则上，020的许多购物车不是跨商店出售的，因此购物车存在于单个商店中并且以浮动层显示。一般而言，为了避免服务器上的压力过大的问题，并非所有添加商品的操作都请求后端服务，并且为了确保一致性，在逻辑处理中考虑逻辑和统一的问题。
（2）结算页
计费页面可以说是电子商务用户的更复杂的页面之一。这涉及分配逻辑判断，交货时间计算，货运计算，订单计算和分配。
配送逻辑判断：根据提供的配送方式，结合仓库配置情况和仓库转移逻辑判断预计交货时间。此部分的物流路线也会影响货运的计算逻辑。当不可能满足单个位置或满足班次时，可能需要采取多个包裹并从不同位置发送它们。
运费计算：根据后台设置的送货模板计算应收取的实际运费。装运模板是指一组装运规则，例如XX收费多少。
订单计算：订单计算主要涉及促销优惠的计算以及交易订单的各个子订单之间的共享金额。
报价计算主要包括优惠券和促销金额的计算。通常，后台将具有一定的计算优先级，例如计算促销金额，然后查看是否满足优惠券的全部减少。需要在计算中考虑促销的范围，例如商家或观众。
金额，电子商务的支付类型已经变得越来越丰富。信用卡，汇款，支付宝，微信，白条，积分，礼品卡等。考虑到订单的反向（完全退休，部分撤退），包括优惠券在内的所有支付金额都需要分配到每个项目，以便在退款时可以保证金额良好。评估计算中有两点需要注意。一个是每种付款方式退款的优先级，以及首先退款的内容。原则上，首先返回的成本低，返回成本高。第二个是在金额未完全分配时如何分配额外部分。小数位数为3时，舍入或直接舍入。此规则应与后端和报告一致，以避免一分钱错误的乌龙茶。
（3）收银台
生成订单后，通过支付系统完成支付操作，因此收银员的主对接系统是支付系统。当您联系第三方付款时，您需要注意第三方付款客户返回的状态不能用作最终付款成功状态。以第三方支付服务器返回的信息为准。理论上，这两种状态是同步的，但设计时应考虑交互情况和数据传输异常。
售后环节：提高信息透明和服务体验
订单详情页面
订单列表页面
在线客服
售后链接主要是从订单生成到订单交付完成的整个过程。这部分的主要功能是处理客户服务和订单。我不会在这里谈论它。只说一些需要注意的经验。
订单列表通常会保留用户显示数据大约三个月，而客户端的删除不是物理删除，而只是订单上的标记。
在数据处理中，考虑到历史数据，一些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中的背景。如提示复制，图标等。
（4）缓存功能
在提供给客户端的数据中，并非所有数据都需要实时更新，因此API会将一些具有较长更新周期的数据放入缓存中以定期更新。如用户信息，类别信息。
数据统计系统
数据统计系统主要用于处理用户埋藏点的信息，用于监控流量数据。
一般数据统计主要分为使用第三方或自建BI系统。客户端需要做的主要是命名掩埋事件并选择触发点。
结言
用户方似乎只关注用户体验和界面功能设计，但实际上反映了整个电子商务生态系统下所有系统操作的最终结果。了解中后台的基本逻辑和流程将有助于提高界面的可行性和合理性。
作者：高慧（微信号@Zatan公用Snappers），有超过10年的IT经验，是互联网资深人士。他曾经在当当网，家庭食品俱乐部，美彩网等工作。
