产品设计中的消息推送设计，需要注意哪些点？（人人都是产品经理专题）
http://www.woshipm.com/topic/push-3
Web网站通知系统设计
http://www.woshipm.com/pd/32652.html
浅谈Web端平台产品消息系统后台功能规划
http://www.woshipm.com/pd/991582.html

消息系统即“信息的传达处理系统”，目的是为了让用户获得需要得到的消息及提醒并进行处理。 “需要得到”的两层含义： 用户彼此互动触发的信息流(留言、评论或者回复、私信等) 应用希望用户了解关注的信息(系统公告等) 设计原则： 消息传播效率高(获取、处理、信息传达、用户反馈等效率) 避免产生骚扰(噪音、频繁提示)

消息包括：IM消息，站内信，系统消息。
IM是即时通讯，多用于聊天。站内信和系统通知的使用场景类似，多用于官方运营下发的消息或系统自动下发的消息，区别在表现层面，站内信像即时聊天界面，有发送方实体，双向，可以回复（存疑）。系统消息是就是公告、提示之类的，单向，不能回复。

消息“推送”一般是指单向（由平台向用户）而非双向消息互发。
发送方——信息传递——接受者
运营人员或业务系统将营销消息或通知消息通过短信、push、微信等渠道发送给用户。
流程图：

2种发送方式：一种是运营活动批量定时投放，运营先筛选用户，然后编辑文案，审核通过后进行发送。另一种是需要实时触发的消息，比如支付成功通知、验证码获取、满足某种条件触发的营销活动等，这类消息时效性要求较高且每个用户发送的消息内容中涉及到差异化的参数。接口实时触发的消息，一般需要业务系统监控到用户行为，将用户账号与需要的参数通过MQ或者接口传递至消息推送系统进行发送。触发的消息需经过一定的过滤与拦截规则，针对短期内已经覆盖过用户进行过滤，异常或者不合规的消息进行拦截，按照设定好的渠道进行推送。

用户筛选需要与标签系统进行对接。 不同渠道的账号不同，需要获取绑定关系。比如短信需要手机号，push需要SDK上报的token，微信需要使用OPEN ID。

消息的应用场景

“消息”是APP中的重要功能，主要提供消息推送和沟通交流的功能。
设计APP的消息中心的时候要根据自身产品定位和用户需求，由此来设计消息中心的页面布局、位置、按钮大小（颜色），选择性地选取其中符合自身产品的功能。
微信、QQ：聊天通讯作为核心功能，消息中心放在APP首页的位置，并且每次打开时也是展示消息页面。
小红书、微博：消息中心主要承载了通知和聊天功能，集合了转发、评论、赞、@等通知功能，以及官方与粉丝、粉丝与粉丝之间的聊天互动功能。
电商类：在消息中心告知用户物流信息，和商家对话了解商品信息，几乎是购买过程中的重要步骤。此外，消息中心还会有一些互动、优惠版块等，使用频率也非常高。
对比盒马鲜生放在首页右上角：
淘宝、京东：B2C或C2C线上交易；交易持续时间长，需要了解商品及快递信息；买家良莠不齐，容易产生纠纷；使用频率高；
盒马鲜生：线下门店+线上下单配送；交易时间短（1-2小时内完成订单）；品质有保障；使用频率低；

一个功能点的设计与产品自身的定位和用户需求有关。在不同类型APP中，其重要程度排序大概为：内容/社交类APP > 电商类APP > 资讯类APP > 工具类APP。
1. 通讯提醒
主要是IM或社交类应用，当用户离开应用时收到好友信息，需要通过消息功能来提示用户查看；还有微博、豆瓣等应用，当收到其他用户的赞、评论或留言时，系统同样需要通过消息功能来提醒用户去查看；
2. 推广促活
一个是对那些流失用户，通过一些用户可能关注的信息来吸引用户回归，达到挽留和减少流失的目的；
另一个方面，将新的运营活动，通过消息宣告给目标用户。
3. 通知提醒
如用户账户变动、产品重大功能更新、商家活动变更等事项，需要及时告知用户；保持用户对重要事项的知情权，不仅是对用户的尊重，更是降低用户对变化的抵触、减少用户抱怨的必要手段。
4. 流程反馈
对于用户的关键操作，尤其是那些可能无法即时呈现最终结果的（比如：申请提现、付款后等待发货、请假等），需要在操作或流程有结果后，通过消息的形式及时给予用户反馈。及时、清晰的反馈是用户体验的重要一环，能够提升用户对流程的掌控感、安全高，从而增加对产品的信心。

正面影响和负面影响

