消息推送机制是 pc 或 app 最常见的信息触达用户的途径之一，在日常使用中，我们碰到比较多的是弹窗设计。本篇文章中笔者对消息机制设计进行了系统的分析，梳理了消息机制设计的整体框架，供大家参考和学习。
作为产品经理，给自己产品设计消息机制的时候，绝不仅仅是一个弹窗就搞定的事情，需要从整个消息机制入手去规划和设计。
本文从消息机制的几个要点出发，讲解如何较为系统化的设计自己产品的消息机制。
消息机制最初源于互联网产品届，主要目的在于拉新促活，提升用户粘性，增强产品和用户的关系，当然使用不当也会存在适得其反的效果。
目前消息机制不仅仅在于拉新促活，另一个主要目的是用于统一产品的消息出口，在产品架构设计时，从消息层来告诉用户产品发生了什么事情，从而做到消息层、主站两个产品设计架构的分离，并且产品信息层结构更清晰。
消息的组成一般大体上由两类组成：标题+内容。
一般移动端信息推送或pc端广告弹窗，消息机制推送的消息的标题会第一时间告诉用户该消息是什么类型的消息，然后具体内容为文本信息或图片、video材料，供用户详细查看具体消息的详情，比如是系统要升级了，还是本次推出了什么活动等等，甚至目前的广告弹窗也遵循这种规则，消息以标题和内容两部分为主。
消息机制在用户侧来看，也就是产品表现层，基本上就是弹窗巨多，也是用户看到最多的一种状态，即正在执行的状况。但是作为产品经理，需要考虑消息机制的多种状态，目前最常见的有如下几种状态：
1. 运行态
该消息已经触达用户，并且正在运行；以弹窗的消息机制来理解的话，可以认为信息弹窗已经弹出，并且还未消息，正在用户的app打开的时候或pc网站打开的时候处于用户可以看到的状态。
该部分在产品设计中，主要以产品表现层考虑的巨多。
2. 就绪态
该消息即将触达用户侧；以弹窗的消息机制来理解的话，可以认为是由于某种原因此时此刻不能弹出，下一个即将弹出的信息弹窗，过一段时间（时间长短不同产品设计不同）或用户触发了某个操作后就会弹出该消息层。
该部分在产品设计中，主要是考虑消息机制的排队逻辑时需要考虑，即多个信息到达时，需要如何处理；如果产品经理定义好就绪态，那么就不会出现冲突的情况。
3. 等待态
该消息在消息队列中，排队等候；以弹出的消息机制来理解的话，本部分可以认为是多个信息都要弹窗，但是需要排出优先级，一个一个弹，这种情况下，除了下一个弹窗处于就绪态（即第二点描述的状态），其余的均为等待态，这种状态下的消息，不紧不慢，还没到它，当然不急咯。
该部分在产品设计中，产品经理主要考虑好消息机制的排队逻辑已经优先级逻辑时需要注意，针对多个消息，不仅需要制定排队逻辑，即按照触发条件依次排队准备弹窗，同时考虑好各个消息的优先级，比如系统升级的提醒是否要高于本次活动节日的运营推广弹窗？
4. 新建态
确该消息刚被放入到消息队列，等待进入等待态（可以理解为信息刚完成，但是前面有多个消息，所以即将进入等待态）
该部分主要以研发考虑为主，对于一个message，研发需要考虑到新建的信息在新建刚完毕时，以及未投入到队伍机制前，需要开辟一个存储空间来对应该消息的存储，这里面的信息定义为新建态。
5. 结束态
该信息已经运行/弹窗完毕，处于结束状态；以弹窗的消息机制来理解的话，可以认为是以及结束的弹窗信息，用户在产品第一界面无法在看到或听到等等。
该部分对应到产品设计中，产品经理主要需要考虑到消息中心，比如已经完成的信息，是否要新建一个信息中心来放所有的信息，以便于用户可以去消息中心查看历史消息？这些问题涉及到结束态消息的处理。
对于以上几种状态，这里给出简单的逻辑流程图，以便于产品经理参考逻辑图来设计自己产品的消息机制的流转逻辑。消息机制中的各消息的多个状态之间的转换业务逻辑如下：
备注：由上述业务流程图可以看到，从新建态到结束态的主流程是消息机制的主逻辑，正向的主流程。红色线代表的是插入性信息，会导致运行态消息被插入的信息打断，从而转换为等待态，再根据排队机制，进行排队等待，转换为就绪态，等待运行。
1. 排队机制
【定义】系统将会维护一个或多个消息队列，所有产生的消息都会被放入或是插入队列中；
【实现逻辑】所有弹窗信息，按照触发时间/优先级，依次排队；等到上一级弹窗倒计时/关闭后，队伍顺次移动；
2. 优先级机制
【定义】系统根据消息的优先级在队列中取出对应的一条或多条消息，然后参考相应的规则来进行弹层；
【实现逻辑】在排队机制中，根据已经弹窗的状态，系统判定下一个弹窗的具体对象，根据优先级/异常机制来进行弹窗
3. 异常逻辑
【定义】当按照正常策略执行的过程中，遇到异常时，系统执行该异常策略，从而避免用户感知到系统bug，提升用户体验；
【实现逻辑】在按照正常逻辑/策略执行弹窗时，如果恰好弹窗刚准备弹/已经刚弹但也没未刷新出/其他情况下，需要给予用户相关信息提醒/图案显示。
对于目前市面上常见的消息机制，常见的推送方式有两种：PULL和PUSH。
PUSH方式可以理解为系统主动推送，根据用户的兴趣、需求，按时按量按类别等要求将信息主动推送到用户端。该方式较为普遍，适用于普遍用户；
PULL可以理解为是用户主动索取，主动索取系统相关信息，主动给系统发出请求索取相关信息。PULL的优势在于针对性较强，由于用户主动索取，所以能够较好的满足用户的个性化需求。
两种方式各有优缺点，在产品设计时，产品经理如果能够更好的理解两种方式的优缺点，那么就可以在和工程师沟通的过程中更好的进行理解技术框架和技术方案。
系统通知类的消息一般为系统的容错机制，更好的保障系统的运行、升级、出错、崩溃等。如：系统升级提醒框、系统崩溃后的信息提醒。
如上图，两款APP的系统通知类信息（以升级提醒为主），其触发条件均为 打开APP后触发，并且推送方式为PUSH，系统自动推送给用户，优先级较高；
当用户打开APP时就可以看到，但是同时这种弹窗最好给用户选择的余地，否则就会适得其反，太强制的操作会导致用户反感，所以我们可以看到上面的两个弹窗，用户可以选择更新，也可以选择不更新。
内容提醒类消息为消息机制里的主体部分，产品的消息机制的设计，围绕着消息机制的运营、促活、拉新等，都可以在内容提醒弹框内做文章，包括运营活动、产品迭代等等。
产品设计过程中除了策划好上述五点的内容外，还需要额外考虑消息机制里的消息的优先级。
比如，如果正在给用户提示系统升级的弹窗（优先级为B），此时如果有优先级为A的消息提醒，如何处理？针对不同优先级、同等优先级的消息机制里的信息，产品经理需要考虑好如何进行产品设计的处理。
规划优先级的这块，在产品设计里不仅能够很好的处理产品消息层面的容错，同时当把产品的定位往平台方向转变时，能够统一规划产品的对接第三方服务。
这里的建议，结合我自己产品的设计，给大家的建议是：
首先，将自己产品的所有消息类型思维导图出来，按照系统通知类、内容提醒类分两类。
根据不同需要，先给两大类定优先级，然后在类别内在进行细类的优先级划分。
如果自己的产品还存在对接第三方系统，第三方也存在消息机制，那么就需要根据产品定位，对第三方也一并进行考虑，比如第三方服务是仅仅为了商业合作？还是第三方能够很大程度的给自己拉新促活？不同的对接目的优先级不同，产品经理需要额外关注。
