小程序能否替代APP？

这是我在某手机厂商面向海外市场从0搭建小程序平台期间的思考回顾。
用了2年半时间，投入不足30人的产研，结合公司所在市场的手机硬件水平和网络水平做了很多定制，完成了必需的平台能力和产品体系搭建，然而从业务的视角来看，尚未看到成功的曙光：没有确定性的流量场景、没有开发者、设计方向也仍有高度的不确定性。
这段历程中做过许多或大或小的尝试，然而无论何种探索的动作，都只是定位、目标、方向的具象化。这些一直萦绕不散的思考应该留下点痕迹，希望对同样想走这条路的人进行判断选择有点帮助。

1、小程序有什么价值？

小程序没有价值！

对于用户，小程序总是被提到轻快、便捷、即点即用，认为这就是小程序的价值，但是很遗憾，这些都只是小程序的特性，而非价值。对用户有价值的是一个个满足具体场景下具体需求的服务或内容，用户不在乎它是APP、网站还是小程序，只要它满足需求且“成本”足够低。因此，轻快便捷只是小程序赖以与APP、网站竞争的特性之一。
但仅仅只是小程序轻快、便捷，也未必能发挥作用：在用户需求产生的一刹那，他需要经历“知道去哪儿找服务->找到服务->使用服务”3个步骤，小程序的轻快只在最后一个步骤发挥作用，而前两个步骤则取决于场景和入口。也正因此，几乎每一家的小程序平台都是“寄生”在超级APP中^[1]、对更浅入口和更多场景“无比饥渴”^[2]。

对于开发者，小程序“开发成本更低、自动更新升级”同样只是开发者进行技术选型的部分决策要素——再低的开发、维护、迭代成本也是成本，开发者在意的是获得客户和收入，表现到合作过程中的具体问题，除了自己的服务怎么用小程序实现，就是“能覆盖哪些用户”、“入口在哪里”、“用户怎么支付”、“怎么做应用内广告”。究其本质，小程序对开发者的价值是开放、共享的价值：开放什么？开放多少？能否获益？用小程序实现是对开发者提出的条件和需要开发者付出的成本。

总之，小程序只是一项技术，它是场景的延伸，是价值的载体，就如广告是价值变现的方法而非价值创造本身。国内做小程序或类小程序平台的企业数不胜数，微信小程序的影响力和商业成功让人误以为小程序有巨大的价值。然而实际上失败或半死不活的小程序平台才是常态，为什么？因为真正有价值的是微信的生态，小程序只是激发其价值的工具。

2、为何还有那么多大厂会做这没有价值的小程序？

分析之前，可以先看看这篇微信的小程序技术发展史：小程序简介-小程序技术发展史 | 微信开放文档。简单来说，微信的开放生态在小程序之前早就已经开始了，H5网页在微信的聊天窗口、公众号的关键词回复和自定义菜单肆意生长的时代，为了死磕更好的端内体验，微信逐渐衍生出了小程序的技术。

小程序的沙盒机制、可控体验^[3]是微信经过实践验证的合适的开放生态载体。而微信开放生态对开发者的吸引力，让其他大厂的开放生态只能选择同样的技术以降低开发者的迁移成本，也减少研发探索的成本。

那么大厂们为什么都要做开放生态呢？
在我有限的视野中，微信并不是最早获得成功的开放生态，而是淘宝开放平台。淘宝通过开放平台，让第三方的软件公司可以基于淘宝的接口，为商家提供更好经营淘宝的软件系统。
对于每个领域的生态开放先行者，开放有三个最重要的前提：

1. 在某个领域占有领先地位，掌握大量的客户资源。
2. 所掌握的客户资源存在尚未被满足的、或长尾或个性化的分散需求，自己并不擅长满足这种需求或自己去满足的性价比太低，而市场上存在有能力和意愿满足这部分需求的其他人。
3. 能牢牢把控住客户最基本的需求、或者满足这些长尾个性化需求的基建能力，确保这是“改革开放”而不是“卖国”。

而大厂从开放中的收益也主要有三：

