浅谈Web端平台产品消息系统后台功能规划

28 评论 2.7万 浏览 291 收藏 13 分钟

看了很多关于消息系统规划的文章,普遍的都是说明APP(安卓/IOS)的消息系统,但是很少从web端进行分析,而笔者借此简单记录下自己在规划web端平台产品消息系统(以后台为主)功能的一个思路。虽然现在互联网是移动趋势,但是web还是重量级的,因为它面向的更多是B端用户。

平台产品与B端、C端产品来说是具有一定的差异性:B端和C端产品在目标用户上有明确的区分,而平台产品面向的目标用户有B端、C端或者BC端都有,简单粗暴理解就是一个聚合平台。比如:阿里巴巴平台、天猫平台、QQ音乐移动音乐平台、艾瑞咨询等等。

而我们平台产品主要是B端的企业级用户,所以本次将简单整理下近期规划的一款web端平台产品的消息系统,仅作为参考。

Tips:消息运营
消息标题如何运营、如何保证触达用户?这类问题已经有相关文章提及就不再多阐述了。下面主要以后台功能逻辑来浅谈。

以下为本次消息系统规划框架:

一、背景

平台型产品初建期需要保证产品的完整性,必须搭建可控的消息系统,形成产品完整的闭环:

  • 一来满足产品的完整性;
  • 二来确保让用户感知到产品是活的;
  • 三来满足平台产品上各个业务的流程。

二、目的

  1. 让用户更加容易获得提醒;
  2. 让产品更加直接的与用户产生交互;
  3. 分类整理消息。

三、用户人群

主要面向B端(企业级)用户

四、场景

  1. 营销类需要:比如运营策略需要的广告消息、优惠消息、活动消息;
  2. 使用服务后的温馨提醒:比如购买某某产品后的售后(发票申请进度、售后申请服务进度等等)、注册使用产品后的版本更新、优化说明等;
  3. 互动提醒:比如工单回复提醒、评论关注回复等提醒;
  4. 任务提醒:比如学习某个视频更新提醒、下载任务提醒、订阅某条推送提醒等等。

消息提醒的场景主要分为这4类,当然还会有更多,这里不一一穷举。对于目前产品能确保以上场景都能实现需求,那就可以了。

因为这就是传说中的MVP?是的没错,下面拓展一下:

MVP:最小价值产品或最小可视化产品,这在精益创业是中很重要的概念。

将核心的功能最先开发出来在不断试错中迭代和优化是我们目前的一种产品开发规则。

五、消息系统规划

消息系统的需求主要分两大类:功能性需求和非功能性需求。

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

Tips:消息状态
消息系统中,每条消息都具有唯一的状态即已读、未读和已关闭(删除,即不在客户端展示后台保留数据跟踪)。而且每条消息隶属于每个消息的分类下,即消息标签。这样区分的目的是便于分类管理和易读性。

消息管理/设置:主要是对接收的消息进行管理/设置,用户和产品之间存在主动接收和被动接收的关系。

用户可以主动去拒绝接收部分消息,这样做可以让用户在产品上获得更大的主动权。不同于普通B、C端的产品的是:平台产品在此类消息管理/设置中将很多的接收权限交给用户有选择性的接收。

并不是所有的平台产品都会有这个功能,对于一些聚集了很多业务的平台来说,有这个功能可以有效的避免接收到多余的消息干扰用户。如:腾讯云、阿里云、百度云等等。

但是对于业务区分不明显且不是很大业务量的产品来说,这个功能的存在无关痛痒。如:微信公众平台、各大媒体后台等等。

六、管理后台规划

