首先為什么要做獲客分析，那其實很簡單。

互聯網時代流量就是錢，流量是硬通貨 ，各大產品都希望能夠控制更多的流量，但是流量又不是憑空而來的，不論是線下邀請還是口碑傳播，又或者投放推廣，都是獲取用的一個過程 。

[[406106]]

之所以要做獲客分析，關鍵點還是在于涉及錢，涉及到預算，這往往是我們要首要分析的一個事情 ，所以我們需要對流量有一個清晰的認知，從數量、質量以及到后續的轉化都能了如指掌，花同樣的錢能夠獲得更好的效果。

我們首先梳理一下完整的付費投放場景，第三方投放內容主要是兩類：

• 廣告位的投放：比如說一些app的開屏廣告，就是內嵌在這種應用的信息流里面的一些廣告，或者說廣告banner之類的。
• Sem關鍵詞的投放：主要其實就是指百度關鍵詞的這種付費投放。

三大痛點

當用戶在這些第三方投放平臺看到產品的廣告和推薦后，一旦點擊就會進入開發的落地頁里，通常是一個h5網頁 ，至此就會有三條不同的路徑出現。

• 第一條，用戶手機里有沒有安裝app，就會跳轉到應用商店安裝app然后再打開。
• 第二條，如果在點擊落地頁的時候，用戶手機有安裝app，那就會從落地頁直接喚醒然后打開app;
• 第三條，網頁端產品就會直接進入網頁端的產品進行使用。

所以最終， 只要進入各個平臺的產品端后，我們就能夠完整地采集用戶的行為數據進行分析。在這個過程中呢主要有三個數據分析方面的重點：

• 第一在于核對和監測合作方的數據。企業要直接花錢做投放，但是卻沒法從企業的角度客觀監測其數據的地方，那就只能依靠第三方給到我們的數據進行核對。
• 第二就是在于如何識別出唯一的用戶，這其實是一個非常根本的一個痛點，用戶從落地推廣頁到網頁端，然后跳轉到應用商店里再下載app這個過程，應用商店就是一個完全的第三方，企業無法采集到數據，這個時候甚至無法衡量這是一個用戶在兩個平臺上的行為，還是壓根就是兩用戶。如果不能解決用戶識別的問題，根本無法確認用戶是自然流量還是推廣活動的流量。也就談不上做分析了。

第三在于各平臺的數據無法匯總統一分析。打個比方來說 一個用戶在安卓上面，就是在不斷的查看商品;最后下單的時候是在ios上完成的。如果行為不能匯總進行分析，我們就只能認為安卓上有一個非常有價值的用戶，在支付前流失掉了。那在這種情況下如果對這樣的用戶做一些其他的策略或者說短信提醒 ，那勢必是無用功， 可能會導致用戶的反感。

01、如何核對和監測合作方的數據?

廣告監測技術從存在廣告開始，就在持續進化。這里出現的難點在于廣告在第三方平臺，一般企業是不能直接去添加數據監測代碼的，所以主流的廣告監測技術會通過對圖片的一些請求次數，來記錄廣告的曝光和點擊 ，從而實現對第三方廣告相關數據的一個監測。

另一方面，對于廣告的檢測我們通常會使用添加參數的方式，這是當時谷歌做的一套方案，現在基本上已經是行業的一個共用的，收到行業認可的一套方式。通過 UTM參數，對不同渠道落地推廣頁配置不同的參數， 當用戶進入落地頁后，瀏覽器會記錄到這個url的地址，從而直接就解析url的這個參數的具體的設置，來明確用戶是從哪個途徑、哪個關鍵詞進入我們產品，最后匯總。

所以， 對于合作方數據的問題，涉及的主要是用戶進入落地推廣頁之前的時候，以及之前廣告曝光的部分，廣告監測技術是一整套的解決方案。市面上其實有很多這方面的產品， 同時諸葛也有對廣告，監測效果監測和評估的分析，感興趣的可以上諸葛了解一下。

有五個獨立維度分別是來源、媒介、活動名稱、活動內容和關鍵詞。當對一個url添加這五個維度的參數，基本上就足夠覆蓋所有的新聞場景。

當然，每個參數的名稱，本質上它就是一個代號，之所以定義了名字，其實只是初步的給大家做一個應用場景的梳理。您也可以完全不按照名字的含義與去設定參數。其實本質上，只要知道哪個參數對應著你設計的哪個維度就可以了。配置好以后傳輸內容的數據就會被自動記錄下來 ，就可以讓我們了解不同關鍵詞、不同媒介帶來流量人數的數量和趨勢，最終幫我們進行這么一個分析。

02、如何識別唯一用戶?

從用戶識別來講有幾個常見的場景，每個場景還會有用戶從未登錄狀態轉化為登陸狀態的這么一個過程。這里背后還涉及到一個用戶在多個設備、多個技術平臺使用后唯一標識的問題。

