如何提高判断微信小游戏用户是否分享的准确率？

分享程序小卡片的流程如下：

1. 客户端程序调用微信提供的分享接口，接口参数里指定分享的文案，以及程序小卡片上要使用的图片的url。

2. 分享接口的调用会拉起微信。

3. 用户在微信里选择要分享的对象。

4. 微信通过客户端指定的图片url发起资源的网络请求。

5. 相关的资源服务器收到请求后返回相关的图片资源。

6. 微信获得图片资源后，在用户选择要分享的对象会话里会展示一个游戏的程序小卡片的浮窗，让用户进一步确认是否分享。

7. 用户点击确认，分享成功。

8. 用户按下返回键返回游戏领取分享奖励。

---

目前微信官方提供给小游戏开发者的拉起微信分享的接口里无法知道用户是否分享了程序小卡片，为了提升产品的用户自裂变效益，每一款微信小游戏内都存在如下功能：

用户分享游戏的程序小卡片到微信后可以获得相关的游戏奖励。

---

由于从微信提供的分享接口无法知道用户是否真正做了分享操作，所以只要用户在游戏中触发了这个分享接口，不管用户最后有没有把程序小卡片分享出去，都只能算分享成功，发放相关的游戏奖励。

这种缺陷对于那些资深的微信小游戏用户群体来说，会让你预期的用户自裂变效益大大降低，因为这类用户玩的微信小游戏多了就能够发现这种缺陷，于是每次在游戏中触发分享执行到分享流程的步骤3时就跳过4、5、6、7步骤，直接执行步骤8操作。

---

针对这种情况，虽然我们无法准确判断玩家是否执行了步骤7，但是可以通过一些手段来提高这种判断的准确率。

目前最low的办法就是在触发分享接口的时候加个定时器，通过从玩家拉起微信分享到返回游戏的时间间隔来模糊判断用户是否进行了分享，例如：设定玩家如果拉起微信分享5秒内就返回了游戏，那么就判定玩家没有完成分享，否则就是分享成功了。

这种套路其实对于那些玩得多玩得久的用户来说，也很容易发觉里面的道道，于是在执行到分享流程步骤3时等上几秒以后再返回游戏，照样领奖励。

---

这篇要讲的解决方案是能把判断用户是否分享的准确率提升到用户的分享流程至少执行到步骤6后回到游戏才能领奖励。

---

提高判断微信小游戏用户是否分享的准确率的解决方案：

为了减小服务器的开发压力，我们把游戏分享的程序小卡片上的图片资源放在了CDN缓存上，这样把微信端请求该图片的访问压力就交给了CDN处理。

1. 搭建一台web服务器，对外提供一个https访问接口，例如：

https://xxxx.cn/wxshareimg

请求参数的格式为：openId:xxxxxx&deppendUrl=https://cdnimgurl.cn/xx.jpg

请求协议为：GET

完整的请求url示例：https://xxxx.cn/wxshareimg?openId:xxxxxx&deppendUrl=https://cdnimgurl.cn/xx.jpg

2. 把分享流程步骤1里的图片url改成这台web服务器对外提供的https访问接口的url，例如

https://xxxx.cn/wxshareimg?openId:xxxxxx&deppendUrl=https://cdnimgurl.cn/xx.jpg

3. 分享流程步骤4的网络请求将由web服务器对外提供的https访问接口来处理，接收到请求后，把请求参数里的openId取出来，然后在数据库里添加一条标识该openId的用户进行了一次分享的记录，然后，通过web请求的重定向特性，设置请求header的重定向url为deppendUrl的值（deppendUrl=https://cdnimgurl.cn/xx.jpg），最后，给微信端返回302状态（表示本次请求需要重定向）。

4. 微信端收到302状态后就知道要请求重定向，于是再次请求资源时拿出请求header里的url（在解决方案步骤3里设定的重定向url（https://cdnimgurl.cn/xx.jpg））重新发起网络请求，这时才真正去CDN里获取图片资源。

5. 用户从微信页面返回游戏页面时，我们再请求自己的web服务器，通过openId来查询该用户是否在数据库里有标识进行过分享的记录，如果记录存在，那么就给该用户发放分享成功的奖励。

---

如此一来，也就间接提高了判断微信小游戏用户是否分享的准确率。