红点系统设计完全指南

来源:产品之术 2020/02/10 阅读:3704 评论:0
分类: 产品运营
活动盒子活动运营工具,一站式解决APP运营拉新、促活、留存难题,提升用户转化! 了解详情

为了让大家正确认识红点,并且设计好红点系统,我准备用这篇文章聊聊:红点的前世今生,我们该如何认识红点,红点系统的坑在哪,如何做好红点机制。

红点系统设计完全指南

作者:花生酱真是太好了 

来源:产品之术(ID:Whoisthatdog)

最近刚好在搭建PUSH和红点系统,整理了一些心得,跟大家聊聊这个小玩意。

我们用APP的时候,见得最多的就是各种各样的红点。这些红点色彩极度饱和,以至于我们几乎无法忽略。

在意义上,它们有的告诉你还有多少未读消息,有的层层递进把你引导到一个广告入口,有的逻辑隐晦让你怎么点都消不了。

相信对于很多像我一样的强迫症患者来说,对红点真的是又爱又恨。

有红点,就总想把它点掉,而没有红点,又怕自己漏掉重要信息。

为了让大家正确认识红点,并且设计好红点系统,我准备用这篇文章聊聊:红点的前世今生,我们该如何认识红点,红点系统的坑在哪,如何做好红点机制。

红点的前世今生

红点机制2009年出现在黑莓手机上,2013年逐渐在ios平台使用,到现在几乎是APP标配。

俗话说:无红点,不套路。

从一开始的单一红点,仅仅提醒待办事项或者更新事项,演化成现在复杂的红点系统。

比如,用数量红点来提醒待办数量。

比如,用文字红点来提醒用户优惠信息。

比如,用多层红点来引导用户层层深入。

红点之所以这么有魅力,就是因为它充分利用了人类的强迫症和好奇心理,能够起到强引导的作用。

一个好的红点逻辑,应该能让用户一目了然红点:什么时候出现、为什么出现、怎么消除。

这背后需要红点机制复杂逻辑的支撑,如果做不好,就会像上面说的,让用户抓狂。但如果做得好,就能够起到影响用户心智,成倍增加转化率的效果。

红点的复杂逻辑

有些同学可能会怀疑,不就是一个红点吗,有更新出现,已阅读消除,不就可以了嘛?

这也是我一开始的想法,直到我遇到一个个坑,才知道这东西有多么复杂。

既然红点代表着更新,那么我们就聊聊更新这个概念。

对于APP来说,什么算作更新呢?

通常来讲,内容的推送时间晚于用户上次观看的时间,就说明内容对于该用户来讲是新的。

那么问题来了,内容推送时间可以后台记录,那么用户上次观看的时间,要怎么取呢?

有的同学说,取查看时的系统本地时间啊。

这是不合理的。原因是,系统本地时间是可以修改的,如果遇到用户恶意修改,红点机制就崩掉了。所以合理的方式是,由前端或后台记录当时的服务器时间,拿服务器时间作为更新判断指标。

那么新的问题又来了,既然要拿取服务器时间,那么就要跟服务器进行交互,来询问是否展示红点。而这个请求量级,是很大的。比如,用户进入微信首页时,如果有更新的朋友圈,用户需要在底部导航「发现」处看到红点,而「发现」的红点逻辑,其实是源于朋友圈有更新。也就是说,用户在进入微信首页时,已经请求到了朋友圈的更新内容逻辑。

所以,看上去简单的红点,其实是涉及到多个层级页面的一次请求,并且往往随着页面跳转和点击来触发,对服务器的压力非常大。

怎么解决呢?这块就涉及到同步和异步的逻辑。

一般来说,如果并发量大的客户端动作,我们可以通过缓存和限流来处理。比如,如果我们限定一段时间,假设是5min,在这5min内,如果请求过红点,则不再请求红点接口。这样就可以大大减少服务器的压力了。

那么,这个时间怎么定呢,是拍脑袋定5分钟吗?肯定不是的。

