一切为了运营！如何从推广短信链接唤起App？

 ●●●

需求描述

写这篇文章&＃xff0c;也是缘于运营的一个需求&＃xff1a;在 App 运营过程中&＃xff0c;会有大量的推广短信&＃xff0c;里面附有链接&＃xff0c;目的是引导用户参与活动。如果用户手机没有安装我们的 App 就引导其去下载页&＃xff0c;如果用户已经安装了我们的 App 就直接在 App 中打开对应的活动。

 ●●●

方案讨论

对需求进行分析&＃xff0c;归纳起来实际上就是一个问题&＃xff0c;如何从短信唤起App&＃xff1f;

这里有两种方案。

第一种&＃xff0c;也是最理想的直接从短信唤起&＃xff0c;也就是点击短信中的链接后如果安装了 App 就跳转到 App&＃xff0c;如果没有安装就在浏览器打开对应页面&＃xff0c;如下图&＃xff1a;

第二种&＃xff0c;经浏览器中转唤起&＃xff0c;也就是点击短信链接后先用浏览器打开对应页面&＃xff0c;在页面中进行“判断”&＃xff08;实际上不是真正的判断&＃xff0c;而是发一个scheme给系统&＃xff09;如果安装了 App 就跳转到 App&＃xff0c;否则就停留在当前页。

下面将对这两种方案分别进行分析、实施。

 ●●●

从短信直接唤起 App

通常&＃xff0c;App 监听私有短域名strange.com&＃xff08;不要问我为什么是短域名&＃xff0c;因为短信就是按字算钱的&＃xff0c;能省一分是一分&＃xff09;地址&＃xff1a;

1. Android 系统

当点击短信中的链接后&＃xff0c;系统会自行判断&＃xff0c;如果安装了 App 就会出一个弹框让用户选择在 App 中打开还是在浏览器中打开&＃xff0c;如图。

对用户来说要多做一次选择&＃xff0c;这绝对不是好的体验。

为了解决这个问题&＃xff0c;Android 6.0 开始支持 Deep Links&＃xff0c;让用户点击链接直达App。

首先&＃xff0c;在 intent-filter 中添加 android:autoVerify&＃61;"true"。

其次&＃xff0c;在私有域下上传一个 json 文件&＃xff1a; https://strange.com/.well-known/assetlinks.json

文件内容&＃xff1a;

[{"relation": ["delegate_permission/common.handle_all_urls"],"target": {"namespace": "android_app","package_name": "应用ID","sha256_cert_fingerprints":["签名证书指纹"]        }    }
]

系统在安装应用后会自动访问 json 文件进行检验&＃xff0c;如果检验通过&＃xff0c;用户访问 strange.com 域名下的链接会直接跳转到应用。

2.iOS 系统

必须采用 Universal Links&＃xff0c;否则点击还是直接跳转到浏览器。

从短信直接唤起 App 总结&＃xff1a;

要实现短信直接唤起 App&＃xff0c;Android可以用 intent-filter 对域名进行监听&＃xff0c;但是会出弹框让用户进行选择&＃xff0c;为了更好的体验&＃xff0c;建议采用 Deep Links 技术方案&＃xff0c;只支持 6.0 以上系统&＃xff1b;iOS 只能采用 Universal Links 技术方案&＃xff0c;只支持 9.0 以上系统。

●●●

经浏览器中转唤起 App

上表所示&＃xff0c;如果只能用备选方案&＃xff0c;那么用户就有可能会首先跳转到浏览器&＃xff08;对应的是下载页面&＃xff09;&＃xff0c;经过浏览器中转&＃xff0c;唤起 App。

通常的做法是&＃xff0c;App 中监听scheme strange&＃xff1a;

H5 页面中内嵌&＃xff1a;

或者执行脚本&＃xff1a;

window.location.href&＃61;"strange://login"

因为浏览器只会处理http、https协议&＃xff0c;当浏览器打开我们的 H5 下载页面遇到不能处理的私有协议 strange&＃xff0c;就会发 intent 给系统&＃xff0c;如果有 App 可以处理这个协议会出弹框询问用户是否用该 App 打开&＃xff0c;否则什么都不做&＃xff0c;具体效果&＃xff1a;

虽然弹框体验欠缺&＃xff0c;不过也是目前比较好的方案了。

兼容性问题

可是&＃xff0c;重点来了&＃xff0c;我们在实际测试过程中发现了一堆兼容性问题&＃xff0c;在说明这些兼容性问题前&＃xff0c;我们先解释一个概念&＃xff1a;intent:// 协议。

Android Chrome 25&＃43; 后已经不支持自定义 scheme 的方式&＃xff0c;只支持 intent:// 协议&＃xff0c;最终要的是需要用户手动进行 点击 才能跳转&＃xff0c;举个例子&＃xff1a;

Take a QR code
// 失效
// 失效

intent:// 协议格式说明&＃xff1a;

intent://scan/#Intent; package&＃61;com.google.zxing.client.android; scheme&＃61;zxing; end;

目前市面上大多第三方浏览器都是基于 Chrome 开发&＃xff0c;这就带来了兼容性问题&＃xff08;没有条件覆盖所有的系统浏览器&＃xff0c;这里只是有限测试的结果&＃xff09;&＃xff1a;