相关字段说明:

  • 消息类型:公告消息、活动消息等。可通过管理消息类型进行新增、编辑、删除操作。这里的消息类型对应的客户端的消息类型。
  • 状态:已发送、未发送、已关闭。这里的状态指的是消息的推送状态,其中已关闭指的是消息在客户端做了隐藏(撤回)的操作。
  • 消息标题:根据客户端的要求,后台做字符、样式、位置等限制。
  • 消息内容:根据客户端的要求,后台做字符、样式、位置等限制。
  • 阅读量:消息在客户端打开/阅读的数量具有唯一性。
  • 推送时间:该条消息成功推送到客户端的时间。
  • 创建时间:创建该条消息的时间。

Tips:管理后台消息编辑和客户端有什么需要注意?
管理后台的消息标题限制字符以及标题的位置样式是和客户端分开的。通常我习惯于将客户端和后台需求都提及到避免开发同学忘记了,避免联调的时候带来不便。

1.创建消息:

根据不同产品的特性后台管理也会具有不一样的功能,但是基本功能都是大同小异的:

  • 消息类型:和客户端对应,将各个消息分类管理。
  • 推送时间:定时和立即推送可有效的管控并做好运营策略。
  • 推送方式:官网、手机、邮箱等。这里的手机可以采用第三方的接口没必要在自己开发,当然这里第三方的推送主要是营销类的短信,对于如果有2B的APP应用则会有不一样的推送方式这里就不过多说明(因为好多大牛都分析过了)。邮箱的话可以集成公司邮箱的API接口或者采用第三方的营销API。
  • 推送人群:根据产品的用户特性,可以简单的区分为普通用户和会员用户。当然对于特殊的需求还会有指定的用户人群。为了方便后续的推送这里面应当可扩展,并不局限于这几个用户人群。
  • 消息标题:-
  • 消息内容:富文本编辑器。
  • 新增热区:单独把热区拿出来讲一下。

热区可能对于部分没接触过的人来说不是很懂,简单理解为就是:某个页面指定区域可以实现点击跳转,更简单粗暴就是超链接,点哪里超到哪里。

为什么编辑器要热区这个功能?

因为我们看到很多的图片消息都是带有领取优惠券或者点击某个按钮进入到活动详情,这个时候纯图片和纯文本都无法满足我们的运营需求。所以可视化的热区功能将提高我们运营的效率和满足各种营销策略。

2.编辑消息

  • 对已发送状态消息可以对其进行的操作仅限于“展示”功能(即在客户端是否展示)。
  • 未发送状态的消息则可以编辑所有字段的内容。
  • 已关闭状态的消息则 不可以进行任何操作在消息后台中相当于回收站,可以给运营做总结分析。

Tips:为什么发出去的消息还要做隐藏/撤回的处理?为什么不直接进行编辑呢?

这里提醒一下,发出去的消息用户已经接收了,如果对已发送的消息进行编辑会带来什么样的后果以及需要承担什么样的风险我们都需要考虑,所以这里不建议直接编辑已发送的消息。

但是我们需要规避已发送的消息是否存在政治敏感、舆论导向或其他,防患于未然才设置一个“展示”的功能。这是一个规避的手段,万不得已是不会使用的

七、非功能性需求

主要是对系统自身的一个提醒,产品的进度任务跟踪以及事件触发的非功能性的需求。规划:
非功能性需求分类主要有3大类:

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

非功能性需求的消息目标用户当然是以“触发”为基准,所有用户只要达到条件触发就会由产品自动推送相关的消息,不管是消息中心里面的消息还是一些小小的提示语,都属于一种非功能性的消息需求。

消息系统的规划主要还是需要根据产品的特性讲消息进行分类。而后台的功能从根本上来说本质是一样的,需要注意的是根据客户端和产品的业务进行逻辑区分,保证能够触达用户。

文章简单记录笔者在规划web端平台产品时候的一个思路,web端产品面向的当然不仅是眼前的B端用户,后续还将会有第三方供应商和服务商的加入。但是对于消息系统的本质来说这是推送的目标人群多了,具体的是以新增用户标签还是另做规划还需要以业务形态来决定。

 