一般来说,这个时间要取决于后台能够承受什么频次,以及,从用户体验上讲,我们的用户能够接受多长。从用户体验上讲,如果你的用户每次操作间隔很长,并且需要红点的内容不多,那么只要设定一个略短于操作间隔的时间,就能保证用户每次操作都能触发一次红点拉取,对用户体验是影响不大的。所以,遇到类似的问题,需要通过数据分析来找到性能和体验上的平衡点。

只有这一种实现方式吗?不是的。

很多人会发现,自己还在首页,没有进行任何操作,红点却突然出现,这是怎么回事呢?

这个时候,对比于上文的前端请求,往往是后台推送的红点。

比如在进行各种运营活动的时候,在有模块更新的时候,就可以使用推送红点机制,来推一个临时红点给到客户端。日常的未读提醒红点和活动运营红点,都是APP引导,比较常用的手段。

那么解决了红点产生的问题,要如何解决多个红点的问题呢?

有的页面会出现多个红点的情况,如果这些红点的逻辑不一致,就会让用户很迷惑。比如,下面的红点表示的是有多少新增的消息你还没读,而上面的红点是一种优惠模式的提醒,这两种红点样式近似,但有区隔。如果用一样的样式,用户就会产生反射,当意义不一样的时候,用户会觉得很迷惑。

所以,如果需要有多种意义的红点,要使用不同的样式。

聊完了红点的产生、多个红点,再聊红点的消除:

通常来讲,有的信息是阅读即可,比如朋友圈。有的信息是需要点击详情查看,比如短信。那么设计他们的消失逻辑呢?有2大原则:

第一,上层页面红点逻辑跟下层页面走。如果有一个短信未读,就需要在ICON处加1,在列表页展示红点。点击进入详情后,列表页红点消失、ICON处红点减1。如果下层的红点不消失,上层的红点也不变。

第二,页面发生跳转之前,往往红点逻辑不变。如果有一个信息流页面,当你进入时,有10条红点信息,而你点击了其中1条时,再返回,其它9条是否消除?我这边的经验是,点哪个、消除哪个,哪怕其它红点消息是阅读性的,也不变。原因就是,当用户了解到自己有10个未读,而处理又必须有先后的时候,不能在用户还在处理进程中的时候,帮他把未处理的信息变成已处理。

红点消除是一个逻辑问题,大家需要根据场景来深入思考,确保把页面内、跳转、点击、曝光等情况下的消除逻辑都考虑到。

如何设计好红点?

想设计好一套好的红点机制,需要有一定的框架。

首先要明白的是,红点是一种引导用户、干预用户的机制,这种机制需要有限制,不能被滥用。

所以一般,我们都会设计红点上限。比如,同一用户,每天看到的红点数量有上限,同一个页面的红点数量有上限。相反,不加规范的话,想想我们的手机屏幕吧,被多少APP强行挂上了琳琅满目的红点。

规范过后,就是各种类型红点的机制。比如未读提醒型、个性推送型、运营型。

未读提醒型,要从里到外层层梳理,再把冲突和消除情况考虑充分。

个性推送型,要做好冲突规则的梳理,避免和未读提醒型产生冲突和歧意。

运营型,要设计多样化的红点模板样式,针对不同的意义,使用不同的推送样式和机制。

梳理完各种类型红点后,还需要进行时效性、性能的评估。

通过评估用户操作时长、频次、请求数量等数据,结合服务器性能,来选择哪些红点被限流,哪些红点需要全力保障实时刷新。

充分考虑以上情况后,才能算设计了一个合格的红点体系。

希望能帮到大家,感谢。

本文由@产品之术 授权发布于活动盒子,未经作者许可,禁止转载。


活动盒子(huodonghezi.com),一款助您大幅降低开发与运营成本,实现场景化、精细化、数据化、自动化,助力运营实现快速拉新、留存、促活,提升用户转化的活动营销工具。应用场景支持:APP应用+H5+微信公众号。立即去体验:http://houtai.huodonghezi.com/users/register 

上一篇: 盲盒的套路

评论

APP运营解决方案

助力APP运营实现拉新、

促活、留存,提升转化率

立即获取方案
热门标签
数据分析 活动策划 活动工具 活动复盘 活动预热 活动设计
热门文章