端內外融合拉新，使用者增長 -- 相關技術方案選型分析

折騰範兒_味精發表於2018-08-17

上一篇聊 H5主流瀏覽器下App導流方案選取 的時候，有的朋友說這麼多個方案只提了一個名字，沒具體提原理和實現，這兩天換工作，需要分享以前的使用者增長心得，於是又重新梳理了一下

概述

1 需求背景

  • H5 網頁端有著便於傳播，方便在各類 APP與瀏覽器容器中進行推廣，在擴充渠道上
  • APP 客戶端用來承接，有著更好的體驗與長久使用者存留的收益與價值

如果能將使用者從 H5 -> APP 的流程進行打磨，將體驗進行優化，就能極大程度的提高拉新的轉化率，而這其中的關鍵就是打破 H5 -> APP 之間傳遞資料，進行無縫銜接的方式。

2 目標

  • 在 H5 中，判斷使用者是否已經安裝 App
  • 已經安裝 APP 的使用者，通過 Schema / Universal Link 的方式進行喚起與傳遞資料
  • 未安裝 APP 的使用者，通過 裝置指紋 / 動態APK / 剪下板 / 蘋果autoFill

需求背景，端內外融合可以讓使用者拉新的過程更加流程，降低門檻，提高轉化。

img

3 方案需要解決的問題

  • H5 無法判斷是否已經安裝App
    • 需要先同時 schema 跳轉
      • iOS上未安裝App會彈出跳轉失敗彈框，不影響流程
      • UniversalLink 可以解決這個醜陋彈框的問題
    • 用下載頁兜底
  • 在沒安裝App的情況下，把H5資料傳遞過去許
    • 幾種方案都有覆蓋面以及成功率的問題，各存在優缺點
    • 缺乏完美方案

4 市場上的一些解決方案

他們其實也都是用的上面提到的技術，只是統一封裝好了服務，統一做好了解決方案。詳細技術實現見下文

系統設計分析

1 H5中判斷安裝App

因為H5沒有Api能夠判斷是否已經安裝了哪些APP，目前廣泛普遍採用的安卓iOS都支援的方案是

  • 嘗試性喚起 Schema
  • 用下載落地頁作為兜底，如果 Schema 失敗，則自然轉入下載

解決方案：

這裡面暫時沒有更好的解決方案，因為JS的能力十分有限，必須依賴宿主環境的能力，如果宿主環境是三方APP，倒是可以通過 JS Bridge 來通過 APP 進行一些是否安裝 APP 的嗅探（canOpenUrl 之類的）

2 H5 在已安裝 App 的情況下，跳轉傳值

2.1 安卓系統

  • 問題1：Schema 容易被瀏覽器/裝置廠商禁止，目前很瀏覽器都禁止了 Schema
  • 優勢：安卓 Schema 嘗試跳轉如果失敗，不會有一個錯誤彈框

解決方案：

暫時想不到，除非和廠商或者渠道App合作開放 Schema 白名單。想要在不對外合作的條件下做更好的體驗，一般是選擇識別禁止 Schema 的瀏覽器UA，然後給頁面進行蒙層提示使用者用系統瀏覽器開啟

2.2 iOS系統

  • 問題1：Schema 容易被瀏覽器/裝置廠商禁止，目前很多 App or 瀏覽器 都禁止了 Schema

img

  • 問題2：Schema 存在被人搶注

  • 優勢：iOS的瀏覽器核心相對統一，支援剪下板，是一個可以考慮的方案

  • 優勢：iOS有 UniversalLink 會解決一些 Schema 的問題，但已然可以被三方瀏覽器禁止

解決方案：

1 使用 UniversalLink 來代替 Schema ，解決醜陋的彈框與Schema被搶注的問題

2 想要突破第三方瀏覽器禁止，除了對外合作白名單/蒙層提示系統瀏覽器開啟。還可以考慮用剪下板，因為第三方瀏覽器一般都不會禁止跳轉AppStore的連結

  • 識別禁止Schema的第三方瀏覽器UA
    • 點選下載，寫入資料進入剪下板，同時跳轉AppStore
    • AppStore上已經安裝 App 會看到 “開啟”按鈕
    • 開啟App，識別剪下板，讀取資料
  • 這樣的流程與蒙層提示系統瀏覽器開啟相比，操作路徑短一些，但是否使用者體驗更優見仁見智