PUSH的利与弊

• 正面影响

（1）信息传达及时。消息通过各种形式触达用户，及时反馈给用户。有利于用户准确知晓自己账户变动，了解市场变动信息，从而做出进一步反应。
（2）丰富运营推广手段，提升产品留存率和活跃度，有利于提升相关业务转化率。
（3）成本较低。消息推送的各种形式本身成本较低，采用自动化的消息推送能大大节省平台的客服人力成本。

• 负面影响

（1）用户易产生反感情绪。每个用户对推送的容忍阈值都不一样。过高的推送频率会对大部分用户形成骚扰，提高产品的卸载率。
（2）识别率低。平台的推送内容混在大量的娱乐资讯APP状态栏通知、各种营销短信之间。如果推送的内容无法不断刺激用户，则用户打开的欲望和识别率会越来越低。

形式/渠道分类

消息的多种形式或载体、分类。
通知栏PUSH、短信、应用内消息、邮件、微信通知等。
外部推送机制：邮件、短信、微信；
内部推送机制：桌面红点、push、消息中心、打点推送；
不同的形式对应的字段不一样：短信需要短信文案，PUSH需要展示标题与内容摘要，微信有模板消息与图文、语音等类型的消息内容。

短信推送

短信的内容形式比较单一，成本不菲。有较好的实时性，触达用户比较直接，方便用户通过短信打开APP查看相关内容，也是很好的保存凭证。
要经过电信运营商的渠道，成本较大，适用于较重大的活动运营或者和个人账户密码相关的业务场景。短信营销通道受到移动运营商的监控，对某些关键词有限制。在Android手机上易被当成垃圾信息进行屏蔽。过于频繁和无关痛痒的短信，会对用户造成很大的反感和困扰。

• 发送对象

选择“最有价值”的用户：A.曾经注册过，但很长一段时间没有打开过APP的用户，可以通过产品特色功能来吸引和唤醒用户再次进入APP，减少流失率。B.长期处于“观望”状态——即注册后一段时间偶尔有登录但未深入使用或产生消费行为的，这类用户往往需要使用短信这种到达率最强的通信方式来争取获得用户的关注。
运营人员在后台根据用户的注册时间、使用情况、消费情况等维度来筛选出各类用户，并有针对性的给他们发送信息，这样可以达到更好的效果。以流失唤起为例，如果我们需要唤起的是流失的活跃用户，在筛选发送对象是，可以从以下维度考虑：

• 重点是那些曾经为平台活跃较高，但当前状态为流失的用户；
• 明确用户流失的时间点，时间过长的用户唤起的可能一般极低，应该予以剔除；
• 了解用户以前活跃时在产品内的核心行为，那些对产品核心功能使用频繁的用户的唤醒可能性往往是最高的，可以重点考虑。
  • 发送内容

发送者：即产品或公司名称；
核心文案：一句话告诉用户产品有什么活动、什么优惠。
跳转链接：一般显示为蓝色下划线的文字链接，一般是跳转到手机wap活动页面、app下载页面等。

• 发送时间

对于大多数用户来说，一天有4个时间段是相对最闲、最轻松或精神状态最佳的。分别是早晨上班时间段（8：00-10：00）、午休时间段（12：00-14：00）、下班时间段（18：00-20：00）、睡前时间段（21：00-22：00）。在选择短信和push发送时间时，需要参考这些规律。
结合产品的定位，比如：外卖应用最好选择中午下班前的1个小时到下班后1个小时（大概11：00-13：00）；新闻、天气类应用最佳的推送时间是早上班时间；而游戏视频等娱乐类的消息，最好选择下班后的时间段。
短信行业内分为通知、营销、验证码类型， 该类型划分主要为方便路由短信至SP服务商不同通道，不同的通道触达率也不同，为了保证重要短信的触达率，需要将不同内容的短信路由至不同的通道发送。

桌面红点

桌面红点是对强迫症很有用的消息设计。机制也很简单，每条push发送到手机的时候可以去更新桌面红点，APP在前台的时候，也可以去设置消息红点。一般而言，消息红点能提醒用户打开APP。但要注意桌面红点要让用户能方便的消除，如果不能，用户可能关掉桌面红点提醒。

PUSH通知栏推送

