用户端走不通，购物单这一商业模式宣告失败。值得一提的是，3月13日微信全新上线的“小程序订单管理”功能，正是同时满足了用户在“订单管理”和“交易保障”两方面的需求。2019年5月，好物圈上线“圈组”功能，它类似微信群，用户通过新建圈组，即可实现种草内容的分组推荐。甚至在功能对比上，圈组也明显落于下风，入口隐蔽，用户交流困难，用户当然没有动力从微信群迁移到圈组。好物圈社群种草方向的尝试，同样宣告失败。
微信圈子一共经历了数次大变动，发展到现在它形成了一个以兴趣为主的社区，并吸引了不少圈子与用户的驻足。但是在貌似繁荣背后，微信圈子仍然有不少亟待解决的问题。
3月12日晚，微信圈子官方透露，圈子接下来将会迎来一次较大的更新，部分调整如下：
当时在朋友圈看到这条消息时，自己内心还是有点小激动的，因为微信圈子终于要有点兴趣社区的样子了。
可能很多人不太清楚，微信圈子早在2018年就诞生了，当时还叫做“购物单”，定位是一个电商工具，期间经过多次改版，才逐渐转向兴趣社区的方向。
在写这篇文章之前，我本来在写《微信圈子：兴趣社区or兴趣孤岛？》的选题，本意是想吐槽微信圈子走偏了，文字中也多少带着点恨铁不成钢的失望。
但现在，我决定推翻原来的部分观点，从微信圈子的五次大方向调整，和大家聊聊这个产品的“前世今生”，还原当时踩过的坑，并且展望未来的可能走向。
01 购物单：电商工具（2018.09-2019.03）2018年9月28日，微信上线“我的购物单”，不久后更名为“购物单”（虽然名字不同，但功能上基本没有调整，接下来统称为购物单）。
对于这一功能，微信搜索应用部产品经理蒲昭昭在微信公开课上（2019年1月）是这么介绍的：
“购物单是一个通过人和社交网络进行信息分发的新工具，微信小程序有各种各样的服务和商品信息，购物单就是帮助用户对信息进行统一的管理和沟通，并且依靠用户行为检验这些信息的真实性及质量。”
简单来说，它是一个电商工具，可以将用户在不同小程序中购买的订单、收藏的商品都聚合到一起，相当于微信内统一的购物车。而要实现这一功能，商家的小程序得先接入购物单功能。
讲到这里，购物单的整个商业模式就出来了（如下图）：
而这一模式能否跑通，则取决于购物单能否同时满足两端的需求，为两端提供某种核心价值。
1. 商家端
购物单可以给他们讲一个流量池的故事，比如未来购物单将聚合了各类商城的存量用户，这将是一个相当可观的免费流量池。而且由于从订单处可直接跳转至对应的小程序商城，因此用户每次打开购物单，都将会是一次刺激复购的机会。
这样的产品并不少见，我的上家就做过一款类似的，叫某某智慧商圈，最初拉商家入驻也是靠这样的故事“空手套白狼”，只要前面谈成了后面的故事就更容易讲下去。也就是说，商家端可以走通。
2. 用户端
腾讯一直有电商梦，购物单的出现，某种意义上可以视作其电商梦的延续，它想做的，就是将散落在大量不同小程序中的用户消费记录聚拢起来，帮助用户快速管理订单信息。
理想很丰满，但现实很骨感，因为用户端压根就不认可这个产品。
为什么不认可？因为没有解决用户痛点。
关于痛点，梁宁是这么定义的，“痛点是恐惧”，我觉得非常准确。
当用户在小程序中购买商品，他们恐惧的或者说害怕的，是没有保障，而订单管理不方便只不过是难受，如果把难受当成用户的痛点，或者当作用户的切入点，那么必然会导致失败。
在购物单的产品逻辑里，订单管理是0，订单保障才是1。如果没有给用户提供 1 这个核心价值，后面给再多 0 的能力也没用。
用户端走不通，购物单这一商业模式宣告失败。
值得一提的是，3月13日微信全新上线的“小程序订单管理”功能，正是同时满足了用户在“订单管理”和“交易保障”两方面的需求。只不过现在这是两个不同的产品了，我们这里不做展开。
02 好物圈：社交推荐（2019.03-2019.05）第一个方向没走通，圈子团队决定另辟蹊径，“好物圈”就是这个时候诞生的。
好物圈，名字基本透露了它想要做的事，即种草，因此当时的产品就新增了“朋友推荐”的功能，让用户可以看到朋友推荐及购买过的商品。
从功能上看，商品的社交推荐确实可以做，微信内生态也确实存在大量的商品推荐行为，不过问题在于，好物圈这一方向与朋友圈、群聊的功能重合了。
可以设想一下这个场景：当我们体验到某款好物，并且有着强烈分享意愿时，我们在微信内一般会怎么做？
- 如果是书影音，我们可能会直接发朋友圈，安利给所有微信好友，因为这类商品具有强社交属性，并且覆盖人群更广；
- 如果是美妆服饰、母婴用品、科技数码产品，我们可能会特定的群，比如闺蜜群、宝妈交流群、数码爱好者群，相比书影音，这类产品会受到特定人群的限制；
- 而如果是内衣这类隐私性极强的商品，我们则大概率会直接私聊分享，而不会公开安利。
这样一来，就会出现一个问题，好物圈的“朋友推荐”在内容丰富度上远远不够，用户没什么可看的内容。而当时就出现过这种令人尴尬的情况，在好物圈，用户几天时间才能刷到一条新的内容，微信好友数量少的，甚至一个月都不见得能刷到一条。
在这种情况下，用户压根就没有动力去使用好物圈。毕竟刷个朋友圈看到的种草内容可能都比好物圈要多。
除了功能重合导致的内容缺乏，好物圈当时还犯了另外一个错误，”朋友推荐”功能设计缺陷带来的推荐行为扭曲。
1. 利己的社交展示超过利他的价值分享
好物圈的“朋友推荐”功能，极大地强化了好友关系对商品的信任背书，并且通过交互功能上的设计，弱化了商品的价值展示，用户需要多次点击才能查看。用户愿意进入其中，更多是因为好友关系，而非被内容吸引。
2. 利己的营销需求超过利他的价值服务需求
好物圈当时吸引了一批商家入驻其中，他们利用好物圈的“朋友推荐”功能，在其中频繁发布有关自家商品的营销内容，这些商品是否真的值得拔草我们不得而知，但整个种草生态已经背离了产品的初衷。
好物圈社交推荐方向的尝试宣告失败。
03 好物圈：社群种草（2019.05-2019.12）第三个方向，是好物圈社群种草方向。
2019年5月，好物圈上线“圈组”功能，它类似微信群，用户通过新建圈组，即可实现种草内容的分组推荐。
尽管这次调整，一定程度上解决好物圈此前存在的的两大问题，即内容丰富度不足和用户推荐行为扭曲，但它依然没有回答一个核心问题，即好物圈圈组与微信群的本质区别在哪里。
甚至在功能对比上，圈组也明显落于下风，入口隐蔽，用户交流困难，用户当然没有动力从微信群迁移到圈组。好物圈社群种草方向的尝试，同样宣告失败。
04 微信圈子：兴趣孤岛？（2019.12-2020.03）社群种草的方向虽然失败了，但这次尝试，却让好物圈团队看到了圈组在UGC以及内容沉淀上的发展潜力，好物圈开始有意识地往兴趣社区的方向进行调整。
2019年12月，“好物圈”更名为“微信圈子”，算是从名称上正式确定兴趣社区的发展方向（之所以说是名称上，是因为在此次更名前，圈子团队就已经开始行动了，比如邀请豆瓣、微博超话、百度贴吧等达人和优秀运营者入驻等）。
这一时期的微信圈子发展得也确实还可以，圈子类目从最开始单一的种草，逐渐拓宽至同城、财经、艺术、旅行、美食、影视等20多个分类，圈子数量也从寥寥几百个，攀升至现在的2万多。
虽然小有成绩，但同时也暴露出一些亟待解决的问题：
1. “积分体系”问题
微信圈子设有作者星级以及圈子积分两大积分体系，目的是为了更好地激励社区UGC内容。
但这种靠奖励积分建立起来的UGC机制，很容易触到天花板，一个很典型的例子就是，微信圈子到现在都无法确定出4星及以上星级作者的权益，因为官方也不知道怎么办。
于是，现在就出现这样一个问题，非圈主创作者要么没动力继续创作，要么用已得的权益创建新圈，离开老圈。因此，我们现在看到的2万多个圈子，某种意义上是一种虚假的生态繁荣。
2. “圈主压力”问题
微信圈子设有投稿收录功能，用户发布的作品必须通过圈主/管理员的审核才会展示。这样的功能，相当于是平台将内容审核的部分权力让渡给圈主，会极大地加重圈子管理者的运营压力，对于粉丝体量庞大的圈子来说尤甚。
3. “兴趣孤岛”问题，也是微信圈子目前存在的最大问题
用户加入圈子后，可能会对不同圈子的多位特定创作者产生内容兴趣并形成关注意愿，但如今的圈子设计，却没有给到用户的这类需求一个出口，用户只能通过频繁进圈子、找创作者的繁琐操作，去实现与创作者之间的连接。
因此在当下的圈子生态里，似乎有且只存在一种关系，即圈主与用户的关系。
但圈子不应该是这样的。
圈子不是圈主们的社区，而是所有圈子用户聚集在一起形成的社区，用户聚集在一起产生内容，用户与用户之间互动形成亚文化，是独属于圈子的亚文化。
写在最后2020年微信公开课上，张小龙预告“短内容”产品即将上线，当时很多圈主猜测会是新版的微信圈子。
后来的事情大家也都知道了，张小龙口中的短内容产品其实是“视频号”，并且当时有着全集团给它的诞生“呐喊助威”，甚至连张小龙本人也现身其中与大家互动。当时就有不少圈主调侃道，“圈子到底是不是亲生的？”，也有部分大圈圈主宣布放弃圈子，转战视频号。
微信圈子其实承载了很多早期玩家的期待，但这一路走来却不温不火，着实挫伤了他们的积极性。
另外值得注意的是，社交产品和社区产品，虽然只有一字之差，但在产品设计与平台运营上却差别甚大，就像我们前面提到，一个社区的成型是要看是否有亚文化形成。
而圈子是从微信的土壤中生长出来的，那么它在形成自己亚文化的过程中，大概率会受到微信多元文化的掣肘，怎么将这种掣肘转化为自己的推动力，将会是圈子的第五次出发面临的最大难题。
成王败寇，在此一役。
作者：一拳超人的弟弟，互联网媒体人，产品爱好者，说话不太利索，走起路来贼快，脑子时常沸腾。 个人公众号：游牧志（ID：nomadic-diary）
本文由@一拳超人的弟弟 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
,