3 H5 在未安裝 App 的情況下，安裝傳值

目前一共有五種方案，可以在未安裝App的情況下，給App傳值

  • 裝置指紋（通用）
  • 動態Apk（安卓）
  • 剪下板（iOS，安卓理論可行幾乎不可用）
  • SFSafariViewController（iOS，很不穩定）
  • autoFill（iOS）

3.1 裝置指紋方案

  • 方案流程

img

核心就是利用 H5 與 客戶端讀取到的裝置唯一標識-裝置指紋，當作key，利用伺服器做資料中轉傳遞資料，但想要找出合適的裝置指紋需要解決幾個問題

這個唯一標識要具備苛刻的條件，想找到其實很不容易

  • 選擇當做唯一標識的內容，必須能讓APP獲取的到（UDID,MAC地址啥的，iOS都拿不到）
  • 選擇當做唯一標識的內容，必須也能讓H5獲取的到（IDFA，IDFV等，JS拿不到）
  • 選擇當做唯一標識的內容，還必須有能力區分出不同的裝置（避免多個裝置取出來的值一樣，無法區分）

所以只能退而求其次，選取模糊裝置指紋

  • 裝置螢幕尺寸
    • 說明：iOS裝置螢幕種類比較少，iOS下比安卓更容易衝突
  • 裝置作業系統
  • 裝置IP
    • 說明：IP會變，因此需要設計失效時間，最好 5min-10min以內有效
    • 說明：同公司WIFI下統一公網出口IP一致，很容易衝撞
  • MAC地址
    • 說明：Wifi下有類似 WebRTC JS通過路由器鏈路反向獲取出MAC地址（還未實踐）
    • 說明：Wifi下客戶端也有一些技術方案可以通過路由器鏈路反向獲取MAC地址（還未實踐）
  • …… 等等

弊端：

成功率問題：因為最終選擇的是模糊裝置指紋，模糊匹配就存在成功率的問題，雖然選取更多的指紋引數可以提升，但無法做到100%。

  • iOS 成功率65% 左右
  • Android 成功率高一些

3.2 動態Apk方案（僅限安卓）

安卓的APK都是一個個ZIP包，因此可以在服務端在使用者請求下載的時候，將使用者的資訊與資料寫進母APK包的ZIP的註釋資訊裡，為每個使用者生成一個專屬的APK，這個註釋資訊的寫入不會影響包簽名，可以在APP啟動的時候由客戶端程式碼讀出。

  • 方案流程

img

  • 存在問題1：無法在通過渠道廠商使用

APK包是使用者級別的定製包（某種意義上的千人千麵包）不可能提供1個包給渠道市場，走渠道市場下載，只能走自己的 H5 下載頁面直接進行安裝

  • 存在問題2：比較佔用頻寬

APK包是使用者級別的定製包（某種意義上的千人千麵包），因此無法CDN，每次都是使用者實時通過伺服器動態進行打包，APK包又比較大，會有一些佔用頻寬，但完全能滿足日常下載需求。如果遇到突發秒殺搶下載等活動需要注意小心

  • 存在問題3：安卓系統可能存在攔截

很多安卓系統，在下載非自己APP市場安裝包的時候，會提示使用者，當前APK包不是來自官方APP市場，建議使用者去市場渠道下載的提示

  • 存在問題4：市場渠道抓包

很多市場渠道為了保證自己的APP版本最新，喜歡自己用指令碼來官網抓包，來官網抓到的包是待動態APK資訊的包，會影響原本市場渠道的優惠投放

3.3 剪下板方案

在 iOS 10 推出後，蘋果遵循了 W3C 的剪貼簿標準，在 Safari UIWebView WKWebView 都提供了 JS API 的剪下板能力，因此 iOS 10 之後，可以完全不借助 APP，直接通過 H5 發起剪下板

安卓上，剪下板的JSAPI，幾乎在現在主流的各大系統與瀏覽器廠商，都不支援。但 Can I Use 上可以查到，高版本 Chrome 核心應該支援。安卓可以不用考慮這個方案了。