APP PUSH定义：通知push的意义在于借用设备的消息功能进行强提醒，在手机终端锁屏状态下通知栏展示或在操作前台顶端弹出的消息通知，点击后可唤起对应的APP，并在APP内跳转到首页或指定页面。
如果用户未关闭PUSH通知的话，PUSH可以从通知栏弹出进行消息显示，具有一定的强提醒性，是产品在站外触达用户的途径。
PUSH点击跳转后便消失，没有痕迹，因此针对重要的通知消息，需要在APP内设置消息中心进行留存通知记录。
消息通知一般用户点击或清除后不会留痕，所以一般的做法是同时发送这2种消息，PUSH强提醒，站内信为了留痕或者保留入口。
核心指标是到达率和点击率。到达率受限于厂商，目前Android全量消息到达率达到50%算是比较好的水平，这还是建立在Android保活联盟的基础上。点击率则跟消息类型和内容息息相关，注意落地页，打造闭环。
推送成本较低。
用户无意或有意去关闭PUSH后，可在产品中某些场景和页面提醒重要性，并通过一定的设计引导用户去开启通知。
组成形式：APP图标和名称+发送时间+文案（标题和内容）+配图。
其他样式：一些营销消息会加入EMOJI表情来吸引用户点击，只要服务支持传输约定好的EMOJI码就可以。目前安卓系统也支持富媒体推送，推送包含图片、语音等形式，对于资讯类的APP可以增加缩略图，吸引用户点击。语音场景还有待挖掘。

iOS和Android均有PUSH系统。iOS在用户不启动APP情况下依然可以接收到推送消息。Android只有APP相关进程（服务）在系统中运行才能收到推送消息。（Google在国内服务不稳定，需要借助第三方的Message推送服务商），如果APP进程被关闭，则推送的消息会被离线缓存到个推服务器上。）
三种途径：手机厂商（小米推送、华为推送）、第三方（友盟推送、极光推送、个推）、BAT推送平台（阿里云推送、腾讯信鸽、百度云推送）。

应用内消息

消息中心是指用来统一展示系统发送给用户各类信息的一个固定的模块，用户可以进入这个模块或页面统一查看各类消息。通常用于那些重要程度较低的通知，最主要的目的是需要向产品的其他位置分发流量。
应用内消息在APP中一般有专门的入口，可在主Tab、消息入口图标中采用小红点或者红色数字以达到吸引用户点击浏览的目的。应用内消息往往与通知栏的推送互为一体。比如点击某个通知栏公告，进入APP应用内消息，自动打开该公告对应的详情页。
入口最常见的一般是单个图标（如：铃铛、信封等），或者直接是文字入口，并配合红点、数字角标、图标动效、震动等各种提示来增加消息的可见性，使用户更容易注意到新消息的到来。
一般由消息列表和详情页组成，除了那些场景单一和功能异常简单的应用，大多app的消息列表会按照消息标题和概要来一条条显示，更多的信息可以通过详情页来展示。
（1）个人消息
与个人账户关联的消息类型，主要包括：账号变更、等级变化、资金流动、交易消息、订单变动、点赞、评论等。
（2）站内通知
APP内容、版块的变动、活动变更、活动结束、功能调整等影响用户使用体验的消息类型。
（3）活动通知
拉新促活的重要手段，引流的入口，用来推广新上线的产品、运营类活动或新功能等。对于比较核心的活动，除了在消息中心展示，还应该在首页位置告知用户，结合banner、弹窗、浮窗广告、通知栏等样式来展示。
（4）系统通知
APP内容、版块的变动、调整等影响所有用户使用的消息类型。一般来说，这种类别往往是重要等级最弱的消息，仅是通知那些不会对用户使用造成重大影响的信息，例如：APP内容、入口的微调，系统升级、放假通知等等。

业务类型划分

消息推送和站内信区别 基本定义的区别：站内信主要是APP内部自己设置的重要信息展示模块，展示信息的内容、样式、时间都是由APP自行设计。消息通知是APP PUSH通过推送通道进行消息推送，一般展示在手机的通知栏或者通过顶部弹窗展示。 展示位置的区别：消息推送展示在手机操作系统的通知栏或者顶部弹窗，站内信是APP内部，自行设计安排。
触达效果的区别：一般消息推送会伴随声音、震动提示用户，提醒到位；站内信一般是静默展示，且实现逻辑主要是用户登录APP后客户端去服务端同步数据。 消息痕迹的区别：消息通知一般用户点击或清除后不会留痕；站内信可以长时间保留，主要是看APP自己的设计。 实现逻辑区别：消息通知是主动调用手机终端厂商或推送服务方的通道，站内信一般只是数据记录，在用户登录APP进入站内信模块时才会主动从客户端向服务端请求数据。
推送消息通知功能通过三方推送系统api对接，可以整合在内部消息推送平台，在发布消息时，只需要让用户选择是要发布push消息还是站内消息，只是一个类型的选择。如果push消息和站内消息区别很大，字段很多也不一致，那就得分开2个功能了，具体要看运营的需求。