1. 更多、更忠诚的客户：客户原本未被满足的需求得到满足，对客户粘性提升是不言而喻的。
2. 生态级别的竞争壁垒：就像中国的制造业外迁，即便有些工厂可以迁移到人工成本更低的地方，但是“全产业链”却难以在朝夕间建成——竞争对手你可以抄袭并超越我的每一个功能，但你难以把开发者悉数转移，那些长尾个性化需求的满足就成了我的壁垒。
3. 商业收入：需求被满足必然伴随着新的收益，基于前提三总能设计出一种分钱的模式，具体是什么方式取决于具体的开放设计、并无定势，在此不再展开。

开放生态会开放什么、开放多少、开放条件是什么，大体上也是从这几点推导演化出来。

当领先者率先开放之后，追赶者和相关者即便开放的前提和收益无法完全具备，也不得不跟随，例如支付宝不得不推出小程序来延续与微信支付的场景争夺、手机厂商不得不推出快应用来延续服务分发的生意，只是这种跟随也因着条件的不足，让“如何开放”不断产生摇摆。在摇摆中，“开放生态”或艰难维持、或最终掉队，但小程序还是作为一种技术载体留了下来，发挥残值：

1. 将小程序作为一项跨端技术，降低研发成本：在中国市场，几乎每个APP都需要为iOS和Android两个版本准备两套开发团队，而基本上每个能跑得起来的小程序框架都是解决了大部分的双系统适配，因此基于小程序来开发对于大多数业务功能而言，都是更节省人力的。更典型的则是“平安”，平安有大量的独立APP，而这些APP之间有大量的业务协同，如果每次的业务协同都要在相应的端上做一遍开发、适配、或者依靠跳转到一个不知道用户是否安装的APP，成本和效率无疑是不可接受的，所以最简单的方法就是每个APP都支持同一个小程序框架，开发一个业务小程序，就可以在所有端上运行^[4]。
2. 将小程序作为一项动态更新技术，提升内部业务的迭代效率：大厂每天都有无数或大或小的迭代赶着上线，而超级APP不可能为了每一个需求无休止地合并代码、测试、发版。而小程序的沙盒机制、可控体验能允许每个业务各自迭代更新，APP的迭代只要关注小程序框架迭代的可靠性就行了，就算一个小程序出了问题，也不会影响APP的其他地方^[5]。目前大部分的小程序平台无论是否成功，也都同时发挥着这部分作用。
3. 将小程序作为一个“超级APP解决方案”对外售卖：“成为超级APP”对很多拥有大流量、行业领先的应用还是有吸引力的，于是全套的小程序架构和代码就成为了一种企业级产品走向了市场，比较典型的有支付宝、华为对海外较大的金融、运营商售卖的小程序架构，阿里云、腾讯云也已上架了其“超级APP解决方案”。至于买了又做成了的还没有看到，毕竟小程序不是价值所在，而在于开放的理念和具体的运营。

前司为什么要做小程序平台？

这是其实是一个战略选择，参考国内经验和这2年多来的探索，我总结为以下的3个选项，然而这些选项也并非完全背道而驰、选择了一个就再也走不到另一个，可以阶段性地选择一个方向发力同时观察转入其他方向的机会。

选项1：建立自己的开放生态

作为手机厂商，如果率先建立一个成功的生态，价值无疑是巨大的，足够高的竞争壁垒 和 生态基建近乎垄断的潜在利润 比“给谷歌打工”好太多了，最不济也能在与其他手机的竞争中具备先发带来的主动权^[6]。

