傻大方


首页 > 潮·科技 > >

通知|B端产品设计:消息中心数据流逻辑



按关键词阅读:

编辑导读:消息中心作为系统信息的集散地,是系统与用户之间对话的基础。本文作者梳理了B端产品的消息中心数据流逻辑,希望对你有帮助。
通知|B端产品设计:消息中心数据流逻辑
文章插图
通知|B端产品设计:消息中心数据流逻辑】此文是本人从事产品经理工作以来,在设计B端企业内部系统消息中心相关功能时的一些思考,偏重数据流逻辑梳理,内容讨论展开多基于B端企业内部产品的消息场景。
一、定位、来源及作用消息中心作为系统信息的集散地,是系统与用户之间对话的基础。通过这个集散地,系统可以向用户传达包括且不仅局限于以下信息:
特别地,针对IM类产品,消息更多是用户与用户之间的对话信息,此类不在这里讨论。
不同的系统,因其产品定位不同,其消息中心数据来源和作用也不相一致。一般系统的消息来源在大方向上可以分为2类,一类是站内消息,一类是站外消息。

  • 站内消息:指系统本身触发的消息内容,涵盖系统公告、待办提醒等;用于向用户传达其在当前系统需要执行或知悉的信息,用户行为一般限制在当前系统内,不与外界系统产生信息交流或动作交互。当然,也有一些消息来源是站内,但用户需要在外界系统完成信息处理的,不过相对比较少。
  • 站外消息:指外部系统通过当前系统分发机制给用户同步的提醒信息;用户在收到此类消息,正常都可以通过当前系统链接到对应外部系统去完成信息处理动作,用户行为不局限于当前系统内,会频繁与外界系统产生信息交流或动作交互。
通知|B端产品设计:消息中心数据流逻辑
文章插图
例如,某司针对HRBP群体有一个工作台系统,用于处理HRBP工作事务,其消息中心定位是作为HRBP获取与其相关的工作事务通知提醒的信息集散地。所以该消息中心的消息来源便不仅有工作台本身,同时支持外部系统消息接入,如招聘系统接入招聘入职相关消息、360评估系统接入评估提醒相关消息等。用户可以通过这个系统获知所有工作相关的信息,并有针对性地对消息进行处理,而不再需要登录其他40+个HR相关系统获取信息。
所以,在开展消息中心设计之前,我们一定是需要明确这个功能的定位和数据范围,也就是梳理清楚战略层和范围层的内容,在这之后才能更好地完善功能逻辑和甄别需求。
二、消息流逻辑无论站内还是站外消息,在消息数据进入消息中心之后,会通过其分发机制触发给相关用户,用户即可在前端系统的消息盒子中查看到具体的消息内容;如果涉及到转发外部系统提醒的,如邮件中心或短信中心等,则会由消息中心向对应系统发起请求,并触发短信或邮件至用户处。可见下面时序图:
通知|B端产品设计:消息中心数据流逻辑
文章插图
我们可以看到,上述时序图涉及消息来源、消息中心、消息盒子和外部通知系统。
  • 消息来源:含站内消息和站外消息,可以是当前系统本身的提醒或公告,也可以是外部其他系统的提醒。
  • 消息中心:当前系统的底层逻辑,用以消息分发、请求外部通知的集中处理模块。
  • 消息盒子:当前系统的消息中心外在表现,用以与用户交互和信息交流的功能模块;用户可以在消息盒子中查阅所有与其相关的消息。
  • 外部通知:部分需强提醒或对时效性要求高的消息,会通过一些外部系统辅助消息及时快速触达,使得用户没有登录当前系统也能获知消息。此类外部通知系统多指邮件服务中心、短信服务中心、企业微信、飞书、钉钉等。
消息来源请求消息通知时,会向消息中心发送请求,请求中一般包含这些信息:来源标识ID、请求时间、接收对象ID、消息内容(标题+正文)、提醒方式等。消息中心可以理解为包含待发送池、已发送池两大数据表:
通知|B端产品设计:消息中心数据流逻辑
文章插图
消息来源信息会先进入待发送池排队,形成一个消息队列,遵循先进先出规则。消息中心会根据每个消息中所携带的接收对象ID进行消息分发,即将该消息发送至对应用户的消息盒子中;同时根据提醒方式判断是否调用外部通知系统启动其他提醒方式。外部通知系统一般有固定的消息模板和提醒逻辑,消息中心需要将提醒对象和应用模板ID、对应模板参数同步给外部通知系统,由外部通知系统判断并触发消息模板进行通知。


稿源:(人人都是产品经理)

【傻大方】网址:/c/1201b0X62021.html

标题:通知|B端产品设计:消息中心数据流逻辑


上一篇:炒房|Zillow“炒房”失败,算法神话破灭了吗?

下一篇:腾讯云|对话北明数科董事长王进宏:因「时」而变,数字化转型赛道遇上了腾讯云