「点开过」就是「感兴趣」?不要以为你真的那么了解我!

所有个推产品都应该加上「隐身模式」功能!

不论是信息流产品、电商或者是社区类产品,似乎不加上「个性化推荐」系统就算不上一个“现代互联网产品”。的确有很多个推产品做得足够好或者为公司生产了不少价值,但对于普通用户来说,调教每个产品的个推系统反而成了一种负担。

Twitter 和微博上时常会看到这样的笑话(外人看来或许是笑话,但对于当事人本人来说必然不是),在一次“偶然并且特殊的”商品搜索或者购买后推荐系统不合时宜的疯狂推荐类似产品,包括但不限于性玩具、异性服饰等等,给用户造成巨大的困扰。

我作为一个了解一些推荐系统原理和产品经理设置推荐机制的用户来说,每次(因为好奇或者某些机缘巧合)搜索、查看敏感内容或者选购部分商品的时候,都只能打开浏览器的隐身模式,在不登陆账户的情况下小心翼翼的进行,生怕日后会在个人的推荐位上留下蛛丝马迹。这样的用法虽然降低了不少风险,但终归不是长久之计,更何况在购买商品时几乎没法不登陆账户进行。

讨论这个问题涉及到推荐系统的根本,也就是究竟应该给用户推荐什么?用户究竟想看到的是什么?

我认为用户行为分类惯性行为和即兴行为两种,前者是用户真正关注的内容,是用户长期的兴趣所在,也是推荐系统真正应该发挥作用的地方;而后者却是用户不经意或是因为特殊需要而临时进行的活动,这部分是所有推荐系统都应该尽量避免涉及的。

现在的很多推荐系统似乎都太过于“饥渴”,发现一丁点用户行为的异常就迫不及待的增加推荐特征,一次偶然的用户行为带来的是长期的、甩不掉的推荐轰炸,这些推荐信息几乎是直接暴露了用户的所有行为隐私,它们带来的负面影响是长久的。

作为厂商,如果实在难以控制这个度的话,不妨给用户提供一个「隐身模式」的功能,不要把这部分用户行为记录在案(或者即便记录也不要加入到推荐系统的训练当中),也算给用户一个喘息的机会吧。

统一的推送渠道对中国 Android 生态意味着什么

工信部电信研究院旗下泰尔终端实验室6月1日发布消息称,安卓统一的消息推送标准目前已取得阶段性成果,未来将由终端厂商提供系统级推送服务(类似APNS的唯一推送通道),确保App的推送消息接收。

这样一则消息在开发者圈子和喜爱 Android 平台的用户群体中得以快速传播,如果能顺利落地,这一举措不论对于开发者还是消费者都是有重大意义的。往小了说,这一标准能对于通知推送起到规范作用,往大了说,这可能是国内 Android 生态极为重要的转折点。

背景

由于一系列「众所周知」的原因,国内的推送服务没法使用 Google 倡导的 GCM 推送系统(现已更新为 FCM),国内的 Android 开发者只能使用自建的推送服务。但随着用户对于相关使用常识的普及,越来越多的用户选择杀死不常用的后台软件,自建推送服务的到达率日益下降。

有大厂背景的几款推送服务也因此应运而生,他们声称拥有极高的推送到达率,其原理很简单,就是将使用了其服务的全部应用关联在一起,只要有一个漏网之鱼就可以把旗下全部应用唤醒,以此保证使用其服务的应用全部运行在后台,以及时获得通知。

这样的做法的确保证了消息到达率,不过坏处也显而易见,不论重要不重要的应用全部存活在后台,导致系统资源消耗极大,所谓「Android 手机越用越卡」就是如此保活的恶果。用户和手机生产厂商为了解决这样的问题采用更严苛的后台限制措施,而推送服务提供商为了突破限制使用更极端的唤醒方式,Android 开发者为了保活明知推送服务的危害也只能选择加入唤醒链,这使得整个 Android 生态陷入一种恶性循环。

推送通知的混乱可以说是整个国内 Android 生态乱象的罪魁祸首

期望

而现在公布的这一推送标准,可能从根本上切断这种恶性循环。统一的推送标准,意味着消费者和开发者不用再进行躲猫猫式的明争暗斗,推送不再需要让软件留存在后台,用户也无须考虑后台限制。

对于开发者来说,这一标准可以不再需要考虑软件后台存活率,可以放心大胆的使用更新版本的 SDK 并利用新版 Android 特性提供更优秀的软件功能。同时,由于有了统一的推送标准,第三方推送服务不再有存在的意义,删除这部分的 SDK 可以大幅降低软件包体积以及请求的软件权限。

