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

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

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

一、名词解释

    一次性订阅：指用户订阅一次，服务号可不限时间地下发一条对应的订阅通知；

    长期订阅：指用户订阅一次，服务号可长期多次下发通知，长期订阅通知仅向政务民生、医疗等公共服务领域开放。

二、订阅通知的方式

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

    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）另外

    考虑到改造成订阅通知的形式后，运营人员可能会考虑通知送达率，我们可以结合“文档分析”中的参数，在运营后台中增加一些统计指标。

    例如，每条通知的累计订阅数量、留存订阅数量、取消订阅数量，同时可以结合用户数预估通知的送达率。

十、总结

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

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

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

作者：氟西汀，公众号：氟西汀终究还是没了

学艺不精，欢迎批评。如想交流产品设计方案，欢迎留言。

未经授权禁止转载