在这里分享一下我关于梳理消息中心分类的观点吧，希望可以对你有所帮助。

关于你的问题“不知如何将消息通知梳理的更清晰一些？”，我对你关于更清晰一些的定义还不是很充分，到达哪种地步才算清晰？？

我会先把消息按照分类来划分大类，即：

1.1系统推送消息，涉及到软件的新品推送、更新推送、商品推送等图文信息推送，可跳转指定页面；

1.2操作反馈消息，涉及到用户的部分操作反馈，如注册成功、文章发送成功、商品下单成功等用户自主操作后的反馈信息，点击可查看详情或跳转指定页面。这里有个基础逻辑设定“哪里的操作反馈信息就满足跳转对应的页面”，也就是 订单消息能通过消息中心跳转到订单页面、文章发送成功信息能跳转到文章详情页等；

1.3用户互动消息，涉及到用户发表的文章或作品，关注、添加好友等用户互动的操作消息。

然后根据这3个分类和产品的内容规划，再来细化性的梳理和规划模板，这样的话，一般不会有大的纰漏，希望对你有所帮助。

我们之前做过一个消息通知系统，主要分为两大类消息：

第一类：系统自动的推送的消息（触发一个条件，进行推送消息）：

这个里面会涉及触发的条件、消息的分类、推送的标题、推送的内容、推送的方式（站内信、push、短信）、目标链接、状态（启用\禁用）等信息；

针对你说的社交的话，触发条件有：

1、关注了你；

2、赞了你；

3、评论了你的帖子；

4、回复了你的帖子；

5、帖子@了你；

6、评论@了你；

7、评论被点赞；

8、评论被删除；

9、用户信息被违规；

10、评论帖子信息违规；

11、帖子回复违规；

12、发帖违规；

第二类：手动推送的消息（在一个时间点，进行目标用户的推送）：

这个里面会涉及消息的分类、推送的标题、推送的内容、推送的目标用户（可以是单个用户、可以是一个用户群等）、推送的渠道（APP、小程序等）、推送的方式（站内信、push、短信）、推送的时间；

这块还会涉及到一些数据统计：比如推送的人数、触达的人数、已读人数、未读人数等维度

希望对你有用！

#产品经理挑战赛# day1 

因为没有设计过类似的功能，所以只能讲下框架上如果我是我的话，会从哪个角度思考8，希望有一点点用。

1.根据产品模块梳理出通知类型，比如社交类产品：

a.系统通知

   a1.必须类通知，维护/关闭/上线重要功能

   a2.召回类通知，“没事找事唤回用户的通知”

b.消息通知

   b1.用户交互通知：IM通知、相互关注通知

   b2.社区通知：帖子通知blabla

2.确认不同类型通知的优先级&确认总的通知数量的限制

优先级例子：交互>社区>必须>其他

数量限制：每天最多给用户发N次push，交互通知不算在内

3.效果监控

正：通知触达率，通知打开率等

反：通知权限关闭率等

核心思路就是根据功能模块和产品运营需要把通知拆分归类，然后成体系的去思考。

在拥有体系后，既可以根据当前体系去控制总体对用户的打扰，也可以选择合适的时机去让用户开启push权限。同时在新增场景时也可以很快把相关通知需求归纳到原体系内。

非常不建议零散的需要通知就涉及对应功能。。。

前期挖了坑，后期埋不好可能直接把自己埋进去……

从题目看不确定是「如何详尽的梳理App里的消息通知」指的是哪一种：

1. 消息通知类型详尽梳理

2. 消息通知流程详尽梳理

1. 如果是想详尽梳理消息通知类型的话，社交产品可能包含这些（具体还得从题主自己的产品业务出发）：

（1）用户模块——用户申请通知，用户间账号互动（如关注、举报、邀请等）通知...

（2）内容模块——用户发表的内容审核（上下架）通知，内容@、点赞、评论、收藏通知...

（3）系统模块——系统公告、升级提示...

2. 如果是想详尽梳理消息通知流程避免设计缺陷的话，可以试着这样：

（1）根据功能模块，先罗列出你的社交产品涉及到通知的所有业务场景

（2）根据触发对象是「人to人」还是「系统to人」，把（1）中的通知分到这两类下方

（3）一般「人to人」的通知优先级较高，细分出来会有诸如「@」，「点赞」，「评论」几种，定好这几种的通知模版，最后把对应业务场景会出现的通知归纳进去

（4）同理，「系统to人」一般是单向同步用户信息而已，可以选择细分or直接用一种通知模版传达给用户。

（5）最后，上述做的消息通知都是in-App message（站内信），还要确定好哪些要给用户弹push（手机系统层级通知）。

关于优秀的软件推荐学习的话，社交软件赛道有很多，没法根据这个描述给到什么参考，建议看看你们对标的竞品，以及市场头部的社交软件，找到一些有帮助的信息～

个人觉得消息通知模块和方法论已经很成熟了，但是还需要根据自身产品特色及业务类型来整合消息通知模块儿。公司平台业务中涉及到多个终端的消息推送，我是这样做的。

1. 先把整体业务流程走通。

2. 以使用者的身份复盘流程：在哪个节点需要让哪个使用者知晓发生了什么事情。不通知会不会发生什么事情，会不会影响使用体验。

3. 和一线运营沟通（业务偏B端）在使用过程中那一块儿的变动消息需要知道但是目前没能得到更好解决的可以考虑加上。

其实这个也像事件统计一样，把场景和流程都梳理出来后，就知道哪些地方需要进行推送通知。主要还是这个通知的时机和频率，不要为了通知而通知，而是想得更深，做这个通知能够给用户带来什么，能够为产品在数据上带来什么价值。并且用户能否单独去关闭某些通知，或者选择哪些通知需要开启。

你拆解一下一些大的app的消息通知模块中都有啥类型，以及他们通知的规则和流程。基本上就出来答案了