少些套路,多点价值

210 阅读3分钟

又来一个通知

今天微信团队又发了一个通知:

通知说了啥

这个通知是要限制公众号客服消息的下发能力,限制前后能力对比如下:

场景下发时限下发条数限制
点击自定义菜单原48小时-->现1分钟原5条-->现3条
关注公众号原48小时-->现1分钟原5条-->现3条
扫描二维码原48小时-->现1分钟原5条-->现3条
用户发送消息保持48小时保持5条
支付成功保持48小时保持5条

可以看出,微信极大的限制了用户点击自定义菜单、关注、扫码三个场景下的客服消息下发能力。不仅减少了下发的数量,也缩短了下发的时间窗口。那为啥做这个限制呢? 通知里说得明白,为了减少对用户的骚扰。 拿关注公众号举例: 很多公众号往往是这样做的:关注的时候给弹出些欢迎语,给用户推些内容;关注一小时之后再给用户推一些东西;关注24小时之后再推一波;48小时客服消息能力要失效前最后来一波。相信各位都曾有过这种体验。尤其是那种从朋友圈广告关注的公众号,经常干这样的事情! 我就被产品运营逼着做过这样的功能,开发出来给用户发了超级多的消息,引发用户大量的投诉取关。但运营小姐姐们可不管这些,他们只管ROI。 这下可好,微信爸爸生气了,觉得不能再这么干了。你要给客户发消息,就1分钟内发完,过了这个时间就不要再打扰用户了。对此,我是非常赞成的,就应该这样嘛,多给用户提供点价值,不要整天老想着催单。多给用户提供点实实在在的价值,少整些花里胡哨的运营套路,这才是正途!

开发者该怎么办

话又说回来,对于我们开发者,这次接口能力的调整,我们该怎么应对呢?

1. 把通知同步给产品运营小姐姐

先告知产品运营小姐姐,这个调整儿童节之后就要生效了,让他们事先做好准备,不要到时候发现数据掉了很多才过来找开发。但是,按照我的经验,多半到时候他们还是会找过来的,建议收藏这篇文章,到时候直接拿这篇文章怼回去,哈哈。

2. 检查三个调整了接口能力的三个场景,及早改代码

先检查一下点击菜单、关注、扫码三个场景下的互动代码,跟产品小姐姐商量下怎么改。先把代码改了,至于啥时候上线,可以再说。或者先定一个deadline,deadline之前走老代码,deadline之后走新代码。

3. 拉取用户互动标签数据的时候记得把上面的三个场景拿掉

还有一个比较容易忽略的地方,那就是数据部分。运营小姐姐往往依赖有过客服互动行为的用户数据,经常会需要这些用户的openid,拿过去手工给这波用户发客服消息。这里也要记得取这部分数据的时候要把上面提到的三个场景的用户剔除掉,否则容易引起大规模客服消息发送失败。