美团网络营销规模分析图( 美团网络营销案例具体分析 )

美团外卖产品分析（二）

承接美团外卖产品分析（一），还在继续，剩余部分和总结将在产品分析（三）中展示。如果分析有什么问题，希望能得到大家指点。

三 .产品分析

1.产品概述：

美团外卖以一款以外卖为核心业务，同时不断拓展其他服务场景（如水果生鲜，超市便利和甜点饮品）的O2O平台。搭建了用户与商家的沟通渠道，并为了提供更好的配送服务，组建了自己的专业配送团队。

2.产品发展趋势：

根据艾瑞指数，如图3-1所示，美团外卖近一年的月独立设备数趋势， 总体趋于动态稳定 ，有 两次大的下降趋势 （2018年9月和2019年2月），其中2 018年2月 下降趋势最为明显，可能是由于过年回家团聚，部分用户不再具备订餐条件。具体情况如下：2018年5月-2018年8月呈平稳上升趋势，而2018年9月-2018年10月呈下降趋势，2018年11月-2018年12月呈上升趋势，2019年1月-2019年3月呈下降趋势，2019年4月开始回升。

3.产品历史迭代版本：

4.结论：

根据以上表格可以发现，美团外卖app的发展可以分为三个阶坦纯粗段：

1.探索期（V1.4.5-V3.8.0）：

在这个阶段，完成的是地址填写，取消订单，支付订单等基本功能的实现，即产品的核心主线。

2.成长期（V4.0.0-V6.10.0）：

这个阶段，始于美团外卖logo改变，表明产品基本功能已实现。裤樱企业开始优化产品形象，改进UI设计，优化用户使用中的体验（即增值功能），开启拉新活动，尝试开拓新的业务市场（水果，便利店，闪购）。

3.成熟期（V7.0.0-V7.13.0）：

当美团外卖红包套餐升级为美团会员，表明产品已经具有较大的市场规模，产品进入成熟期，开始构建自己的会员体系，增加用户归属感，并继续优化产品使用中的用户体验，增加用户粘度，提高用户活跃度。

4.未来（V7.14.0-V？？？）

在未来，增加用户粘度和提高用户活跃度肯定还会是美团外卖的核心任务，但当外卖市场完全成熟，新的业务市场（水果生鲜，便利店，闪购等）也有可能会成为新的发力点。

四 .产品功能结构业务流程分析

1.产品功能结构：

美团外卖app功能结构分为四大模块：①首页，②会员，③订单，④我的

四大模块均可通过底部TAG进入，其中①首页是导航页，app打开后默认进入该页面，当首页滑到下方时，首页图标变为回顶部，一键回顶部。②会员主要是会员办理和专属福利（加购红包与大额兑换）。③订单模块显示所有发起过的订单（已完成，已取消和正在交易），并显示经常购买的商家。④我的是app常见的功能模块，具体的结构功能图如下：

3.产品业务流程：

配送是外卖的核心业务，因此本次分析就从用户下单到用户接餐的配送流程进行分析，具体如图4-4所示所示：

在梳理流程图时，发现了一个 小问题 ：现在版本，当顾客催单时，催单信息反馈给的是商家，最后顾客得到的也只是商家确定了催单信息，并不能得到具体还有多长时间到。要想确定得给送餐员打电话，而送餐员往往在路上，或给别人打电话，很少接听。因此， 建议 用户点催单时，先判断餐在哪，在商铺，给商铺发让镇提醒信息，在骑手身上，给骑手发提醒信息，骑手有空时直接回复还有多久。

五 .产品页面分析

1.首页：

美团外卖针对的是人们用餐问题，而在用餐问题上有个世纪性难题——吃什么？打开app，用户的第一个需求就是找到我想吃的。因此，首页为app默认页面，主要帮助用户选到目标菜品。具体如何帮助用户选餐，见下文分析：

首页为长幅，本文根据手机屏幕显示长度切分为四个部分，通过向下滑动，依次经过四个部分。

功能分析：

首页的主要功能是将用户导向目标商家。如何做呢？主要通过以下6个基本功能：

1. 定位功能：通过定位主动为用户做第一步筛选商家，避免错误订单。

2. 搜索功能：为目标明确的用户设置搜索功能，并在搜索页根据历史记录提供历史搜索和热门搜索的推荐搜索词和推荐商家。

3.分类功能：首先是主要分类icon如图5-1，尽管美团开拓了甜点饮品，超市便利，蔬菜水果，药品等业务，但app主体还是以外卖为主。外卖内容还是外卖信息，要想快速进入其他业务，分类icon很重要。其次是精细分类，对于只有大概方向，但没有具体目标的用户，通过分类功能，更加便于用户定向浏览商家，确定目标。精细分类icon的显示很重要，太多难以找到，太少不能精准定位，因此结合推荐功能，根据用户历史习惯显示。