打点提醒

有需要用户点击查看的内容，会从首页开始一路打点，直到用户点击查看之后，红点才消失。打点提醒在游戏中比较常见，因为游戏一般结构比较复杂，且更新比较频繁，各种活动和运营策略复杂多样。打点提醒是最能让用户快速使用的方式。

邮件推送

邮件推送的成本较低，但用户必须用邮箱注册或绑定邮箱。邮件本身不能直接触达用户，且不易于读取，因此用户打开率比较低。多用于活动运营推广或者账户相关信息存档。
查收邮件的情景倾向于完成重要的事情，对非紧要的营销类邮件容易忽略。同时因为长期的营销邮件滥用，目前邮件的通知效果越来越差。但对于卸载了APP的用户而言，邮件仍然是召回流失用户相对有效的手段。

微信服务号推送

微信消息的打开率甚至高于短信，价格更廉价（基本没什么成本），且支持图片文字混合形式，更容易提高点击率。相比应用内通知，微信服务号推送更能触达用户。前提是要引导用户完成微信端绑定平台服务号。

弹窗

【其他分类方法】根据在用户端（APP）展示的形式，大概有短信、push通知、弹窗浮层类、应用内消息（消息中心）四大类。

针对弹窗的说明
推广促活：新的产品、商品上架、新活动上线时，或是重要的高频活动需要进行推广时（如提醒每日签到），在用户登录或进入app，或进入特定模块时，用弹窗的形式来告知用户。
通知公告：产品端或企业方面的重要事项，可以通过弹窗来告诉和提醒用户。例如：订单异常、产品停服更新、账户变动等。
功能引导：折扣券即将到期的提醒、红包可提现的提醒、奖励兑换的提醒、APP升级提醒等，这类对用户的事项，如果能适时给与提示，则可以有效提高用户的积极性，提高相关功能的转化率。反之，如果在发生重要变化时，用户不知道，很可能造成用户的不满。
（除了弹窗，还有浮层类提示，比如app底部或顶部的提示栏、页面边缘的按键浮层等形式。）

后端设计逻辑

梳理消息推送场景，实现运营“精准打击”。
为满足长远需求，方便统一推送，在开发资源足够的情况下应当将APP推送功能、短信营销平台置于自己的后台管理系统中。
不同的推送形式，涉及到的前后端流程。

消息创建步骤

1.投放人群选择
和标签系统进行对接；通过业务系统监控用户行为，将用户账号与需要的参数传递至消息推送系统进行发送。
2.消息类型与等级划分
根据业务场景、重要等级，选择相应的消息类型；
3.消息内容设置
不同的渠道所需要的消息内容不一样；
4.消息跳转
短信消息需要将长链转化成短链（短信是按照字符数进行收费的，可读性）；push跳转至H5页面和原生页面，跳转协议由客户端提供；微信消息；
5.其他需记录信息
消息发送部门，用来作为后期短信费用结算的依据，免费资源则可以分析各个业务部门对消息资源的使用情况。
转化行为口径：为了更好地衡量消息发送的质量，应该记录下每条消息下发的目的，比如：订单、实名、激活、下载、通知等，将消息与转化行为匹配起来进行数据分析。
产研负责人：在消息发送之前应该记录好每个任务或模板，对应业务线的产品、研发实际消息的负责人，当消息发生客诉时，通过消息记录查询功能，可迅速定位消息的产研负责人，紧急确认对应消息是否有异常并解决。
6.推送时间设置
创建的消息任务可以预定时间进行发送；对于已经固化的营销场景，需设置周期性任务，设置初始执行时间与执行周期。接口触发的时间一般为实时触发，触发时间由业务系统决定。

其他

