👫

邀请奖励机制

如何设置一种邀请奖励机制, 让用户分享下载 APP 时候可以获取到相对有效的下载量?

比如 A 用户分享带有 AAA 邀请码的分享链接推荐他人下载 APP, 其他用户通过此链接点击了下载(iOS与安卓), 那么此时给 A 用户增加邀请数量.

本文讨论我所了解的处理方法.

下载发送日志到后台

受邀用户在分享页面点击下载按钮时候向后台发送邀请码.

这样有个明显的漏洞, A 用户可以自己手动点击下载按钮, 会不停的给后台发送请求, 从而刷邀请量.

限制方法:

后台通过cookie/ip等判断用户是否存在刷单, 进而增加限制.

神奇的方法

以上方法用户很简单就能 get 到请求链接, 进而用个简单的脚本就可以刷单.

昨天发现了一个神奇的邀请机制, 在邀请下载页面没有向后台发送任何请求, 页面有两个按钮, 「iOS」与「安卓」下载, 点击 iOS下载, 会通过 itms-services 协议下载企业版本 app, 点击安卓下载会下载安卓 apk 包.

经过我的测试, 点击下载后也不能给我增加邀请数量, 但当我安装打开之后我的邀请数量会增加.

👉邀请链接👈

可以查看上方的链接源码, 里面没有向后台发请求的代码, 点击按钮只是 location.href 跳转, 那它是怎么实现的呢?

猜测: 打开链接时将邀请码存到系统本地, 打开app时候获取此邀请码发送给后台.

再次检查它的源码, 发现他们用了 clipboardjs. 于是真相大白, 他们将邀请码保存到系统粘贴板, 在打开app时候 check 粘贴板内容, 再将数据上报.

正规途径

以上方法很蹊跷, 当然也可以抓包看下调用的是哪一个请求, 再模拟刷单, 这是避免不了的.

但是保存到粘贴板就是网页与app内容共享的唯一途径了吗?

不是的.

一个友好的操作系统必须提供一种方式来让沙盒app与系统其他项目共享数据, 比如在 iOS 里 app 可以读取和操作 iCloud 数据, 当然对于网站数据共享 apple 提供了一种独立的解决方案: Shared Web Credentials.

Shared Web Credentials

那么安卓的处理方式是什么呢? Enable automatic sign-in across apps and websites

在我们一生中,命运赐予我们每个人三个导师,三个朋友,三名敌人,三个挚爱。但这十二人总是不以真面目示人,总要等到我们爱上他们、离开他们、或与他们对抗时,才能知道他们是其中哪种角色。