在《微信服务号订阅通知灰度测试：模板消息之变》中，笔者分析了消息通知方式改变对大家产生的影响，弊大于利。     基于被“用户体验感”挟持的大前提下，不管微信团队是否执意要对策略做出调整，大家都需要未雨绸缪，合理的面对并解决这个风险，以免措手不及。     这篇内容，将会为大家分享笔者结合自己的产品，总结出改造的设计方案。分享前，先为大家解释一下订阅通知所涉及到的名词、订阅和推送通知的方式。 一、名词解释     一次性订阅：指用户订阅一次，服务号可不限时间地下发一条对应的订阅通知；     长期订阅：指用户订阅一次，服务号可长期多次下发通知，长期订阅通知仅向政务民生、医疗等公共服务领域开放。 二、订阅通知的方式 [图片]     目前微信只开放了两种可以进行消息订阅的途径，具体流程如下。 [图片]     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）另外     考虑到改造成订阅通知的形式后，运营人员可能会考虑通知送达率，我们可以结合“文档分析”中的参数，在运营后台中增加一些统计指标。     例如，每条通知的累计订阅数量、留存订阅数量、取消订阅数量，同时可以结合用户数预估通知的送达率。 十、总结     以上就是笔者在本次微信计划调整通知策略的事件中，所做出的产品改造方案。     建议在微信明确下线模板消息前，尽量不要安排研发人员进行备用版本的开发，在调整尚未明确之前，安排研发实现无疑是一种浪费人力成本的做法。但作为项目管理者或产品经理，应该在发现风险时，准备多种方案。     最后，希望微信团队能够充分考虑调整策略对服务商、开发者产生的巨大影响，做出合理的决定。 作者：氟西汀，公众号：氟西汀终究还是没了 学艺不精，欢迎批评。如想交流产品设计方案，欢迎留言。 未经授权禁止转载