一、消息审核
创建好消息任务或者消息模板，需要经过谨慎审核后才能发送，避免出现失误产生不良影响。一般需要业务线内部负责人审核与公司平台或者对应职能部门审核。审核要点为：消息文案是否符合广告法、消息跳转是否正常、发送频率、时间是否合适等。
二、消息过滤与拦截
消息过滤主要针对营销类型消息，时段限制（早上9点至晚上8点之间可发送）、频率限制（用户7天内只能收到1条短信，针对周期性任务，同一任务触达过的用户可以进一步扩大过滤周期）、黑名单限制（用户退订）。
消息拦截主要为限制发送量级，比如每个业务线针对同一用户每日最多发送5条短信；公司整体对同一用户最多发送30条短信；短时间（时间可设置，如300S）内同一用户重复内容过滤；量级的控制主要为避免由于业务系统故障造成的对用户消息轰炸，产生不良影响。
关键词拦截，如包含违法、暴力等词汇。
三、消息发送
优化消息发送的性能，提高消息发送的稳定性。发送环节应该添加监控并且适当打印日志，以便及时发现异常并定位问题。
四、消息路由
短信、安卓push均可接入多个渠道，搭建分发集群。可以根据业务逻辑指定通道发送，也可以根据下游通道状态自动路由。
五、数据分析
【触达漏斗】发送数量——触达数量——点击数量——转化数据。
对于短信来说，涉及到短信费用，需要针对渠道和成功触达条数进行计费，设计对账看板。
短信退订、PUSH关闭等用户行为数据也需要进行分析，便于调整后续触达策略。

PUSH推送技术知识

不同类型APP对PUSH的需求也不同，IM类APP追求实时、稳定的触达，此类APP一般通过自己的长连接进行消息推送，保证用户在收到消息的时候能够实时地接收消息消息。另外，一些安卓厂商也会给予头部APP的进程一定保护，对相关的进程纳入白名单，在清理进程的时候予以忽略。
新闻资讯类的APP与工具类APP的PUSH推送机制基本一致，仅在频率控制上有差异，新闻资讯类由于新闻资讯较多，需要将突发新闻及时推送给用户。

PUSH消息在消息系统创建好后进入发送阶段，服务端需要根据用户终端信息进行路由，如果是iOS系统，会调用苹果自身的推送通知服务（APNs），如果是安卓系统，那么根据不同的厂商去调用不同的厂商SDK。
对于不同的系统版本，支持的消息展示形式也不同，比如iOS10之后，当APP在前台时，是否通知栏展示，此样式可以根据产品需求来选择，有服务端传输相应通知方式的值即可。如果非五大厂商内的手机，可以通过自己搭建的长连接或者使用第三方服务进行推送。
通过接入第三方消息推送平台来实现消息的推送，比如信鸽、个推等。多数的通道会将消息是否成功推送到客户端SDK的回执数据反馈给发送方，需要提供回调地址。

推送系统的三层结构

三层结构

推送系统流程：

时间、场景、目标用户？ 标题、图片、文案、着陆页？ 任务建立、消息下发、消息路由、消息到达？ 推送平台、用户设备、设备系统、展示方式 用户点击、用户浏览、后续转化 发送成功、下发率、达到率 用户行为分析 用户喜好度分析

通道类型

厂商通道、第三方推送服务平台、长连接。
厂商通道是手机终端厂商推出的推送服务，通过接入厂商SDK，内部服务端可以将消息推送到手机系统的服务端，再下发至客户端内部的厂商SDK，由操作系统进行相应展示，点击后唤起相应APP，这样可以避免APP进程被杀死后消息无法触达用户，因此触达率较高。
第三方推送平台是推送服务公司自己搭建相关的消息服务。并且各个APP使用了同一个平台的推送服务时，客户端都是集成同一个第三方推送平台的SDK，因此形成了一个推送联盟，当联盟中的其中一个APP的消息进程没有被杀死的时候，其他的APP也可以利用进行通知用户，形成了相互唤起，提高触达率。经过一些场景的测试，相互唤起的成功率并不是很高，需谨慎结合自身场景评估。为了提高触达率，第三方推送平台也会集成各大厂商的SDK进行推送。
长连接就是建立手机与服务端的一条链路进行消息数据推送，通过长连接也可以进行APP状态监控，但完全由长连接推送且保证触达的稳定，需要投入的研发资源较多，且需尽量避免自己的长连接进程不要被操作系统杀死。

优劣势对比

下发推送

• 推送账号

推送时客户端的PUSH SDK均会根据用户的设备号生成一个对应关系的TOKEN。在SDK内部，如果使用的是第三方推送服务，则去第三方的SDK注册；如果是厂商，则去商城SDK注册；如果使用自己长连接，则去自己的SDK进行注册，作为后续推送的标识用户的唯一ID。

• 消息路由

根据不同的业务场景，可能会定向推送给不同版本APP的用户。因此服务端在通道能力路由的时候，不仅需要能够区分通道，还要进一步能够针对用户的手机终端进行更加精细化的差异推送。
此外，消息通道并一定是100%稳定，如果下游通道出现问题，服务端需能够将由于通道问题导致的消息路由到备用通道去发送，以保证业务稳定触达。

• 全量推送