4.推荐功能：如果说前两种用户还比较好导向目标商家，那么还有一种用户他自己也不知道该吃什么，我们怎么解决呢？这就需要推荐功能了，像美团外卖app首页的“为你优选”，“优惠专区”，“大牌臻选”，根据早中晚餐，每周优惠活动，好评商家和以往消费习惯，尽可能地为你“量身推荐”。而且从V7.3.0版本开始，推出了智能点餐，定制性质的推荐功能。

5.商家展示功能：当前几种都没有得到想要的结果，怎么办呢？在首页下方列出了“到店自取”和“附近商家”的简要信息，展示关键信息（店名，评分，起送，人均，距离，时间等），用户通过闲逛的方式，找到目标商品。但在此基础上，增加了排序和筛选功能，提高了选择效率。

6.购物车功能：不同于电商购物车，一次可购买多个商家，多个物品。外卖通常一次只买一家，故每个商家页单独设置结算按钮。购物车主要用于多家店订单比较。

交互分析：

1.上下滑动：主页面内容较多，屏幕无法一次展示完全，而手机使用时是竖屏，通过上下滑动比左右滑动能保持更好的连贯性。

2.左右滑动：如“滚动广告播放页”和“自取商家”。在有限的空间展示了更多的内容，并且对于“广告播放页”而言，动态滚动更容易引起用户注意。

3.点击进入页面：美团主页主要为导航功能，是为了引流。所以大部分按钮，点击进入细分页面，如“为你优选”、“分类图标icon”、“优惠专区”、“津贴臻选”点击进入相应频道页，而“大牌臻享”、“附近商家”点击进入商家页。“搜索框”进入搜索页，“位置”进入收货地址页面，“信息”进入消息中心页面。以及“搜索框”下的关键词推荐，点击进入搜索结果页面。

4.点击排序：主要在附近商家，根据不同需求排序。

5.点击展开下拉菜单：附近商家中的“综合排序”和“筛选”。由于选项过多，而当前层级已经较低，不适合单独做页面，故将部分隐藏，通过下拉菜单展开。

6.悬浮框：“津贴臻选”、“购物车”和“智能点餐”采用悬浮框的形式，随主页面移动而移动。

一键置顶：当页面滑动过下时，首页按钮变成置顶按钮，一键回到页面顶端。

Apache Kylin在美团数十亿数据OLAP场景下的实践

美团各业务线存在大量的OLAP分析场景美团网络营销规模分析图，需要基于Hadoop数十亿级别的数据进行分析，直接响应分析师和城市BD等数千人的交互式访问请求，对OLAP服务的扩展性、稳定性、数据精确性和性能均有很高要求。本文主要介绍美团的具体OLAP需求，如何将Kylin应用到实际场景中，以及目前的使用方式和现状。同时也将Kylin和其它系统（如Presto、Druid等）进行了对比，阐述了Kylin的独特优势。

作为公司的平台部门，需要给各个业务线提供平台的服务，那么如何建设一个满足各种需求的公司平台级OLAP分析服务呢。首先，一个开源项目在公司真正落地会遇到很多障碍，这主要是由各个业务线不同的数据特点和业务特点决定的，所以本文会介绍一下美团的数据场景有什么特点美团网络营销规模分析图；其次，针对这些数据特点，尤其是和Kylin设计初衷不太相符的部分，有什么样的解决方案；第三，目前OLAP领域还没有所谓事实上的标准，很多引擎都可以做类似事情，比如普通的MPP，Kylin，或者ES等。这些系统之间的对比情况如何，应该如何选择，美团网络营销规模分析图我们也有部分测试数据可以分享巧绝；最后，简单讨论一下未来准备在Kylin上做的工作。

1、美团的数据场景特点

第一个特点是数据规模和模型特点。一方面从数据规模上来讲，事实表一般在1亿到10亿量级，同时还有千万量级的维表，也就是超高基数的维表。另一方面，数据模型是一开始遇到的最大困难。因为Kylin最初的设计是基于一个星形模型的，但很不幸由于各种原因，很多数据都是雪花的模型，还有其它的模型，比如所谓“星座”模型，也就是中间是两张或者三张事实表，周围关联了其它很多维表。业务逻辑决定了这些数据的关联方式非常复杂，根本无法用经典标准的理论来解释。

第二个是维度。维度最理想的情况是固定的，每天变化的只是事实表。但实际上维度经常会变，这可能和行业特点有关，比如组织架构，相关的维度数据可能每天都会变化。除此之外还可能要用今天的维度去关联所有的历史数据，因此要重刷历史数据，相应的开销也比较大。

第三个是数据回溯的问题。比如发现数据生成有问题，或者上游出错了，此时就需要重跑数据。这也是和经典理论模型有区别的。

