zoukankan      html  css  js  c++  java
  • 全面分析:APP中的消息功能设计

    一、定义

    APP的“消息”模块,是通过APP或手机这个客户端,围绕某个产品的功能进行交流、沟通的重要方式。这种沟通,一方是运营人员或商家,也可以是产品或系统本身,为方便说明笔者这里姑且统一简称为B端,另一方则是使用APP的用户,也即是我们一般说的C端。

    消息功能是产品中B到C沟通的重要机制,是产品中非常重要和基础的一个功能模块。消息功能,因为产品的定位不同,其重要程度也存在非常大的差异。简单来说,在不同类型APP中,其重要程度排序大概为:内容/社交类APP > 电商类APP > 资讯类APP > 工具类APP。

    二、消息功能的应用场景

    从产品或设计人员的角度来说,消息功能一般有以下应用场景:

    1. 通讯提醒

    主要值IM或社交类应用,当用户离开应用时收到好友信息,这时需要通过消息功能来提示用户查看;还有如微博、豆瓣等应用,当收到其他用户的赞、评论或留言时,系统同样需要通过消息功能来提醒用户去查看;

    2. 推广促活

    包括两个方面:

    • 一个是对那些流失用户,通过一些用户可能关注的信息来吸引用户回归,达到挽留和减少流失的目的;
    • 另一个方面,将新的运营活动,通过消息宣告给目标用户。

    3. 通知提醒

    如用户账户变动、产品重大功能更新,或商家活动变更等事项,需要及时告知用户;保持用户对重要事项的知情权,不仅是对用户的尊重,更是降低用户对变化的抵触、减少用户抱怨的必要手段。

    4. 流程反馈

    对于用户的关键操作,尤其是那些可能无法即时呈现最终结果的(比如:申请提现、付款后等待发货、请假等),需要在操作或流程有结果后,通过消息的形式及时给予用户反馈。及时、清晰的反馈是用户体验的重要一环,能够提升用户对流程的掌控感、安全高,从而增加对产品的信心。

    三、消息的分类

    广义的“消息”,并不局限于客户端APP之内,而是包括B端到C端传递信息所有方式。根据在用户端(APP)展示的形式,大概有短信、push通知、弹窗浮层类、应用内消息(消息中心)四大类。

    接下来我们将依次分析这4种类别的消息,探讨下它们的应用场景、优缺点和设计时需要注意的问题。

    四、短信

    短信因为要经过电信运营商的渠道给用户手机发送信息,所以对产品来说成本是最高的。另一方面,虽然随着各方监管及规范,骚扰和垃圾短信泛滥的情况已经大有改观,但过于频繁和无关痛痒的短信,会对用户造成很大的反感和困扰。因此,在发送前,务必要慎重。

    1. 发给谁?

    一般来说,从产品经理角度来说,发送短信的目标用户中,有两类用户是“最有价值的”。

    • 一类是那些曾经注册过,但很长一段时间没有打开过APP的用户,为了尽量减少流失率;我们可以通过产品特色功能来吸引和唤醒用户再次进入APP。
    • 另一类用户,是那些长期处于“观望”状态——即注册后一段时间偶尔有登录但未深入使用或产生消费行为的,这类用户往往需要使用短信这种到达率最强的通信方式来争取获得用户的关注。

    理想情况下,运营人员通过后台,可以根据用户的注册时间、使用情况、消费情况等维度来筛选出各类用户,并有针对性的给他们发送信息,这样可以达到更好的效果。以流失唤起为例,如果我们需要唤起的是流失的活跃用户,那我们在筛选发送对象是,可以从以下维度考虑:

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

    2. 发什么?

    大多推广、促活、新闻资讯类的短信,其内容一般由3个部分组成:

    1. 发送者:即产品或公司名称;
    2. 核心文案:尽量一句话告诉用户产品有什么活动、什么优惠、
    3. 跳转链接:一般显示为蓝色下划线的文字链接,用户通过点击文字可以实现跳转,一般是到手机wap活动页面、app下载页面等。

    某社交app的推送短信

    3. 什么时候发?

    对于大多数用户来说,一天有4个时间段是相对最闲、最轻松或精神状态最佳的。分别是早上班时间段(8:00-10:00)、午休时间段(12:00-14:00)、下班时间段(18:00-20:00)、睡前时间段(21:00-22:00)。产品经理和运营人员在选择短信和push发送时间时,需要参考这些规律。

    当然,还要结合自己产品的定位,比如:外卖应用最好选择中午下班前的1个小时到下班后1个小时(大概11:00-13:00);新闻、天气类应用最佳的推时间是早上班时间;而游戏视频等娱乐类的消息,最好选择下班后的时间段。

    以下是引用的小米对push推送发送时段点击率的统计(我们有理由相信,对于短信也是大同小异),也可以看到在下班后(晚上)、中午、及周末的推送的效果明显更好。这也在一定程度上证明了,选择合适发送时间的重要性。

    推送(push)发送时间和点击率

    五、push

    1. 定义

    push通知,是通过互联网服务器直接向用户终端(APP)发送信息,并且消息会显示在用户手机的系统通知栏。在国内,目前消息推送主要有以下三种途径:手机厂商(小米推送、华为推送)、第三方(友盟推送、极光推送、个推)、BAT推送平台(阿里云推送、腾讯信鸽、百度云推送)也可以进行多种推送形式的组合。

    Ios的推送走的是苹果自己的服务器,无论用户的app是在线或者离线都可以接收到推送信息(前提是用户开启推送通知权限);而android版使用个推(因众所周知的原因,Google在国内服务不稳定,于是就有很多第三方的Message推送的服务商),如果app进程被关闭,则推送的消息会被离线缓存到个推服务器上。

    因此与短信相比,即时性要弱一些。当然部分手机和平台可以通过代码解决,但涉及较多技术问题,并不是这里要讨论的范畴。

    2. 主要场景

    因为push通知可以绕过运营商,所以相比短信成本更低,可以更频繁的使用,所以在多数情况下,运营人员喜欢用它来替代短信,给用户发送一些不定期的信息,如各种促销、运营活动,以达到唤醒、增活和留存的目的。一些新闻资讯类的app也会通过push的方式推送一些有趣、新奇的信息,来吸引用户进入app浏览。

    push通知一般由APP名称(或图标)+发送时间+文案组成,用户点击通知,可以唤醒APP并跳转到对应的页面。

    有一类比较特殊的push通知,即类似qq和微信的通知。主要用来提醒即时查看收到的新的消息。

    3. 如何提高达到率?

    很多用户因为手机推送太多造成困扰,可能会主动关闭app的推送功能;尤其是对Ios应用在安装时,很多用户无意或有意去选择关闭。导致后面的push通知无法到达。

    因此,我们要在产品中提醒push的重要性,并通过一定的设计来引导用户去开启通知。

    新浪微博/拉勾网

    六、弹窗/浮层

    通过弹窗来给登录的用户发送消息和通知,是一直很直观的形式。只有最重要、最有时效性的状态更改才应该使用弹窗。

    主要包含以下场景:

    1. 推广促活

    新的产品、商品上架、新活动上线时,或是重要的高频活动需要进行推广时(如提醒每日签到),在用户登录或进入app,或进入特定模块时,用弹窗的形式来告知用户。尤其是那些理财、电商类的应用,其日常的产品上新非常频繁,经常需要用消息的形式来进行推广。

    2. 通知公告

    产品端或企业方面的重要事项,如果这些事项对用户使用产品确实有重要影响,可以通过弹窗来告诉和提醒用户。例如:订单异常、产品停服更新、账户变动等等。

    3. 功能引导

    折扣券即将到期的提醒、红包可提现的提醒、奖励兑换的提醒、APP升级提醒等等,这类对用户的事项,如果能适时给与提示,则可以有效提高用户的积极性,提高相关功能的转化率。反之,如果在发生重要变化时,用户不知道,很可能造成用户的不满。

    4. 浮层类型的提示

    除了弹窗,还有浮层类提示,比如app底部或顶部的提示栏、页面边缘的按键浮层等形式.在app中,我们最常见的有以下两类:

    (1)浮窗广告

    一般用来推送一些临时的活动,可以用来作为与当前页面相关的活动推广入口,用户点击这些悬浮图标或按钮,可以进入弹窗或其他页面查看更详细的内容,这种消息类型其实与那些可以随时由后天配置的banner功能非常类似。

    需要注意的是:为了避免造成糟糕的体验,这些浮窗广告应该有关闭按钮(且关闭后不要无休止的弹出),或者至少应该设计成可以在屏幕移动的,这样可以避免影响用户查看页面其他内容。

    (2)顶部提示栏

    适合一些可以用简短的一两句话表达清晰的提示文字,这些消息一般是临时的(可随时在后台上下架)、且与当前页面紧密相关的。如果是一些临时或时效较短的消息,应该允许用户可以手动关闭,且在有效时间内应该及时下架。

    七、消息中心

    消息中心是指用来统一展示系统发送给用户各类信息的一个固定的模块,用户可以进入这个模块或页面统一查看各类消息。

    这个模块一般由消息列表和具体详情页组成,除了那些场景单一和功能异常简单的应用,大多app的消息列表会按照消息标题和概要来一条条显示,更多的信息可以通过详情页来展示。

    对于消息详情页,既可以简短的一两句话,也可以是包含为字、图片、视频等多媒体信息。一些运营推广的活动,也可以通过消息的形式发送给用户,并允许用户跳转到应用内其他模块或H5页面。

    消息中心的入口,最常见的一般是单个图标(如:铃铛、信封等),或者直接是文字入口,并配合红点、数字角标、图标动效、震动等各种提示来增加消息的可见性,使用户可以更容易注意到新消息的到来。

    大多情况下,仅用一个维度来呈现各类消息,会使消息列表变得非常混乱、没有主次,且并不利于突出运营人员希望用户重点关注的消息(如活动上新)。因此,笔者建议在设计消息中心时,应当进行适当的分类,这样用户可以方便用户快速定位自己感兴趣的类型(如账户变动等个人消息),而忽略那些可能并不是那么重要的消息(如系统更新公告等)。

    不同定位的产品,消息类型和复杂程度也差别甚远。因此无法在此一一举例。笔者仅以互联网金融(P2P)产品的消息为例,来分析下消息中心的消息分类。

    (1)个人消息

    与个人账户关联的消息类型,主要包括:账号变更、等级变化、资金流动、交易消息、订单变动、点赞、评论等等。

    (2)站内通知

    APP内容、版块的变动、活动变更、活动结束、功能调整等影响用户使用体验的消息类型。

    (3)活动通知

    拉新促活的重要手段,引流的入口,用来推广新上线的产品、运营类活动或新功能等。对于比较核心的活动,除了在消息中心展示,还应该在首页位置告知用户,结合banner、弹窗、浮窗广告、通知栏等样式来展示。

    (4)系统通知

    APP内容、版块的变动、调整等影响所有用户使用的消息类型。一般来说,这种类别往往是重要等级最弱的消息,仅是通知那些不会对用户使用造成重大影响的信息,例如:APP内容、入口的微调,系统升级、放假通知等等。

    总结一下

    1. 确认目标

    在设计消息功能时,需要确认设计的目标,也即场景。这样才能选择更合适的形式。

    在明确消息功能的场景下,还需要明确哪些消息是真正对产品有价值的,哪些是对用户有价值的。有价值的消息,才有发送的必要,宁缺毋滥。例如:核心的推广活动可以为产品带来收入,是对产品最有价值的,因此可以选择短信、push、弹窗、消息中心的一种或多种同时发送,从而提高达到率。

    而那些日常产品的更新通告之类的消息,无论是对产品和用户,都是“不那么重要的”,这样的消息,发送到消息中心即可,同时在用户端,归类到重要程度最低的“系统消息”的类别进行展示即可,这样可以不用占用用户过多的注意力。过多的、过于频繁或无价值的消息,只会让消息功能变为鸡肋,甚至成为用户的认知负担。

    2. 提前规划

    需要说明的时,这些功能最好需要在产品设计之初就要规划好,而不是每次都重新设计。例如:我们只需要在产品的后台设计好发送弹窗消息的功能,并规划好相关可选的控制字段,如图片、按钮、发送位置、发送频率(如每天一次、仅打开app一次等)。

    这样,当运营或产品人员需要有新的消息需要通过弹窗来发送时,就可以直接在后台上传设计好的弹窗图片素材,并设置相关参数即可,而不是每次都要开发人员来帮助实现、甚至是重新发包。

    3. 精细化运营

    无论是以上4类消息中的哪一种,都是可以筛选用户类型,分别发送。粗放、无针对性的发送固然简单,但不仅达不到预期的促活、提升使用体验的效果,还会对用户造无谓的打扰,引起用户的不满。

    日常工作总结,不足之处,欢迎拍砖。

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

    题图来自Unsplash,基于CC0协议

    http://www.woshipm.com/pd/1635620.html

  • 相关阅读:
    JavaScript大文件上传(切片)
    hdu 4841 圆桌问题(STL vector)
    hdu 5389 Zero Escape(记忆化搜索)
    hdu 1331 Function Run Fun
    hdu 1078 FatMouse and Cheese(记忆化搜索)
    【CQgame】[幸运方块 v1.1.3] [Lucky_Block v1.1.3]
    SAP C4C,CRM和S4HANA的Saved Query使用介绍
    SAP CRM中间件Material Sales Organization和distribution channel的映射逻辑
    SAP CRM 中间件Request download里,遇到/SAPPSPRO/S_MAT_ENHANC_COMM 错误的解决办法
    SAP 数据库表CRMD_ORDERADM_I字段OBJECT_TYPE的计算逻辑
  • 原文地址:https://www.cnblogs.com/softidea/p/11460589.html
Copyright © 2011-2022 走看看