閒魚喚端的背後

作者：閒魚技術——胖仔

背景

眾所周知，想要DAU穩步上升，端外引流是一個必不可少的手段，常見的引流方式有：廣告投放、分享迴流、流量互換等，而他們也有著一個共同的技術問題，就是喚端，本文著重分享一下喚端的相關知識以及閒魚在喚端體系內的一些方案。

喚端概述

何為喚端？簡單概括，喚端就是在某些場景下通過一定的手段開啟目標APP並且加載出希望展示給使用者的內容，下面是幾個常見的例子：

閒來無事你在床上逛淘寶，看到一個二手手機非常便宜，當你想要點開商品詳情時，手機自動打開了閒魚APP並且載入了商品詳情頁，你可以在閒魚APP內完成後續的瀏覽和購買行為，此為喚端。

Ding！你手機收到一條簡訊，提示你金枕榴蓮僅需9.9就能帶回家，你抱著試一試的心態點開了簡訊裡的連結，此時手機自動打開了某電商APP並且加載出了金黃誘人的榴蓮商品資訊，此為喚端。

​

喚端最直接的意義是為了獲得更多的使用者流量。但顯然，獲取使用者流量的道路上充滿著阻礙，比如某些應用為了更好的鎖住使用者會禁止開啟其他App，這個時候就需要引導使用者通過其他方式主動開啟App，或者使用者壓根就沒有安裝App，則需要引導使用者完成下載並且在使用者下載完後展示給使用者希望看到的內容，所以，喚端並不僅僅是喚端，它還包括了下載和還原兩大內容，整個喚端版圖示意如下：

喚端方案

最為常見的喚端方案是url scheme喚端和universal links喚端。

Url Scheme

什麼是url scheme

url是統一資源定位符，通俗的說就是網址，有時候也會叫連結、地址。scheme是標識資源的訪問方式，比如http、ftp、https都屬於一種scheme，在手機系統中，可以通過app的特定scheme來實現app的跳轉，比如需要開啟簡訊應用並向10086傳送一條資訊，就可以使用如下連結，前面的sms就是簡訊應用的標識，而後面的10086表示傳送物件是10086，如果在瀏覽器中訪問這個地址，那麼系統就會開啟簡訊應用並且向10086傳送一條簡訊，這是一個比較簡單的url scheme。稍微複雜一點的url scheme可能是長這樣的，這個是跳轉閒魚商品詳情頁的url scheme，它主要由四個部分組成，前面的fleamarket是閒魚的標識，後面的item是一個具體的action，再後面就是一系列引數的key值和value值，其中scheme部分將被系統識別並完成app開啟行為，後面的引數將由app自身完成解析和處理。

如何觸發喚端

url scheme是一個靜態協議，那麼要怎麼呼叫來觸發喚端呢？常見的有幾種方式：

1.通過window.location.href 直接跳轉連結，IOS中大多用該方案

1.通過iframe跳轉連結，安卓中大多使用該方案

1.通過特定js bridge開啟APP，此處以支付寶為例

如何判斷喚端成功

大部分情況下，我們希望在喚端失敗後引導使用者前往下載，那我們如何才能知道喚端是否成功呢？對於公司內部二方APP來說，往往可以通過一些客戶端提供的橋樑精準得知喚端是否成功，甚至可以預判斷是否已經安裝APP，但對於一些三方場景，如系統瀏覽器、微信客戶端等，就沒辦法精準的知道是否喚端成功了，這時候有兩種處理方案：

1.不管使用者是否已安裝APP，在嘗試喚端的同時展示下載彈窗，可能會誤中部分有端使用者，但可以保證鏈路完整性2.監聽頁面失焦時間，在特定時間內只要使用者離開頁面，則認為喚端成功，反之則認為喚端失敗，此方法存在一定的錯誤判斷，因為大部分APP在跳轉其他APP時會有一個二次確認框，確認框的行為我們是無法感知的，可能使用者點了取消但會被認為喚端成功，也有可能使用者停留時間過長雖然喚端成功了也被認定為喚端失敗

Universal Links

IOS9以上引入了 universal links，相比於scheme 喚端，universal links是一個直達連結，當用戶開啟 universal links 時，iOS 會檢查目標域名是否註冊了任何已安裝的裝置。如果有，對應App 將立即啟動，而不會再載入網頁。如果無，則將在瀏覽器中繼續載入對應的 Web 頁面，這樣保證了比較好的使用者體驗。universal links 需要客戶端配合在系統中註冊域名，所以此方案的前提是當前版本的客戶端已完成域名註冊。js程式碼示意如下：

下載方案

當直接喚端失敗時，我們往往需要引導使用者下載來做更多的引流可能，對於不同的手機系統，需要跳轉不同的應用市場，IOS相對統一直接跳轉App Store即可，大部分APP也不會攔截App Store跳轉，安卓市場相對雜多，不同的手機應用市場的地址不同，對於一些非主流機型需要通過直接下載APK包的形式下載APP，流程示意如下：