从维度的角度来看，一般维度的个数在5-20个之间，相对来说还是比较适合用Kylin的。另一个特点是一般都会有一个日期维度，有可能是当天，也有可能是一个星期，一个月，或者任意一个时间段。另外也会有较多的层次维度，比如组织架构从最上面的大区一直到下面的蜂窝，就是一个典型的层次维度。

从指标的角度来搭态讲，一般情况下指标个数在50个以内孝枝姿，相对来说Kylin在指标上的限制并没有那么严格，都能满足需求。其中有比较多的表达式指标，在Kylin里面聚合函数的参数只能是单独的一列，像sum(if…)这种就不能支持，因此需要一些特别的解决方法。另外一个非常重要的问题是数据的精确性，目前在OLAP领域，各个系统都是用hyperloglog等近似算法做去重计数，这主要是出于开销上的考虑，但我们的业务场景要求数据必须是精确的。因此这也是要重点解决的问题。

在查询上也有比较高的要求。因为平台的查询服务可能直接向城市BD开放，每次会有几十、上百万次的访问，所以稳定性是首先要保证的。第二要求有很高的性能。因为用Kylin主要是为了实现交互式的分析，让使用者能够很快拿到结果，所以需要秒级响应。

另外经常会有人问到，Kylin有没有可视化的前端，在我们内部更多是由业务方来做，因为原来本身就有这样的系统，以前接的是MySQL等其它的数据源，现在可以直接使用Kylin的JDBC driver对接起来。

以上是美团在OLAP查询方面的一些特点。在用Kylin之前，实际上有一些方案，但效果并不理想。比如用Hive直接去查，这种情况下，第一个是慢，第二会消耗计算集群的资源。尤其每个月第一天，大家都要出月报，跑的SQL非常多，全提到集群上去，并发度限制导致跑的比平时更慢。我们原来也做过预聚合的尝试，这个思路跟Kylin很像，只不过是自己做这个事，用Hive先把所有的维度算出来，然后导入MySQL或者HBase。但是这个方案并没有像Kylin这么好的模型定义抽象，也没有从配置到执行，预计算，查询这样整体的框架。现在通过使用Kylin实现了低成本的解决这些问题。

2、接入Apache Kylin的解决方案

针对上述的问题，经过大量的尝试和验证，目前主要的解决方案有以下几点。

最重要的第一点，就是采用宽表。所有非标准星型的数据模型，都可以通过预处理先拉平，做成一个宽表来解决。只要能根据业务逻辑把这些表关联起来，生成一张宽表，然后再基于这张表在Kylin里做数据的聚合就可以了。宽表不只能解决数据模型的问题，还能解决维度变化、或者超高基数的维度等问题。

第二点是表达式指标的问题，也可以通过提前处理解决。把表达式单独转成一列，再基于这列做聚合就可以了。实际上宽表和表达式变换的处理可以用hive的view，也可以生成物理表。

第三个是精确去重的问题，目前的方案是基于Bitmap。由于数据类型的限制，目前只支持int类型，其它包括long、string等类型还不支持。因为需要把每个值都能映射到Bitmap里,如果是long的话开销太大。如果用哈希的话就会冲突，造成结果不准确。另外Bitmap本身开销也是比较大的，尤其跑预计算的时候，如果算出来的基数很大，对应的数据结构就是几十兆，内存会有OOM的风险。这些问题后面我们也会想一些办法解决，也欢迎在社区里一起讨论。（补充说明：目前已在1.5.3版本中实现了全类型精确去重计数的支持。）

从整个系统的部署方式上来说，目前Server采用了分离部署的方式。Kylin Server本质上就是一个客户端，并不需要太多资源，一般情况下使用虚拟机就能够满足需求。

实际的部署情况可以看这张图，左下角的是hadoop主集群，用于执行每天所有hadoop作业。中间最重要的是Kylin01和02这两个server，是用于线上环境的serve。其中kylin01是生产环境，这个环境一方面要负责从主机群上跑计算，把数据导到HBase，另外也要响应前端的请求，从HBase里读数据。如果想新增一个Cube的话，需要在kylin02上操作，也就是预上线环境。所有业务方人员的cube数据模型定义都是在kylin02上做，没有问题后由管理员切到kylin01上。

这样做的一个好处是kylin01作为一个线上服务能保证稳定性，甚至权限控制能更严格一些；第二，预上线环境下开发完成后，管理员可以在投入生产前进行一次review，保证cube的效率。

右上角是另外的调度系统。整个数据仓库的数据生产都是通过这个调度系统来调度的，其中的任务类型很多，Kylin的cube build任务也是作为其中的一种类型。在上游的数据就绪以后，根据配置的依赖关系，自动触发Cube建立的过程。

