万博manbetx

今日:
首页 万博manbetx官网 解决方案 公司要闻 产品展示 联系万博
万博manbetx > 产品展示 >
浅谈Web端平台产品消息系统后台功能规划
来源:万博manbetx  发布时间:2019-09-07 07:01  点击次数:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  推送方式:官网、手机、邮箱等。这里的手机可以采用第三方的接口没必要在自己开发,当然这里第三方的推送主要是营销类的短信,对于如果有2B的APP应用则会有不一样的推送方式这里就不过多说明(因为好多大牛都分析过了)。邮箱的话可以集成公司邮箱的API接口或者采用第三方的营销API。

  推送人群:根据产品的用户特性,可以简单的区分为普通用户和会员用户。当然对于特殊的需求还会有指定的用户人群。为了方便后续的推送这里面应当可扩展,并不局限于这几个用户人群。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  一般做法:1.先把产品的信息流转过程用流程图梳理出来;2.结合思维导图将每个业务线.再表现形式上可以设计消息模板列表、变量列表。

  这里的变量比如,你提到的XXX商品,就是一个变量。订单状态也是一个变量。变量程序后台设置好,文案我们可以随时在后台管理做编辑就可以了。

  需不需要发消息,是业务需要,使用场景决定的。不完整又怎么滴,满足用户才是第一。

  满足用户虽然是第一,产品完整虽然对用户来说不痛不痒,但是我们作为产品对自己一手策划的肯定是希望能保证一个完整的产品架构。

  首先最主要的还是满足各个业务场景的需求,毕竟最接触商业变现价值的也就这个背景;

  其次产品完整性和感知活的是根据不同阶段的产品才会有的,产品发展前期这个消息功能是完善用户体验其中一个功能。

  “活的”可能不够精确,不过表达的意思是:一个作为B端平台服务于用户,更好的触达用户。让用户知道我们产品是不断完善和更新,而不是一个“死的”玩意。

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

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

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。



相关阅读:万博manbetx

Copyright © 2019 版权所有 万博manbetx官网
万博manbetx | 网站地图