美图秀秀作为一款上线超过十年的产品，是如何保持活力，压过了后来居上的新型产品呢？

美颜是刚需

没有被美颜过的照片不值得被审视。

从朋友圈到微博到抖音，从自拍到美食到旅行照，“美颜”这件事越来越被重视。国产手机们甚至把相机的美颜功能当作主打功能之一，并以人工智能等越来越高端的技术支持。

市场如此之大，但掠食者并不多。

被耳熟能详的产品，屈指可数：新贵轻颜相机以及三个传统大佬美图秀秀、B612和美颜相机。

美图秀秀作为老牌的美颜相机，在很长一段时间他的PC端甚至被当作PS的替代物。但过去一年，他却差点被新入局者取代。

根据七麦的统计数据，过去一年轻颜相机长期稳定保持在App Store摄影与录像板块TOP10的美颜相机类产品只有三款。轻颜相机后来者居上，2018年5月上线后快速蹿升至榜单头部。

我们排除掉这个有巨大流量支持的“异类”，观察两个老牌产品的排名趋势也非常有意思。

两款产品的排名在2018年可谓是竞争激烈，整个3月和4月B612赶超美图秀秀，5、6月美图赶超后B612休整了一段时间，再次上线后直到19年初一直压过美图。

19年元旦后，B612排名开始出现较大幅度的下落，甚至跌出了前十。

美图秀秀作为一款上线超过十年的产品，是如何保持活力，压过了后来居上的新型产品呢？或许和他的“不务正业”有些关系。

“不务正业”的美图秀秀

2018年6月，美图秀秀宣布转战社交平台，推出了美图社区

从社区上线后美图秀秀App Store排名的数据看，显然社区并没有帮助美图在榜单排名上做出多大贡献。很多时候从新功能的增加到获得新增流量需要很长的口碑传播周期，产品需要一些运营策略来加快这个进程。

2019年初，美图秀秀上线了百度智能小程序版，功能板块完全颠覆了原来的功能设置：

不看标题，你会以为它是“小红书”！一个美颜产品，好歹在小程序端放那么一两个美图的功能，全都是“社区”，不是“不务正业”是什么……

然而，美图秀秀这一招却非常之好使！

都9012年了，没人会在百度App搜索一款App的名字来获取功能。美图秀秀很明显也了解这一点，所以他们并没有期望用户会在百度搜索自己产品的名字来完成P图的任务，而是揩了百度智能小程序的另一个油：流量分发。

或许美图秀秀是从小红书身上发现了百度智能小程序的价值。知晓程序曾报道过小红书在百度智能小程序上的玩法，小红书为“女性内容消费”树立了典范，来到百度智能小程序端小红书则通过百度“搜索+信息流”触及了更多元化的用户，延伸到四五线城市、男性用户，让“内容”有了新的消费场景。

小红书的百度智能小程序对小红书来说是用户类型的扩充，对美图秀秀来说则是有“爱美之心”新用户的引入。

可能恰是基于此，美图秀秀在App Store的排名快速赶超B612。

小程序的另一种流量玩法

美图秀秀从百度智能小程序的内容社区实现了用户增长这件事，在我看来这只是百度智能小程序最基本的价值——引流。百度智能小程序有更多的流量玩法。

1. 从内容到消费的“种草”经济学

根据《QuestMobile人群洞察：亿万少女的消费选择》报告中的数据：网购少女（24岁以下，线上消费意愿较强的女性）通过微博、朋友圈和公众号推送获取商品资讯的占比和TGI（即Target Group Index，可反映目标群体在特定研究范围内的强势或弱势，TGI指数= [目标群体中具有某一特征的群体所占比例/总体中具有相同特征的群体所占比例]*标准数100）均较高。

除了商品特性，网购少女们被内容种草的几率十分明显。

很显然，内容对驱动消费的价值已经非常明显。美图秀秀做内容、做社区的目的我们也可以由此大概猜到一二。

实际上不止美图秀秀，越来越多的内容类小程序在百度App涌现出来。这或许可以成为内容的第二春。

我曾在晓程序观察发起的微信小程序大咖分享中对“玩车问问”微信小程序做过如下评论：

二次销售是几乎所有媒体的主要收入来源，汽车自媒体也不例外。在信息化程度不那么完善的时候，二次销售的主要内容是用户兴趣。小程序的出现给了媒体们一个“精细化卖粉”的途径，玩车教授搞得「玩车问问」无疑是这其中应用最好的玩法之一。

「玩车问问」很难通过收取提问佣金抽成的形式实现盈利，因为买车市场本身不是一个规模化的经济。但通过良好的互动体验、丰富的购车问题，把粉丝“爱车”这个泛化的兴趣标签，变成“爱哪款车”；通过粉丝在小程序内选车、看车、问车等d行为，给粉丝打上更细分更详尽的标签。

「一直看奇瑞汽车+问了好多奇瑞的售前问题+手机号」这样一条线索给到汽车经销商，肯定可以卖出一个比千次曝光更好的价钱。

这就是为什么媒体很值得做一个小程序的原因，辅以完善的数据埋点和统计技术，你可以比粉丝更了解他自己，到那时候还愁赚不到钱么？

那些宣布All in小程序的媒体人可能不是炒热点，他们只是比你更懂媒体。