左上角这边还有一个完全独立的线下测试集群，这个集群是完全开放的，主要是给用户做一些最开始的可行性调研或者评估的工作，但同时也不保证稳定性。

一个开源的系统从社区拿回来，到真正的落地，再到上生产，这个过程相对还是比较长的，这里并没有太多的技术问题，更多的是一些流程上的经验。就是如何在各个阶段给业务方提供更好的服务，使得接入Kylin的过程更顺畅，沟通成本更低。整个过程主要分为四个阶段。

第一个阶段是方案选型，业务方根据业务需求，选择一些方案进行调研。我们在这个阶段提供了需求的Checklist，从数据模型，维度各个方面列出来比较详细的点，可以让业务方自己对照，确定需求是不是能够被满足。

在确定Kylin能满足需求的基础上，接下来是第二步，线下探查，也就是线下评估或者测试。我们提供了非常详细的接入文档，以及线下测试的环境。第三步是线上开发，我们也有一些文档支持，基于抽象出来的场景，每个场景怎么配置Cube，或者做哪些预处理，如何优化等，能够给业务方一个指导性的意见。

最后是开发完成后的切表上线。这个过程目前还是由管理员来操作，一方面是为了避免误操作或者滥操作，另一方面也会对cube进行review，帮助进行优化。

3、主流OLAP系统对比分析

通过和其它同学交流，有一个感觉就是大家都觉得Kylin还不错，但并不是特别有信心，或者不知道非要用它的理由是什么，或者它和其它系统的对比是什么样的美团网络营销规模分析图？这里也有部分测试结果可以和大家分享。

整个测试基于SSB的数据集，也是完全开源的，实际上是专门用于星型模型OLAP场景下的测试。整个测试数据集是非常标准的五张表，可以配置一些参数决定生成的数据集规模，然后在不同的规模下做不同查询场景的测试。现在已经完成的测试的系统包括：Presto，Kylin1.3，Kylin1.5和Druid。数据规模包含千万、亿、十亿三种规模；维度个数为30个；指标个数为50个。典型的测试场景包括：上卷、下钻，和常用的聚合函数。

这里挑选了典型的五个查询场景：一个事实表的过滤和聚合；五张表全关联之后的查询；两个Count Dstinct指标和两个Sum指标；后面两个查询包含8~10个的维度过滤。

这张图是千万规模下的一个测试结果，包括了四个系统。我们在用Kylin或者其它系统之前没有专门用于OLAP分析的引擎，只能用通用的。Presto是其中表现非常好的引擎，但是在OLAP这种特定的场景下，可以看到不管跟Kylin还是Druid相比差的都比较多，所以前两个测试包含了Presto结果，后面就没有包含了。

这里比较有趣的现象是在第三个查询，Kylin1.5反而比Kylin1.3要慢一些。这个地方我们还没有搞清楚是什么原因，后面会详细的看一下。当然这个也可以证明数据没有修改过，是真实的测试数据。

从后面的两个查询上可以看到，在千万规模的级别，和Druid还是有比较大的差距。这主要和它们的实现模式相关，因为Druid会把所有的数据预处理完以后都加载到内存里，在做一些小数据量聚合的时候，可以达到非常快的速度；但是Kylin要到HBase上读，相对来说它的性能要差一些，但也完全能满足需求。

在亿级的规模上情况又有了变化，还是看后面两个查询，Kylin1.3基本上是一个线性的增长，这个数据已经变得比较难看了，这是由于Kylin1.3在扫描HBase的时候是串行方式，但是Kylin1.5反而会有更好的表现，这是因为Kylin1.5引入了HBase并行Scan，大大降低了扫描的时间。Kylin1.5的数据会shard到不同的region上，在千万量级上数据量还比较小，没有明显的体现，但是上亿以后，随着数据量上升，region也变多了，反而能把并发度提上去。所以在这里可以看到Kylin1.5表现会更好。这里也可以看出，在数据量成数量级上升后，Kylin表现的更加稳定，在不同规模数据集上依然可以保持不错的查询性能。而Druid随着数据量的增长性能损失也成倍增长。

刚才是在性能方面做的一些分析，其实对于一个系统来说，性能只是一个方面，除此之外，我们也会去考量其它方面的情况，主要有以下四点。

第一，功能的完备性。刚才提到我们所有的数据必须是精确的，但是现在基本上没有哪个系统能完全覆盖我们这个需求。比如Druid性能表现确实更好，但是它去重计数没有办法做到精确。

