合理面对风险,服务号订阅通知的正确打开方式

2 评论 11123 浏览 38 收藏 16 分钟

编辑导语:我们的微信里一定都有不少的订阅号,服务号订阅通知对于用户的体验感有着不小的影响。本文作者为我们分析了订阅通知的方式以及推送通知的方式,并且针对本次微信计划调整通知策略事件,制作了一份的产品改造方案。

《微信服务号订阅通知灰度测试:模板消息之变》中,笔者分析了消息通知方式改变对大家产生的影响,弊大于利。

基于被“用户体验感”挟持的大前提下,不管微信团队是否执意要对策略做出调整,大家都需要未雨绸缪,合理的面对并解决这个风险,以免措手不及。

这篇内容,将会为大家分享笔者结合自己的产品,总结出改造的设计方案。分享前,先为大家解释一下订阅通知所涉及到的名词、订阅和推送通知的方式。

一、名词解释

  • 一次性订阅:指用户订阅一次,服务号可不限时间地下发一条对应的订阅通知;
  • 长期订阅:指用户订阅一次,服务号可长期多次下发通知,长期订阅通知仅向政务民生、医疗等公共服务领域开放。

二、订阅通知的方式

目前微信只开放了两种可以进行消息订阅的途径,具体流程如下。

1. 文章订阅

可以在服务号发布的文章中,插入订阅通知组件,用户点击进行订阅。

每篇文章最多插入10个订阅通知组件,每个组件最多包含5条通知,每个组件不能同时包含一次性订阅和长期订阅,文章推送后用户才可点击订阅。

2. 网页订阅

可以在服务号绑定的安全域名中,通过微信JS-SDK调起订阅通知界面。目前没有组件数量和订阅通知数量的限制,但每个组件不能同时包含一次性订阅和长期订阅,并且实际效果需要真机调试,无法用开发者工具模拟。

三、推送通知的方式

通知的推送流程,与模板消息推送流程基本一致,只是将验证[是否已关注服务号]改变成了,验证[是否已订阅通知]。

四、通知中的区别

在用户订阅消息后,已关注和未关注服务号,收到消息通知的表现形态有区别,具体表现形式为:

1. 已关注

已关注服务号的用户,和以往下发位置相同,直接推送到服务号内。

2. 未关注

未关注服务号的用户,会直接下发到服务通知,和小程序的通知入口一致。

以上就是笔者对订阅通知功能的理解,下面我将会为大家分享产品改造方案。由于不同产品的交互和业务逻辑不同,所以订阅通知的改造和实现过程仅供参考,具体实现方案还需要根据自身行业做出调整。

五、设计前言

本次是以一款G2C产品为例,产品功能通过服务号+小程序实现。C端用户在关注服务号并注册小程序的前提下,在小程序中触发需要通知的事件后,会在服务号中,同时给C端用户和G端用户推送通知。

因为一些业务需求的原因,C端用户必须要关注服务号。在1年前设计产品时,笔者根据此原因,并结合小程序通知需要G端用户订阅的前提。本着减少用户操作次数,并且服务号会定期群发文章供G端用户学习的想法,选择了通过服务号下发通知的设计方式。

应用场景举例(请勿带入现实生活):C端用户小赵在关注服务号并注册小程序(注册时获取了手机号码)后,G端用户会收到服务号注册成功的通知。

同时开发者后台实时根据小赵的手机号码探测网络中的风险。当小赵的隐私信息泄露后,会通过服务号给小赵和G端用户推送通知,告知存在信息泄露风险。

在互联网中,有类似场景的行业还有很多,甚至有一些产品是单服务号实现业务,对模板消息是具有强依赖性的,那么应该如何进行改造设计?

六、用户特征分析

在设计需求之前,笔者首先思考了产品面向的用户群体的特征,一共有两类:

1. C端用户

  • 特点:对产品依赖性不强;
  • 存量用户:基本不会重新进入服务号订阅通知;
  • 新增用户:基本会订阅通知,但订阅留存率可能较低;
  • 原因:产品是由G端用户进行推广,推广时现场教C端用户如何操作,但事后C端用户基本不会再次打开。所以增加服务号订阅通知流程,对新增用户基本无影响,但存量用户的订阅没有保障。

2. G端用户

  • 特点:工作原因,对产品依赖性高;
  • 要求:自己能收到通知,C端用户必须关注服务号并且可以全部收到通知。

七、确定设计边界

分析用户特征,确定产品用户需求后,需要明确设计边界,防止设计时违背用户需求。

1. C端用户

  • 产品使用方式:依旧采用关注服务号+注册小程序的方式;
  • 消息通知:无论是存量用户还是新增用户,都必须可以收到通知。

2. G端用户

  • 产品使用方式:在满足对C端用户要求的前提下,可以接受任何方式,但应尽量简便;
  • 消息通知:必须可以收到通知。

八、文档分析

确认用户特征和设计边界后,阅读微信开放文档,寻找是否有可以额外利用的点。在“订阅通知接口-用户操作订阅通知弹窗”中可以发现,用户在订阅/取消订阅通知时,微信都会向开发者服务器发送通知。

注:微信开放文档是动态文档,所以在阅读此文时,要注意自行查看文档,避免因微信单方面更新文档而造成信息差。

参数如下:

九、设计思路

