“流量黑洞”经不起推敲？“算法黑洞”才能赢

小提示：您能找到这篇{“流量黑洞”经不起推敲？“算法黑洞”才能赢}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的“流量黑洞”经不起推敲？“算法黑洞”才能赢内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

“流量黑洞”并不是真正的黑洞，“算法黑洞”才是真正会导致赢者通吃的黑洞。

我们看到了一个大的趋势——那就是“数据云化”。

具体来说：企业越来越倾向于通过SaaS（软件即服务，Software as a Service）的方式形成“业务流（work flow）全覆盖”的数据底层构架。

所谓SaaS，是在IaaS（基础设施即服务，Infrastructure as a Service）提供基础设施（如场外服务器、存储和网络硬件等）、PaaS（平台即服务，Platform as a Service）提供基础设施及中间件（如编程语言、开发库、部署工具等）的基础上的进一步延伸。

具体来说，SaaS企业自己搞定硬件和中间件，将使用者想要实现的功能开发成应用软件，并为使用者提供账号供其使用，再按照不同服务等级收费。

当下，SaaS已经越来越火，某种程度上，暗暗印证了前面提到的商业趋势。

2016年，Oracle用93亿美元收购了Netsuite；2018年，刚传出的消息是SAP（思爱普）与Qualtrics达成80亿美元的收购意向……大额的收购案背后，都是传统软件巨头们“Buy to Cloud”的决心。

另一方面，本年，SaaS巨头Salesforce的估值达到了1000亿美元左右。

有意思的是，国内却出现了相反的趋势：2017年下半年开始，SaaS领域的融资出现了“断崖式”下滑。其中，2014年以后成立的SaaS企业，倒闭数量竟高达数百家。

无论SaaS企业作为一种B2B的商业模式是否存在独立发展的巨大空间，我想要强调的是，SaaS作为互联网企业的底层构架，可以释放出巨大的数据红利。

一个互联网企业为了让自己搭建的平台具有更高的运转效率，自己搭建底层的SaaS似乎是必由之路，这样就能实现对于业务流的有效覆盖，将业务流全部数据化、在线化。

2018年5月16日，美团宣布全资收购餐饮SaaS服务企业屏芯科技，后者一直致力于打造智能餐饮数据云平台。

国内一个可能的趋势是：互联网巨头企业并购行业内SaaS企业的案例还会越来越多，而他们瞄准的，都是至今依然丞待开发的、巨大的数据红利。

一、互联网经济的三波红利

互联网经济发展至今，已经涌现了两波红利；而第三波红利即将来临。

1. 流量红利

那个时候，企业只要接网就可以带来大量廉价的线上流量。

以凡客为例，2008年其开始尝试从传统的电话销售方式（原型是一家名为PPG的企业）转型线上，一个月后，其销售额的一半就已经是从线上获得。

另一个例证是“千团局”时期，团购网站鏖战厮杀，各自摧城略地，在极短的时间内就将大量商户搬到线上。

除了强势的地面“扫街”外，团购网站确实能够从线上为商户带来大量流量才是根本原因。所以，在那个时代，创业者在融资时说的都是流量的故事。甚至，有的风投机构直接用“用户数”乘以“单个用户获取成本”来为项目估值。

2. 生态红利

在大部分线上流量已经被挖掘，逐渐聚拢于BAT等大巨头之后，“流量黑洞”基本形成。

此时，流量不再取之系统学习电商运营不尽用之不竭，而是变得成本极高，企业说故事的方式也开始不同。

一类拥有流量的企业反复强调自己在打造生态，强调自己能够利用好流量，能做许多事情（多种生意）。例如，小米讲“生态链”的故事，乐视讲“生态化反”的故事，虽各有成败，但商业故事的方向都是德阳网站网站建设一样的。

与之相反，另一类不拥有流量的企业则强调“不做流量的入口，而做服务的出口”。它们在大流量入口的企业搭建的平台或生态里发展，力图变成生态里的“霸王龙”。

这个阶段，流量本身已经不是一个特别成立的故事了，此时，如何变现才是关键。

所以，对于生态红利时代的创业者或者资本来说，要想对项目进行估值判断，关键在于先了解清楚流量能够成就什么具体的生意，以及这些生意究竟能够做多大。

3. 数据红利

当同时具备了流量资产与生态资产时（即供需两端都上线了），商业模式的关键就在于：是否能够有效撮合供需。

互联网经济兴起的早期（2012年前后），业界一度认为黄太吉、小米那种建立粉丝群，通过交互用户获得用户需求的方式就是“互联网思维”。但事实上，那种方式建立的只是一个“小生态”，成本极高，且无法规模扩张，并非真正的“互联网思维”。

而真正的互联网商业模式，一定是基于数据来撮合供需的。形象点说：

• 一是要有以“产品”或“社群”形式出现的“终端”，形成流量的入口，并且将流量数据化、在线化；
• 二是要能够提供“云端”服务，在资源数据化、在线化的基础上，通过“大数据+云计算+算法”，将其精准配置给流量。

按照常理去推断：这个领域应该是互联网企业最擅长的地方；但事实上，这里却是诸多互联网企业共同的短板。

