同城配送系统

同城外卖配送系统解决方案

时间:2022-02-06 16:24  作者:admin  来源:未知  查看:  
内容摘要:首页作为平台展示其功能模块与活动信息的重要窗口,对于用户的印象非常重要。打开美团外卖的首页,可以发现: 美团外卖采用icon配合文字的方式展现内容,主页推送了大量的优惠信息,刺激用户的消费心理。顶部置有搜索框,搜索框下方显示历史搜索记录。当有目...

  首页作为平台展示其功能模块与活动信息的重要窗口,对于用户的印象非常重要。打开美团外卖的首页,可以发现:

  美团外卖采用icon配合文字的方式展现内容,主页推送了大量的优惠信息,刺激用户的消费心理。顶部置有搜索框,搜索框下方显示历史搜索记录。当有目标商家时,可以点击搜索框,跳转界面后可以直接对商品或商家直接搜索,也可以根据搜索发现(智能推荐)和历史搜索信息进行选择,若对智能推荐的商品不感兴趣,也可以选择换一批。

  在搜索模块下方置有分类导航栏,用户可以根据喜好对特定分类商品进行浏览,减少用户操作步骤,在*短时间内列出*贴合用户需求的商品。

  当用户没有目标商家或商品时,系统智能推荐功能可以协助用户进行选择,包括各时间段优选好店、附近商家、发现好菜功能,并有综合/评分/距离/销量等排序,满足了用户从各个角度做出消费判断。

  同时,美团外卖在店铺/商品信息的展示方面具有多字段的特点:月售越多、评分越高等越能使用户放心下单,而距离和配送时间能给用户一个大概何时取到餐的心理预期。

  用户进入店铺信息页之后,可以看到全部的商品,清晰的商品图片、突出的优惠价格、商品的人气,降低用户决策时间,引导用户直接进行商品选择;

  在点菜页面下,左侧为导航栏,右侧为商品的图文描述。值得注意的是,当用户曾经在该商家购买过商品,那么再次购买时,可直接选择再来一单,此功能在我的订单模块也有设置。由于产品的特殊关系,美团外卖的评价页面与美团、大众点评APP的评价页面颇为相似,评价对用户下单具有一定参考价值。

  商家页面则一般显示商家的基本信息,用户获取商家线下的实景图和食品安全证明等重要信息,有利于提高用户对商家和美团外卖APP的信任度。

  用户在店铺信息页选择感兴趣的商品后,进入商品详情页,商品详情页直接影响用户消费体验感,页面的设计直接决定用户的购买行为。

  进入商品详情页后,平台采用“图片+排名关键字”的形式共同展示商品,商品展示图片占据页面篇幅较大,且非常精美真实,给用户很大的视觉冲击,直接让用户感觉商品的色泽、品质,并给出排名,不仅让用户快速获知商品的特点,同时产生了强烈的的下单欲望。

  同样,平台设置了“评价”模块,可以方便用户了解其余用户购买时经常遇到的问题,告知用户商品的保存条件与保质期;在商品评价中,用户可以通过其余用户的评价信息,获知其购买后的真实体验。值得注意的是,平台并非根据用户评价的时间先后顺序进行排列,而是对评价信息进行了筛选,将详细或带图片展示的评价排在靠前的位置;以上这些设计均是为了辅助用户购买决策,加快下单时间,从而提高转化率。

  通过“优惠搭配”前后的价格对比、红包、明显的补贴活动标识等突出划算氛围,让用户感觉到现在购买很划算,如果此时不买就是损失,进一步缩短用户决策时间。

  将商品加入口袋后,点击“去结算”,进入待提交页面。在该页面,用户可以获取立即送出情况下的预计送达时间信息,若时间不在用户的心理承受范围内,可重新选择商家/商品,通过灵活的送达时间选择,降低用户的对下单的心理门槛。

  美团外卖的支付流程为提交订单-支付订单 -支付完成3步。其中在提交订单页面,系统会显示津贴优惠、门店新客优惠、满赠优惠等。对于满减优惠,系统会自动提示额外购买商品会有更大优惠,从而激励用户去凑单,以更大的优惠力度吸引用户,促使用户享受优惠从而下单。

  在完成收货信息填写和优惠选择后,点击提交订单进入支付订单页面,用户可以根据需求选择美团支付还是第三方支付。此外,美团外卖还推出了极速/免密支付功能,简化用户支付流程,该功能可在我的钱包中设置。因为美团和建行交行的合作关系,美团外卖推出了储蓄卡支付立减优惠以及每日下单优惠,从价格上击溃用户的心理防线。

  客单价=付费总金额/付费总人数,即所有付费用户在一段时间内的平均付费金额。因此,要想提高客单价可以采取以下两种方式:一种是提升单个用户的单次消费金额,另一种则是提升单个用户在一段时间内的消费频次。接下来,本文将具体分析美团外卖是通过哪些方式来提高客单价的。

  设置免配送门槛:比如烧烤店,设置15元的起送费,减少一串两串这种小单。通过这一措施,可以引导用户增加单笔购买金额,也是对平台配送资源的进一步优化。

  特价优惠:平台在部分单品会推出每单特价等优惠措施,引导消费者“买得越多,优惠越多”,极大提升了用户单次消费的金额。实际上大部分每单特价与满减优惠都是冲突的,用户往往会忽略这一点导致掉入“价格陷阱”。

  相关商品推荐:平台会根据用户的购买记录中商品的分类和次数,通过推荐算法自动推送给用户感兴趣的商品;因此,该功能在用户可能忘记购买推荐的商品或原本没打算购买的情况下,看到平台推荐与提醒购买类似商品时,因为过去良好的购买体验与商品质量保证,增大一并购买的概率,从而提高下单金额。

  *近常买:在“订单”模块中,可以查看以往全部的订单信息,并在单个订单中设置了“再来一单”功能,用户点击后可以直接再次购买相关商品,避免重新挑选。

  在全部订单页面的顶部设有“*近常买”,点击进入可以看到常买的商品,对于有固定频率购买某些商品的用户来说,会更乐意直接下单。

  美团会员:美团外卖也提供了会员服务,成为平台的会员后,可以每月固定红包、商家红包、购买加量包、签到领饭钱,这些会员专享的服务权益,无形之中提高了用户的消费频率,将不确定的消费行为转化为确定的付费行为,从而提高了平台收入的稳定性。

  从以析可以发现,美团外卖之所以能成为美团公司的战略重点以及得到资源的倾斜,靠的是摸索出的优秀的变现方式和拆解提升GMV的手段,也因此占据着美团商业帝国的“半壁江山”。

  上图是外卖App引入MRN后的架构全景图,接下来我们会从下到上、从左到右逐步介绍:

  *下层是Android/iOS系统服务层,因为MRN是跨端的,所以需要引入这一层。相对单一平台来说,由于MRN的引入,整个App的架构不可避免地需要考虑Android和iOS平台本身的差异性。

  再往上一层是MRN基建层,这一层的工作主要是:(1)尽可能地屏蔽Android和iOS系统的差异性;(2)打通已有的平台基建能力,让上层业务不能感知到差异。

  再上一层是业务组件层,这一层相对于单一平台来说,区别不大,主要是增加了Android和iOS的RN容器,同时业务组件是可以被RN调用的。

  继续往上是MRN接口层,该层的主要任务是尽可能地屏蔽Android和iOS组件之间的差异,让上层页面使用的RN接口保持一致。

  是业务层,这一层是用户可直接接触到的页面,页面的实现可以是Android/iOS/RN。

  左上角是研发支撑,主要包括代码规范、代码检查工具、Debug插件、准入规范、准入检查工具、代码模板插件等。这块相对于单一平台来说,主要的差异体现在:由于编译器和语言不同,使用的工具有所区别,但工具要做的事情基本是一致的。

  左下角是测试支撑,主要包括UI自动化测试、自测覆盖率检查、AppMock工具、业务自测小助手、性能测试、云测平台等。这块相对于单一平台来说,基本也是一致的,主要的差异同研发支撑,主要是语言不同,使用的工具有所区别。

  右上角是发布支撑,主要包括打包Bundle和APK、打包检查、发布检查、发布Bundle和APK等。这块相对于单一平台来说,保持了打包发布平台的一致性,区别在于:需在原有的基础上,增加MRN的打包发布环节。

  右下角是运维支撑,主要包括基建成功率监控、业务成功率监控、线上问题追踪、网络降级等。这块相对于单一平台来说,保持了一致性,区别在于:需在原有的基础上,增加MRN的监控运维。

  RN对双端只提供了30多个常用组件,与成熟的Native开发相比,天壤之别。所以我们在开发的过程中面临的一个很重要问题就是组件的缺失。于是,MRN团队基于RN组件进行了丰富,引入了一些优秀的开源组件,但是源于外卖业务的特殊性,一方面需要业务定制,另一方面部分组件依然缺失。所以为了减少重复代码,提升外卖客户端MRN的研发效率,建设外卖组件库就变得非常有必要。

  上图是我们外卖组件库的架构图,层依赖Android和iOS的原生服务;然后是MRN基建层,用于抹平Android和iOS系统之间的差异;再上一层则是外卖组件库及其依赖,如平台组件库和打包服务,组件库分为两类:纯JS组件和包含JS和Native的复合组件。再上一层则是Android和iOS的MRN容器,它提供了上层Bundle的运行环境。整个组件的架构思路,是利用中间层来屏蔽平台的差异,尽可能地使用JS组件,减少对原生组件的依赖。这样可以有效地减少上层业务开发时对平台的理解。接下来,我们主要讲一下WM-RN组件库:

  如上图所示,WM-RN组件库主要包含三部分:RN interface、RN Native组件、外卖RN JS组件。RN Interface主要包括Native组件的Bridge部分和Native组件在JS侧的封装,封装一层的好处是方便调用Native暴露出的接口,也可以用来抹平Android和iOS系统间的差异;RN Native组件分为Android和iOS两端,依赖各自的业务模块,为RN提供外卖Native的业务能力,如购物车服务、广告服务;外卖RN JS组件则是纯JS实现,内部兼容外卖App与美团外卖频道间的差异、Android和iOS平台间的差异,依赖现有的MRN组件库和外卖开源Beeshell组件库,减少组件的开发成本;从工程的物理结构来看,建议将Native组件、RN Interface放在一个仓库进行管理,主要是因为Native与JS侧的很多通信都是通过字符串来匹配的,放在一起方便双端与JS侧的接口统一对齐,发布时也会更加方便。目前,外卖组件库已经扩展了几十个业务组件,支持了线上近百个MRN页面。

  目前,美团外卖App存在三种技术栈:Native、MRN、H5,面对业务持续增长和安装包不断变大的压力,选择合适的技术栈显得尤为重要。H5在性能和用户体验方面相比Native和基于Native渲染的RN相对弱一些,所以目前大部分H5页面只是用来承载需求变更频繁、需要即时上线的活动页面。那么MRN和Native的界限是什么呢?当有一个新的页面产生时,我们应该如何做取舍?通过实践,我们逐渐摸索了一套选型规则,如下:

  Native选型规则,强交互(同时存在2种及以上手势操作),无法用二元函数描述的复杂动效,对用户体验要求的页面,类似首页、点菜页、提单页等。

  对于强交互或强动画,MRN技术栈支持效果不理想,不建议使用。其他情况下,建议使用MRN。

  发布运维是一个成熟的软件项目中非常核心的部分,它保证了整个项目能够高效且稳定地运转。建立一个稳定可靠的发布运维体系是我们建设整个外卖MRN技术体系的重要目标。但发布运维的建设上下游牵扯了众多基建:拥有一个合理的工程结构对发布运维来说至关重要。如果工程结构臃肿且混乱,将会引起的一系列的权限问题、管理维护问题,这样会严重制约整个发布运维体系的效率。所以MRN的工程架构演进优化也是发布运维体系建设的重要组成部分。

  任何一个大型、长期的前端技术项目,良好的工程结构都是研发发布支撑中非常核心的部分。从2018年10月份,外卖正式启动MRN项目以来,面临涉及近百个MRN和几十人参与的大规模MRN应用计划。从项目初期,我们就开始寻找一个非常适合开发维护的工程结构。

  在*开始的时候,我们的目标是快速验证及落地,使用了一个Git库与一个Talos项目(美团自研发布系统)去承接所有页面的开发及发布工作,同时对权限进行了收缩,保证初期阶段的安全发布。然而随着页面的增多,每个版本的发布压力逐渐增大。发布SOP上的三大关键节点权限:Git库操作权限、Talos的发布权限、美团自研的线上降级系统Horn权限,互不相关,负责人也各异,导致发布时常因各个节点的权限审批问题,严重阻塞效率。

  随着项目的大规模铺开,我们的页面数量、合并上线次数与初期已不可同日而语。为了解决逐渐臃肿的代码仓库问题及发布效率问题,我们将庞大而臃肿的RN库根据业务维度和维护团队拆分成了4个业务库,分别是订单业务、流量业务、商家业务、营销业务,并确认各库的主R,建立对应的Talos项目,而主R也是对应Talos项目的负责人。同时所有的主R都有MRN灰度脚本的管控权限。这样一来,MRN的工程结构和Native的工程结构完全对齐,每个责任人都非常明确自己的职责,不会来回地穿插在不同的业务之间,同时业务库任意页面的发布权限都进行了集中,RD只需要了解业务的负责人,即可找到对应的主R完成这个业务的所有相关工作。

  在项目初期,对于每个库的工程结构,美团内部比较流行的工程结构有两种:一个是适合小型业务开发的单工程多Bundle方案,另一个是相对更适合中大型业务开发的多工程多Bundle方案。

  顾名思义,单工程单Bundle方案的意思就是一个前端工程承载所有的业务代码,*终的产物也只有一个RN Bundle。通过入参决定具体加载哪个页面。

  对于业务不多,参与人不多的团队,使用单工程单Bundle的方式即可快速完成开发、发布。因为通过一次发布就可以完成整个发布的工作,但是带来的弊端也是不可接受的:因为所有业务都耦合在一起,每次更新都会“牵一发而动全身”,增大了问题的隐患。如果多个业务需求同时提测的时候,在团队配合上也是一个极大的挑战,因为新版本号会覆盖旧版本号,导致两个需求提测时会出现相互覆盖的情况。所以我们在立项之初就排除了这种方案。

  多工程多Bundle方案的意思就是一个Git库中存放了多个页面文件夹,各个文件夹是完全独立的关系,各自是一个完整的前端工程。拥有自己独立的MRN配置信息、package.json、组件、Lint配置等(如下图所示)。每个页面文件夹都输出一个独立的RN Bundle。

  相比于单工程单Bundle方案,多工程多Bundle方案将页面进行解耦,使之基本可以满足中大型MRN项目的需求。在外卖MRN项目初期,一直都使用着这样的工程结构进行开发。但是我们也为之付出了相应的代价,即每个页面的依赖都需要对应RD去维护升级,依赖碎片化的问题日趋严重。同时在工程级别的管控,如统一Lint规则、Git Hook等也变得更加复杂。

  随着外卖MRN页面规模以及参与人规模的进一步增大,多工程多Bundle方案的缺点日益凸显。特别对于那些前端技术底子相对薄弱的团队来说,依赖管理问题会变得很头疼。在这种情况下,单工程多Bundle的方案就应运而生了。

  核心思路也很简单:观察一下单工程单Bundle方案和多工程多Bundle方案的优缺点可知,单工程单Bundle依赖管理方便的优点主要来自于“单工程”,而多工程多Bundle的业务解耦的优点主要来自于“多Bundle”。所以结合这两种工程方案的核心优点,就可以设计一种新方案:单工程多Bundle。即用一个工程去承接所有的页面代码,但是又可以让每个页面输出独立的RN Bundle来保证互不影响。其实,这种方式类似于Native一个静态库的管理,如下图所示:

  通过分析MRN的打包原理可知,MRN通过一个配置文件配置了一个Bundle的所有业务信息以及mrn-pack2的打包入口。所以我们只需要让配置文件支持多份Bundle信息的配置,通过打包命令与参数选择正确的mrn-pack2打包入口,即可打出我们*终所需要的业务Bundle。如下图所示:

快跑者是成都零点信息技术有限公司开发的一套配送/调度/代办类软件系统,抢单 派单模式,专注解决同城配送,最后一公里配送管理问题。开放API接收各电商外卖平台订单。配送员APP 发单商户APP 调度管理客户端。