還原方案

所見即所得是一項非常重要的技術，如果引導使用者開啟App後沒有做好承接，使用者體驗會有斷層，也很容易造成使用者流失，比如使用者如果是由端外的9.9包郵商品吸引而來的，就應該自動展示對應商品詳情以保證鏈路完整。在有端直接喚端的場景下，客戶端可以直接識別到喚端協議中的引數從而開啟對應的承接頁，但對於無端場景，場景還原會變得相對困難，閒魚的還原方案可以歸納為兩類

1. 服務端輔助還原

在端外使用者跳轉下載前，前端主動進行資料上報，在使用者下載完開啟App後，客戶端主動讀取相關服務並進行匹配，若存在匹配資料，則開啟對應目標頁

2. 本地輔助還原

在端外使用者跳轉下載前，前端主動進行資料本地儲存，在使用者下載完開啟App後，客戶端主動讀取本地資料並進行匹配，若存在匹配資料，則開啟對應目標頁

喚端資料追蹤

資料協議

No Data, No BB！喚端層面我們最關心的資料就是喚端成功率，這個指標可以很好的衡量一個業務的引流價值，想要精準的計算喚端成功率，必然需要統計頁面的喚端量和到端量，為了更加精準的識別每一個到端使用者的來源，我們設計喚端資料協議如下：

xianyu_growth_channel.spmstr-source-materialId-type.extend

•xianyu_growth_：固定值，用於標識為閒魚使用者增長域帶來的喚端資料•channel: 喚端渠道資訊，如在淘寶內的喚端可以標識為tb•spmstr：spm資訊，集團內一種頁面的唯一識別符號•source：自定義來源，如抖音廣告卡片可以標識為douyin_card•materialId：素材ID，如點選購買按鈕的喚端可以為buy_button，點選檢視更多的喚端可以為more_click•type：喚端型別，用於標識此次喚端是直接喚端還是下載還原間接喚端•extend：拓展欄位，由業務自行填充想要統計的資料，如商品ID、分享來源等

資料SDK

如果所有的資料都由各個業務方以引數的形式傳入，顯然費時費力且容易出錯，對協議不瞭解的開發很容易亂傳引數值而導致資料統計缺失或者異常，所以需要有一個SDK來儘可能收斂資料內容，下面是幾個可以自動判斷填充的欄位：

1.channel：大部分渠道都可以通過ua來獲取渠道標識，如淘寶、天貓、淘特等2.spmstr：可以通過統一方法自動獲取到spm值，無需業務傳入3.type：在喚端SDK執行喚端或下載行為時可以動態修改type值，如直接喚端的賦值為0，通過上報還原的賦值為1，通過剪下板還原的賦值為2，也無需呼叫方感知

資料上報

有了資料協議，接下去就是資料上報儲存了，此鏈路需要前端、客戶端、後端、BI多端的配合，前端負責在連結後面拼接資料協議，客戶端在識別到特定標識時解析並上報資料內容，後端拿到資料內容後進行資料儲存，BI需要解析資料庫中儲存的內容並可視化展示各業務各渠道的喚端漏斗。整體鏈路示意如下：

喚端成功率統計口徑

喚端分母：端外點選pv，因端外大概率未登入，所以統計uv意義不大 喚端成功（粗口徑）：端外直接監聽到的喚端成功回撥，誤差較大 喚端失敗（粗口徑）：端外直接監聽到的喚端失敗回撥，誤差較大 到端分子（精準口徑）：端內直接上報的資料pv，誤差較小 喚端成功率公式：到端PV / 喚端PV 各渠道各業務的喚端率：通過channel和spm篩選可以計算出對應成功率​

喚端在業務中的應用

為了讓喚端更加的簡單高效，我們通過連結劫持的形式讓業務開發做到喚端無感，開發單點業務的時候該怎麼跳就怎麼跳，不需要關心當前是在什麼渠道、什麼場景，也不需要處理引導下載和場景還原，所有的喚端細節都交由統一喚端模組處理。當業務確認當前頁面需要用於外投時，僅需要引入下面的喚端模組並進行簡單配置即可相容所有的端外喚端功能，該模組會在劫持到連結跳轉時進行一些計算來確認是否需要攔截喚端。

有端直接喚端效果演示

無端下載還原效果展示

​

​

​

總結&展望

以上就是閒魚在喚端、下載、還原、資料方面的內容，我們致力於打造一個極致收斂、極致簡單、開發無感、業務無感、資料自動化的喚端體系，這也將成為接下來半年核心攻打的方向，接下來也會結合端內分享去做全鏈路資料追蹤，希望明年能有一個更加巨集大的喚端版圖，讓喚端發揮出它最大的業務價值。