原因很简单，在第一、二波红利期里，更多是通过头部流量（需求）和头部资源（供给）的拉动，形成了一定的GMV。这类需求和供给都特别强烈，当互联网企业提供了一个线上平台，它们自然能够形成交易，但这并非企业基于数据进行撮合的结果。

而一旦第二波红利也开始消失，企业就必须寻找新的突破口。

此时，一方面是生态红利消失殆尽；另一方面是那些深耕数据红利的企业开始越过“拐点”。这个V字形的谷底必然会有一个“大爆炸”；而在此之后，会有若干之前有过累积的企业突破拐点、横空出世，甚至再次诞生BAT级别的、几千亿美元估值的头部企业。

当然，也有可能是BAT这类企业再进一步，抵达万亿市值（图1）。

图1：三波红利演变图

二、挖掘数据红利的两要素

“流量黑洞”并不是真正的黑洞，“算法黑洞”才是真正会导致赢者通吃的黑洞。

• 有一种论调是：互联网用户相当于一个金字塔，只有塔尖的一小部分人会付费，所以，必须要形成庞大的用户基座（即要有庞大的流量池）。
• 另一种论调是：导入大量的头部资源方，不论是带入其本身的流量，还是依赖它们的交易能力，都能够立竿见影。

但如果我们了解互联网经济的发展规律，就会发现这两种论调都会“过时”。互联网商业模式的终局还是会落到数据红利上。要挖掘出数据红利，应该是这样一种“循环的逻辑”：

• 基于产品形式的“端口（硬件+软件）”导入流量和资源，这个上线的过程自然会形成供需两端的“在线热数据”；
• 而后，基于算法来匹配供需，为流量匹配精准的资源；
• 供需的每一次匹配都会形成双方的反馈，也会导致持续的在线动作，而这些源源不绝的数据又会优化算法，导致对于供需的匹配更精准。

其实，用数据喂养出更好的算法，就是一个“机器学习”的过程，这个过程造就的就是一个不断强大的“人工智能”。可怕的是，这种人工智能的成长是没有上限的，越多的数据来“喂养”，它就越强大，越能促成供需两端更精确的匹配，也导致更多的流量和资源进入，平台或生态就会越来越强。

例如，谷歌基于用户的搜索动作和对结果的反馈，不断优化搜索的算法。这一过程中，越来越多的用户感觉到其强大的内容提供能力而进入平台，越来越多的内容也被抓入平台。其实，我以前提到的“流量黑洞”并不是真正的黑洞，“算法黑洞”才是真正会导致赢者通吃的黑洞。

2002年，谷歌还是没那么出众的小公司，也并未IPO。

凯文凯利问谷歌创始人拉里佩奇：“拉里，我搞不懂。已经有这么多家搜索公司，为什么还要做免费网络搜索？这主意有什么好的？”

后者回答他：“哦，我们其实在做人工智能。”

如凯文凯利一样对互联网趋势有敏锐洞见的人，尚且不能预测互联网经济的未来，而拉里佩奇这样的先驱却在开始就看到了终局，的确让人感叹。

总结起来，互联网企业要挖掘数据红利，应该具备两个要素：

其一是要有基于场景的“产品”来形成入口，让流量和资源以数据化的形式上线。

• 一是要有成立的“场景”。即用户或商户的需求应该是高频的、刚需的，这是商业模式能否成立的基础，也是决定商业模式能够做多大的底层逻辑。
• 二是要基于“场景”做出能够简单上手但又功能强大的产品——这决定了理论上存在的流量和资源能否上线以及在线效率如何。一款杀手级的产品能够将场景完美实现，让供需双方都沉浸其中，而这通常需要创业者通过交互用户来获得概念并设计产品。

其二是要有“计算能力”，能够把数据用活，形成一个闭环。计算能力是“大数据+算法+云计算”三者的结合，缺一不可。

• 由于供需双方的上线，大量的“在线热数据”适时产生，形成了我们口中的“大数据”；
• 而“算法”则是商业模式设计思路的体现，由互联网企业自己来定义，并设定机器学习的演化路径；
• 至于“云计算”，Amazon的AWS、微软的Azure、谷歌的GCE、IBM的Softlayer和阿里云之类的服务商已经实现了计算能力的随需调用（就像工业经济时代的电力一样）。

当三者结合，就能够把数据高效地用起来，实现供需之间的匹配，并通过机器学习让算法越来越“聪明”。

显然：前面小范围交互用户（或商户）获得需求的方式只是商业模式的起点，并不能替代后续这里通过“计算能力”实现的效果。

基于此，评估互联网企业在撮合供需上的“转化能力”的基本逻辑应该是：

E=P * C

这样设置模型意味着：两者对结构的影响都是乘数效应，而任何一个变量过于弱小，项目的估值都不会太高。

本文精选自穆胜博士新著《创造高估值：打造价值型互联网商业模式》

#专栏作家#

穆胜，微信公众号：穆胜事务所（ID：hrm-yun），专栏作家。知名管理学者，北京大学光华管理学院工商管理博士后，管理学博士，穆胜企业管理咨询事务所创始人，互联网商业模式和组织转型研究专家。

本文于，，

，基于CC0协议