第二，系统的易用性。作为一个平台服务，不仅要把系统用起来，还要维护它，因此要考虑部署和监控的成本。这方面Kylin相对来说也是比较好的。Druid一个集群的角色是非常多的，如果要把这个系统用起来的话，可能光搭这个环境，起这些服务都要很长的时间。这个对于我们做平台来讲，实际上是一个比较痛的事。不管是在部署，还是加监控的时候，成本都是相对比较高的。另外一个查询接口方面，我们最熟悉或者最标准，最好用的当然是标准SQL的接口。ES、Druid这些系统原来都不支持SQL，当然现在也有一些插件，但是在功能的完备性和数据的效率上都不如原生的支持。

第三，数据成本。刚才提到了有些数据需要做一些预处理，比如表的拉平或者表达式列的变换，除此之外还有一些格式的转化，比如有的系统只能读TEXT格式，这样都会带来数据准备的成本。另一方面是数据导入的效率。从数据进入数据仓库到真正能够被查询，这个时间中间有多长。数据存储和服务的时候需要多少机器资源，这个都可以归为数据成本，就是使用这个数据需要付出的成本。

第四，查询灵活性。经常有业务方问到，如果Cube没定义的话怎么办？现在当然查询只能失败。这个说明有的查询模式不是那么固定的，可能突然要查一个数，但以后都不会再查了。实际上在需要预定义的OLAP引擎上，这种需求普遍来讲支持都不是太好。

这张图是各个系统全方位的一个对比。

从查询效率上看，这里表现最不好的就是Presto，表现最好的应该是Druid和Kylin1.5，两者不相上下。从功能完备性上来讲，确实Presto语法和UDF等等是很完备的，Kylin会稍微差一些，但比Druid好一点。

系统易用性上区别不是太大，这里主要考虑有没有标准的SQL接口或者部署成本高不高，用户上手能不能更快，目前来看Druid接口上确实不够友好，需要去翻它的文档才知道怎么去写查询的语法。

在查询成本上，Presto是最好的，因为几乎不需要做什么特殊的处理，基本上Hive能读的数据Presto也都能读，所以这个成本非常低。Druid和Kylin的成本相对较高，因为都需要提前的预计算，尤其是Kylin如果维度数特别多，而且不做特别优化的话，数据量还是很可观的。

最后从灵活性上来讲， Presto只要SQL写出来怎么查都可以，Druid和Kylin都要做一些预先模型定义的工作。这方面也可以作为大家选型时候的参考。

刚才比较客观的对比了几个系统，接下来再总结一下Kylin的优势。

第一，性能非常稳定。因为Kylin依赖的所有服务，比如Hive、HBase都是非常成熟的，Kylin本身的逻辑并不复杂，所以稳定性有一个很好的保证。目前在我们的生产环境中，稳定性可以保证在99.99%以上。同时查询时延也比较理想。我们现在有一个业务线需求，每天查询量在两万次以上，95%的时延低于1秒，99%在3秒以内。基本上能满足我们交互式分析的需求。

第二，对我们特别重要的一点，就是数据的精确性要求。其实现在能做到的只有Kylin，所以说我们也没有什么太多其他的选择。

第三，从易用性上来讲，Kylin也有非常多的特点。首先是外围的服务，不管是Hive还是HBase，只要大家用Hadoop系统的话基本都有了，不需要额外工作。在部署运维和使用成本上来讲，都是比较低的。其次，有一个公共的Web页面来做模型的配置。相比之下Druid现在还是基于配置文件来做。这里就有一个问题，配置文件一般都是平台方或者管理员来管理的，没办法把这个配置系统开放出去，这样在沟通成本和响应效率上都不够理想。Kylin有一个通用的Web Server开放出来，所有用户都可以去测试和定义，只有上线的时候需要管理员再review一下，这样体验就会好很多。

第四，最后一点就是活跃开放的社区和热心的核心开发者团队，社区里讨论非常开放，大家可以提自己的意见及patch，修复bug以及提交新的功能等，包括我们美团团队也贡献了很多特性，比如写入不同的HBase集群等。这里特别要指出的是核心团队都是中国人，这是Apache所有项目里唯一中国人为主的顶级项目，社区非常活跃和热心，有非常多的中国工程师。特别是当美团网络营销规模分析图你贡献越来越多的时候，社区会邀请成为committer等，包括我自己及团队成员也已经是Apache Kylin的committer。同时也非常高兴看到以韩卿为首的Apache Kylin核心团队在今年初成立的创业公司Kyligence，相信可以为整个项目及社区的发展带来更大的空间和未来。

4、未来工作

在未来工作方面，我们认为Kylin还有一些不理想的方面，我们也会着力去做优化和改进。

第一，精确去重计数。刚才提到只支持Int，接下来有一个方案会支持所有的数据类型，能够扩展大家使用精确去重的场景范围（补充说明：目前该功能已在1.5.3版本中实现）。

