分享回流调起实战

分享回流调起实战

Android小彩虹2021-08-24 3:18:44200A+A-

分享闭环的意义

看了最近热播电视剧《创业时代》,感受了一波创业的波折、守业的艰辛。对于初创产品需求主要是:1)品牌感知,2)引导下载APP体验,追求更多的是下载量。对于已经基本成型的产品来讲需要,关注更多的是,手机生态中所提供服务使用的连贯性,追求更多的则是DAU/MAU。

从最近AppStore中APP更新频率来看,明显可以感受到现在市场对APP的重视程度。然而当下APP之间竞争激烈,好不容易吸引过来的用户不想轻易被别的APP抢走,但又想夹缝中求生存费劲形式想从别人家的APP中导流来自己APP,在这样的矛盾和糟糕环境中,分享和分享回流一直倍受老板和业界关注。

分享逻辑闭环可以拆解来看一下,如图:

APP_A 一般指的是非社交平台APP,APP_B一般是带有社交属性的APP,可以简单理解为:XXAPP跟微信的关系。现阶段微信一家独大,微信做了连接一切的事情,被公认为是传播最有效的渠道。各家也是想法设法充分利用好这个平台。

上图中两个虚线框,按照需求关系『分享功能』是有较稳定的解决方案(NA有分享SDK或配置,H5可以借助NA进行功能实现),不在本文讨论范围。『回流功能』则是需要集成大前端(FE\Android\Ios)所有力量进行攻破的课题。

Native现状梳理

调起APP方案梳理