首先在網頁端，為了方便用戶使用是可以在瀏覽器里儲存cookie信息的，通過cookie來識別用戶是業內通用的做法。但會存在一個用戶在多臺設備的多個瀏覽器上使用的可能性。

所以在用戶有登陸行為后，一般以用戶賬號作為唯一識別的標識來打通各個平臺、各個瀏覽器上的行為;

如果用戶是未登錄狀態，我們主要通過這個瀏覽器的cookie來識別用戶;

當用戶從未登陸狀態轉變為登陸狀態后，那我們就將用戶賬號信息作為用戶的唯一識別標識。并在關聯層面上，通過cookie的唯一性，不管用戶在登錄前還是登錄后，cookie是唯一的，這樣就可以將用戶在登錄前的行為打通。

移動端其實和js端是一樣的道理，但是難度最大的就是如何在js的移動端和app的移動端之間來標識用戶。

比如說你做了一個活動推廣，然后同時在知乎、豆瓣、貼吧上做推廣。那用戶打開推廣頁后點擊下載， 就會跳轉到蘋果商店或者應用寶、豌豆莢之類的應用商店等，啟動app的時候你就并不知道這個用戶是從知乎帶來的，還是豆瓣帶來的，你只能看到這些從蘋果商店來的或者說是從應用寶來的。但顯然這并不能對我們推廣活動任何的幫助，最后可能都歸到同一個應用平臺上或應用商店里了。

所以需要有技術能夠把用戶下載前的身份、下載中、下載啟動app后的身份做一個關聯 ，那我們就能夠去跟具體的推廣活動有關聯起來，尤其是在做活動前，如果想要做精準的追蹤，那這樣的技術方案其實要提前了解。

Deeplink技術的原理來給大家解釋一下。

它主要解決的問題：

• 其一就是在應用商店不允許我們做一些渠道跟蹤的標識，而且應用商店給我們開放的數據維度和標識方案都比較有限，無法實現用戶的來源標示;
• 第二個問題就是，這個過程其實是用戶從手機瀏覽器到移動端app的一個遷移過程。

所以這兩個技術平臺的標示方式不同，也是難以標示同一用戶的一個巨大問題。那么在實現方式上，就是在沒有用戶帳號作為跨平臺標識的條件下，通過采集到的基礎信息和算法技術，然后繞過應用商店和技術平臺帶來的數據斷層，實現用戶來源標識和用戶唯一性標識，直接打通落地推廣頁和app之間的這種用戶行為關聯。

具體的算法本質上，其實是兩個方面：

一方面是一個有效的時間窗口，通常我們會定義為半個小時作為一個用戶轉化的一個周期 ，畢竟從登陸到這個網頁，到最終能下載 、啟動，其實中間是需要一個轉化時間的，這個時間也是可以調的，但是太長就失去識別的價值了，因為時間一長各種可能性太多，不太好把握 。所以建議是半個小時甚至更短的時間。

另一方面就是能夠采集到的設備和環境信息，比如說瀏覽器的user agent、設備特征 比如說型號品牌，然后最終通過算法，整合這些多維度的信息做出判斷。

03、如何匯總各平臺數據分析?

那之前說過的第三個痛點在于，各平臺的數據無法匯總做統一分析的問題。在剛才說了用戶唯一標識的這個問題，被解決以后匯總分析的就比較簡單了。在諸葛的最終方案中，提供整體各平臺數據分析的一個能力，用戶只要是在我們自有平臺上的行為數據，我們都是可以整合到一起進行分析，實現完整用戶生命周期行為。

打個比方，我們可以精準的看到哪些用戶是從知乎的推廣渠道來的，同時這些從知乎來的用戶有多少注冊了，那么這些用戶在js、安卓和ios的行為特點是什么樣的。通過對全平臺用戶行為的監測和監控，其實能夠清楚地知道各渠道用戶質量的一個情況。可以幫我們了解到比如說js端是否承載了引流的功能 ，移動app端是否承載了沉淀用戶的作用等。

我們今天的內容簡單的跟大家聊了聊獲客分析中的三個重點，其實這三個維度的價值就是能夠精準衡量用戶的獲取來源和新增活躍狀態，能夠在平臺之上更為宏觀和真實的看到多個平臺的新增活躍到底是一個人還是多個人;其二就是分析用戶各平臺之間的一個流轉狀態，相信絕大多數企業對各平臺的應用端是有定位的，當我們看到用戶在各平臺之間的流轉狀態后，才能夠知道用戶是不是按照我們設計的那樣。

總之呢，在現在大多數公司都呈現出這種全平臺客戶端的狀態下，整合各平臺數據做分析其實是非常有必要的。