本文由 @Randy俊 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自PEXELS,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
4人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 你好 可以加个微信吗😁

    回复
    1. 主页可以加。谢谢阅读

      回复
  2. 超赞! 多谢分享

    回复
  3. 效果图看不清?

    回复
    1. 看不清

      回复
  4. 想问一下,非功能性的消息,也要在管理后台展示出来吗?

    回复
    1. 展示出来便于维护和后期运营

      回复
  5. Minimum Viable Product

    回复
  6. 消息的跳转,可否详细说明下,对于不同类型的消息不同场景下,用户收到消息后的跳转是什么?求指教

    回复
  7. 非常完善!干货满满!!!!

    回复
  8. 基础消息系统已经非常全了,
    后续自动化配置、管理、分发tag其实还可以更好

    回复
    1. 你好,我最近也想了解下关于后续自动化配置这一块,前辈有什么资料吗?小白表示还没有头绪。 ➡

      回复
    2. 你好,我最近也想了解下关于后续自动化配置这一块,前辈有什么资料吗?小白表示还没有头绪

      回复
  9. 请问热区跳转的链接,是在哪里配呢?

    回复
  10. 希望有更多 像本篇一样的优秀实用的好文章 赞! 😉

    回复
  11. 正好需要设计这个功能,正好搜索到了这篇文章。感谢作者的解惑,写得很详细,看完之后有了详细的思路,很受用,大大的赞

    回复
  12. 有些地方不太懂,想请教一下。关于非功能性的业务上消息,如订单的流转的一些提醒,在后台设计中,该怎么设置(譬如这个消息的文字模板之类的:“敬的客人,您好。您于2018-04-12 12:22:44下单的商品 xxxxxxx商品 尚未完成订单,请尽快支付>>>>”)?

    回复
    1. 一般做法:1.先把产品的信息流转过程用流程图梳理出来;2.结合思维导图将每个业务线需要的推送穷举出来;3.再表现形式上可以设计消息模板列表、变量列表。
      这里的变量比如,你提到的XXX商品,就是一个变量。订单状态也是一个变量。变量程序后台设置好,文案我们可以随时在后台管理做编辑就可以了。

      回复
  13. 方便加个微信不

    回复
    1. 可以呀randyjun1993 😎

      回复
  14. 背景写的着实佩服

    回复
    1. 😈

      回复
  15. 功能描述的很详细,但是我觉得作为一个项目的痛点,下面两个明显不是。
    ———————————————
    一来满足产品的完整性;
    二来确保让用户感知到产品是活的;
    ———————————————
    需不需要发消息,是业务需要,使用场景决定的。不完整又怎么滴,满足用户才是第一。
    第二点,觉得用”活的”这个词,不够精确。

    回复
    1. 满足用户虽然是第一,产品完整虽然对用户来说不痛不痒,但是我们作为产品对自己一手策划的肯定是希望能保证一个完整的产品架构。
      首先最主要的还是满足各个业务场景的需求,毕竟最接触商业变现价值的也就这个背景;
      其次产品完整性和感知活的是根据不同阶段的产品才会有的,产品发展前期这个消息功能是完善用户体验其中一个功能。
      “活的”可能不够精确,不过表达的意思是:一个作为B端平台服务于用户,更好的触达用户。让用户知道我们产品是不断完善和更新,而不是一个“死的”玩意。

      谢谢你的评论。一起加油! 😎

      回复
    2. 有点挑刺的回复,居然得到解释。
      作者的修养让我佩服,祝你越来越顺。

      回复
    3. 淡定淡定,完全没这个意思。-。-, 解释是因为别人浏览了文章给自己意见和看法,背后肯定会梳理和想方设法去维护自己的立场(当然有时候肯定会陷入无法自拔)。

      PS,也许我立场维护的太过自我,让你产生误解。不过还是很感谢有人评论回复,这样才有更多多巴胺分泌。 😀

      回复
  16. 写得很详细,很受用,辛苦了,赞

    回复
    1. 感谢你的阅读。分享出来增加自己的印象。

      回复