查看原文
其他

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

产品刘 2022-10-16

The following article is from 杂谈暖阁 Author 高晖


用户端的内部构造

用户端一直有着迷之尴尬的地位,既充当门面却深受各个系统的“牵连”。所有系统的最终表现都依赖于用户端的展现,所以说用户端是产品价值的最终体现。我们来看下用户端内部都有什么。

电商的用户端主要功能是提供购买和商品展示,并能够协助用户进行个人服务管理。从用户的阶段来划分,主要分成售前、售中、售后三个阶段。其中个人信息的管理属于贯穿整个使用过程。

售前环节:实现用户购买前的浏览和检索。

  • 首页(对接CMS、商品、类目、推荐、促销、广告、搜索)

  • 频道页(对接CMS、商品、类目、推荐、广告)

  • 专题页(对接促销、商品、CMS、广告)

  • 搜索结果页(对接搜索、商品、推荐、广告)

  • 搜索分类页(对接类目、商品、搜索、推荐、广告)

  • 发现页(对接商品、搜索、推荐、促销)

售前环节主要功能是完成商品的展示,页面的信息布局和UI是此类模块的首要功能。由于电商平台商品、类目众多,所以数据多是由负责规则整合的系统完成数据处理,然后通过页面、内容生成系统完成前台的展示工作。

售中环节:实现用户的购买

售中环节也叫购买流程,是实现用户从下单到完成支付的整个过程。这个流程是整个电商体系中最重要的环节。其中交易、订单和支付系统负责这个环节的核心逻辑。

  • 商品详情页(对接商品、促销、推荐、广告、CMS、会员)

  • 购物车(对接商品、促销、交易、推荐、广告),其中库存部分可放入商品或交易中合并计算,也可单独由库存系统提供处理。

  • 结算页,也叫订单确认页(对接商品、促销、交易、订单、会员)

  • 收银台,也叫支付页(对接支付、订单)

  • 支付完成页,也叫订单完成页(对接订单、推荐、广告)

(1)购物车

购物车环节要考虑库存是否需要做占用。购物车做预占库存可以第一时间通知用户库存状态,但有可能出现较多占用后但未生成订单的情况。而生成订单后占库存则能保证订单和库存匹配率最大,但用户在下单后才被告知无库存,用户体验相对较差。

常规做法会在购物车环节设置数量阈值,库存小于阈值显示用户库存紧张。然后在下单环节完成扣减库存的情况。如果是秒杀或者是类似唯品会的抢购模式,则可以在购物车扣减库存,增加倒计时(如15分钟)提示提高用户抢购感。

促销金额的计算也是购物车需要考虑的主要逻辑之一,由于商品详情页都是单品信息,所以组合促销的金额计算是在购物车体现的。

另外,作为电商的“近亲”020领域的购物车相比传统电商处理方法有所差异。020的购物车原则上很多是不跨店铺销售的,所以购物车是存在于单个店铺中且以浮层的方式展示。一般来说为避免对于服务器造成压力过大的问题,不是所有的添加商品的操作都是请求后端服务,在逻辑处理上为了保证一致需要前后端都考虑逻辑统一的问题。

(2)结算页

结算页可以说是电商用户端比较复杂的页面之一。这里面涉及到配送逻辑判断,送达时间计算,运费计算,订单计算及分摊等。

配送逻辑判断:根据提供的配送方式结合仓配情况和移仓的逻辑来判断来预计送到的时间。此部分的物流配送的路程情况也会影响运费的计算逻辑。当无法单仓满足或者移仓满足时,有可能需要拆多个包裹从不同的仓发送。

运费计算:根据后台设置的运费模板来计算实际应该收取的运费。运费模板是指设定好的一套运费规则,比如满XX收多少等。

订单计算:订单计算主要涉及到交易单各个子单之间促销优惠的计算和金额分摊。

  • 优惠计算主要包括优惠券和促销活动的金额计算。一般情况后台会有一定的计算优先级,比如计算促销活动的金额,完成后再看是否满足优惠券的满减金额。计算时需要考虑促销范围,如商家还是全场。

  • 金额分摊,电商的支付类型发展到如今是越来越丰富。信用卡、汇款、支付宝、微信、白条、积分、礼品卡等等各种各样。考虑到订单逆向(整单退,部分退)的情况,需要将所有支付的金额包括优惠券都分摊到每一个商品上,以便退款时可以保证金额不错。分摊计算有两个要注意的事情,一个是各项支付方式退款的优先级,先退什么在退什么。原则上先退成本低的,在退成本高的。二是当分摊时金额除不尽的时候多余的部分如何分摊,小数后三位的时候四舍五入还是直接舍掉。这个规则要和后端、报表保持一致,避免出现一分钱误差的乌龙。

(3)收银台

订单生成后要通过支付系统完成支付操作,所以收银台的主要对接系统就是支付系统。对接第三方支付的时候需要注意的是,第三方支付客户端返回的状态原则上不能作为最终支付成功的状态,要通过第三方支付服务端返回信息为准。理论上这两种状态是同步的,但设计时要考虑交互和数据传输异常的情况。

售后环节:提高信息透明和服务体验

  • 订单详情页

  • 订单列表页

  • 在线客服