1、部分浏览器&＃xff0c;只支持 intent:// 协议 手动 唤起&＃xff0c;如chrome、锤子。

2、部分浏览器只支持 scheme 唤起&＃xff0c;如 UC 浏览器。

3、大部分浏览器&＃xff0c;同时支持 scheme 私有协议和intent:// 协议 自动 唤起。但&＃xff0c;都没有按标准的 intent:// 协议来实现&＃xff08;除了 360 浏览器&＃xff0c;给 360 点个赞&＃xff09;&＃xff1a;

·       有的浏览器在 App 没安装时并没有执行S.browser_fallback_url&＃xff0c;而是跳转到应用市场如猎豹浏览器4.46.3、乐视浏览器 1.2.1.29。

·       有的浏览器不支持S.browser_fallback_url如搜狗浏览器、欧朋浏览器、猎豹浏览器。

·       有的浏览器无论应用有无安装S.browser_fallback_url一直都会执行如 QQ 浏览器。

所以对这部分浏览器&＃xff0c;不能使用 intent:// 协议。

4、更奇葩者&＃xff0c;二者都不支持&＃xff0c;如百度浏览器。

兼容性问题解决方案

针对上述三个兼容性问题&＃xff0c;第 4 种情况无解我们直接忽略&＃xff0c;第 2 第 3 种情况只能用自定义scheme 的方式。

问题出在第 1 种情况&＃xff0c;因为只能手动唤起&＃xff0c;我们需要对浏览器类型进行判断&＃xff08;浏览器没有提供是否支持自定义 scheme、intent://的 API 只能通过 UA 判断&＃xff09;&＃xff0c;结合我们有限的测试结果&＃xff0c;如果是锤子、Chrome 原生浏览器&＃xff0c;需在页面中内置一个“下载应用”的按钮引导用户点击。

// 如果安装了 App 就跳转&＃xff0c;否则就访问 S.browser_fallback_url 的值 http://strange.com
跳转到活动页/下载

我们来分析一下浏览器的 UA &＃xff0c;举几个例子&＃xff1a;

//小米系统浏览器User-Agent:Mozilla/5.0 (Linux; U; Android 6.0.1; zh-cn; MI 3W Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/53.0.2785.146 Mobile Safari/537.36 XiaoMi/MiuiBrowser/8.9.5// 小米 Chrome 原生浏览器User-Agent:Mozilla/5.0 (Linux; Android 6.0.1; MI 3W Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.108 Mobile Safari/537.36// 锤子系统浏览器User-Agent:Mozilla/5.0 (Linux; Android 5.1.1; YQ603 Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.11 Mobile Safari/537.36// 锤子 Chrome 原生浏览器User-Agent:Mozilla/5.0 (Linux; Android 5.1.1; YQ603 Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.89 Mobile Safari/537.36

可以看出小米浏览器是在 Chrome 原生浏览器的 UA 上增加了 XiaoMi/MiuiBrowser/8.9.5 这部分特征码。类似的&＃xff0c;很多第三方浏览器都是在 Chrome 基础上增加自己的特征码&＃xff0c;换句话说 Chrome 原生浏览器 UA 没有自己的特征。

而锤子系统浏览器和 Chrome 原生浏览器 UA 几乎一样&＃xff0c;这就使得判断是否锤子系统浏览器、 Chrome 原生浏览器 变得异常困难&＃xff0c;要想尽可能完美解决问题只能使用排除法。

排除法由于不可能排除所有非 Chrome 原生浏览器&＃xff0c;可能会存在误伤的可能。

经浏览器中转唤起 App 总结&＃xff1a;

要实现经浏览器中转 自动 唤起 App&＃xff0c;Android和 iOS 都可以通过 自定义 scheme 的方式&＃xff0c;但 Android 的情况稍显复杂&＃xff0c;因为部分浏览器并不支持&＃xff0c;必须换成 intent:// 协议的方式 手动 唤起。

考虑到浏览器判断的难度&＃xff0c;结合浏览器市场占有率的情况&＃xff0c;我们最终的方案是暂时忽略 锤子系统浏览器、 Chrome 原生浏览器 这部分不支持 自定义 scheme 自动唤起 App 的用户。

●●●

从短信唤起 App 最终方案

综合起来就是&＃xff1a;

·       通过 Deep Links&＃xff08;iOS则是Universal Links&＃xff09;&＃xff0c;可以实现点击短信链接直接唤起 App&＃xff1b;

·       如果系统因为各种原因不支持 Deep Links&＃xff0c;备选方案是 intent filter&＃xff0c;不过会出弹框让用户选择用哪个 App 打开链接&＃xff1b;

·       如果用户没有选择我们的 App 而是选择了浏览器打开&＃xff0c;则通过 自定义 scheme 尝试唤起 App&＃xff1b;

·       由于技术和成本问题&＃xff0c;我们忽略不支持 自定义 scheme 的浏览器。

如下图所示&＃xff1a; 

当然除了技术层面的&＃xff0c;短信本身的稳定性到达率也很重要。网易云短信&＃xff0c;三网合一&＃xff0c;验证码、运营短信、通知短信全能发&＃xff0c;而且关键价格一样。活儿好不好&＃xff0c;戳【阅读原文】&＃xff0c;申请试用短信&＃xff0c;试试就知道~