这么简单都做不好?教你如何做好一条「消息推送」

「消息推送」看起来简单,背后也有大学问哦。

消息推送(push)作为在App运营中经常会使用到的一种手段,能够低成本、点对点的向用户传达明确的信息。但同样的,消息推送作为运营人员与用户间最近距离的一种接触方式,若使用或设计不慎,也可能会引起很大的负面作用。甚至会因骚扰用户而导致应用被卸载。

最近在做一款社交类微信小程序时,我也遇到了一个与推送相关的问题。在解决完自己的问题后,我想梳理一下自己解决该类问题的思路,一方面为了加深自己的理解,查漏补缺。另一方便也希望能够为需要的人提供一点设计时的建议。

一、内容优先级

需要推送的信息,一类是为了实现基本功能所必要的硬推送信息,一类是作为运营手段的软推送信息。前者在推送中的优先级是大于后者的,尤其是在有大量的需要被推送的内容时,设计者应懂得取舍和权衡。

合理分类好应用中涉及到的需要被推送的不同信息,并给予不同的推送方式,可以帮助我们有效的维护好与用户间的亲密关系,避免踩到雷坑。
从这一维度看,硬推送信息的优先度自然是大于软推送信息的。

其次,若按照与用户相关角度看,通知信息可分为:用户相关信息和用户不相关信息。前者的推送优先级自然是所有的信息优先级中最高的。而在用户相关信息中又可以划分出许多类别的信息层级。比如 :

1、用户的敏感操作行为带来的反馈信息。这类信息在游戏和社交软件以及涉及到金钱交易的操作中最多见。比如探探的匹配成功,付款时的身份验证,clash of clans的建造完毕提示,订单的状态更新。

而如何界定“敏感”程度,还要看该项操作的紧迫性和应用核心功能的相关性。比如,投诉类信息虽然与一些应用的核心功能无关,但是作为牵动到用户情绪的敏感内容,一定要慎重对待,优先推送。

2、用户的一般性操作带来的结果通知。一般而言,能够在很短时间内得到结果的操作,尽量给予即时的通知。而对于需要消耗一定时间才能得到结果反馈的操作,比如媒体的下载,后台的处理结果等,也尽量在第一时间内向用户告知结果。总的来说,这类信息要做到即时通知,保证实时性。

Paste_Image.png

二、推送形式

主要的推送方式按技术的实现方式上有三类:

轮询方式(Pull)App客户端定期发起Push消息查询请求,来达到消息推送的目的。Pull方案的优点和缺点都比较明显,整体架构简单但实时性较差,我们可以通过加快查询频率,提高实时性,但这会造成电量、流量消耗过高。

基于短信的推送方式(SMS push)通过短信发送推送消息,并在客户端置入短信拦截模块,能拦截短信,并解析后转发给App应用处理。这个方案实时性好、到达率高,但成本很高。

长连接方式(Push)移动Push推送基于TCP长连接实现,消息实时性好,这是目前主流的实现方式,需要维护App客户端和服务端的长连接心跳,会带来额外的电量、流量消耗。

按具体表现形式上有:短信形式,系统推送,邮件发送,App内部提示。

其中,采用短信的形式,用户触及率最高(不考虑短信被拦截的问题),但也最容易引起用户的负面情绪。所以短信形式应该用于涉及金钱交易类信息的推送,如行程订单,支付验证;或者频率需求低的安全类问题,比如与账户密改相关的一类信息。

个人认为,运营类信息特别是广告类信息,不适合采用短信通知的形式,除非该类信息里包含着对用户有着巨大吸引力的内容。与此同时,一定要在信息结尾提示用户退订的流程与做法。

系统通知推送,作为最常见,直接的信息传达形式,也是运营者最喜欢借助的手段。该类方式既可用于传达与主要功能相关的信息,又可传达与运营者意愿相关的信息。而实际上用户愿意主动接受的是前者。

所以,运营者要意识到每一次通过系统通知推送其他类别的信息,实际上都是要冒着引起用户负面情绪的一次尝试。只有真正和用户相关的信息文字才会吸引到用户的注意,否则无论标题文案多么精彩,也只能依附于用户片刻的情绪和好奇心。

对于采用发送邮件的形式,由于不同用户查看邮箱的习惯不同,导致部分用户无法在第一时间内浏览到邮件的内容(不考虑邮件被拦截),所以这就意味着该方式不能用于推送时效性较强的信息。但正因为多数用户都有定期查看邮箱的习惯,所以根据这一点进行一些时效性较弱,且具有周期性更新的内容推送是合理的。同时邮箱作为用户的账号管理中枢,也适用于接受与账号安全密切相关的信息。

所以,我们在选择推送方式上,要从迫切度、频率需求、实时性这三个方面来考虑。

迫切度上短信>系统推送>邮箱

安全性上短信>邮箱

频率需求系统推送>邮箱>短信

(以上排序为,由强→弱)

