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

　　我的艳遇谁的妻

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　当APP处于后台（即在屏幕中APP为不可见状态）时才使用推送提醒，由于Android和iOS机制不同，此处区分两个平台：

　　Android：设备要接收到推送需APP进程存活，而国内Android设备的系统均为定制过的ROM，APP存活需将APP设置为白名单（如微信钉钉跟各大手机厂商均有合作添加产品白名单，或将APP加入手机自带的安全工具白名单），这样才能推送不会丢失；另外，国外版的Android大多为原生系统，进程存活率较高，不需要额外设置白名单来存活。

　　iOS：iOS的推送均需要通过苹果服务器进行推送，跟进程存活没有关系，无论进程在后台活跃还是被kill，都能收到推送（前提是用户推送通知权限，可参考小红书的常驻引导方式）。

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

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

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

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