对于消费者来说,这一标准可能从根本上摆脱应用后台驻留的问题,Android 系统越用越卡的谎言也不攻自破。同时,后台驻留带来的电量快速流失问题也会得到极大的环节。由于有了官方的推送形式,如果开发者都能按照标准进行开发,用户可以获得更一致的通知体验,并且也不必再提心吊胆,操心后台驻留的问题,Android 平台的使用成本和门槛也将大大降低。

阻碍

愿景是美好的,但实际的落地过程恐怕不会如此一帆风顺,首要的问题就在于如何保证现有设备如何接入这样的系统。根据目前的消息,这样的标准需要手机厂商在系统中预置相应套件,那对于现有产品来说,这样的条件怕是很难落实,尤其是大环境下,各厂商懒于向旧设备提供系统更新,现有设备很可能完全无法从这样的标准中获益。而对于开发者来说,目前已出售的设备占据了市场的绝大部分份额,为了让这部分机器也能达到较高的通知到达率,在相当长的一段时间内还是很难将第三方推送服务抛弃,这样一来第三方推送服务带来的链式唤醒导致的一系列仍无法彻底解决。待到使用该平台的手机得到普及时,恐怕又是几年过去。

另外,如果该标准并非强制执行,必然会有部分开发者为了自己产品的保活而坚持使用第三方推送服务,不愿切换到新的推送标准,从而可能出现劣币驱逐良币的结果。类似前些年各种垃圾短信的狂轰乱炸,也是由工信部牵头,限制企业发布短信广告的能力,保证用户可以退订广告信息,但正所谓道高一尺魔高一丈,企业为了钻规定的空子、避免被退订,设置各种花式退订关键词,让用户几乎不可能退订成功,而这样的做法正在被越来越多的企业使用。

总结

无论如何,由国家牵头推动这样的事情必然是在 Google 入华难以实现的情况下最优的解决方案。正如广告短信这件事一样,虽然没能从根本上杜绝这样的情况,但起码改善了整个通信网络空间,给了用户更多的选择权。同样对于 Android 消息推送来说,这样的标准也不大可能完全改变中国 Android 生态的现状,但必然能防止这个生态继续崩坏,并很可能在可见的将来逐渐变得越来越和谐。

先试再买:双赢的好生意

谈起付费模式,越来越多的产品开始使用订阅制的方式,不论对于消费者还是内容提供方来说,订阅制都是利大于弊的方式。从消费者角度说,订阅制相比一次收费制更灵活,价格也更具优势,同时订阅制的形式也能保证和鼓舞内容提供方更高频次的更新。对于内容提供方来说,订阅制的形式带来了更多的付费用户量,保证了用户的使用时间和粘性。

但对于内容型产品来说,订阅制也有一定的问题:即用户可能对于内容的质量、数量没有信心,订阅了代表在一段时间内与整个产品的绑定,不论内容的好坏,订阅的费用都不能退还。这种方式相比单次内容的付费反而提高了门槛。

为了应对消费者这样的疑虑,提供新用户一定时间的试用期限非常必要。试用给新用户以内容质量的保证,让用户对于内容的质量、数量有信心,一方面可以增加付费用户的数量,另一方面,也可以提高付费用户对内容的满意度。

一个典型的例子就是 Apple Music,相较于已经成熟的 Spotify 仅提供一个月免费试用期,Apple Music 选择提供 3 个月的免费试用,这或多或少使得 Apple Music 的付费用户数在 18 个月内达到 2000 万,而为了达到这个数字,Spotify 用了七年时间。当然这样的结果有苹果本身品牌号召力和时代背景的原因,但付费用户的快速增长和高满意度很大程度来源于试用期带来的信任感。

抖音是怎么做成短视频社交的

前段时间在互联网新闻中常常看到「抖音」这款应用,下载尝试了一下,从内容形式上,几乎与前几年在海外市场火了一把的 Musical.ly(妈妈咪呀) 完全一致。但却能在短视频产品云集的现在杀出一片天地,论及原因,大概是因为抖音在内容引导上做的格外出色。

众所周知,UGC 社区运营的难点在于内容生产对于普通用户的门槛,发布有趣、吸引人的内容(尤其是音频、视频内容)需要具有极高的智力和精力门槛,能够生产优质内容的用户永远占据少数,而大多数普通用户生产的内容大多千篇一律、没有特点。这样的社区慢慢就会产生类似微博的大 V 社区:少数人掌握生产内容的能力,多数用户跟从、观看内容,从而变成一个名副其实的 PGC 社区。

而「抖音」在内容的引导上降低了这个门槛。在「发现」tab 中,提供了大量的主题,每个主题中提供内容示例,给了普通用户一个模仿的范本。对于普通用户而言,创作难,但是模仿易,即便普通用户在几次尝试之内也可以创作出质量较高的内容,并且在模仿过程中可以或多或少体现个人的特色。这样的模版范例保证了用户生产出的内容质量下限,而没有限制内容质量的上限。整个社区的内容普遍高质量、低重复,形成了一个良性的 UGC 社区氛围。