第二，在查询效率和Build效率上也看到了一些可以优化的部分。比如队列资源拆分，我们所有计算集群的资源都是按照业务线核算成本的，但是现在Kylin本身还不太支持，这个我们也会抓紧去做，相信在很多公司也有类似的需求。还有大结果集和分页。当结果到了上百万的量级时，查询时延会上升到几十秒。同时在查询的时候有可能需要排序并且分页，就是把结果全读出来之后，根据其中的一个指标再order by，这个开销也是比较大的。我们也会想办法进行优化。

最后，Kylin1.5之后有明细数据和Streaming特性出来，后面也会做这方面的尝试。

5、QA

Q1：之前在Build的时候一直提到成本的问题，能给出一个估计值吗，如果一百亿的数据，需要多少时间？

孙业锐：有一个简单数据，大概是两亿行数据，维度的话有十四五个，Build时间不超过两个小时，Build出来的数据是五六百G。

Q2：原始值是多大？

孙业锐：把这个数据抽出来之后，就是只参与Build的数据压缩后只有几个G。

Q3：Kerberos认证失效的问题你们遇到过没有？

孙业锐： Kerberos认证完之后，会在本地临时目录下有一个ticket问题，每天在外部定时刷新一下就可以了，服务是不用停的。

主持人：我补充一下我们为什么选择SQL接口？Kylin解决的是真正的用户面是谁，其实是业务人员和分析人员，他只会SQL，几乎那些人很少说再学个JAVA，所以能给他一个标准的SQL这个是让他上船最快的事情。其实这就是易用性很重要。

刚才看到了Kylin在千万级规模和亿级规模的表现，如果数据规模上到十亿，百亿，千亿的时候，我相信Kylin应该会秒杀所有一切。因为我们现在有另一个案例，生产环境上千亿规模的一张表，可以做到90%查询在1.8秒以内。另外我觉得非常好的一点，像美团、京东这边贡献了很多patch，其实就是把需求提出来，大家可以一起来做。

作者介绍

孙业锐，美团高级工程师，Apache Kylin Committer。2012年毕业于电子科技大学，曾在奇虎360工作，负责Hadoop平台建设，2015年加入美团。目前主要负责数据生产和查询引擎的改进和优化，专注于分布式计算，OLAP分析等领域，对分布式存储系统亦有丰富经验。

移动端外卖app美团外卖与饿了么竞品分析报告

移动端外卖app美团外卖与饿了么竞品分析报告

一、分析背景

1.1 市场分析

二、竞品对象

三、竞品分析

3.1 定位和功能

3.1.1 产品定位

3.1.2 产品功能

3.2 设计和技术

3.2.1 交互和体验

3.2.2 视觉和风格

3.2.3 亮点功能备陪敬

3.3 运营及商业化

3.3.1 运营模式

3.3.2 盈利模式

3.4 用户数据

3.4.1 用户数量和活跃度

3.4.2 活跃时段

3.4.3 地域差异

3.5 核心策略分析

3.5.1 版本迭代和演变

3.6 优缺点总结和借鉴

四、总结

1.1  市场分析

       中国外卖市场经过几年的迅速发展，外卖产业链逐步完善，餐饮外卖市场逐步成熟。未来外卖服务人群、场景外延，本地差异化细分成为行业发展趋势。

2016-2020中国在线外卖用户规模及预测

        2018年中国外卖用户规模较2017年增长17.4%，达到3.58亿人，2019年超4亿人。外卖用户增长速度趋于稳定，市场仍未饱和。

2016-2020 中国在线外卖市场规模及预测

       中国外卖市场规模每年保持两位数扩张速度，2018年外卖市场规模突破2400亿大关，2019年全年整体市场规模将超2800亿元。经过近几年外卖服务的普及，其市场发展已进入稳定增长期。

2018Q4 中国在线外卖主流平台新零售业务交易额环比增长率

       2018年第四季度饿了么及美团外卖新零售业务交易额均较第三季度有显著增长，其中乱樱饿了么新零售业务交易额增长率为32.2%，美团外卖新零售业务增长率为24.8%。基于餐饮外卖市场的逐步成熟，饿了么和美团外卖正在加速探索新零售业务，未来新零售业务将是外卖主流平台的新竞技场。

2018 年Q3-2019年仿慎Q3主流外卖品牌交易额占比分布

      根据2018年Q3-2019年Q3可以看出，美团外卖、饿了么、饿了么星选瓜分外卖市场规模占比98%。美团外卖、饿了么两者外卖交易份额占比高达92.8%，其中美团外卖交易额占比稳中有升，2019年Q3已达65.8%，饿了么及饿了么星选略有下滑。

       根据上述市场分析了解到，外卖产业链正在逐步完善，餐饮外卖市场逐步成熟，现对外卖产业交易额占比较大的美团外卖与饿了么进行竞品分析。

3.1 定位和功能

3.1.1 产品定位

（1）用户定位

下面利用KANO分析法对移动端美团外卖和饿了么进行用户需求定位：

