编辑导语:目前我们可以看到,视频号已经成为微信的重点布局模块,很多人在使用微信时也看到了视频号推荐功能。作为用户,你对这个功能有什么感受?微信为什么要上线?本文从用户、创作者、平台三个方面来分析这个问题,一起来看看。
目前在订阅号列表中,已经推荐了所有在线视频号(一个月左右)。不知道老铁的感受。
我从用户侧、创作者侧、平台侧三个方面总结和分享个人观点:
首先,从用户的角度来说,作为一个用户,总的来说,我个人的体验并不友好。
1.强制性建议
如果用户关注的微信官方账号与视频号绑定或者,无论你是否关注他的视频号,都会收到视频号的推荐(如果你只关注视频号也会收到推荐)。不管用户是否同意。
2.无法关闭
作为用户,我没有权利选择是否接收,甚至微信根本不提供选择关闭的选项。如果有,那就是选择注销自己关注的微信官方账号。这种强制逻辑不像也不应该是微信的风格。
3.视频号的内容可能不是微信官方账号粉丝喜欢的。
以我自己为例。在我关注的微信官方账号中,有一个叫:keso怎么想的?
Keso老师写的每一篇文章我都会看,这从它出现在我的“定期阅读吧”就能看出来。
但是keso老师的视频号基本上都是自己宝宝的日常生活(我没有别的意思,只是举个例子),但是和他写的文章比起来,我不得不承认,我对keso老师发的视频号的内容不是很感兴趣,一开始会看,后来就直接无视了(还是那句话,我很尊重Keso,只是举个例子)。
当然,keso先生可能只是把视频号当成了他生活朋友圈的视频版,但是因为视频号新的推荐机制,在微信官方账号里推荐给了他的粉丝。
所以我会想屏蔽视频号推荐,但是我会发现上面提到的问题:入口没有关闭或者屏蔽。
我可以不关注keso老师的微信官方账号吗?
比如我关心的:我最爱历史。比如我中午午休的时候看了它的推文,但是它的视频号和文章类型完全不一样。同样,我也完全没兴趣看。
所以我的看法是:一个微信官方账号创作者的视频号的内容,未必是微信官方账号粉丝或者读者所向往的。
如果用户无法选择屏蔽或者关闭视频号,那么从长远来看,对于视频号的用户来说,将是一种【消费】。
4.重复内容
如果创作者只推送了微信官方账号中的视频内容,同时更新了视频号(并与微信官方账号绑定),那么作为用户,他会收到两次相同的推送。
这难道不是对用户耐心的另一种[消耗]吗?
5.进一步消费
要知道,订阅号列表早在视频号之前就开始推荐【广告】了。
再加上和视频号推荐一起出现,就算你是6.4寸全面屏,也无法在这个屏幕里获得任何有价值的信息。进一步[消费]用户。
这种体验真的很惨。
6.消费习惯
这最后一条是正面的,是好事。
毕竟每个用户对于信息或者内容的消费习惯是不一样的。不是所有用户都喜欢看图文,也不是所有用户都喜欢刷短视频。
我们可以从提问的三种方式看出这一点:
你看,从内容消费习惯来说,用户总想为同样的内容找到更合适的消费内容的方式。
所以视频号的推荐可以匹配那些喜欢通过视频获取信息或资讯的用户。
但是,以我为例。我个人不习惯把我曾经写过的一篇五六千字的文章录到同一个视频里,然后分发出去。
我在想,如果把文章转录成视频,如果没有新的信息增量,似乎对用户不公平,浪费用户的时间。
看来是时候改变一下了。
我个人还是通过图片、文章或书籍而不是视频获取信息或知识,包括短视频和长视频。
二、创作者侧1.增加流量入口
对于创作者来说,当然是好事。
众所周知,视频号与Aauto Quicker、Tik Tok最大的区别在于其基于社交算法的推荐机制(并且没有冷启动流量池)。
我在《为什么不爱刷视频号》里举了个例子。即便是像央视新闻这样的官方媒体,Tik Tok视频号的数据也可以用泥泞来形容。
我猜这也是视频号不被创作者重视的原因之一吧。
现在订阅号增加了视频号推荐,意味着视频号又多了一个流量分发渠道,而不是单纯依靠社交推荐的私域流量。
据大伟本人实测,即使用户只关注【视频号】,不关注其绑定的微信官方账号,也会在订阅号消息列表中收到该视频号的内容推荐,如下图所示:
2.视频号与微信官方账号粉丝交流。
这意味着你在微信官方账号的粉丝就是你视频号的粉丝,即使他不关注你的视频号(前提是视频号绑定了微信官方账号)。
相当于直接通过微信官方账号来反转视频号。
去年我写过一篇文章《为什么视频号一定要配微信官方账号》,阐述了三个原因:
目前微信官方账号越来越重要。
对于创作者来说,微信官方账号成了视频号撬动流量的杠杆。
现在,当视频号和微信官方账号已经绑定后,用户在视频号观看视频时,可以直接关注微信官方账号。
视频号直播时,还会显示微信官方账号的身份,引导粉丝关注微信官方账号。
此外,用户发布的视频号动态(包括历史视频)会同步显示在微信官方账号首页。
用户点击名称,直接跳转到微信官方账号中的视频号菜单,而不是视频号。这是否意味着,在某种程度上,视频号属于微信官方账号的一个附属功能?
这也契合了月初微信将视频号重新定义为微信生态中原子化组件的思路。
让它深入人心。
3.模糊推荐机制
订阅号中视频号的推荐机制我一直不明白怎么推荐。
总体来看,订阅号列表中的视频号推荐机制比较模糊,随意性较大。
目前一次最多只推荐两项,有时会推荐一项(大家注意一下,在微信消息列表中,当几个订阅号显示为未读时,视频号推荐会算作一项未读)。
如果不更新,肯定会收到视频号推荐;比如我自己的视频号更新后,为什么没有收到视频号的推荐?朋友送的喜欢能收到吗?每次开入口都有订阅号吗?
我不这么认为。有时候点了订阅号,连续几次都没有,有时候连续两次都有。
如果同时有几个更新,应该先推荐哪个创作者来补两个视频号推荐?创作者半年前更新的视频号内容还会进入推荐流量池吗?如果不是,你多久前不推了?
创作者不知道,用户当然也不知道这个推荐机制是什么。
一点也不像微信官方账号:
一方面,用户会有心理预期;另一方面,作为创作者,他们也清楚地知道,用户只要更新,就会全额收到推文。
三、平台侧1.视频号的疯狂迭代
一年来,视频一直在以疯狂的速度迭代,三天一小版,五天一大版。
微信公开课提到:
从2020年10月到2021年12月,视频号已经完成了17次迭代。
比如微信官方账号的文章支持视频号卡的插入,微信官方账号与视频号的绑定,订阅号消息中出现的视频号等等。
2.培养用户习惯
一方面,视频号本身通过版本迭代会越来越完善。
另一方面,更重要的是,要通过更多的场景接触,培养用户在微信生态中短视频内容消费的习惯。
视频号只有具备足够的用户习惯和粘性,才能吸引更多的创作者,形成良性循环。
到目前为止,微信里几乎所有能打开的流量和入口都已经释放到视频号了。
场景,包括但不限于群聊、朋友圈、私聊、直播状态展示、微信官方账号关联、西城男孩、五月天演唱会,前段时间正式运营,可谓无孔不入,无所不知。
甚至为了进一步培养用户的消费习惯,视频号还推出了直播预订推广和关联交易的新功能,以利益驱动的方式引导用户。
但我只是担心,当越来越多的视频号运营者利用裂变来“骚扰”用户时,会不会适得其反?
为什么好友分享的视频号不能直接预览,要点击进入才能观看?我的看法是:引流视频号,进一步培养用户习惯。
3.视频号分步改进算法推荐
视频号正在内测中逐渐减少社交推荐,而不是机器推荐。第一,通过视频号,直播入口,加大推荐和引导。
二、视频号在内测中会去掉【好友】。
对于这个观点,感兴趣的老铁可以看看《视频号从社交推荐向机器推荐妥协了吗?这是我六个月前写的。
这意味着,在某种程度上,视频号的主要社交推荐并没有带来预期的效果或者不能满足视频号更快发展的需求,或者说它依赖于更人性化的算法推荐。
之前看到过类似的观点,分享一下:
Tik Tok目前的成功已经证明了算法推荐的胜利。微信的护城河是社交关系。今天它为了短视频直播损失了很多时间。不是因为微信内容没有短视频直播这种媒体进化,而是因为他无法像Tik Tok一样,充分利用推荐的算法作为新人类获取信息的基本途径。
包括a auto quickless和a auto quickless,显然都在把握短视频直播内容的媒体红利,但在组织能力上非但没有输,反而被Tik Tok反超。而是在短视频直播商品内容供给充足的情况下,仍然固守双排社交关系分发基本盘,没有果断完成并转化为算法推荐为核心的情况下,他们在败北
当然,在Aauto quickless 8.0版本之后,算法推荐,也就是公共领域流量的分配有所加强,但在某种程度上,必然会淡化其一直引以为傲的私有领域属性,也就是主播和粉丝之间的粘性和忠诚度。
最后简单总结一下。
未来用户在微信中接触和消费的视频号会越来越多。
不,更准确地说,是越来越多的[视频]内容。就像今天的微信官方账号,普通用户可能意识不到它的存在,但它无处不在。
至于视频号,时间会告诉我们答案。
附:视频号如何关联微信官方账号?首先你得有个微信官方账号。其次,你得打开视频号。
接下来通过视频号个人主页找到“账号管理”,进入看到“绑定微信官方账号”,输入要绑定的微信官方账号ID。微信官方账号管理员收到绑定通知后,确认完成绑定。
如果不想点击视频号头像直接跳转到微信官方账号首页?
此时,你只需要修改微信官方账号和视频号的绑定关系。有两种方法可以实现这一点:
第一种方法,通过“微信官方账号后台-设置和开发-微信官方账号设置-账号详情”,选择“视频ID”,点击跳转到视频号首页。
第二种方法可以在手机上实现,可以通过“视频号详情首页-'…'-右上角账号管理”解绑(请慎重)。
看完这篇文章,老铁:我还没开通微信官方账号,马上开通;如果视频号还没链接,现在就链接。以上。
#专栏作家#
孟大伟,微信微信官方账号:孟大伟,人人都是产品经理专栏作家。前百度高级产品经理。持续关注电商/短视频/引流和变现,让世界不断前进。
本文由人人作为产品经理原创发布,未经作者允许,禁止转载。
图片来自Unsplash,基于CC0协议。