来源：简书
作者：Carson_Ho
原标题：先别高潮，其实小程序对你还是没什么卵用
数英网已获授权，转载请联系原作者
前言
2017年1月9号，小程序如期而至。今天我将从产品的角度，带大家去解决以下问题：
小程序应该使用在哪些需求场景？
作为不同的互联网从业者（产品、运营、技术）该怎么迎接小程序？
你该开发微信“小程序”还是 App？
数英网此前已经有很多文章来描述小程序的形态和使用流程，本文将不再阐述。
目录
1 “小程序”是什么？
内置于微信的云端应用程序，不需要安装、下载，用完即走。
官方称为：小程序，可理解为“镶嵌在微信的 App”
与订阅号、服务号和企业号属于同级体系。由此，小程序、订阅号、服务号、企业号形成了并行的微信生态四大体系。
2 互联网从业者该如何对待小程序？
通过上面的描述，你大概了解到小程序是什么了，那么：
和现在的 Web App、原生 APP 有什么区别？
作为不同的互联网从业者（产品、运营、技术）该怎么对待小程序？
请看下面分析：
2.1 对于用户
性能比 Web App 好
微信为开发者提供基本 SDK（组件、框架API以及开发者调试工具）同时开放后台服务器，这使得小程序的性能和流畅度远高于 Web App。
但性能和流畅度还是不及原生 App。
使用成本更低
无需安装，不占内存，在微信内即搜即用，使用成本相对于安装 App 来说降低了很多。
无缝连接微信的账号体系，你甚至不需要注册登录。
2.2 对于开发者
学习门槛低
微信小程序的底层技术支持和 HTML 技术有很多相似之处，前端技术相对于其他技术来说无论是入门和学习门槛都较低。开发成本低
相比于开发成本和维护成本居高不下的 App 来说，在满足功能需求、性能需求的前提下，“小程序”基于其跨平台的属性，无疑开发成本和维护成本更加低。
2.3 对于产品策划者
基于微信的社交关系链和生态系统的产品矩阵，让产品形式的创新有了更进一步的想象空间。
当然这取决于微信本身的开放程度。
基于小程序开发成本和性能体验的平衡特点，让产品策划者在设计产品解决方案时多了一种极具性价比的产品解决方案。
特别是用于 MVP 试错、快速验证产品模式。
2.4 对于产品运营者
绝大部分的 App 都会面临用户获取成本太高、活跃不足和留存难的问题，特别是现在用户需求基本被满足的时代，流量的获取和转化成本越来越高。
由于微信对小程序的克制，小程序的获客成本和用户留存问题更加严重，根本没有提供流量红利，完全没有。
获客成本
微信对小程序并不提供如同应用商店一样的营销推广支持，用户只能通过：线下扫一扫：一来是微信希望小程序的使用场景对接线下，把线下流量都引到微信上。二来是微信不允许第三方来它的生态里控制流量入口。
应用内搜索：还是精确搜索！用户得对产品有较强的认知和偏好才可能搜索产品名称，根本不存在所谓的 SEO 和 ASO。
好友分享：纯依靠好友分享，微信群一个群最多500人一个人最多有5000好友，流量规模根本不足。
小程序的获客成本可能比 APP 更高。APP 推广还有应用商店、移动广告平台之类的花钱渠道，小程序的获客，可能你有钱都不知道去哪儿花。
关于留存
张小龙多次强调：小程序用完即走。实际上，根本不存在留存问题。用户想不起你，你根本无法触达用户，这意味着你无法对用户进行群 Push 或过多的营销动作，小程序只能发送客服信息和模板信息。
App 还能 Push、应用内调起等等。
小程序留给产品运营者的空间真的非常小，如何做好用户获取和用户留存更是一大难点。
2.5 总结
小程序是 Web App 和原生 App 的一种中间产品形态：在开发成本和性能体验之间取得了很好的平衡。
对于开发者、产品/运营者有机遇也有挑战，具体情况要看具体操盘。
对于用户来说，小程序是一种新的技术解决方案，最后目的还是为了满足用户日益变化的需求。
3 小程序的应用场景
在了解其功能和特点后，那么，小程序适用于什么需求场景呢？请看下图：四象限需求层次图：
四象限需求层次图
横轴=需求刚性，纵轴=需求频次，象限=需求类别
3.1 象限1：高频、刚需
对于高频、刚需的使用场景，由于用户使用频次很高，对于产品形态要求：
寻找产品的成本要低
性能和流畅度要求非常高
小程序并不使用高频、刚需的使用场景，因为小程序：
寻找产品成本高：每次都必须在微信内重新搜索，成本比固定在手机某个位置高得多
性能和流畅度不及原生 App
结论：小程序不适用于高频、刚需的需求场景，该场景下应采用原生 App。
3.2 象限2：高频、非刚需
对于高频、非刚需的使用场景，由于里面涉及的产品类型较多（内容型、工具型、社区型、游戏型），要试情况而定：娱乐类需求（阅读、音乐、视频、游戏、社区）。
阅读类的内容型产品
需要深度阅读环境和较高的交互、视觉体验，建议使用原生 App；
当然你也可以先用订阅号或服务号进行导流
偏工具的内容型产品（如音乐类和视频类）
功能和性能满足的前提下，基于开发成本和使用成本，建议采用小程序社区类产品
鉴于微信拥有强大的关系链，建议先用小程序进行快速试错 / 作为入口，待尝试成功后再将流量导入到原生 App游戏类产品
鉴于游戏要求很高的交互、视觉体验和沉浸感，建议采用原生 App
当然小游戏类别的产品，采用小程序是非常不错的，因为微信有着天然的获客和传播能力
日常工具类产品
在功能和性能满足的前提下，基于开发成本和使用成本，建议采用小程序
假如野心足够大，有足够的战略布局成为平台级产品的话，如美图秀秀，可以先做小程序，再导流到原生 App
偏运营为主或带有媒体属性的产品
根据张小龙对小程序的定义：用完即走，可以预测微信对于小程序在推送消息、运营方面会非常克制，这有区别于订阅号/服务号推送消息、App 推送消息，所以，假如你的产品是以运营为主或带有一定的媒体属性产品，建议你还是优先采用订阅号或服务号（具备发送消息功能），甚至是原生 App。
特别提醒：
由于高频、刚需场景市场已经被巨头垄断，所以很多创业者基本会选择在高频次、非刚需的场景切入。
区别于“原生 App 开发难度大、周期长、获客成本极高、推广成本极高”的现状，小程序在开发成本和性能体验取得了较好的平衡 + 微信天然的传播能力和获客能力，所以创业者应该通过小程序来进行 MVP 产品的尝试。
结论：对于高频、非刚需的使用场景，采用的产品形态试情况而定，小程序主要适用于：
偏工具的内容型产品
日常工具类产品
社区类产品（作为导流作用）
游戏类产品（小游戏）
创业者进行 MVP 产品形式的探索
3.3 象限3：低频、非刚需
对于低频、非刚需需求，基本是属于小众的需求，一般有两种情况：开发者自身兴趣 / 专业级产品，面向某领域专业用户。
对于第一种情况，就看开发者本身的能力，如果你是移动端开发者，那就开发原生 App；如果你是前端，就开发小程序
对于第二种情况，由于专业级产品一般对于性能和交互体验较高，所以优先采用原生 App
3.4 象限4：低频、刚需
对于低频、刚需的需求场景，这里涵盖了大量长尾的生活服务需求，比如说各种旅游需求、各种上门服务等等。这类长尾需求的现状是：
原生 App：大量使用频次过低（一个月甚至半年才1、两次）的原生App却占据着手机大量内存。
订阅号 / 服务号：Web App 的性能和流畅体验无法满足功能需求。
是的，这类长尾需求的的解决方案正是处于原生App和订阅号 / 服务号 进退两难的地步，而小程序是 Web App 和原生 App 的一种中间产品形态：在开发成本和性能体验之间取得了很好的平衡。所以说，小程序正好是解决这样需求场景的解决方案
结论：小程序非常适用于低频、刚需的长尾生活服务需求。
3.5 总结
小程序场景总结：（以按优先级排序）
基本涵盖所有低频、刚需的长尾生活服务需求场景
初创企业进行产品模式的探索
作为增量渠道，为原生 App 进行导流
小部分高频、非刚需场景
具体看下图：
小程序场景总结
另，从网上整理的微信小程序首批发布名单也可以看出，使用小程序的基本是工具类、低频的生活服务类需求的产品。
微信小程序首批发布名单
4 小程序的初衷
同样作为产品人，我一直坚持做产品的信仰：勿忘初衷。对于腾讯、对于微信、对于张小龙我相信亦是一样：连接一切。
微信作为腾讯的拳头产品，自然担任着这种重要任务。
4.1 我们先来看下微信的发展历程：
微信1.0
目的：连接人与人
功能形式：即时通讯、摇一摇、朋友圈和附近的人微信2.0
目的：连接人与信息
功能形式：订阅号、朋友圈热文搜索微信3.0
目的：连接人与服务
功能形式：企业号、服务号
显然，微信对于1.0时代和2.0时代的任务已经完成得无可挑剔，堪称现象级产品策略和操盘。
但是，对于微信3.0 连接人与服务呢？微信为搭建连接人与服务平台试过了微信服务号，微信企业号，然而都没有达到预期的效果。
同时，通过上面的四象限需求场景分析，你会发现，服务号作为产品解决方案的需求场景基本被小程序所取代。所以，小程序颠覆的并不是原生 App，而是服务号。
请你把上面把小程序的作为解决方案的需求场景换成服务号，你会相信便是现在市场现状。
虽然原生 App 的应用场景受到了一定的冲击，但原生 App 的需求场景依旧无法被取代。
腾讯又一次颠覆了自己，就像当年微信颠覆 QQ 一样。
再加上日常增显的用户关于长尾生活服务的需求：
原生 App
大量使用频次过低（一个月甚至半年才1、两次）的原生 App 却占据着手机大量内存订阅号 / 服务号
Web App 的性能和流畅体验无法满足功能需求
是的，这类长尾需求的的解决方案正是处于原生 App 和订阅号 / 服务号 进退两难的地步，而小程序是 Web App 和原生 App 的一种中间产品形态：在开发成本和性能体验之间取得了很好的平衡。所以说，小程序正好是解决这样需求场景的解决方案。
4.2 于是，在我看来，微信开发小程序的初衷是：
从公司战略（初衷）出发，小程序实际上是微信在服务号的基础上对提高企业服务能力的一次尝试，更进一步连接人与服务。
从用户需求角度出发，解决”大量使用频次过低（一个月甚至半年才1、两次）的原生 App 却占据着手机大量内存“ + “Web App 性能无法满足生活服务需求”的问题，为了囊括市场大量高频、非刚需的长尾生活服务需求场景，将用户与服务进行对接，更进一步连接人与服务。
从小程序的入口来看，张小龙说扫一扫是第一入口，而且只能线下，很大程度上表现出小程序是希望重新定义线上产品与线下服务场景的连接，在线上流量趋向饱和的情况下，微信希望凭借着小程序往线下获取流量。
这一举措会让微信支付获得更大的市场份额和高频的使用。
分析到这里，相信大家已经明白：什么场景下我该开发微信“小程序”，什么场景下该开发原生 App。
5 补充内容
5.1 App 是不是不用活了？
每当一种新技术的出现，人们往往会将其与之前技术对比，并采用”非此即彼“的做法。
一般出现上面这种言论的人，基本上是开发者：前端 Vs 移动端 。
我先问个问题：
民国年代，人们基本以自行车代步；之后，当汽车甚至是飞机面世后，请问，自行车这种出行方式还存在吗？
相信你应该能明白我的意思：任何撇开需求场景而空谈解决方案都是没有意义的，小程序仅仅只是作为一种新的技术解决方案出现。
同时，从上面四象限需求层次分析可以看出：
原生 App 和小程序的应用需求场景不同，所以无谓说颠覆。
真的要说颠覆，那么小程序颠覆的是服务号，而不是原生 App。
小程序实际上是提供了一种新的产品解决方案，微信是在鼓励H5开发，但依旧开放了 App 的接口能力，这说明未来 H5 和 App 并不是‘你死我活’的状态，应该是混合应用的趋势。
对于开发者、产品 / 运营者，要做的应该是正确判断需求场景，然后选择合适的解决方案更好地去服务用户。
而不是一味叫喧 App 将死、开发小程序就足够了这些浮躁的言论。
5.2 小程序会不会成功？
早在微信做小程序之前，这种基于 H5 的“轻应用”模式已经被国内几家巨头所尝试。
2013年，百度正式推出“轻应用”平台。李彦宏当时对其寄予厚望，“未来搜索引擎在智能识别用户需求后将实现无需任何下载安装，直接调起应用”。
同样的问题也出现在更早之前的浏览器“网页应用”上。UC 浏览器、360浏览器、百度浏览器等早在百度提出“轻应用”概念之前，就已经开始推广“网页应用”了，三者都基于客户端或者手机浏览器进行架构。
但是，他们都失败了。原因主要是：“轻应用分发平台”、“网页应用”极大程度上依赖于主产品的属性认知和使用场景：
搜索和浏览网页的工具属性太强，无法唤起人们进去使用其他服务的认知。
搜索和浏览网页属于非刚需、中低频需求，用户使用频率和活跃时长较低，无法撑起整个服务生态。
但是，对于微信来说：
已从”即时通讯工具“转变成‘生活服务平台”：各种城市服务+生活服务，使用场景早已拓宽。
本身社交属于高频、刚需的需求，保证了用户的使用频率和活跃时长。
所以说，微信一定会成功吗？我觉得倒不一定。
但是，假设有一天，如果有一款产品能在“轻应用”领域上取得成功的，我相信一定是微信。
6 写在最后
先别高潮，静下心来想想小程序该用在哪。
对于用户来说，我建议你的手机清多几个 G 内存来迎接小程序的到来。
对于产品 / 运营者来说，要做的应该是正确判断需求场景，然后选择合适的解决方案更好地去服务用户。跟风最可怕！
对于开发者来说，兴趣最重要。跟风最可怕！
- END -
转载请在文章开头和结尾显眼处标注：作者、出处和链接。不按规范转载侵权必究。
未经授权严禁转载，授权事宜请联系作者本人，侵权必究。
本文禁止转载，侵权必究。
授权事宜请至数英微信公众号(ID: digitaling) 后台授权，侵权必究。
评论
评论
推荐评论
暂无评论哦，快来评论一下吧！
全部评论（0条）