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

        对于大多数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机制不同，此处区分两个平台讲解：
       Android：设备要接收到推送需保证APP进程存活，而国内Android设备的系统均为定制过的ROM，APP存活需将APP设置为白名单（如微信钉钉跟各大手机厂商均有合作添加产品白名单，或将APP加入手机自带的安全工具白名单），这样才能保证推送不会丢失；另外，国外版的Android大多为原生系统，进程存活率较高，不需要额外设置白名单来保证存活。
       iOS：iOS的推送均需要通过苹果官方服务器进行推送，跟进程存活没有关系，无论进程在后台活跃还是被kill，都能收到推送（前提是用户开启推送通知权限，可参考小红书的常驻引导开启方式）。

       短信：到达率和成本更高，一般仅用于交易、大型推广活动和用户召回等强提醒场景；同时，当用户推送权限处于关闭状态时，也可使用短信触达后引导开启。
       3. 补充
       对于有多端（不同设备）登录功能的产品，还需要设计相应的多设备登录时，移动设备可开启免提醒的功能（具体可参考微信和钉钉）。

       消息系统的设计，要充分考虑产品所针对的用户群体，保持消息频率的克制和消息的实际意义，而非为了点击转化的诱导提醒。
       当然，理想和现实总是不一样的，用户体验和产品效益之间永远都是一个聊不完的话题，最重要的还是找到那个平衡点。只有这样，消息系统才能真正的起到促进用户留存和活跃的作用。