然而前司建立开放生态的前提尚未具备，只是有“抢得先机”的条件：
第一个前提，凭借其在既有市场中手机市占率的优势，是具备建立自有生态的资源条件的。
第二个前提，海外市场是由APP+H5网站的传统互联网生态在满足，而从中国移动互联网的发展中，可以看到随着网络基建的发展，这一生态在未来松动的可能^[7]。同时，其既有市场“有能力和意愿满足个性化、长尾需求的其他人”这一条件也仍处在特别早期——本地开发者群体规模尚小，本地需求大部分是全球性的开发者满足全球发达地区的溢出^[8]，前司在开发者运营上也还没有太多的积累。不过，无论是这类市场自身发展、还是发达地区市场竞争逐渐饱和后向这类市场延伸，长期的趋势是向好的。
第三个前提，APP+H5网站的传统生态，谷歌靠账号+GP+搜索+admob/adsense等一系列产品的相互捆绑，构建起了从用户发现服务->使用服务->完成价值交换的基建，单一的手机品牌或者APP开发者，均无法完全脱离谷歌自立，当下在海外的任一手机厂商都不具备掌握生态基建的前提。但是安卓系统的开放性令手机厂商具备定制OS的能力，也就有了定义另一套基建的可能——在更前置的入口^[9]开放用户触达和需求即时满足的能力，并逐渐捆绑后续的生态和商业基建。

但是，建立生态的投入是巨大的^[10]，而前司缺乏商业基建能力来同时满足 开发者投入到小程序开发所需的商业回报 以及 自身投入生态基建的商业回报，无论是财务上还是组织上的坚持都是反人性、难持续的^[11]。
且开放生态的法务合规、权限能力管理、体验管理与普通的产品需要全然不同的理念和方法体系，内部需要在开放原则和开放边界方面形成新的共识与共建，这是对组织内部已有观念、流程、标准的巨大挑战。

选项2：作为一项技术解决方案

这个选项，也就是上面说过的“小程序的残值”，主要是将小程序作为一项动态更新技术，提升内部业务的迭代效率。

作为一个规模也不算小的集团公司，内部也有大量的业务应用，这些应用普遍依赖手机预装但又未必是用户的“必须”，利用小程序的动态技术，既能减少这些应用占用“不需要”或“暂不需要”的用户的存储空间，又能让这些应用不那么依赖预装和OTA从而更灵活地迭代。

但这一选项会非常容易陷入“猴子掰玉米”的机会主义，原因在于小程序的技术特性虽然能满足快速迭代的需要，但是还有一个隐含的前提是小程序具备能够实现业务所需的底层能力^[12]。如果每个阶段没有明确的业务侧重方向，仅仅因为“偶然”的需要而不断堆砌零散的能力，最终会发现投入没比做开放生态小，回报还不如做生态；且小程序无论是场景能力还是底层能力都需要多方的协同，“一项技术解决方案”很难具备足够的驱动力。但若小程序只守着快速迭代的价值，回避业务所需的能力建设，则必然导致业务无法实现预期的功能效果，业务也就不可能舍本逐末地采用小程序技术。

选项3：作为业务合作的解决方案的一部分

虽然和上个选项类似，都是将小程序作为一项技术来使用，但在“术”的层面全然不同：明确的业务价值决策之后，再考虑小程序对具体业务的作用，可落地性上将会大大提升，这可能是大多数公司发展小程序平台的唯一选项。

具体的业务可以是内容娱乐、政务民生之类的服务，也可以是负一屏、搜索、智能助手之类的入口场景，重要的是小程序需要深入结合业务的“场景->入口->服务”的闭环进行迭代，并注意能力设计的抽象和分层架构以免都成了定制开发。

因此，小程序能否对业务产生助力就是最重要的问题，一般可以通过以下3个方面进行评估：

1. 服务场景的特性：小程序最常被提及的即点即用、用完即走主要说的就是这个方面。即点即用和用完即走可以分开来看。即点即用面向的是需要便捷的服务场景，用户用最快的速度就可以进入到服务而不需要再经历下载安装或搜索筛选，例如停车缴费、排队取号等；用完即走面向的是明确目标的服务场景，用户完成目标的过程希望越快越好且完成之后也无需关注下次是否需要、何时需要，例如充值、预约等^[13]。
2. 入口场景的特性：这一点对比APP安装来阐述会更容易理解——除了应用市场等用户有认知的分发场景或者用户明确的下载安装需求，其他情况下当用户看到感兴趣的内容并点击后，承接的页面如果是“请先下载XXX”，用户对这个场景入口的认知会更偏向“广告”而非“解决问题”，这在手机和大多数工具类应用的用户习惯下尤为明显。例如手机负一屏、桌面搜索、AI助手等入口场景，小程序和H5网页都会与这些场景更契合^[14]。
3. 运营阶段的特性：业务初期、变化调整期需要更灵活地迭代，小程序的动态发版、自动更新特性能让调整更快地对用户生效。

