App Link实践之路

在移动端,由Web页面或者某个应用,通过以链接的形式打开另一个APP的业务形式被叫做应用调起。通常使用的方式有Universal Link(适用于iOS 9及以上版本),Deep Link(适用于Android及iOS 7、8)。以下统称为App Link。之前也写过一篇关于Universal Link的,点击传送门访问。

今天要说的,是从业务层考虑这些技术的实现意义、成本以及实际收益。

简单的架设一个场景,比如某宝商家给用户发短信或者邮件,内容包含一个简短的url,期望用户主动点击该url后可以启动某宝应用并跳转到该商品的页面并开始购物下单。

另外一个场景,用户通过度娘网搜索某个热门头条,发现一个来自今晚头条的标题很吸引人就点击查看,此时调起了本地安装的今晚头条APP,打开了该新闻,在阅读后这个用户给这篇新闻点了一个“赞”。

最后一个场景,某汪给自己暗恋已久的女神通过墨墨发送了一个链接,女神点击后打开了秋秋音乐并开始自动播放了一首薛之谦的“演员”。

OK,这些场景都来自现实,每分钟都在上演。

实现意义

对于用户,这会是一种增强的体验,通过一个url可以从当前的一个场景转换到另一个场景,达到了一个比较连贯浏览动线效果,进而在APP中做想做的事情。
对于业务提供方来说,这是一种自然而然地将流量由App之外引入到App内,继而产生DAU的方式。话说大部分App的业务都集中在App内,而非网页。所以此类App更加需要这样的业务入口。

用一句话总结就是:App Link是移动互联网时代打通开发者App内资源与用户需求的一种新的模式。通过整合和索引合作APP的内部资源,将App内信息呈现给用户,用户通过点击相应内容可直接跳转至开发者Native App的指定资源,从而实现平滑用户体验。

实现成本

这里主要分解开发的成本。
1. 针对平台使用不同的协议
iOS 9+采用通用链接(Universal Link),即以https://{domain}/{uri}为标准形式的链接,如https://m.babytree.com/justopenapp
Android 或低版本iOS采用Deep Link,即以{scheme}://{uri}为标准形式的,如: babytree://index

  1. 重视uri规范。通常需要制定详细的访问规则,约束uri和app内资源的访问,使得一个uri可以准确对应app中的一个页面或资源。

  2. 为不同的浏览器尝试App Link触发方式。比如,Universal Link可以通过window.location直接触发,Deep Link可以通过iframe进行触发。但事实上window.location不是最佳的选择,iframe也不是屡试不爽的方案。

  3. 为结果提供多维度测试。针对测试,这里有必要进行展开说明,也会为看到此文的同学提供有力参考。

我在测试中,设定的维度是:
平台(系统 iOS、Android各版本)
软件(各种浏览器App、邮件App、短信App)
为了减少测试成本,软件维度里只选择最新的软件版本参与测试。

那么可以枚举的测试条件就以这样的形式呈现:
iOS 10.3.2 – UC 11.7.2
iOS 10.3.2 – Safari
iOS 9.3 – Safari
MIUI 4.0 – 自带浏览器 v2.1.2
MIUI 5.0 – QQ浏览器 v9.1

从业务角度出发,系统和软件可以枚举用户基数较大的几个,进而缩减测试成本。

为什么要测试呢?因为事实上,App Link在各类软件中触发,会先通过软件的一层代理。如果软件屏蔽App Link,或者代理了App Link触发的后续操作,进而影响到App Link功能的发挥。

最近就遇到了各种各样App Link功能无法正常发挥功能的情况,而主要集中在各类Android手机的软件中,也就是Deep Link协议不灵了。

请看这个坑(通过domain进行举例,DP为DeepLink简称),以下每个链接打开的页面,都通过iframe访问同一个 {scheme}:// 协议并自动DP。
1、用oppo手机 uc浏览器打开 https://a.domain.com/uri 发现无法DP
2、用oppo手机 uc浏览器打开 https://b.domain.com/uri 发现可以DP (同主域,不同子域)
3、用oppo手机 uc浏览器打开 https://www.apptranz.com/apps/wap/dptest.html 发现可以DP (不同主域)

简单分析就知道,同一个scheme,在不同域名下达到的效果不一致。很大可能是浏览器对某个域名下的DP行为进行了限制。
事实上,这种打开页面就自动DP的方式触发了UC浏览器的反垃圾广告机制。
自动触发DP对用户来说都是未知的操作行为,UC拦一道也无可厚非。这样的话,因为不同的用户的访问导致自动DP被操作次数激增,导致这种行为被自动屏蔽(拉黑)。
不过这种行为是针对页面url的,所以更换域名后,UC并没有直接对DP进行拦截。

我总结了目前各大浏览器不DP所遇到的情况:
1、APP把DP协议给禁了,比如微信APP内置浏览器、手机百度APP等……
2、APP把网页主动DP禁了。这是出于安全,对iframe的请求进行了拦截,但通常都会询问,除非用户选择不再弹出,或者选了忽略。如小米4(MIUI旧版本)原生浏览器。
3、APP把网页主动DP给屏蔽了。出于广告位反垃圾规则,针对域名做了这件事。如UC等。

实际收益

以上,我们通过App Link能实现流量的导入,以及App的活跃增长。这是一笔可计算的收益。
当用户点击一个链接并触发App Link协议后,往往会遇到软件的拦截,系统的拦截,多数情况下会询问用户是否要打开目标应用。
每一次询问就是对用户耐心的一种挑战,所以最终用户点击到用户打开APP,会有一定比率的流失,每个阶段的流失被称作一个漏斗模型。在不同系统、不同软件用户的漏斗模型均不同。

最终我们评估实际收益时,需要衡量多种渠道(平台、软件)的触达情况。
通常,App Link打开的比率能超过20%,就令人很欣慰了。

总结,基于业务需求的技术改进是必要的,但可用性和易用性是衡量技术是否适用于业务场景最直接的测算维度。在开展技术实施前,做好漏斗模型是很有必要的。

发表评论

电子邮件地址不会被公开。 必填项已用*标注