售后环节主要是订单生成后到订单交付完成的整个过程。这部分主要的功能就是跟客服和订单打交道。这里就不展开说了。只说一些需要注意的经验。

  1. 订单列表一般会保留三个月左右的用户显示数据,而用户端的删除不是物理删除只是订单上打标记而已。

  2. 在处理数据时考虑到历史数据较多,部分O2O的APP会使用历史订单数据和当日订单数据分开的读取的方式。

  3. 订单详情一般会有再来一单的功能,电商系统只需要判断是否存在可售卖的SKU即可。而O2O则需要增加判断区域属性。

  4. 在线客服要考虑是否是对接第三方应用,在嵌入对方的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系统两种情况。用户端需要做的主要是进行埋点事件的命名和选择触发点。

 结言

用户端看似只是关注用户体验和界面功能设计,实则反应了整个电商生态下所有系统运作的最终结果。了解中后台的基本逻辑和流程有助于在构想界面时提高可行性和合理性。

PS: 转发此篇文章到朋友圈或者是产品经理群,并截图发给微信chanpin628,可以找我领取一份BRD。

NOTE:为了不错过每一篇干货文章,顺手星标或者置顶一下吧,这样我就更容易出现在你的微信里,毕竟我们从不说废话。

更多干货可关注微信公众号:chanpinliu880

想学习更多关于产品、职场、心理、认知等干货,可长按右边二维码,关注我们。

老司机教你做产品经理4.0

3.0的培训已经告一段落,也帮助很多小伙伴找到产品经理的工作,如果你关注我的朋友圈,应该会发现几乎每天都有小伙伴向我报喜。(这里只简单的贴几张)

有了1.0、2.0、3.0的培训经验,以及我自身的不断成长(是的,我也一直在一线互联网公司不断的实践),让我更有信心做好自己的4.0课程。

我们的课程特色如下:

1、简历优化、面试辅导

因为我是转行的产品经理,在转行的道路上我走了很多弯路,但同时也积累了很多的面试经验,哪怕现在工作稳定了,我也经常去面试,一是检验自己的市场价值,二是积累面试经验,外加辅导上百位学员面试,让我对面试有了更深的了解,简历优化可以让你有更多的面试机会,面试辅导可以让你面试成功的概率大大提升。

2、工作中的实战分享,帮你高效工作

3.0的末期课程我们已经加入了很多实战案例的分享,这些案例不仅包含我之前做过的项目,还有我身边产品小伙伴做过的项目,有些axure原型案例,你直接可以拿过去在自己的工作中复用。

同时我们还带领大家从0-1的做一个项目(包含前后台),让大家在体会产品从0到1的过程。

3、每周六项目分享群,各行各业的小伙伴分享他们的行业见解和项目经验

我们每周六还有项目分享群,会有各行各业的产品经理在此分享他们的行业见解和项目经验,视频直播分享,可以互动提问的哦,要学习好产品,无非是多学习,多总结,多交流、多实践,这就是最好的学习和交流方式。

4、多导师教学

当然我觉得我一个人的能力还不够,所以我邀请了之前曾在携程、同城旅游、途牛等多家互联网公司工作过,有六年多经验的verna姐姐作为我们课程的讲师,给大家分享经验。

同时我也会邀请一些在一线互联网公司工作的产品经理来给大家分享他们的产品知识,帮助大家更好的结交行业人脉,学习行业知识。

5、完善的知识体系

你是否看了很多产品文章,依然云里雾里?你是否觉得学习了很多产品知识,依然做不好产品经理?造成以上现象的有两个原因:1、缺少实践(什么是转行?当你找到一份满意的产品工作的时候就转行了)2、没有形成自己的知识体系,所以在我们的课程,我梳理了完善的知识体系,给到大家,以后你学习到的碎片化知识直接往里面丢。

6、有问题随时提问

当然我不能保证你随时问,随时解答你,但是我可以保证你当天问,当天解答你,相当于你找了一个老师在带你。可以看一下学生对我们的评价。(太多了,这里就不一一列举了。)

课表如下:

报名的童鞋在工作中有啥问题可随时咨询!

如果担心讲的质量,可以加我微信(yw5201a1)索要试听课程。

担心没时间听的小伙伴放心,我们会有录屏供你反复学习。

开讲时间:每周天晚上8:30(2018年12月16号开始)

总课时:终身制(只要我还在互联网行业混,就会不断的把我的经验分享出来给大家)

授课形式:CCtalk视频直播授课(同时会录屏方便大家复习)

讲师:刘大大、Verna

讲师介绍:

刘大大

我是刘大大,人人都是产品经理专栏作家,产品100年度优秀作者,现任某世界500强公司产品经理,曾在平安、麦子金服,中赢金融等理财平台担任产品经理,曾发表过热门文章《产品经理面试习题大汇总》,《产品经理如何写好MRD文档》等,从来说的都是干货!

Verna:

我是你们的小姐姐Verna,有6年多的产品经理工作经验,拥有OTA行业排名前三的携程,同程艺龙,途牛多家B端C端项目经验,比较熟悉下单预订、营销、社区等领域,在提升用户体验方面有丰富的研究与实践。我愿用女产品经理的视角带你了解互联网的方方面面。选择我,让我们一起成为优秀的互联网人~~

报名方式:本期课程报名费是3999

两人报名3900;三人报名:3800;四人报名,3700;5人报名:3600。(以3999为基础的前提下)

扫描下方的二维码,付款后加微信:yw5201a1 拉入上课群。

送福利:把此文章转发到朋友圈保留24小时即可找我领取一份想要行业的原型和PRD文档。

往期精彩文章

知识星球精华

面试一对一辅导

Keep APP产品需求文档(PRD)

Axure 原型 | 用Axure画流程图

产品经理如何进行需求分析

面试后台产品经理的时候面试官在考察啥

哪些迹象表明你面试没戏了?

穷人到底穷的是什么


点击“阅读原文”

即可进行报名。

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存