小程序与业务结合需要注意什么？

2年多的发展，小程序距离“成功”尚远，且业界除了微信也没有哪个小程序平台可断言为成功，此时说小程序应该怎样与业务结合、应该怎样做能成都是某种程度的不负责任，但是以下这几点，是我们在共识和探索过程中走过最长的弯路。

宿主与场景的区别

大多数人会因为小程序的主要入口在哪儿而混淆了小程序的宿主APP和场景入口，实际上，小程序的宿主和场景是需要被明确区分的，它们解决的是不同的问题。

宿主解决的是能力覆盖的问题。小程序会像APP一样利用到本地存储来保障用户使用服务的“延续性”，因此宿主需要尽可能地统一；而为了让尽可能多的用户可以使用小程序，宿主的选择最重要的就是覆盖足够广且具备保活的条件。对手机厂商而言，小程序最合适的宿主是OS、桌面，或者某个100%预装覆盖且权限足够大的应用。

场景入口解决的是触达和便捷的问题，让用户在需求产生的一刹那能最快地找到服务、使用服务，因此小程序的场景入口发展趋势是奔着分散去的^[15]。

因此，小程序与业务结合时，必然需要打破端的边界，更多地主动了解相关端的特性进行跨端的方案设计，“提需求”和“提建议”就是小程序产品设计工作的一部分，即便各端的最终方案是由负责各端的人决定、小程序侧所做的方案都是“废稿”，这个“废稿”完成了“让各端在不了解小程序的情况下设计适合小程序的方案”这一使命。

场景导流与场景融合的区别

任何一个服务去寻求场景入口的时候，大多数人的第一反应就是“导流”——哪个地方流量大，就到那里去打广告，这往往会带来场景侧用户体验与导流需求的直接矛盾。

应对这个矛盾，惯常的思路是做“精准”——给到用户他有所偏好的东西，这样就不伤害用户体验了。但这还不够——无论是什么场景，用户都是基于其特定的目的来访问并停留在场景内，一个场景要有理想的转化效果，需要同时考虑用户需求和场景契合度。

在中国和发达国家，网络基建成熟，用户都是“实时在线”的，只要导流的形式不是强迫性、误导性的，用户相对容易接受，看到喜欢的也不妨点进去看看。但在其他国家，相对高昂的流量成本让用户不得不更专注于当下场景的目的，“不妨点击”发生的概率更低。“找对用户”和“找对场景”两者的重要性，在中国和发达国家可能是七三开，在新兴市场可能就是五五开甚至四六开。

因此，小程序与场景结合，不能是单纯的“导流”，更需要思考与场景的融合，让用户对于小程序的出现不意外，甚至觉得“还挺好”。虽然这种要求有点过于理想，场景体验与服务推广的主旋律仍是博弈与平衡，但事实上，一个成功融合的场景带来的确定性可能比N个在博弈下反复摇摆的场景具有更大的“破局”作用。

找场景与造场景的区别

无论用小程序来做什么业务，除非业务自带场景入口，否则都需要打通某个场景入口；从发挥小程序的便捷特性出发，也天然需要去拓展更浅、更多地场景入口。

手机自带的软件，除了应用市场、游戏中心之类，大部分都是面向泛用户的工具场景而非发现服务的场景，用小程序实现的服务要与这些本身就功能明确、用完即走的工具场景很好地融合，概率是比较低的。因此，小程序拓展场景入口并不是找场景的逻辑，而是“造场景”的逻辑——找到适合拓展出发现属性的场景并与之共建。

这样的场景主要可以分为3类：

