APP产品策划:消息系统设计简析

从零开始学运营,10年经验运营总监亲授,2天线下集训+1年在线学习,做个有竞争力的运营人。了解详情

对于大多数APP产品而言,消息系统都是一个必不可少的功能模块,其核心目的是让产品直接与用户产生交互,帮助用户更容易获得提醒,在保证用户体验的同时可有效提升用户留存和活跃。那么,消息系统在设计的有哪些需要注意的点呢?请听笔者慢慢道来~

一、消息分类

在进行消息系统设计时,我们需要先把产品可能涉及的消息进行分类,确定不同消息的实际触发场景和节点。

以下是几种常见的消息类别:

1. 互动消息

常见于社区类产品,包括点赞、评论、转发、分享和打赏等互动行为,由用户A基于用户B生产的相应内容(如动态、文章、视频等)执行互动操作后触发生成。

2. 关注消息/好友申请

常见于社区和社交类产品,其触发形式主要根据实际的产品形态进行确定,如用户关系为强关系,则可将消息的触发设计为实时触发;而如果为弱关系,则可以考虑将触发逻辑设计为定时或定量触发。

3. 订单、物流消息

在交易类产品上比较多见,主要根据相关订单和物流状态的变更而触发提醒。同时,需要注意区分状态变更时的用户状态和提醒必要性,对于用户主动触发(即显性)的状态变更可考虑不做提醒,记录类的消息除外。

4. IM聊天消息

有社交属性产品的基础功能,主要可以分为一对一陌生人和好友聊天,以及单聊和群聊;消息的触发为发送后实时到达并提醒,以保证聊天过程顺畅。

5. 内容、活动和系统通知

类似于IM聊天消息,但展现形态和触发场景更灵活多变,可根据设定条件或后台人工触发,跟产品基础调性和内容的相关性极高。

二、时间戳

对于消息的显示,可根据所要提醒内容的格式和优先级进行设计。但无论如何设计,消息时间戳都是组成一条消息不可或缺的部分。其中,使用12或24小时制一般以用户设备选定的格式为标准。

常见的时间戳设计规则如下:

1. 互动、订单、物流类消息时间戳

以用户设备的时间为参考:

  • 消息在今天范围内,显示XX:XX,如 10:02, 18:10
  • 消息在昨天范围内,显示昨天XX:XX,如昨天10:02,昨天18:10
  • 消息在昨天前且在今年内,显示 XX-XXXX:XX,如4-12 10:02,5-4 18:10,12-2012:12
  • 消息在今年以前,显示XX-XX-XX XX:XX,如16-4-12 10:02,17-12-1 12:12

2. IM聊天消息时间戳

以用户设备的时间为参考:

  • 消息在今天范围内,显示XX:XX,如 10:02, 18:10
  • 消息在昨天范围内,显示昨天XX:XX,如昨天10:02,昨天18:10
  • 消息在昨天前且在今年内,显示 XX-XXXX:XX,如4-12 10:02,5-4 18:10,12-20 12:12
  • 消息在今年以前,显示XX-XX-XX XX:XX,如16-4-12 10:02,17-12-1 12:12

聊天会话页消息流的时间戳显示与隐藏:

  • 新消息接收或发送的时间相对于已经显示的时间戳,小于5分钟的,消息不显示时间戳;
  • 大于或等于5分钟的,显示时间戳。

三、可见对象

消息可见对象可理解为提醒对象,但两者并不完成对等,因为对同一条消息而言,对于不同可见对象的提醒方式并不完全一样。

1. 目标对象可见

如关注、订单、物流和系统通知类消息,消息有明确的目标对象(即被关注对象、下单用户和通知对象),该消息的指向为明确指向。

2. 目标对象和内容主可见

如互动类型的消息,内容主生产的内容下可能有多个用户参与互动,且互动的明确对象不一定为内容主(内容主为内容关联互动对象),此时产生的消息提醒就涉及到目标对象和内容主可见。

3. 会话对象可见

见于IM聊天模块,单聊为聊天双方可见,群聊为群成员可见,但对于聊天系统提示类的消息,则需要根据提示的具体场景来确定可见性(如微信群组退群消息仅群组可见,安全风险提示仅消息接收方可见等)。

四、提醒方式

1. 应用内

红点:

可分成不计数红点的弱提醒,以及计数(超过99显示99+)红点的强提醒;同时,进一步细分还可以增加类红点方式提醒(可参考QQ群的免打扰提醒方式),该方式比不计数红点提醒更弱,仅用来表示计数,强化用户感知。

震动和声音:

一般仅针对计数红点的强提醒消息进行震动和声音响应;同时需要对震动和声音响应进行频率限制,如1秒内收到多个消息,仅震动和声音响应一次。

2. 应用外

APP红点:

根据应用内消息计数来标记红点进行提醒。

推送:

当APP处于后台(即在屏幕中APP为不可见状态)时才使用推送提醒,由于Android和iOS机制不同,此处区分两个平台讲解:

  1. Android:设备要接收到推送需保证APP进程存活,而国内Android设备的系统均为定制过的ROM,APP存活需将APP设置为白名单(如微信钉钉跟各大手机厂商均有合作添加产品白名单,或将APP加入手机自带的安全工具白名单),这样才能保证推送不会丢失;另外,国外版的Android大多为原生系统,进程存活率较高,不需要额外设置白名单来保证存活。
  2. iOS:iOS的推送均需要通过苹果官方服务器进行推送,跟进程存活没有关系,无论进程在后台活跃还是被kill,都能收到推送(前提是用户开启推送通知权限,可参考小红书的常驻引导开启方式)。

短信:

到达率和成本更高,一般仅用于交易、大型推广活动和用户召回等强提醒场景;同时,当用户推送权限处于关闭状态时,也可使用短信触达后引导开启。

3. 补充

对于有多端(不同设备)登录功能的产品,还需要设计相应的多设备登录时,移动设备可开启免提醒的功能(具体可参考微信和钉钉)。

五、写在最后

消息系统的设计,要充分考虑产品所针对的用户群体,保持消息频率的克制和消息的实际意义,而非为了点击转化的诱导提醒。

当然,理想和现实总是不一样的,用户体验和产品效益之间永远都是一个聊不完的话题,最重要的还是找到那个平衡点。只有这样,消息系统才能真正的起到促进用户留存和活跃的作用。

 

作者:瞻星同学(微信公众号:产品研究社)

本文由 @瞻星同学 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

评论
欢迎留言讨论~!
  1. 太少前端了

    回复
  2. 作者可否就不同产品的消息功能进行分类,来一篇文章详细解析一下?嘿嘿

    回复
  3. 赞!

    回复
圈子
关注微信公众号
大家都在问