啥是项目立项书

项目立项书是一个产品真正从 0 到 1 的第一步,在做成熟产品时很难经历这样一个立项过程。这次的小程序大赛中做的学区房小程序项目,就是一个跳脱现有产品、真正从零起步的新项目,我也有幸能经历这样一个立项过程。撰写立项书是一个复杂的过程,因为立项书不是简单的功能规划,确定的是整个产品的大方向,未来的迭代、更新都要以此为基础。

项目立项需要考虑长远。一个项目的立项,不仅仅需要提出项目的短期目标,也要考量其长期迭代方向,为产品的未来做足考虑。只顾眼前,产品的指向性就会不够明确,未来迭代的方向也不明了,未来的迭代中极有可能出现南辕北辙的情况。

项目立项同样需要考虑周密。作为整个产品的指导方针,立项书需要厘清整个产品逻辑,明确各部分组件的功能、目的、使用场景。清晰、明确的立项书是产品的指南针,而含糊的立项书在一开始就给产品埋下了不安定的种子。

灰度测试怎么玩?

微信最近“增加”了两个小功能,一个是「搜一搜」,另一个是「看一看」。之所以在增加上加了引号,是因为这两个并不算新功能,「搜一搜」的功能在原来的搜索框内可以完成,「看一看」也就是原来搜索页上的「朋友圈热文」。但推出这两个小功能的媒介——「实验室」,却是微信上实打实的新功能。

实验室这样的灰度测试在很多产品上都有先例,平台级的例如 iOS 上的 Testflight、Google Play 的 beta test;也有应用级的例如即刻的 3.0 实验室功能、Chrome 的测试版本等等。灰度测试有诸多好处:方便验证需求、小规模测试效果、预热舆论方便推广等等。这些好处不必详述,但灰度测试并非万能,本身也具有一定的缺陷和误差。

从验证需求的角度上说,灰度测试通常是需要用户主动申请的,而愿意参与灰度测试的大多本身就具有较鲜明的用户特征:愿意尝试新功能、对产品忠诚度高、对新功能可靠性的容忍度高、愿意提供用户反馈等等。这样的用户群体很可能不能完全代表所有用户群体的意见和态度,尤其是像微信这样用户量庞大、用户特征复杂、覆盖各年龄层次教育水平的“大产品”。参与灰度测试的用户喜欢的功能普通用户可能根本不买账,测试用户反感的普通用户也可能非常需要。

从用户体验上说,普通用户对于灰度测试不会非常乐观和欢迎,有些用户觉得这样的形式是将用户作为小白鼠,是产品对用户的不负责任。另外,在很多用户的想法中,测试意味着不稳定,甚至意味着不安全。因此灰度测试可能会影响普通用户对于产品的信任感。

从行业竞争角度上说,灰度测试也可能过早暴露产品迭代方向和战略倾向,让竞品有机可乘,甚至在功能正式上线之前就被竞品复制,导致错失商业良机。

用户怎么就对游戏化乐此不疲

去年下半年,支付宝低调上线了「蚂蚁森林」小模块,除了在春节期间做过一阵子相关用户激励活动之外,没进行过大规模推广。我接触的时间比较早,那时候知道这个小模块的用户还不多,好友通讯录里除了在支付宝工作的同学外也没有别人使用这个功能。乍看之下,这就是个简化版、轻量化版的偷菜游戏,前些年这种题材社交游戏的充斥已经让很多用户感到厌倦,但现在再看,会发现好友的能量几乎都会被很快收集,自己的能量也经常受到好友的光顾。这说明这个小模块不光用户量越来越多,活跃度也相当可观!微信运动的设计和蚂蚁森林也具有异曲同工之妙。

即便是一个被用烂题材的游戏性尝试,也依然能在现在得到用户的买账,游戏化的引入能为一个内部具有人际关系网的产品带来极大的好处。游戏化的设计本身就能引起用户的兴趣,给关系链中的用户产生互相竞争的心理,在游戏中的用户间互动也让用户互相提供了正向鼓励,增加了话题,提高了用户之间的互动率,进而提高整个产品的活跃度。

之前在创业的产品中也做过游戏化的尝试,虽然最后产品失败了,但这个部分的尝试一直是产品中的亮点。对于产品内游戏化部分的设计,与单纯设计游戏不同,应尽可能简化,也不应占用用户较长的使用时间。保持用户的长期低热度的活跃应是游戏化的主要目标,繁琐的设计、复杂的互动反而可能适得其反,让用户快速厌倦。不设置输赢,将竞争化为攀比,绝对化的输赢只能取悦一部分赢的用户,而输的那一部分,会迅速丧失热情和耐心,而淡化输赢、刺激所有参与用户的攀比心是整个竞争体系的关键,这样的良性竞争可以让几乎所有的参与者得到相近的获得感。