在经过以上分析后,产品的改造设计思路已经基本明确了。下面采用将C端用户和G端用户拆分开方式,给大家分享我的解决方案。请自行进行差异设计。

1. C端用户

1)存量用户

首先,通过分析用户特征得知,C端存量用户并非100%不会重新进入服务号订阅通知。

为了保证C端存量用户在想要主动订阅时,能够有一个可订阅的入口。在将模板消息改造为订阅通知后,我们应该在服务号中提供一个便于查找、操作简便的订阅入口。例如,可以将能够订阅消息的文章或H5悬挂在服务号菜单中。

如果用户忠诚度较高,不会因为文章群发而出现大规模取关的话,在改造后可以通过群发文章来提高订阅转化率。笔者所负责的产品用户忠诚度偏低,属于静默类型,所以不计划通过群发文章提醒存量用户进行订阅,仅在文章和H5中悬挂注册入口和订阅入口。

2)新增用户

在分析用户特征时,笔者有提到这款产品的C端用户来源是G端用户现场推广引导注册。在根据自身业务流程做出调整后,对新增用户影响较小。

模板消息正式被微信团队替换为订阅通知后,也没有其他解决方案能够绕过订阅模式。所以在做调整时,要尽可能的保证减少用户为订阅做出的额外操作次数。

例如:笔者在某通快递小程序,仅查询物流动态就需要进行2次消息订阅,很令人不舒服。

我们在做设计功能时,可以考虑将验证是否订阅通知作为使用功能的条件,但并不适用于所有行业。例如,在用户下单时,验证是否订阅了发货通知,如果没有订阅就不允许下单。这种办法虽然可以提升订阅率,但显然也会影响成交率,请谨慎使用。

3)补偿机制

在解决完可以主动订阅的用户的问题后,我们还需要考虑如何对未订阅的用户发送通知。在这款产品中,不会收到通知的有存量未主动订阅的用户、新增拒绝订阅的用户、订阅后自行取消订阅的用户。

笔者采用的方式是,发送通知前验证用户是否订阅消息,如果没有订阅,就对用户发送手机短信。同时在短信中,可以结合小程序的“UrlScheme.Generate”能力,实现在短信的URL链接中跳转小程序。

在设计改造方案时,笔者查询了大量资料,得知互联网中有一些能力可以实现URL链接跳转到微信并访问指定H5页面,但此行为违反微信运营规定,所以没有采用。

2. G端用户

在进行特征分析的时候,我们提到G端用户因为工作原因,只能遵守产品规则。但在改造时仍然需要考虑,因为用户体量大,必然会出现因为操作失误而未订阅的用户,所以无论选择哪种方案,都应该增加与C端用户相同的“补偿机制”。

笔者在改造G端用户的通知接收方式时,考虑了两种解决方案:

1)服务号通知

给G端用户提供一个单独的在服务号进行订阅的入口。但G端用户原有业务是依托小程序进行实现的,所以在服务号中通过文章或H5的方式进行订阅都存在问题。

  • 文章:G端用户为内部用户,如果对外暴露文章形式的订阅入口,在C端用户误操作时,对C端用户不够友好;
  • H5:G端用户依托小程序开展业务,单独开发H5页面提供订阅能力对G端用户来说操作麻烦,并且不利于开发者进行维护。

笔者个人认为,微信生态中,H5的使用体验没有小程序好,并且为了节省项目成本,所以不考虑将小程序业务改为H5实现。

2)小程序通知

将G端用户的通知订阅方式彻底改变为小程序订阅的方式,因为笔者所在行业属于政务类,可以申请到长期订阅的通知模板,在改为小程序订阅后,G端用户只需要订阅一次,就可以长期接收消息通知。

按照这种方式进行改造后,G端用户基本可以完全脱离服务号,仅使用小程序就能开展工作。

经过笔者预估,如果采用这种改造方式,会降低G端用户对服务号的关注率。在“设计前言”中有提到,服务号会定期群发供G端用户学习的文章,所以改造后还计划在小程序中增加浏览文章的功能,但是否增加此功能,还需要在改造后观察服务号文章的阅读数据是否下降。

3. 另外

考虑到改造成订阅通知的形式后,运营人员可能会考虑通知送达率,我们可以结合“文档分析”中的参数,在运营后台中增加一些统计指标。例如:每条通知的累计订阅数量、留存订阅数量、取消订阅数量,同时可以结合用户数预估通知的送达率。

十、总结

以上就是笔者在本次微信计划调整通知策略的事件中,所做出的产品改造方案。

建议在微信明确下线模板消息前,尽量不要安排研发人员进行备用版本的开发,在调整尚未明确之前,安排研发实现无疑是一种浪费人力成本的做法。但作为项目管理者或产品经理,应该在发现风险时,准备多种方案。

最后,希望微信团队能够充分考虑调整策略对服务商、开发者产生的巨大影响,做出合理的决定。

 

作者:氟西汀,一个懂的不太多的pm,公众号:氟西汀终究还是没了

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

题图来自图虫

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 小程序的订阅,用【服务通知】推送,将来会面临全部商家都通过这个入口推送,分分钟把自家内容顶上去。怎么看?

    回复
    1. 确实会有这个问题的哈,目前所有的小程序下发消息都是共同一个消息通道的

      回复