（2）市场定位

根据市场定位分析，使用四象限分析法可以得到：

3.1.2 产品功能（罗列对比）

3.1.2.1 美团外卖app产品功能结构图

3.1.2.2 饿了么app产品功能结构图

3.1.2.3 产品功能对比图

       从上表可以比较得出，美团外卖与饿了么在核心功能上基本相似，但是美团外卖多了智能点餐；而饿了么增加了更多登录方式、支付方式和联名信用卡优惠。

       美团外卖专注于页面的美感，集中在开发其他功能；而饿了么风格简约，但增加了许多优惠方式来增加用户黏性。两者App存在差异性，迎合了不同喜好的用户，喜欢界面美观、更愿意去体验其他功能可以选择美团外卖，如果选择简单订餐、订餐优惠可以选择饿了么。

3.2 设计和技术

3.2.1 交互和体验

3.2.1.1 商家页面（左为美团外卖，右为饿了么）

       在商家页面，两款App整体呈现均采用信息流列表形式展示商家，均有综合排序、满减优惠、配送费优惠等过滤条件，均展示了商家评分、月销售量、起送费、配送费、配送时间、配送距离等。

不同之处：

（1）美团会展示商家商品描述语，帮助用户选择；饿了么会展示部分商家的菜品及价格吸引顾客。

（2）美团还新增了智能点餐机器人，更加方便快捷的帮助用户进行点餐。

3.2.1.2 点餐页面（左为美团外卖，右为饿了么）

       在点餐页面两家均显示了商家部分信息，大体分为点餐、评价、商家三个板块，提供了搜索、分享、收藏的功能。

不同之处：

（1）美图外卖整体排版简洁优美，同时在页面的左下方有一个满减神器，通过智能计算的方式为用户进行点餐优惠。

（2）饿了么在页面上方提示了该商家的评分与月售信息，同时两者在相同地点相同时间下单商家配送时间，饿了么蜂鸟专送时间少于美团快送。

3.2.1.3 评价页面（左为美团外卖，右为饿了么）

       两款App均展示了商家评分、味道评分、包装评分、配送满意度等。

不同之处：

（1）美团外卖用户评价引入了大众点评的评价，对用户来说，更具有参考价值；

（2）饿了么评价页面则显得朴实无华，二者对比，使得美团外卖的用户评价质量更高、页面更美观。

3.2.1.4 订单确认页面（左为美团外卖，右为饿了么）

       在订单确认页面，两款App均提供了地址、送达时间、联系方式、准时服务、号码保护等功能。

不同之处：

（1）在填写地址信息上，美团外卖会提示用户选择正确的地址信息，而饿了么会显示默认地址；

（2）在收纳菜单上，美团外卖在进行菜单确认时会收起部分菜单，饿了么会直接显示所有菜单。

3.2.1.5 订单支付页面（左为美团外卖，右为饿了么）

       在订单支付页面，美团外卖的结算流程为：去结算-提交订单-选择支付方式-美团支付（或第三方支付）-支付完成，共五步；饿了么的结算流程为：去结算-确认支付（默认为支付宝支付）-第三方支付-支付完成，共四步。

       相比之下，饿了么较美团外卖支付流程更加简洁，同时美团外卖不支持支付宝支付，一定程度上流失了部分支付宝用户。

3.2.1.6 订单配送页面（左为美团外卖，右为饿了么）

       两款App均展示骑手的位置、距离、联系骑手、催单等功能。美团外卖使用的是美团专送，饿了么使用的是蜂鸟快送，两家的配送功能相对完善。

3.2.2 视觉和风格

通过对比美团外卖和饿了么的视觉与风格可以得到：

3.2.3 亮点功能

3.2.3.1 美团外卖亮点功能

① 智能点餐：通过语音和键盘输入自己想吃的东西，选择吃饭人数，系统通过大数据智能推出外卖商家供用户选择；

② 美团会员：伴随着无门槛红包，刺激用户消费，增加用户的参与感与自豪感，适当增加用户的黏度；

③ 好友拼单：符合美团外卖的特色功能，主要与社交相关，需要与微信绑定，增加了社交属性。

④ 大学生专属特权：紧抓大学生消费心理，赠送大额红包，促进学生群体消费，锁定目标用户。

3.2.3.2 饿了么亮点功能

①3小时公益：饿了么提供一个较低门槛公益活动，让人人都能参与到公益之中，使得让参与者具有社会责任感，进而加深用户黏性；

② 超级会员：会员作为传统的功能，可以起到用户划分的作用。饿了么的超级会员功能，第一，能够尽全力加大优惠力度，留住客户；第二，与其他功能挂钩，刺激相关功能的使用率增长；第三，会员用户能够在用户调研中取得关键作用；