相信没有一个媒体不希望像玩车问问一样获取到更精准的用户标签信息，但内容类小程序在微信生态一度不被看好，因为微信小程序始终坚持的“去中心化”让内容类小程序无法获取到足够的流量，甚至没有使用场景。

微信端不被看好的类目，在百度却有了发展空间。不知道玩车教授有没有在百度端上线小程序，反正我在信息流里多次刷到过“汽车之家”。

小红书、美图秀秀和汽车类小程序的成功让行业看到了百度对于“内容”扩散效应，百度信息流能够“千人千面”为用户匹配精准信息。

2. 细分垂类的长尾精准分发

如果说爱美是天性，还不足以体现百度精准分发流量的价值的话，你可以去观察一下宝宝巴士在百度智能小程序搭建的内容小程序矩阵。从怀孕指南到宝宝故事到儿歌，涵盖了母婴范畴的方方面面。

这种每隔一岁都会有几乎完全不一样需求的细分类目，需要极其精细化的运营。人工是很难做到差异化的触达到每一类粉丝，同一个宝妈群可能会涵盖0-6岁各个年龄段的母亲。

但这对算法来说简直小菜一碟：算法可以根据搜索、浏览等行为，精准的判断用户类型，并以此向其推荐最适合他们的内容。

内容行业的野蛮增长期早就过去了，未来的红利在于“精打细算”。那些公众号时代很难被挖掘的长尾流量，可以被算法精准掌控。

3. 从搜索到重决策消费的“安利”

古有人生两大乐事“洞房花烛夜，金榜题名时”，今有人生三大难题“买房、买车、养孩子”。

三件人生大事客单价均超过10万，是大部分人一年的收入，这种消费是特别重决策的。大部分人需要长时间、频繁地获取相关信息，经过细致的比对后才会小心谨慎的付费。

这种长时间纠结的状态，公众号是无法捕捉的，你无法判断刚刚关注你的那个粉丝进入到买房的哪个纠结阶段了。即便如此，买房、买车和母婴类目下仍然出现了多个千万级大号/矩阵。

但是搜索可以做到。用户的搜索行为完美的“暴露”了自己的心路历程，基于用户的搜索标签，信息流会精准的推荐相关内容到消费者。

毫不炫耀的举个例子：我最近看装修看到头疼。大概估算一下，算上家用电器我那小屋装修完了又得一个年收入。从知乎搜到微信公众号又搜到百度，留下了大量我的“纠结数据”。和微信、知乎主动获取资讯的方式不同，百度把我的“纠结标签”给到一堆小程序，然后信息流里出现了他们影子。

好不好不说，每十来条就会出现一次的内置在小程序里的资讯和问答内容，读起来真的容易一不小心就买了一个吸尘器或者抽油烟机。

4. 直接“搬运”也不失为一个良计

当然，我是说“搬运”自己的内容。

在微信生态下，将公众号/App/官网的内容直接搬运到小程序端是很难跑通的。除了前面提到的没有分发渠道外，在微信小程序端阅读内容的场景不符合用户习惯，唯一比较适合的入口是在公众号内以“加餐”的形式做延伸阅读。

延伸阅读的前提是你有足够的内容可以延伸，但当你有了足够多的内容，仅靠公众号作为“延伸”的入口就有点捉襟见肘了。比如：有丰富优质内容积累的马蜂窝，它在微信和百度端都上线了小程序。

根据量子程序的小程序统计数据，马蜂窝旗下共有6款微信小程序，除了“马蜂窝旅游攻略”外，其他均为功能型小程序。

浏览微信端马蜂窝旅游攻略小程序绑定的公众号推文，鲜有插入小程序来扩展阅读的情况。显然，马蜂窝在微信端的运营策略是通过功能来获客，通过内容“导流”的方式似乎不在他们的运营方案里。

百度端虽然只有“马蜂窝旅游攻略”这一款小程序（也可能是我只看到过这一个），但是信息流里可谓三步一岗五步一哨（因为前段时间要举办一个小轰趴在百度搜过好多民宿信息）。

假设我是一个旅游爱好者，在看过三五篇来自马蜂窝小程序的精品旅游攻略后，我几乎不会拒绝去专门下载这个App。

这就体现出了百度智能小程序对那些具有大量优质内容积累产品的优势：直接把内容“搬运”一下，就会有源源不断的流量。

百度玩内容确实有一套

百度用一年的时间完成了百家号内容创作者从0到100万的增长，可见其在内容分发方面的“天赋”。对于内容类小程序开发者/团队来说，百度智能小程序可能是第二次上车的机会。

或许我们已经习惯了微信不做中心化分发的小程序逻辑，忘记了我们的初心是获取流量。小程序也不过是另一种获取流量的新玩法，它还不足以改变互联网的运转逻辑。

我在年初曾对微信、百度、支付宝的小程序分别做过分析，文末留下一句本来想要好好解释的“悬念”，但被我“鸽”了：

微信小程序作为先行者，做了很完美的开发者教育，以至于开发者们开拓阵地到新平台后，仍然在寻找和微信对标的玩法。这一点是错误的。

微信社交生态下，裂变是重要流量来源。进入百度生态后，社交裂变不再起作用，但不代表就没了流量。相同，微信上走不通的玩法，在百度端却可以6到飞起。比如：这个“不务正业”的美图秀秀，社区搞得也蛮有声有色的。

#专栏作家#

喜新，微信公众号：喜新，人人都是产品经理专栏作家。产品经理、新媒体、数据分析师三栖。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议