场景 调起原理 外部调用方式 下载 参数携带
Android浏览器 <data android:scheme="myscheme://" /> 1. location.href="myscheme://xxx"
2. <iframe src='myscheme://xxx'>
1. location.href="myhost://xxx.apk"
2. location.href="应用市场(下表)"
URL拦截
IOS浏览器 Universal Links (IOS9+)
1. 创建apple-app-site-association
2. Xcode的capabilities配置域名信息
3. AppDelegate.m 中支持
1. 访问配置的域名(a.com)
2. 跨域访问(b.com 跳转 a.com
location.href="itunes.apple.com/tw/app/id12…" URL解析:userActivity.activityType.webpageURL
IOS浏览器 Scheme:- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url location.href="myscheme://xxx" 同上 URL拦截
微信 白名单机制
1. 白名单内的支持调起
2.其他如果在应用宝发布,可以通过应用宝间接调起
location.href="a.app.qq.com/o/simple.js…" 携带给应用宝,交给他们处理 location.href="a.app.qq.com/o/simple.js…"

Android 各大应用市场Scheme

平台 sheme 正则
小米 mimarket://details?id=xxx&back=true /\(.Android.(MI|Mi|Redmi|HM NOTE| 201\d{4} Build).*)|Android.*XiaoMi/
sumsung samsungapps://ProductDetail/xxxx /\(.Android.(SAMSUNG|SM-|GT-).*)/
华为 appmarket://details?id=xxxx /\(.Android.(HUAWEI|HONOR|HW-
oppo oppomarket://details?packagename=xxxx /Android.*(OPPO|A31.? Build|R\d+(Plus)? Build)|Android.*OppoBrowser|^OPPO/
vivo vivomarket://details?id=xxxx /\(.Android.(vivo|VIVO).*)/

调起流程设计

说明:设计方案是按照两个域名的方案设计。A.COM 和 Universal Link(Ulink) 分别是两个不同域名

调起实战

机缘本次项目调起功能的实现,从源头深入了解并实现了调起功能,实战过程中的几个点总结起来跟大家一起分享。

微信拦截调起咋回事

2018年初,微信干了一件蛋疼的事情,Universal link进行白名单机制。之前限制了scheme开发者不得不转向Ulink方案,但是这样一来完全把微信内调起封死。如果想调起,需要进入其白名单,具体方法不得而知。

白名单Android同学反编译分析出来的,具体怎么做的如有微信同学,欢迎出来批评指正,愿听其详。

微信限制后有三个方案:

  • 右上角三个点,浏览器打开;
  • 跳转应用宝,连接scheme;
  • IOS直接跳转Appstore打开,但无法携带参数。

域名需要几个

域名是一个可选项。

无域名方案

也就是所谓的scheme方案,安卓&IOS都可以通过scheme方案来实现。

想到一个问题:如果定义自己APP的schema为一个别人APP的sheme(如wx://)它会调起谁?实战发现,会调起后安装的APP。如此使用scheme,想必会产生一系列问题。也许这是IOS使用ulink的考虑出发点。

为了不必要的冲突scheme命名还是要多考虑一层的。

单域名方案(A.com

直接打开页面无法跳转对应的Ulink(因为iOS 9.2之后规定,Ulink必须跨域访问才能生效)。但实践证明当单域的时候,分享到微信,再次选择用浏览器打开,如果已经安装APP,会自动调起。这是比较完美的用户体验。

从别的页面跳转到当前单域名下,理论上因为IOS9+的Universal Link使得调起的用户体验更加流畅,所以理论上有一个域名,IOS配置没问题就可以调起。实战过程中遇到两个蛋疼的问题:

  • 有些用户会长按复制URL在浏览器直接打开无法调起,无法调起;
  • 如果恰好安装了APP,合作方页面(B.com)跳转到页面(A.com)不会看到页面直接调起,合作方一般对这种行为非常反感,因为直接跳离了他们APP。

多域名方案(A1.com & A2.com

为了解决单域名的两个痛点,降级体验。A2.com作为Ulink的配置,先进入A1.com的页面,多一步点击操作,然后跳转A2.com页面进行后面逻辑操作。

调起是怎么请求的

iframe or location

H5调起NA的第一种模式是scheme。

不论iframe还是location,其实本质都是要发出一个scheme请求,APP可以监听到提前约定好的协议,进而启动APP。如果没安装APP,也期望不会对用户体验造成伤害。

iframe的特点是页面不会跳转,当前访问页面无感知(具体实现如下),不过遗憾的是IOS9之后就不支持了。

let last;
 
let invoke = function(scheme) {
    last = +Date.now();
    let $node = document.createElement('iframe');
    $node.style.display = 'none';
    $node.src = scheme ;
    let body = document.body || document.getElementsByTagName('body')[0];
    body.appendChild($node);
    setTimeout(function() {
        body.removeChild($node);
        $node = null;
    }, 10);
};
 
 
invoke(scheme);
setTimeout(function() {
  // 防爆点
  if (Date.now() - last < 1600) {
    location.href = unifiedDownloadURL;
  }
}, 1500);

location的特点是history可能会发生变化,同时些特殊APP的webview发现未知协议还会跳转到一个错误页面,不过IOS如果scheme的话只能这么搞了。

所以我的结论:Android iframe & IOS src

前端跳转 or 服务端跳转

H5调起NA的另一种模式是Universal Link。

在启动服务端方案之前,设计了一版纯前端的方案。A2.com配置Ulink ,A1.com-A2.com的过程中如图,1)需要一个中间页承载,2)需要手动出发跳转下载或者定时促发,这不是用户期望看到的。

为了减少用户感知,将A2.com对应的中间页跟下载页URL打包,访问A1.com后,点击跳转A2服务端提供接口,直接302跳转对应下载ULR(当然也可以Nginx配置转发,但为了可维护性,建议写到业务中)

中间页的意义

通过上述服务端跳转来讲,也许中间页是没有存在意义的。要么调起,要么跳转下载,完全不需一个中间页。仔细想一下还是有两个弊端的:

  • 调用复杂。抽离调起方法,但如果但业务多地方,or多业务多产品线引用的时候,就显得有点冗余。这时候如果有一个中间页,调用方只需要跳转过来即可
  • 缺少品牌宣传。如业务初期,无外部落地页,比如一个海报加一个二维码想调起,这个时候如果没安装APP的时候,也没有品牌宣传直接引导到APPstore或者直接下载,略显强硬。这就要根据业务具体情况来看中间页存在的意义。

调起的极致化体验

二次分享

在微信中有如图的几种分享状态,第一个是APP分享后的,后面两个是对分享的再次分享的不同状态。这需要进行一些微信的配置,才能达到2图的效果。后面有机会可详细分享。

监听来源,引导回流

最近发现一些APP,从A应用跳转到B应用,B应用里会提示返回A应用的提示。跳转原理是一致的都是监听别人调起然后,调起别人,理论上都是scheme的具体应用。

判断APP是否安装

有些应用为了考虑更多的兼容性,选用上面提到的中间页方案。这个时候是立即打开?还是立即下载?如果知道应用在手机里安装的状态,对于用户体验来讲应该是较为重大的提升。可惜系统没有提供这样的接口,H5跟NA都无法准确获取。不过可以开动脑筋,利用服务端,通过对APP打开情况对设备号、登录状态、设备标识、IP等信息记录,打开下载页的时候,准确提示用户是下载还是打开。后面有机会的话常识去做一下。

总结

本人最近参与做了一个创新型APP,关于调起这块进行了全方位的了解。

关于技术选择:初期选择:IOS单域名、Android Scheme调起,服务端302分发下载连接,在分享出来的落地页上突出品牌宣传,完成调起功能。后期产品做大了,引入中间页通用方案,提供更加通用解决方案。

关于用户体验:这个社会为了利益,无奈让开发者夹缝中生存找解决方案。这无异于早些年JS的 升级过程,需要颠覆性产品不断涌现,比如腾讯、百度提出的小程序生态。这是一个需要时间的过程...持续关注。

参考文档

欢迎留言沟通交流。如有需要转载或者引用,辛苦标注一下,互相帮助。

点击这里复制本文地址 以上内容由权冠洲的博客整理呈现,请务必在转载分享时注明本文地址!如对内容有疑问,请联系我们,谢谢!

支持Ctrl+Enter提交

联系我们| 本站介绍| 留言建议 | 交换友链 | 域名展示
本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除

权冠洲的博客 © All Rights Reserved.  Copyright quanguanzhou.top All Rights Reserved
苏公网安备 32030302000848号   苏ICP备20033101号-1
本网站由 提供CDN/云存储服务

联系我们