③ 金币商城：通过收集和购买金币，在商城兑换物品，抓住用户省钱心理，增强用户粘性。

3.3 运营及商业化

3.3.1 运营模式

3.3.1.1 美团外卖运营模式

3.3.1.2 饿了么运营模式

3.3.2 盈利模式

       在互联网O2O快速扩张的形势下，盈利模式成为关键存活标准，在美团外卖和饿了么逐渐形成自己的生态圈之后，盈利模式也逐渐成熟。

3.4 用户数据

3.4.1 用户数量和活跃度

2017 年Q1-2019年Q3中国移动端外卖用户MAU

       中国外卖用户规模逐年增长，2019年Q3突破4亿大关。

2019 年Q3一二三线城市外卖用户周均启动外卖App次数

       2019年Q3，一二线城市高粘性外卖用户持续增长，三线及以下城市用户外卖习惯加速养成。

2019 年Q3中国外卖用户省市渗透率TOP5

       北京、天津及上海直辖市外卖渗透领先，陕西省及山东省进入Top5。三线及以下旅游城市外卖用户同比增长显著，游客经济带动旅游城市外卖提升。

3.4.2 活跃时段

2019 年Q3中国外卖用户活跃时间分布占比

       2019年Q3，外卖用户正餐时段活跃度同比均有增长，其中早餐时段增幅最高，达14.5%，午餐时段同比增幅8.9%，晚餐时段同比增幅2.9%。

2018 年10月-2019年9月主流外卖平台用户分时活跃度

    饿了么用户午餐高峰最为活跃，美团外卖用户全时段活跃度均较高。

3.4.3 地域差异

2018 年中国在线餐饮外卖平台一二线城市订单量

       根据艾媒咨询数据显示，美团外卖和饿了么在一二线城市的竞争更趋激烈，2018年中国一二线城市在线餐饮外卖订单量份额分布中，美团外卖份额达51.8%，饿了么为47.4%，两者之间的差距进一步缩小。

2019 年Q3外卖商家新增用户城市等级分布

       美团外卖商家新增用户近五成来自三线及以下城市，饿了么商家新增用户超六成来自一二线城市。

3.5 核心策略分析

3.5.1 版本迭代和演变

3.5.1.1 美团外卖核心版本迭代

3.5.1.2 饿了么核心版本迭代

3.6 优缺点总结和借鉴

       美团外卖同饿了么间的竞争同时也是腾讯和阿里巴巴之间的博弈。美团外卖的生活场景更加丰富，团购能够实现引流，另一方面，多线作战每个业务都有劲敌；饿了么专注外卖，体系更加轻盈，更具有创造力。

       美团外卖风格更加简洁、美观，虽然加入了跑腿代购、打赏骑手、推荐红包等功能，但保持了一贯的简约风格，每个功能几乎只有特定入口。而饿了么每个功能入口更加多样化，并且加入了更多功能，比如：金币商城、3小时公益等兴奋性需求。这样的风格差异化满足了用户的差异化需求。

       外卖O2O行业用户粘性较弱，两家平台都从社交等方面入手，旨在增加用户黏性。饿了么的蜂鸟快送和美团外卖的美团专送都在物流配送方面发力；而无论是推荐有奖、拼手气红包，其目的都是从社交的角度发力，一方面实现流量裂变，一方面增加平台的社交属性。这一方面饿了么出击尤为明显，而美团外卖主要通过好友之间互动来完成。

       外卖领域同质化严重的情形下，外卖平台仍然具有变数，平台应注意推陈出新，积极进行版本迭代，同时更加加强外卖品质监督，提升物流、食品安全等方面的质量，在服务质量和趣味性方面双管齐下。叠加多样化的配送服务，全面提升配送运力流转，是厂商盈利的方向之一。而如何寻求差异化、提升服务质量以及不断衍生出新的用户需求，提升用户体验和服务质量，成为外卖厂商持续良好发展的制胜因素。

       从广度来说，外卖产品包括的不仅仅是移动端app，商家加盟、线下配送、取餐、就餐都是关乎产品竞争力的重要环节。美团外卖、饿了么在线上产品部分都没有明显短板，线下才是产品改善的重点。

        随着市场的稳定和用户的积累，美团外卖和饿了么不断的上涨提成，强烈的盈利需求，造成的结果就是压榨外卖骑手、剥削消费者、提升商家的抽成。虽然外卖给我们生活带来了很多的生活便利，但增加了商家的压力，让城市出现了更多的摩托车电动车横冲直撞，增加交通安全隐患，让城市污染更加严重，这种生活便利带来的压力未免有点太大了，反倒培养出整个社会的懒惰。所以个人认为外卖平台需要稍微考虑下商家的权益，不然长久下去，彼此的权益都将受到伤害，进而导致外卖平台在消费者心中的形象荡然无存。