小程序是拉拢边缘用户的好途径

从流程上说,微信小程序并不比完整的 App 使用起来更方便,Android 上确实可以将小程序快捷方式添加在桌面,但在 iOS 上,进入微信小程序首先需要进入微信,然后进入发现 tab,进入小程序列表,找到需要的小程序并打开,相比普通 App 的打开流程多了很多步骤。在这样的情况下,让用户愿意使用小程序,与引导用户下载安装 App 相比难度不相上下。小程序的开发不能走 App 大而全的路线,也应从功能选择上避免一些选择。

其中最重要的一点,是避免让小程序承载需要长停留时间的功能。扎根于微信的小程序在使用中常会被频繁的微信消息提醒打断,如果小程序提供的功能需要用户长时间停留会造成严重的不连贯性。诸如长文阅读类、电商类产品做成小程序是极不明智的。

保持纯净,避免添加非核心功能。在我理解中,小程序的存在是拉拢 App 产品边缘用户的重要措施,这部分边缘用户或是因为需求频次低或是对产品非核心功能无需求,极可能因为 App 的体积庞大等原因卸载 App 产品。而小程序小而精的特点正好契合了这部分用户的需求:不占容量、用完即走、不用担心垃圾信息的推送,这些都很好的满足了这类用户的需要。如果小程序也走大而全的道路,等于放弃了小程序的特性优势。

个性化推荐的好与坏

个性化做聚合,大部分产品都把个性化推荐作为一个必不可少的 Feature,但大部分实现形式都比较简单粗暴,差一点的直接靠标题分词匹配关键词进行推荐(比如百度),好一点的考察更多维度(用户画像、标签、每篇文章阅读时间等)综合考量进行推荐(比如微信的朋友圈热文)。前者经常出现因为一次偶然用户行为而大量无用且同质的推荐出现,后者也会在一定的用户习惯训练下让推荐的内容集中于个别几个话题之中。

从用户角度上说,个性化推荐的确可以方便应用推送自己“已经”感兴趣的话题内容,但推荐的形式通常都很蠢,即便是后一种相对“智能”的推荐系统,依然会让用户看到的内容越来越固定、越来越局限。而用户在聚合类产品中,希望获得的可能是更广阔的视野,更丰富的内容,希望看到的可能是一些平时没关注过、不了解的东西。花费大力气做出的个推系统有可能反而弄巧成拙。

做不做个推,如何做个推,值得思考。不做个推的即刻也同样能得到市场的认可,在聚合类产品林立的市场中占有一席之地。做个推,也可以着力于多维度考量用户行为,相似内容排查筛选和适当插入扩展延伸推荐等等,不走简单粗暴的分词-匹配-推送路线。

别推送让用户讨厌的消息

消息推送的内容通常包括两部分,一部分是针对用户个人的消息提醒,另一部分是产品给用户的内容或活动推荐。前一种实现功能性,保证用户收到消息的及时性;后一种实现产品自己的运营需要,提高用户活跃度。

两部分相辅相成,前一部分更多有利于用户自身,后一部分更有利于平台发展。两部分的主要受益者的不同导致了两者在一定程度上处于冲突的状态,用户不喜欢成天推送运营消息的产品,产品也不甘为了用户体验放弃推送这一绝佳的运营渠道。

我认为要做用户愿意打开的推送消息,主要得从内容、时机、频次、文案几个方面来打磨。

  • 内容方面,推送消息应对用户日常使用场景具有高关联性,让推送的内容对用户有价值、有吸引力。内容的价值多少决定了用户会不会把你的产品放进通知黑名单里。
  • 时间上,根据目标用户人群的不同选择合适的时机,没人希望在忙碌和休息时间收到不合时宜的通知推送。
  • 频次上最难以把握,不同产品的用户有各不相同的特征,对推送频次的容忍度也不同。比如上班族和学生都不希望上班/课时手机不停地推送与自己不相干的内容。同一个产品中不同活跃度的用户也对推送频次的接受程度也不同。产品的活跃用户一定会更关心产品动态,也更能接受高频次的推送,低频用户则会因高频推送而逃离。
  • 文案是推送消息的门脸,能通知栏里脱颖而出就等于有了更高的点击率,简洁明了的文案也不至于让用户对推送内容一头雾水。另外,文案还应照顾用户的情绪,既不唯唯诺诺也不居高临下,即便是网易云音乐里那批最擅长自黑的用户也难以接受诸如「你这么爱听歌,一定活得很难过吧」这样的文案。

消息推送可以是利人又利己的工具,用户也可以从推送的内容受益,平台可以通过推送笼络用户,但当推送变成一种骚扰,用户一定会把你赶出自己的手机。