从产品层看微信会这样取代原生APP

最近一阶段H5技术被推到高峰，很多人认为借助H5就能利用微信公众号取代APP原生应用了，而事实是怎么样的？这里我从产品层做一个客观分析。

一，原生APP总体趋势

要谈APP是否会被微信取代，那么必须回过头去看整个APP的增长势头，早在2014年百度就发布移动分发市场报告，Android市场大盘增速放缓，红利正在消失。

而客观来看待，工具型APP发展正出现瓶颈饱和，工具类APP该做的都已经做完。剩下的APP都是围绕着内容生产的社交以及新闻类APP，而这很考验运营势能。

结论：现在做APP开发，要想再做成一个纯工具不与智能硬件或者线下结合的APP的机会不存在，其次内容型APP需要强运营能力。所以在这种情况下，我们下面要讨论第一是工具类APP能否迁移到微信服务号中？第二是这类运营的内容型产品能否迁移到微信服务号？

二，原生APP四象限与微信关系

现在从用户数和打开频率来讨论下原生APP的四象限，这四象限代表着已经存在的需求，这里的用户多少以BAT的矩阵产品为基准线，我们从这四个象限出发来看下微信服务号与之对应的关系。

用户多，频率高：这类APP是BAT矩阵产品，要在微信服务号里面做是不可能的，BAT也不会考虑，而下一个BAT级别的公司一定不会在微信服务号中诞生，必须另辟山头。所以没有任何机会。

用户少，频率低：这类APP就是我们常见的在应用商城中那些小而美的产品，一些小创意产品，这类APP产品本身就没太大机会，所以放到服务号中更没机会。因为需求已经被验证过了。

用户少，频率高：这类APP类似滴滴打车，上门洗衣，上门按摩等等。这里把打车APP也归为用户少的原因是因为相比于微信和QQ这些BAT矩阵产品，安装打车软件的人数还是少的，而其他任何垂直服务类APP相比于BAT矩阵产品也是少的。但是这类APP有一个机会就是利用微信的服务号把自己放到里面，为用户提供服务，这样既省去了高昂的开发成本，又减少了高昂的用户获取成本，试想，现在让用户去为了获取某个服务而要下载APP有多困难，并且现在地推也主要是让用户扫描微信服务号二维码，但如果说要在线下让用户扫描二维码下载APP，这种场景是非常不合理的，因为绝大多数场景都没有WIFI。目前微信服务号里面已经出现了大量的O2O服务，酒店预订，洗车，上门服务等等。但是微信自身一方面也在做，在微信钱包中就把滴滴打车融入其中，以及预订火车票和飞机票等等，所以与微信竞争的O2O产品未来存在一定风险，不过目前大可不必操心，必须先做大了才有资格谈以后。

再说垂直社交类产品，这类APP是否适合在微信公众号内做？答案是微社区本身就是垂直社交APP，垂直社交本质上是论坛，而微信内部已经介入微社区，很多公众号也在利用微社区做垂直论坛。但一切的前提是这个公众号自身有极为强大的影响力，否则一切都是空谈。而当这些微社区的用户体积到达一定规模后，就可以立即鸟枪换炮，比如公众号“人鱼线VS马甲线”，首先在公众号里面有一个粉丝庞大的微社区，而随后又独立研发APP，脱离微信。微社区毕竟只是BBS，可以延展的功能不够，并且用户没有掌握在自己手中，这也是投资人不想看到的。所以微社区可以作为跳板存在，当然更多的也得看团队是否有跳出去的实力。

用户多，频率低：这类型的APP基本都是工具类APP，比如任何手机出厂都会自带计算器APP，日历APP，便签APP，闹钟APP等等，这些APP在用户规模上是与BAT矩阵产品差不多甚至还要多的。但是这些APP在使用频率上就不高了，比如普通人一般会多久用一次日历？但每天会打开微信和QQ。

所以我要讨论的是这些有一定用户基数但是不高频的APP迁移到微信是否可行。那么先讨论一个可行的就是“备忘提醒”类APP，当你有什么需要通知如果有个服务号能够直接让你满足这个需求就是非常不错的，你只需要进入服务号，然后设置备忘提醒就可以了，不过微信团队也是非常聪明的，他们也早就发现了这个需求可以实现于是做了一个“语音提醒”进行了狙击，该服务号可以直接通过语音设置备忘提醒，比任何输入操作都方便。这类可以做到服务号的APP毕竟只是少数，并不是所有APP都有机会，下面讨论如果原生APP迁移到服务号，那么怎样的APP会符合微信的设计？

三，原生工具类APP迁移到微信服务号的条件

下面从用户体验上来谈谈，原生工具类APP迁移到微信服务号需要具备怎样的条件。

条件一，从产品层面来说一定要在更方便，更有效率的基础上去实现，比如“记账软件”这种主动操作的产品，就不适合，因为用户使用微信反而增加了操作成本，而一旦一个产品的操作成本增加，那就必死无疑。

原生打开：找到手机界面的APP固定位置->直接打开APP->对应操作

原生切换：系统层切换->对应操作

微信服务号打开：微信顶部搜索或逐行找到服务号->进入服务号->点击底部菜单或推送消息链接进入H5页面->对应操作

微信服务号切换：退出服务号->*用户有可能跳出微信，所以还可能需要切换至微信->微信顶部搜索或逐行找到服务号->进入服务号->点击底部菜单或推送消息链接进入H5页面->对应操作

条件二，根据条件一推出，很多原生工具APP用户的主动操作在微信符服务号的操作是增加成本的，所以这类原生工具APP迁移到微信行不通，原生工具APP迁移到微信更多的是需要满足用户的被动需求，也就是“推送大于主动”这类APP才可能有一定机会。

条件三，根据微信自身限制推出，这类APP必须满足微信开放接口条件，推送可以做到，但类似WIFI助手，清理内存的服务就无法做到，因为微信没有提供对应接口。但是提醒类就可以，服务号微信提供日50万次指定用户推送的客服回复接口（可以当APP云推送用），以及用户唯一openid获取接口，完全可以做。

结论：所以增加用户操作成本的这类型的原生APP绝对不适合进入微信服务号。原生工具类APP迁移服务号必须满足，1，以推送主导。2，其次微信接口条件满足。

所以某些服务号值得尝试，不一定能成功但有一定机会，语音提醒（微信已做），邮件提醒和回复（腾讯企业邮箱已做），朋友生日提醒，重大日程倒计时提醒，PM2.5警报提醒，星座运程提醒，团队协作推送提醒，锻炼提醒，喝水提醒，吃药提醒等等自行考虑，但要相信腾讯方面不是傻子，一定也在考虑这方面的服务号产品，在你做之前要想清楚你的积累资源是否足够？其次如果微信屏蔽你的朋友圈分享链接怎么办？这是现实问题。

结语：

所以最后总结，借力微信服务号和H5技术可以做三类原生工具APP，第一类是低频O2O服务类，第二类是以某个公众号为核心的垂直社交，第三类是“推送”逻辑的原生工具APP，而这类APP腾讯方面已经在着手布局，由于成本不高，这三类都在一点点实现。

所以对一件事要下判断除了要看大势以外，还要回到具体的场景，虽然H5崛起，但一项新技术要想颠覆一切，还需要看是否在真正落实的场景中能够给用户带来真正更高的效率，而不是靠臆想。