以oto为例,拆解平台中的「订单系统」

发布于 2021-04-05 22:04

对于许多前端产品（泛指）以及刚入门的平台产品经理来说，订单系统都是一个极其费神的东西，因为它实在太过重要。

「干货」

盆友们节日快乐~在假期的最后一天发篇文章庆祝一下？


01


前言



企业生存的本质就是销售，卖出自己的产品，养活自己。
所以几乎所有的企业都需要“卖产品”，只不过形式各有不同：
滴滴、美团、淘宝等第三方平台卖服务；
好未来、斑马、vipkid等教育产品卖课程、卖师资；
神策、友盟、诸葛 IO等数据服务商卖平台；
传统公司卖实体
对于美团来说，订单是一切用户下单后提供服务的底层基础，若是订单逻辑不通畅，那么通过订单衍生出的中台系统，一定极度难用
本篇文章，就以大家每天都在用的美团的O2O业务为引子，拆解企业中的订单系统逻辑

02


业务场景



在我们大学的时候，每逢假期总会约上几个同学，一起去改善伙食；当时O2O还比较火，在线上下单到店消费，总是能省个十几二十块钱。
我们的消费行为一共可以分为以下几步：
1、我们在美团上找到想去的饭店
2、选定套餐并下单支付
经过上述的四个步骤，我们就可以安心的坐下来等待上菜了；当然，这是最简单的流程，我们可以把每一步里都再复杂化一些

第一步的时候：
1）我不知道想吃什么，希望系统能够推荐
2）之前那家饭店很好吃，但是我忘记叫什么名字了

第二步的时候：
1）我有一个满300减50和满400打9折的优惠券，我得想想怎么用最划算
2）在结账的时候发现没钱了，临时去找朋友借
第三步的时候：
第四步的时候：
1）我迟到了半个小时，店家还给我留着位置，这不是白白的损失吗
带着上述的问题，我们进入下个模块，一起制定订单的字段及其逻辑

03


订单的字段



我们根据用户的实际业务场景，进行逐步的拆解，在所有的实际业务字段设计中，均可用此方法进行拆解



01 下单到支付

1、在用户下单后，数据库中需要生成一个订单，以美团为例，数据库中有上亿条数据（若数据量过多，涉及到拆表、拆服务器、建立中间键等操作，本文不做展开），我们如何精准的找到这条数据？用主键ID吗？但主键ID对于正常人类是不具有信息价值的，内部员工都无法通过订单号获取有用的信息，并且没有规律的一串数字用户看着也难受，这显然不是最优解，那么我们就需要“订单号”来标识该订单，订单号是一个可以自由定义规则的字符串，例如：2021年4月5日下的订单，订单开头就是“20210405”。这样我们找到了第一个字段：订单号


2、有了全局唯一的订单标识，我们该如何把订单跟用户联系起来？要知道，订单是基于用户产生的，并且用户还会凭借这个订单去消费，基于业务考虑我们必须把订单和用户联系起来，所以我们需要在订单中加入用户的标识，通过这个标识，我们就可以找到用户跟订单间的关系。这样我们找到了第二个字段：User_ID
3、用户购买的是哪个商品，店家必须知道，要不咋上菜？所以就需要在订单里记录用户的这一单购买了什么样的商品，但是还有问题，我举个例子：用户定了一份“豪华四人低脂水煮鱼套餐+自选配菜4份”，我要把这记录在订单里，那订单也太乱了，所以我们需要在订单里记录一个商品ID，通过商品ID能够从商品表中查到这个订单所包含的商品。这样我们找到了第三个字段：商品ID（ps：在数据库中，一般我们称从A表关联到B表，用来联查数据的字段为“外键”，上面的User ID也是外键）
4、每个公司的业务都需要经过财务进行上税操作，那我们就必须要知道通过该订单用户消费了多少钱、平台方实际盈利了多少钱，如此一来才能正常的进行上税操作。这样我们找到了第四、五个字段：支付价格、实际收益
但是我们需要考虑到优惠券对商品价格的影响，这在数据分析时极其重要，企业可以通过对收益率的分析调整优惠券策略，以达到最大盈利点。这样我们找到了第六、七个字段：商品价格、优惠券（ps：一般来说“商品”会记录价格，所以“商品价格”字段，也可以放在商品表进行记录）
5、为了获取完整的用户行为信息，比如“下单”这个行为，我们通常会在用户下单时生成订单，而不是在支付时才生成订单。那么我们就需要标记这个订单当前的状态。这样我们找到了第八个字段：状态
6、在订单创建时，我们应当记录该条订单的创建时间，用以做数据分析、处理客诉、状态的变换（后续会详细说明）。这样我们找到了第九个字段：创建时间



02 消费

1、用户到店消费时，需要证明自己是已经在美团上下过单，这时候我们需要给用户提供一个凭证，全局唯一的订单号是否能成为凭证？答案是否定的，我们需要考虑到，店家有看到订单的需求，而订单号是订单的唯一标识，大概率我们会给店家看到这个唯一表示，如果用订单号做“消费凭证”，那么店家完全可以在用户未消费的情况下进行“消费”操作，所以我们需要给用户提供一个除订单号外的凭证。这样我们找到了第十个字段：消费凭证（ps：消费凭证是一个数组，这个数组是另一个外键表的唯一ID，我们可以基于另一个外键表生成qrcode码）
2、在订单被消费时，我们应当记录该条订单的消费时间，用以做数据分析、处理客诉。这样我们找到了第十一个字段：消费时间