剪下板API依賴於DOM的點選，無法做到JS直接靜默寫入，所以流程上必須先請求好剪下板的值，然後寫入H5 DOM，等待DOM被點選，寫入剪下板。

  • 方案流程

img

  • 存在的問題

    • 剪下板都是系統共用，可以被任意APP修改覆蓋，也可能被使用者主動修改覆蓋
    • 注意與其他剪下板口令衝突的情況（比如吱口令），僅識別自己的口令，使用完清除
    • JS 程式碼都是完全暴露的，在JS程式碼中做加密不可行，得需要服務端做加密，或者直接伺服器儲存，只返回密文或者伺服器儲存的Token憑證
    • 端程式碼在本地資料還原，可以使用自己的本地密文解密方案，也可以通過伺服器儲存的Token憑證，從伺服器讀取資料

3.4 SFSafariViewController方案（不推薦）

由於蘋果的沙盒機制，業務APP與H5所在的瀏覽器APP分屬於不同沙盒，Cookie是不互通的，因此在APP內起WebView，幾遍訪問同域名下網頁，也無法獲取Cookie中的資料。

在 iOS 9 剛推出 SFSafariViewController 可以在APP內開啟屬於系統Safari沙盒的一個網頁，從而能與系統Safari共享資料。

方案流程：

  • 支援 iOS 9 以上
  • Safari 開啟H5，網cookie中寫入資料
  • APP安裝，開啟一個隱藏的SFSafariViewController
  • SFSafariViewController 訪問一個H5 頁面，用JS讀取cookie資料，然後用Schema，傳給已開啟的App

存在問題：

  • H5 僅限Safari，三方瀏覽器，APP都無法支援
  • 隱藏SFSafariViewController，已經被蘋果稽核禁止，如果想要使用這個方案，得顯性的在APP內開啟SafariVC介面才能傳遞資料

3.5 autoFill方案（調研中）

蘋果在 iOS 11 中提供了 autoFill 能力，能夠實現在 Safari 網頁中，自動記錄下來的使用者名稱與密碼，在 App 中無縫的自動填充

方案流程：

  • 在H5中對錶單控制元件開發密碼自動記錄keychain的功能
    • 不要使用 H5 Cookie 式記住密碼
    • 使用 input 的 type = ‘password’ type = ‘name’ 的瀏覽器記住密碼方式
  • 配置 apple-app-association
    • 域名根目錄下配置 apple-app-association 的 json file
    • app 開啟 Assocated Domains，並配置域名
  • UITextView/UITextFiled 配置
    • 設定 TextContentType 屬性為 username 與 password
  • 當使用者點選輸入密碼，會提示自動輸入

img

  • 存在問題：
    • 資料傳遞場景只適用於登陸名密碼，不適合傳遞其他資料
    • 以自動記住密碼的形式會給使用者帶來不安全感
    • 可以被使用者設定上關閉
    • 所有記住密碼與自動提示都會有系統級顯性的UI感知，無法做到靜默傳遞

推薦解決方案

由於每一種方案都無法做到完美，所以採用多種方案按著優先順序組合生效

1 安卓推薦方案

  • 通過Schema跳轉，兜底下載落地頁，判斷是否安裝
  • 已安裝App
    • Schema 開啟，直接傳遞資料
    • 對於封禁Schema跳轉的瀏覽器UA，採取蒙層提示系統瀏覽器開啟
  • 未安裝App
    • 自主H5網頁渠道，採用動態APK
    • 外部市場渠道，採用裝置指紋匹配（失敗率略高，做好未匹配兜底方案）

2 iOS推薦方案

說明：UniversalLink 屬於iOS平臺專屬，他與schema能力差異不大，為了統一安卓與iOS的實現，完全可以用Schema替換

  • 通過UniversalLink跳轉， 兜底下載落地頁，判斷是否安裝
  • 已安裝App
    • Universal Link 開啟，直接傳遞資料
    • 對於封禁 UniversalLink 的瀏覽器UA，採取蒙層提示系統瀏覽器開啟
    • 對於封禁 UniversalLink 的瀏覽器UA，也可以採取剪下板+跳轉Appstore開啟的方式
  • 未安裝App
    • 剪下板方案，適用任何場景
    • iOS10以下，採用裝置指紋匹配兜底（失敗率略高，做好未匹配兜底方案）

相關文章