一般来说，对于公司内部运营或公司的相关数据均是以产品的customer id为准，用户数据系统对接消息系统时也多为customer id，因此需建立customer id与推送TOKEN的关系，便于运营针对用户进行推送。但对于一些场景会需要针对未登录的用户也进行推送，即全量推送；比如突发重大新闻资讯、大促等活动，所以运营系统需要提供全量推送功能，针对所有TOKEN进行推送。

数据上报

上报数据包括触达、点击、关闭、退出、注册等数据。
对于所有方式的触达消息，都离不开触达与点击，触达的数据通过厂商的需要厂商回调上报，点击数据可以由SDK上报服务端。对于push的关闭，也是需要进行考量的，来评估push是否过度发送，打扰到了用户。关闭数据有两部分，一部分为APP内部的关闭，sdk直接上报给服务端即可；另一部分为用户在手机操作系统上关闭了对应APP的push，需要APP在前台时，sdk调用手机终端相关方法获取该用户是否关闭了系统通知，然后上报至服务端。
注册数据即用户首次启动APP时，去相关sdk注册token。
一般来说，用户退出账号时，sdk需要上报服务端，解除token与customer id的绑定关系。

《推送系统从0到1》系列文章

《推送系统从0到1》系列文章

消息系统逻辑实现机制

消息合并

消息在推送之前需要进行汇总合并，目的在于提高消息传播处理效率；减少骚扰，降低噪音；平衡服务器压力。
合并周期

固定时间内的消息全部汇总(24小时内/30天等) 无固定时间(只要未处理/未读即汇总) 组合用法：合并24小时内未处理消息

分类合并

同种类进行合并(如n条留言合并为1条) 同一发起人合并(如张三给你发来的n条私信) 同一时间周期合并(如24小时共收到n条评论)

简书为例，消息系统分得比较细，包括评论、简信、投稿请求、喜欢和赞、关注、打赏、其它提醒等。
分析消息句子结构，总结如下：
「谁对一样属于谁的事物做了什么操作」
「someone do something in someone’s something」

someone = 提醒的触发者，或者发送者，标记为senderdo something = 提醒的动作，评论、喜欢、关注都属于一个动作，标记为action something = 提醒的动作作用对象，这就具体到是哪一篇文章，标记为target（targetType） someone’s = 提醒的动作作用对象的所有者，标记为targetOwner

消息分发

消息按照规则汇总完成后，系统将其通过消息管道推送到用户，以便用户处理。

• 分发方式

  主要是Push和Pull。 第一种是客户端使用Pull（拉）的方式，隔一段时间去服务器上获取信息，看是否有更新的信息出现。 第二种就是服务器使用Push（推送）的方式，当服务器端有新信息时，把最新的信息Push到客户端上。 Pull方式更费客户端的网络流量，更主要的是费电量，还需要程序不停地去监测服务端的变化。Push可以针对消息的时效性做出及时的通知。

以知乎为例
推比较常见，需要针对某一个问题维护一张关注者的列表，每当触发这个问题推送的条件时（例如有人回答问题），就把这个通知发送给每个关注者。
拉相对麻烦一点，就是推的反向，例如每个用户都有一张关注问题的列表，每当用户上线的时候，对每个问题进行轮询，当问题的事件列表出现了比我原本时间戳大的信息就进行拉取。
可根据消息的不同采用不同的获取方式：

通告和提醒，适合拉取的方式，消息产生之后，会存在消息表中，用户在某一特定的时间根据自己关注问题的表进行消息的拉取，然后添加到自己的消息队列中。 私信，适合推的方式，在发送者建立一条信息之后，同时指定接收者，把消息添加到接收者的消息队列中。

目前大部分消息优先推送未处理消息合并后的总数，以提醒用户已有新消息需要处理。用户点击数字后再去服务端请求具体的消息内容。此种方式综合考虑了成本、压力和体验。当然，某些极端情况下需要进行优化处理：如未读消息超过1000，用户请求时先推送前50条或者放入cache中等。

• 分发频率(时间)

根据消息的优先级来做区隔：

• 分发管道

分发管道即消息通知的具体推送渠道，根据业务类型可以分为：web、App、短信、邮件等。

用户处理

根据分发方式，对通知的处理在逻辑上可以分为两层：通知状态的处理和通知内容的处理。
状态的处理狭义的理解即为是否已读(已处理)。
通常初始数字即为系统推送过来的未读总量，用户点击数字进入相关功能列表查阅后读取的动作完成，未读数字相应减少。
有几种情况需要变通处理：