1. 场景衔接的工具：帮助用户快速基于A场景的信息线索到B场景的服务，例如扫码、短信、文本拾取功能等。如果是做线下网点大量覆盖或适合裂变传播的业务，可以考虑这类场景入口。
2. 打发时间的工具：用户无明确目的地进行内容消费的场景，负一屏对部分用户属于此类^[16]，我们也确实曾经尝试并验证了用户此类需求的真实存在。需要注意的是，这类场景容易因为场景本身定位的模糊，成为多方需求博弈的焦点而缺少确定性；但若能确立“调性”的共识并完善流量机制、建立场景渗透与服务引流的共赢关系，将会有效地提升场景本身的价值。
3. 寻找的工具：用户根据自己的经验和习惯、试图找到某种东西或信息的场景工具，包括搜索、智能助手等。这种工具天然的追求就是更准确、更直接，同时需要内容、服务等各种类型的供给，尤其当下AI的飞速发展让“智能助理”越来越接近现实，而智能的体验终点绝不仅仅是“给出答案”，至少也是“找到服务”，这也是天然适合用小程序承接的^[17]。一直以来手机无论是搜索还是语音助手的场景，都因为意图识别的智能程度不足和服务供给有限，用户在经过一段时间的好奇尝新后，仅在有限的确定需求时使用这类工具，因此与这类工具场景的共建同样需要从具体的业务开始培养用户习惯，并沉淀出可持续扩展的“让用户知道这里能找服务->让用户在这里找到服务->让用户即点即用”的通用开放机制。

拓展业务与拓展小程序的区别

小程序的拓展，在业务开展方式上也存在一些问题。在前司，受限于组织架构设计，主要都是通过销售去向客户介绍小程序平台、看客户是否有意向进行小程序合作，这个过程中，小程序仅作为一种技术推广，而无论是流量还是变现能力都缺少确定性，既然没有业务属性，也就很难与业务成果直接挂钩。

与之形成对比的，也有过单一业务结合小程序进行拓展的尝试：负一屏的资讯入口开放+小程序 作为一个整体性的资讯合作方案去拓展业务，虽然有同样存在因为不熟悉的往复沟通，但客户群体、合作内容、各自收益和条件都有明确的方向和指引。

“明确一件用小程序来做的事然后去找开发者”和“找开发者来用小程序做点事”，貌似前者局限了选择面而后者空间更广阔，但实际上在驱动力和组织性上有巨大的区别。前者先进行了完整的业务设计，然后驱动完整场景的产品设计，再由销售对外推广，整个执行过程中每个角色的协同和分工是确定的。后者则像是盲人摸象，于是在各个环节出现了错位：销售只能跟客户泛泛地介绍一种技术，等着客户自己领悟能做什么；客户对于一个陌生的东西很难一下有什么具体的想法，就算提出了想法，能否配套能“客户成功”的资源和销售方案，销售也没底；总部则因为仅仅是想法且过于非标无法给出确定性的评估和答复，也很难主动为一个不明确的意向做方案设计。

国内无论是何种小程序平台，仅从其产品上看都不涉及这个问题，那是因为市场上有成熟的服务商，微信和支付宝在不同的行业领域要么依靠三方服务商，要么依靠自己的行业运营团队在输出解决方案。

从0开始做小程序平台，最关键的是什么？

1. 发现场景、复访场景、覆盖规模：“小程序做了有没有人用？”这不是单纯有没有流量的问题，虽然必然需要有基本的场景流量，但更重要的是确定性和稳定，因为这决定着开发者要如何推广和运营小程序，是开发者判断“能不能做”、“什么时候做”的决定性因素^[18]。
2. 广告变现能力、支付能力：“小程序做了有什么用？”开发、推广、维护的投入必须最终转化为商业收益，尤其是这几年“先免费做大规模”不work之后。而服务变现，要么广告、要么订阅、要么卖东西，那广告变现能力和支付能力二者就必不可少，至少也得有其一^[19]。此外，不同的服务类型适用的变现方式不同，此2项能力的完善程度，也反过来影响小程序可以承接的业务类型。
3. 风控治理体系：小程序由第三方开发，天然存在“开放”所伴随的风险，而小程序“寄生”在超级APP之中，一旦出问题对宿主品牌会产生直接冲击。如果风控能力过于薄弱，就只能将小程序的场景、类型、数量都压制在影响可控、人肉可覆盖的范围之内。当然，前两个问题是这个问题的基础，如果开发者都没兴趣来，风险也就无从发生了。