我们现在有一个需求,某一个活动需要拉新所谓的拉新一般是推 App 下载,这个用户通过这个活动下载了 App 后,我们需要做到【在数据库中记录这个用户下载这个 App 是通过那个二维码渠道的,从效果上说,我们期望:
① 每个活动(渠道)在数据表中有一条记录,而一旦有经过该渠道下载的 App 被打开后,该渠道的下载量会 + 1,算 KPI 的(单独一条记录,带有时间戳)
② App 首次打开时,如果检测到了渠道上报后,还应该为该 App 打上一个全局的渠道标志,后续的所有请求都应该将此参数带上,为后续产生订单以及流水做准备
比如之前我们为 H5 与 Server 的 Ajax 请求约定的是这样的:
- 1
- var param = {
- 2 //公共参数
- 3 common: {
- 4 us: '渠道',
- 5 version: '1.0.0'6
- },
- 7 other: '' // 业务参数
- 8
- };
每次请求就必定会带上业务参数,而 us 就是 native 需要带的渠道参数,当然 native 的公共参数比前端多的多,需求明确后,我们清理下 iOS 引导至 App Store 的一般流程。
这边的一般流程是,我们一个 App 活动,或者我们一次推广,一般来说都会用微信打开这个网址,这个是前提一:
① 我们的一次下载来源于一次活动(推广或者固定的下载地址),而微信是主要的打开设备
然后,我们要引导至 App Store,一般来说会访问一个 H5 页面(在微信中会引导在 Safari 浏览器中打开),然后由 H5 下载落地页跳到 App Store 完成下载,这个是第二个前提:
② 我们每次是由一个统一的带渠道因子的 H5 页面,引导至 App Store 的
在上述基础上,我们期望:有一个唯一的 H5 引导下载落地页(这里基本会抛弃微信应用宝引导下载了)
这里初步的实现方案是:
打开 H5 落地页时候,将这次活动的渠道号以及 ip+ua + 时间戳传给 server 端记录,如果在一定时间内,机型和 ip 成功匹配,则认为这次下载来源与这次渠道号
这里需要:
① Server 端,提供一个接口,记录当前渠道 + ip+ua + 时间戳 + 屏幕信息(所有能记录的都记录),提供一个渠道匹配判断标志
② H5 访问落地页的时候上报相关信息
③ Native 首次打开的时候,调用 native 提供的判断接口,给该次 App 打标志
这里提出了三个要素:
① H5 落地页
② server 上报接口
② server 检查接口
而这种方案是不精确的,H5 如果能拿到设备号这类唯一标识的话,便能大大提高准确性,然后无论微信 jsdk 或者 Safari 都是做不到的,而网上搜索的方案,提到了一个 SFSafariViewController,似乎能达到共享 cookie 的作用,于是进行了一番探索。
我们调研下来,在我们的场景下,大概是这么一个情况:
① 我们使用 Safari 打开一个页面,并且操作 cookie
② 在我们的 App 中,SFSafariViewController 这个库能打开一个我们给予的 Url,并且这个网页如果和上面是一个域名 cookie 是共享的
这个就很有意思了,我们就完全可以这样做了:
① 访问 H5 下载落地页访问接口上报时,Server 往 cookie 种入唯一标识而后引导至 App Store
② App 首次打开时,以隐藏状态打开上报页面,因为同域名,会将 Safari 的 cookie 带上,这里也会带上 IP 等标识
④ H5 检查页,使用 Hybrid 交互,告诉 native 给该 App 打上标识
- let vc = SFSafariViewController(url: URL(string: "http://domain.com/landing.html")!)
这里方案确定,然后开始落地实施试试情况,后续在数据展示一块以友好的方式展示出来,便是大数据的一环
参考文章:
来源: http://www.cnblogs.com/yexiaochai/p/6480020.html