微信团队在1月27日发布《服务号订阅通知灰度测试》公告，宣布将在2021年1月27日0:00至4月30日24:00进行服务号订阅通知功能的灰度测试，并在灰度测试结束后另行公布订阅通知和模板消息功能的调整策略。 近几年，随着微信订阅号的改版、小程序模板消息功能的调整，大部分需要实时将消息触达用户的公司，都选择了依托微信服务号模板消息来开展业务。 虽然此功能还未明确将替代模板消息，但仍值得思考一下：此举对微信、开发者、运营者、用户，分别意味着什么？ 从微信来看 微信把订阅通知的功能初衷定义为：提升用户体验，减少开发者对用户的骚扰行为，并增加营销类消息的推送能力。 订阅通知是一个用户主动订阅、服务号按需下发的通知能力。 -微信团队 1.消息通知方式的变化 对此事件有过了解的读者会发现，微信此举并不是对模板消息进行了[升级]，而是[重构]了服务号的消息通知逻辑： 1.不能给只关注不订阅的用户发送模板消息； 2.订阅后，已关注服务号的用户，消息通知下发到服务号内，未关注的下发到服务通知； 3.非公共服务类服务号，根据微信目前的规定，每次给用户发送消息通知都需要被订阅，但用户可以自行选择长期订阅。 简单来说，服务号的消息通知方式向小程序看齐了，不能直接通过服务号向已关注未订阅的用户推送模板消息，但用户订阅消息后取关服务号仍可以对其发送消息通知。 例如：改版后即使关注了XX银行信用卡中心，但未订阅，也无法通过服务号收到动账、还款的消息通知；但订阅取关后，仍能收到服务号的消息通知。 2.治理生态的决心-顶住压力做变革 据笔者的非官方统计，国内共100W+开发者服务于微信生态，生态内共有1000W+公众号，其中服务号占比超过60%。(此处并未统计服务号粉丝总和) 从上面所描述的内容中，可以得出一个结论： 微信在服务号开发者、用户基数如此之大，且大部分公司业务基本成熟稳定的情况下，决定灰度测试订阅通知，可见其治理模板消息滥用，过度、恶意营销的决心。 从开发者来看 笔者个人认为，微信团队在模板消息被滥用这个问题上，有一些过度武断了。为了治理1%的滥用情况，影响了99%的开发者的直接利益。 1.牵一发而动全身 对于服务号的开发者而言，这个简单的调整可以被称作颠覆了绝大部分公司的[业务根基]。 有很多初创公司，整体收入都是依托于服务号来进行的，甚至强依赖模板消息开展业务。甚至一些具有一定规模、业务成熟的公司，很多系统的功能都是围绕模板消息进行开发的，二次开发成本不可谓不大。 2.被迫改变的无奈-APP开发和短信平台的春天 在微信团队发出公告后，微信开放社区中的状况可以用“炸锅”来形容。并且在公告后，却无法明确调整策略，导致开发者无法决策是否进行二次开发。如果在开发完后，微信选择暂时不做出调整，那之前所付出的开发成本都将打水漂。 在此事件后，很多开发者都选择了将消息通知方式更换为短信通知的方式，但短信发送费用可能会导致运维成本的直线上升。更有甚者，直接选择了脱离微信生态，开发独立APP处理业务。 如果按照现在的状况发展，笔者个人认为将会为APP开发服务商和第三方短信平台带来更高，甚至激增的收益。 从运营者来看 对于服务号运营者来说，这个变化“悲喜兼集”，悲在运营的难度被大大增加了，但如果真的仔细研究了新的规则，就会发现运营的玩法更加多元化了。 1.运营难度增加 以往的服务号运营，只需要考虑如何将用户导流到号内，并保证留存率就可以了。在新功能出现后，运营者可能还需要做出很多的调整，来引导用户去订阅自己的消息通知，才能够完成业务闭环。 同时，运营者要关注的数据将不再是以前单纯的关注、取关数，势必会增加消息订阅数量、取消订阅数量，来保证消息通知的触达率。 之前通过模板消息来完成营销、实现业务的服务号，必须要因此而“改头换面”，以实现存活在微信生态内的目的。 2.运营方式的变化-新玩法的出现 细心的读者会发现，消息通知方式改变后，服务号运营玩法出现了新的途径。以前为了给用户发送消息通知，大多数服务号都采用引导关注的方式，但订阅通知上线后，即便用户不关注服务号，订阅消息后仍可通过服务通知的方式获取消息，具体逻辑见下图。 [图片] 根据新的消息发送方式，运营者可以直接绕过关注服务号这一步，直接采用H5页面引导订阅的方式，对用户发送消息，甚至探索更多的玩法。 从用户来看 微信团队认为：从用户的角度来看，部分用户在无预期的情况下，收到了与自己无关的信息，对用户造成了骚扰。 微信作为国民的刚需应用，笔者本人也是重度用户之一。个人认为此变化有利有弊。 1.操作成本增加 大多用户或多或少都有一些需要接收的消息通知，例如信用卡的消费提醒。按照微信现在的文档中提供的能力，在微信改变通知方式后，用户必须挨个打开需要接收消息的服务号，寻找订阅入口，并手动订阅，才可以继续接收消息通知。 这种方式无疑加大了用户的操作成本，在之前关注的服务号中需要重新订阅一遍，在新关注的服务号中，如果想要接收消息通知，还需要额外做出订阅的操作。 另外微信针对订阅功能，在开发文档中给开发者设立了一些门槛，这也将造成对用户的不友好。 详见下图，一个开发者为了满足微信门槛做出的Demo。笔者预估每个功能给用户增加的操作时间超过15秒。 [图片] 2.使用方式的变化-消息列表更“干净”了 通知方式改变后，用户如果只想要接收服务号内和自己相关的消息，而不想接收群发的文章等。可以选择只订阅消息，不关注服务号。 在互联网时代，各种信息的狂轰乱炸给网民造成了不小的压力。这对用户来说，信息的接收可以更加的随心所欲，减轻了用户的信息压力。 最后 希望微信团队能够慎重考虑调整策略，甚至可以考虑沿用原来的模板消息推送方式，仅增加“拒收通知”的选项来逐步解决生态中的问题。 个人认为，微信此举已经展示了自己的决心，建议大家尽早的未雨绸缪，以避免自己的业务受到影响。 笔者从事行业对于模板消息属于强需求，所以将会在近期为大家提供一个自己结合微信文档所总结的产品设计方案。 作者：氟西汀，公众号：氟西汀终究还是没了 学艺不精，欢迎批评。如想交流产品设计方案，欢迎留言。 未经授权禁止转载