ps: 最近在做一款微信小程序时发现,小程序的接口不允许向用户及时发送系统推送,所以这个时候要借助订阅号或者服务号来完成。对于服务号,每个月只允许向用户主动推送四次自定义内容。对于订阅号,每天可向用户推送自定义内容,但该内容无法和各用户的openid关联。

三、推送时间

选择恰当的推送时间,从而精确的向用户推送合理信息,也是需要仔细考虑的。如很多公众号选择在晚上7点~10点范围内推文是有其道理的,毕竟这个时候用户有相对宽松的时间来浏览扑面而来的各种信息。

新闻类、公告类信息适早上7点前推送;

需要用户参与互动类内容则适合在午间饭后,晚上睡前推送;

营销类推广推送宜避开目标用户工作繁忙时段;

采用短信、系统推送形式的信息,一定要避开有可能打扰用户休息的时间段;

采用邮件形式推送的信息宜早推送,因为一定数量的用户存在工作日上午查阅邮箱的习惯。

在推送时间的选择原则上,众说纷纭。我认为,需要具体的分析自己的用户群体的活动习惯,并与推送的目的相匹配,在这个基础上再来确定时间点。而时间点一旦确定下来,也不要轻易更改。

飞常准这个软件在推送时间的选择上值得借鉴,比如国内航班和国际航班的提醒时间存在区别,乘机人与借机人的推送时间也有区别,做到了针对每一部分用户都能够较为准确,在合理的时间段推送。而在技术上,飞常准这类App采用的是读取系统日历的方式来确保推送的及时通知,这样一来,也减轻了服务器的压力和推送成本。

四、推送频率

推送的频率越高,自然越易引起用户的情绪波动。所以在推送频率的制定上,尽量避免推送意义较小的内容,从而降低推送频率。对于用户真正关心的内容,不必过度考虑高频推送给用户带来的后果,毕竟在这种情况下,没有什么能够比让用户在第一时间得到自己所关心的信息更重要了。

但是,对于一些用户自愿持续关注的时效性较强的超高频信息,更建议把这类推送放在App内部,或者当该类信息累积到一定量时,再通过系统通知方式来进行推送。比如。不过,这类问题的最优解决方法,我认为应该在应用内部提供让用户能够自定义的推送功能。

手机的闹铃实际上就是这一问题的一个典型例证。在有悖用户意愿的情况下,闹铃在任何时候响起都是一种极大的骚扰。但一旦经过用户设定,无论在何时以怎样的频率响起,用户只会觉得闹铃是可以给自己提供便利的工具。

五、文案格式

在文案的格式上,主要需要考虑到两个问题。

1、字数限制

iOS对系统推送中内容文档的要求是4kb,大致两三千字的容量。所以对于字数上限,并没有需要特别注意的地方。但实际上,字数过多会严重引起用户阅读不适。在能明确信息表达含义的前提下,字数固然是越少越好,不宜超过三行。

对于以短信推送的形式,尽管对字数没有上限要求。但当我拿出手机时会发现,字数过多的短信内容我从来都不会看,哪怕会忽略一些带有重要内容的信息。因为在我的潜意识里,采用这种格式的信息大多都是广告。不能排除很多用户都有这种心理,所以如果不得不通过超过三行文字来表达出重要信息,务必要在显眼处标注重要词汇。

2、文案风格

在推送系统消息、重要信息、验证码、操作指令等严肃性内容时,尽量以直叙的方法来描述,不推荐带入感情色彩,同时要突出关键性内容。iOS向开发者提供了推送信息中文字格式的更改渠道,并且在iOS10中允许开发者在系统推送中加入缩略图。

Paste_Image.png

在推送一般性运营内容时,在推广活动,向用户提供优惠便利时。要在文字初始时把优惠向用户展现出来。

Paste_Image.png

前面说了几句话都在为最后那句送话费做铺垫,用户没那么多耐心来读完所有信息。

Paste_Image.png

1元包月骑单车,一目了然。

在进行活动预告时,尽量在推送中使用简要语言描述活动概况,切忌不要说的太隐晦,否则大概率会被用户作为广告丢在一边。比如:

Paste_Image.png

百度外卖到底要推出什么样的活动呢?

像一些写作手法,如夸张法、蹭热点法、设问法等手法需要结合运营内容具体分析。当然,无论采用哪种手法都要秉持实事求是的原则。一味为了博眼球吸引用户注意的标题,被用户专心浏览后发现恶趣味的实质时,怕是摆脱不了被拉黑的命运了。

六、数据运营

确定一套push规则后,仍需要在运营期间结合A/B测试和数据分析,找到真正符合用户期望和接纳信息习惯的合理推送方式,对规则进行不断修改和更正迭代。

总的来说,想做好信息推送的设计,除了需要全面的考虑以上六点内容外,还要真正保证被推送信息在内容上的合理、优质。否则即便一时抓住了用户的心理引起注意,也会逐渐埋没,被用户贴上无用信息、骚扰信息的标签,最终造成不可挽回的局面。

文/Elc_tom

0条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表