03 售后

1、在用户发起售后申请时，我们需要处理用户的售后信息，售后过程中也会需要很多新的字段，如果将这些字段继续加在订单中，那么订单的字段将会再增加许多，不利于数据库的检索操作，一般做法是用户在发起售后时根据订单生成一条“售后单”，并且将售后单的ID记录在订单中，以此关联订单和售后单。这样我们找到了第十二个字段：售后单号

2、用户若消费完成后，对此次服务不满，我们应该提供退费的途径，一般来讲退费应当按照用户支付的路径进行退回，所以我们应当记录用户支付的来源。目前部分平台的做法是退回到自己内部平台的账户中，这种做法能够为自己的账户体系带来现金流量，但也会引起用户的反感。这样我们找到了第十三个字段：支付来源（ps：支付来源中应当记录第三方给予的支付订单号）

章节总结：
订单体系一定是根据业务而搭建的，我们不能盲目的生搬硬套，例如：
京东、淘宝绝大多数情况下需要对订单进行发货操作，在订单中就要存储相应的外键字段，但O2O业务一般不需要


04


订单状态详解



在第三章节中，我们知道了订单中应当存在“状态”字段，该字段是订单流转的核心枢纽，在本章节我们对订单各个状态展开讨论

平台希望获取到用户的所有“行为信息”，若用户没有完成支付则不生成订单，就会流失掉一部分用户数据，这对于目前的“推荐算法”来说是不能忍受的。所以用户在下单之后，支付之前，应当存在一个状态：待支付
若订单用户长时间停留在待支付状态，会占用甚至浪费用户以及店家的资源，比如：
1、优惠券被用于该订单，在下其他订单时该优惠券无法使用（目前没有展开讲过优惠券系统的逻辑，若有兴趣可以在后台留言）
2、跟店家定好了8点到店吃饭，但用户迟迟未到店，店家给用户留出桌椅就属于浪费（用饭店举例可能不太贴切，大家可以想象一下秒杀活动的库存占用）

所以若订单长时间停留在待支付状态下，应当有自动取消订单的机制，让订单自动从“待支付”进入到“结束”状态，所以应当存在一个状态：已结束
用户支付完成后，“待支付”状态应当发生改变，并进行对应的订单操作，比如：生成消费凭证、记录支付来源，并且根据当前状态决定该订单是否起效，所以应当存在一个状态：已支付

在用户到店消费后，店家获取到“消费凭证”后即可对此订单进行服务，在服务开始前，应当修改该订单的状态，以免一个订单被重复多次使用，从而造成店家的亏损，所以应当存在一个状态：已完成
既然用户到店才能完成该订单，并且在待支付过程中要考虑资源的浪费，那么在支付完成后就不需要考虑资源浪费了吗？若用户一直不到店该怎么办？
对于这个问题，针对不同的业务有不同的解决方案：
1、若付款后此位置以及菜品会为用户保留一段较长的时间（比如2小时），则可以着重考虑：店家为此已经付出的资源，就算用户未到店消费，也应当让商家收到这笔钱，用户需要为不守约行为而买单。但这本质上是一个偏向商家的逻辑，对此需要有一个状态：已过期，对于已过期的订单，用户无法进行消费，但可以继续申请售后
2、若用户付款后商家并不会为其预付资源，或预付的资源很少，则可以更多的考虑超时后给予自动退款，所以应当存在一个状态：未履约
用户在消费完成后，若对服务存在争议，可以选择进行售后，售后时有两种结果：

1、商家同意退款，订单状态变更为：已退款
2、商家不同意退款，且最终未能完成退款，订单状态不发生变更。某些情况平台仅允许用户对一个订单进行一次售后，那么订单状态需要变更为：已售后，此状态下的订单不能再发起售后


章节总结：
订单如上所述的状态并不一定是必须的，比如“已售后”的状态，我们可以检测该订单中是否存在“售后单号”来判断该订单是否进行过售后，单独列出此状态是为了方便读者理解



05


订单还能做什么




订单是一个企业最底层的逻辑，也是对业务最基础的支持，它远不止上述这些内容。比如我们的数据产品，关于收入、付费率、续费率等等数据分析都是基于订单而产生的，以下我将列举与订单高度相关的模块/工作供读者思考：
1、优惠券系统
2、基于订单的BI系统
3、基于订单的数据分析工作
4、淘宝、京东类电商平台的智能推荐系统
- End -

往期文章推荐：
1、平台产品，搭建属于你的「AB Test」
2、后台权限系统搭建方法论
平台搭建的日常
人人都是平台产品，这里是平台产品的集中地
5篇原创内容

本文来自网络或网友投稿，如有侵犯您的权益，请发邮件至：aisoutu@outlook.com 我们将第一时间删除。

相关素材

活动页面海报 运动鞋
活动页面海报 运动鞋
以梦为马不负韶华
以梦为马不负韶华
操作系统企鹅平台服务器系统设计
操作系统企鹅平台服务器系统设计