• 若用户未读信息较多(m=100)，但第一页列表只能显示(n=10)条的话，那未读数字即为m-n=90；
• 某些产品会将点击等同于已读，即用户只要点击无论是否打开列表查看均认为已读。这样的处理一般用于重要级别较低的消息，点击即已读可有效降低骚扰。
• 某些重要级别较高的消息已处理状态可以定义为用户进行相关操作后才为已处理，而非查阅。如用户进行评论、回复、点击忽略或点击删除等动作时才认为已处理。

内容的处理狭义的理解即为用户是否操作。
根据不同消息类型和业务，操作可分为：

• 处理：用户必须点击功能链接进行处理。如：你的密码过于简单，点此进行修改;
• 回复：如回复私信，对评论进行回复;
• 确认：对消息做出确认的反馈，如某些系统提示可设置“我已知道，不再提示”的选项;
• 忽略：用户进行忽略操作或不进行任何操作;
• 删除：用户删除本消息。

消息处理后的状态需要统一
消息需要标记是否已处理的状态，且状态在不同的终端是打通的。如：用户在客户端对消息进行了查看，在web站点本消息应自动标记为已读状态。

遇到的其他问题

长时间不登录，登录后收到一大串推送轰炸？
离线推送？
退出登录后还会收到，怎么处理？
多终端登录，怎么推送？

防骚扰、打扰策略

1、提供通知频率和渠道的管理功能（如邮件退订，消息通知类型管理）
2、增加屏蔽功能
消息屏蔽功能在业务上属于第一条中通知类型管理，当业务模块较多时，或者开放平台功能接入的第三方应用通知时，可使用屏蔽功能。（新浪微博）
3、结合权限体系
功能隐私设置：使用隐私设置界定具体的接收权限、范围等。（微博私信设置）
结合黑名单功能：使用黑名单可屏蔽指定用户或关键词的具体消息通知。

用户拉回策略

当用户长时间不登陆或对消息不处理时，可使用其他渠道推送通知，已达到拉回的目的。 这个要与网站整体的拉回策略相结合。

通知管理

通知列表：

• 查询条件：创建时间（段），创建人，状态（已发送、未发送）
• 列表：标题，创建人，创建时间，发送时间，接受角色，状态，操作

添加通知弹窗：标题，内容，发送时间，接受角色

消息接收设置

京东商家店铺例子
第一时间收到经营情况的通知，以便及时知晓并处理。例如订单、工单、售后等处理状态消息或店铺经营的一些异常情况等。而“消息接收设置”的作用是对每种系统消息设置接收通知的方式。
消息类型陆续开通（业务）
接收方式：shop端提醒、邮件提醒、短信提醒、IM端提醒。

不同模块可设置不同的接受邮件和短信（邮箱地址和手机号码）；子账号的消息接受权限请在“账号管理”主菜单中配置。
多个邮箱地址和手机号码以逗号隔开，最大值分别10/3；
咚咚子账号——将消息提醒方式设置为IM提醒，然后在账户管理-员工管理-员工信息-补充权限，将子账号添加相应的消息提醒权限。
设置提醒时段——“已订阅”或“未订阅”——“铃声”“震动”设置

iOS和Android

iOS版本的APP消息提醒设计

iOS对于消息通知的提示有自己的设计规范，分为本地通知和推送通知。 推送通知或推送消息是服务器执行。
iOS的消息通知有两种形式，Badge Notification和Alert Notification。

• Badge Notification

指出现在应用程序图标右上角的红色圆形数字提醒，用于提醒一些无需即时处理的消息，比如程序更新数、未读邮件数等。Badge Notification只有在Home Screen的对应屏上才能看到，因此不适合用于提醒一些重要性高或需要及时处理的通知。而且Badge Notification的形状颜色大小等都是默认且无法改变的。

• Alert Notification

非常直接地以对话窗口的形式出现在屏幕上，用于重要或需要及时处理的通知。不过Alert Notification常常粗暴地打断正在进行中的任务，强迫用户马上做出选择，且无法汇总查看所有通知，当有多条通知时，无法选择性处理，只能按提供的顺序一个个处理。


iOS 11的四种消息通知类型**
横幅（Banner）
横幅通知会显示程序的小图标（低分屏下显示29×29的图标，高分屏显示58×58的图标），程序的名字和通知的内容。（只要不是锁屏状态，都可以从屏幕顶部向下滑打开通知中心。 ）
提醒（Alert）
提醒通知不会自动消失，需要用户与之交互才能关闭。设计师需要设计通知的具体内容，有时还要为action button（后面会谈到）设计title。
APP设计师值得注意的是：一条提醒可能会包含一到两个按钮。对于有两个按钮的提醒，需要把关闭提醒的按钮放在左边，把action button放在右边。 如果只有一个按钮，这个按钮应该是一个确定按钮。
标记（Badge）
标记通知是显示在程序图标的右上角的红色椭圆形标记，里面显示的数字表示需要用户处理的通知的数量。
声音（Sound）
声音提示也是iOS的一种通知方式，支持自定义，可以与前面三种通知类型搭配使用。

