5 月 17 日晚，微信官方发布了小程序分享功能将进行多项调整的预告，全面涉及小程序、小游戏、微信内的网页（公众号、H5）以及 app 等。这将在很大的程度上，影响着微信生态中的流量关系甚至商业关系。事实上，早在 5 月 16 日，一张署名微信团队的「分享功能调整」的公示图便引发了朋友圈的广泛传播。
为鼓励用户自发分享喜爱的内容，减少强制分享至不同群等滥用分享能力，破坏用户体验的行为，微信公众平台分享功能即日起做出如下调整。以下是微信公众平台公告：
分享功能调整
为鼓励用户自发分享喜爱的内容，减少“强制分享至不同群”等滥用分享能力，破坏用户体验的行为，微信公众平台分享功能即日起做出如下调整：
1、7月5日起新提交的版本，用户从小程序、小游戏中分享消息给好友时，开发者将无法获知用户是否分享完成，也无法在分享后立即获得群ID。该策略在最新版开发者工具上，可以选择基础库 2.0.8版本预先体验。具体调整点为：
（1）分享接口调用后，将不再返回分享结果事件。
（2）通过调用 wx.showShareMenu 并且设置 withShareTicket 为 true ，当用户将小程序转发到任一群聊之后，不再支持获取到此次转发的 shareTicket。但是当此转发卡片在群聊中被其他用户打开时，依然可以在 App.onLaunch() 或 App.onShow 获取到 shareTicket。
2、6月份新版微信客户端发布后，用户从微信内的网页分享消息给微信好友，以及分享到朋友圈，开发者将无法获知用户是否分享完成。具体调整点为：
（1）分享接口调用后，不再返回用户是否分享完成事件，即原先的cancel事件和success事件将统一为success事件。
（2）在6月份新版微信客户端上，微信会提供新的自定义分享卡片标题、简介和配图的能力。该接口不支持获知用户是否分享出自己的网页。
（3）在新版自定义分享能力发布后，原有认证公众号的“获取分享到朋友圈按钮点击状态及自定义分享内容接口”和“获取分享给朋友按钮点击状态及自定义分享内容接口”权限将逐步回收，请开发者关注后续站内信通知。
3、6月份新版微信客户端发布后，用户从App中分享消息给微信好友，或分享到朋友圈时，开发者将无法获知用户是否分享完成。具体调整点为：
（1）分享接口调用后，不再返回用户是否分享完成事件，即原先的cancel事件和success事件将统一为success事件。
据悉，这一功能之所以尚未正式发布，因具体调整点和执行时间还无法敲定。而根据微信官方公布，小程序分享功能的调整将在 7 月 5 日新提交发布的版本中执行，网页和 app 会在微信 6 月新版微信客户端发布后执行。
此外，不再支持小程序「打开其它小程序」的组件也将在 7 月 5 日执行。
微信分享功能到底调整了什么？
分享功能的调整可概括为 4 大方面：
1. 微信内网页分享好友、朋友圈
用户从微信内网页分享消息给微信好友，以及分享到朋友圈，开发者将无法获知用户是否分享完成。
其中包括：
分享接口调用后，不再返回用户是否分享完成事件。即将发布的新版微信客户端，将不再支持获知用户是否分享自己的网页。新版本发布之后，原有认证公众号的「获知分享到朋友圈」、「获知用户分享给朋友」的接口权限也将逐步回收。
这意味着，以后微信中的 H5 和公众号内容也都无法获得分享数据的反馈。
2.App 分享至微信
新版微信客户端发布之后，用户从 app 中分享消息给微信好友，或分享到朋友圈时，开发者将无法获知用户是否分享完成，一律统一为分享成功。
所以，对于外部应用通过微信制造传播的效果，也将带来一定影响。
3.小程序、小游戏分享给好友
用户从小程序、小游戏中分享消息给好友时，开发者将无法获知用户是否分享完成，也无法在分享后立即获得群 ID。
其中包括2点：
分享接口调用后，将不再返回分享结果事件。用户将小程序转发到任一群聊之后，不再支持获取到此次转发的 ShareTicket。
但是，当此转发卡片在群聊中被其它用户打开时，依然可以获取到 ShareTicket。这意味着，微信在功能考量方面，更加认可用户自发分享之后产生的裂变效果；但对于初始的分享触发机制进行限制，从而造成了初次分享与二次、多次分享的监测隔离。特别对开发者的设计强制分享功能形成制约。
4.小程序跳小程序
除此之外，此次调整还更新了小程序组件。
7 月 5 日起，新发布的小程序版本，将不再支持无需用户点击即可直接调用的「打开其他小程序」接口及「打开小程序设置页」接口。而且，在最新版的开发者工具中更是提前取消了该接口支持。
因此，除非用户自行许可，否则开发者再无权限直接进行小程序跳转，阻止频繁发生的小程序恶性跳转导流。
促分享仍有意义，分享数据仍有价值
这次微信的分享功能调整，实际上是一个制度性调整。
从所有类别的分享接口全面回调，可以看出，微信采取的是无差别对待的方式。但是重点，还是针对近期发生在小程序特别是小游戏的恶性群分享事件。
不过，之所以祸及到网页和 app ，可能是在传达统一思路：就是微信对于任何形式的强制分享、诱导分享都持不支持的态度。
而 app 的分享调整，或许还有其它原因，特别是前段时间短视频 app 通过微信进行分享时，与平台方微信所形成的一些冲突。在移动互联网端，微信已经变成了各大 app 的公用通道，因此，这方面的策略也显得尤为重要。
但是，应该说这次微信的政策并非是「限制」，而只是「不鼓励」政策，至少对用户二次分享的反馈仍然是开放的。当然，从逻辑上来说，这个反馈也应该被开放，毕竟这是用户自发行为，开发者所获得的也是良性数据。
但既然这个数据是开放的，而小程序又特别依赖社群分发，因此整体上分享数据的参考价值仍然很大。而且，大部分的用户习惯还是以成功分享为主，不成功为少，试探性、欺骗性分享几乎很少出现。
同时，大部分用户触发小程序右上角「多任务」键只有「转发」、「关于」、「取消」3 种选择，「转发」的动机意图往往更大，这里面的换算公式，相信很快会随之出现。
微信正在填自己的坑
其实之所以微信小游戏最终造成了如此泛滥效果，也与小程序的功能设计缺陷有关。
但是作为一种功能设计本身，此前的分享功能的确在促进小程序活跃乃至爆发方面起到了巨大作用。然而，这个阶段如今已经过去了微信的分享政策收紧是必然趋势。接下来，微信将采取两种手段来综合管理：制度性功能调整和人工执法。所以，即使分享本身仍然大有裨益，但开发者不应该为此再做冒险了。
用户的归用户，企业回归产品
分享功能的回调，与其说是开发者权限被收回微信，不如说是微信把选择权放给了用户。用户决定分享什么，而不是被迫分享什么。应该说，这是用户理应获得的权利，但是此前因为受到各种干扰而没办法自由实现。
不过，对于开发者而言，并不能因为功能的变化而放弃分享的努力。莫种意义上来说，小程序产品的群分享能力是产品的生命线，在微信中，分享造成的流量远远大于搜索获得的流量。因此，对于开发者来说，要做的是回归产品，回归产品功能设计，而不是分享玩法。开发者还是需要设计产品更利于分享、更易于分享、更愿意被用户分享的产品，即使是没有数据反馈也应该做。
而除了自身产品的传播之外，因为功能的调整，小程序分享到群和小程序跳转都受影响，因此，小程序的流量会骤然紧张。在接下来的推广方面，小程序会更加依赖外力，特别是小程序广告，而且只能是官方的广告渠道。
参与讨论
发表评论