Android 版本的APP消息提醒设计

android的消息提醒设计：
Alert：强打断型提醒，提醒内容与当前应用有联系时可以接受；
标记：一种不紧急的提醒方式，增量很难记住，部分用户有强迫清零的习惯；
Toast：纯告知，不需要处理；针对正在操作的反馈；
预览：可辅助用户判断是否需要查看该信息详情，但要注意结合“标记为已读”机制；
通知栏：是一种被普遍接受的通知方式，优点是“集中处理”；

项目举例

背景
平台型产品初建期需要保证产品的完整性，必须搭建可控的消息系统，形成产品完整的闭环：
一来满足产品的完整性；
二来确保让用户感知到产品是活的；
三来满足平台产品上各个业务的流程。
目的
让用户更加容易获得提醒；
让产品更加直接的与用户产生交互；
分类整理消息。
场景
营销需要：比如运营策略需要的广告消息、优惠消息、活动消息；
服务需要：比如售前流程、售后流程（发票申请进度、售后申请服务进度等）、产品更新修复（注册使用产品后的版本更新、优化说明等）；
互动提醒：比如工单回复提醒、评论提醒、关注提醒；
任务提醒：比如学习某个视频更新提醒、下载任务提醒、订阅某条推送提醒、收藏更新等。

功能性需求和非功能性需求

功能性需求：该产品具有的功能，让用户通过这些功能完成任务或者满足各类业务需求的功能，统称为功能性需求。比如：人工push、营销类消息推送、重大版本更新通知、修复公告等。 非功能性需求：主要是产品的性能、系统、进程提醒等需求。比如：系统提醒、事件触发提醒、进度/任务跟踪提醒等。

消息管理/设置：主要是对接收的消息进行管理/设置，用户和产品之间存在主动接收和被动接收的关系。
用户可以主动去拒绝接收部分消息，这样做可以让用户在产品上获得更大的主动权。不同于普通B、C端的产品的是：平台产品在此类消息管理/设置中将很多的接收权限交给用户有选择性的接收。并不是所有的平台产品都会有这个功能，对于一些聚集了很多业务的平台来说，有这个功能可以有效的避免接收到多余的消息干扰用户。如：腾讯云、阿里云、百度云等等。
但是对于业务区分不明显且不是很大业务量的产品来说，这个功能的存在无关痛痒。如：微信公众平台、各大媒体后台等。

相关字段说明

消息类型：公告消息、活动消息等。可通过管理消息类型进行新增、编辑、删除操作。这里的消息类型对应的客户端的消息类型。
状态：已发送、未发送、已关闭。这里的状态指的是消息的推送状态，其中已关闭指的是消息在客户端做了隐藏（撤回）的操作。
消息标题：根据客户端的要求，后台做字符、样式、位置等限制。
消息内容：根据客户端的要求，后台做字符、样式、位置等限制。
阅读量：消息在客户端打开/阅读的数量具有唯一性。
推送时间：该条消息成功推送到客户端的时间。
创建时间：创建该条消息的时间。
编辑消息：对已发送状态消息可以对其进行的操作仅限于“展示”功能（即在客户端是否展示）,未发送状态的消息则可以编辑所有字段的内容。
(为什么发出去的消息还要做隐藏/撤回的处理？为什么不直接进行编辑呢？发出去的消息用户已经接收了，如果对已发送的消息进行编辑会带来什么样的后果以及需要承担什么样的风险我们都需要考虑，所以这里不建议直接编辑已发送的消息。但是我们需要规避已发送的消息是否存在政治敏感、舆论导向或其他，防患于未然才设置一个“展示”的功能。这是一个规避的手段，万不得已是不会使用的。）

非功能性需求

主要是对系统自身的一个提醒，产品的进度任务跟踪以及事件触发的非功能性的需求。
非功能性需求分类主要有3大类：
业务需求：主要是产品各个业务的提醒，如订阅提醒、任务进度提醒、学习进度提醒等。
系统性能：如发生无法访问、卡顿会有系统提醒，当然这里可以设置一些亲切的语句来提醒用户避免流失。
事件触发：产品使用过程中所触发的一些事件，如下拉加载时候提示语或者加载动画。