1. 程式人生 > >多渠道推廣場景下,如何實現 App 使用者增長的精準歸因?

多渠道推廣場景下,如何實現 App 使用者增長的精準歸因?

為了實現使用者的快速增長,以推廣 App 為目標的線上廣告投放是很多平臺獲取新使用者的重要方式。隨道移動網際網路的發展,現在 App 推廣的渠道越來越豐富,除了 WAP 站點、第三方 App 之外,HTML5 成了 App 推廣的又一個主戰場。

選好了合適的推廣平臺,預算(理論上)也到位了,作為直面使用者的重要一環,如果沒有做好對投放效果的追溯和評估,將直接影響到使用者增長的整個過程,使之前的種種努力功虧一簣。

App 啟用是指新使用者首次開啟 App 的行為。在進行一輪廣告投放之後,對 App 啟用渠道的歸因分析是定位使用者來源、效果評估和推廣成本核算的主要方式之一。

 

傳統的 App 啟用渠道歸因

目前常見的 App 啟用歸因方式有裝置號歸因、渠道號歸因、IP+UA 歸因等。以下分別進行簡要介紹。

1. 裝置號歸因

裝置號歸因主要應用於第三方 App 中推廣,應用場景以資訊流廣告為主。

大多數情況下,第三方 App 都可以獲取到使用者移動終端的裝置號,如 iOS 系統下裝置的 IDFA、Android 裝置的 IMEI。因此在資訊流等廣告中,第三方平臺反饋給廣告主的點選資料通常會包含使用者的裝置號資訊。當用戶下載 App 完成啟用後,可以將獲取到的裝置號與第三方廣告平臺反饋的裝置號進行匹配進行歸因,來評估投放效果。

這種方式的歸因相對比較精準。但需要說明的是,為了得到更準確的分析結論,我們會同時使用多種歸因方式,通常來說裝置號歸因的優先順序較高。這就帶來一個問題,通過其他形式推廣帶來的啟用很可能會首先與裝置號歸因的方式匹配。比如使用者點選了資訊流廣告之後並沒有產生下載 App 的願望,而在之後點選了 HTML5 廣告並促使其完成了最終下載啟用 App 的行為。

按照行業通用的 Last Click(最後一次點選)的計算方式,實際應該歸因在 HTML5 廣告下。但 HTML5 的渠道又無法獲取使用者的裝置號資訊,所以這次行為很可能就會被歸因在優先順序較高的資訊流形式下,導致誤差的產生。

2. 渠道號歸因

「渠道號」指寫入安裝包的渠道標識。一般會將渠道號提前寫入 APK 安裝包裡,然後分發給不同渠道,渠道號會伴隨安裝包的整個使用週期。使用者啟用 App 後,可以從安裝包獲取到渠道號標識資訊進行匹配,所以理論上也是相對準確的歸因。

但這種方式會出現被手機應用廠商攔截的情況,也容易被不良的渠道方拿來進行資料作弊,從而無法有效評估真實的線上推廣效果。

3. IP+UA 歸因

IP+UA 是指通過將使用者點選廣告時的 IP、User-Agent(簡稱 UA,用來提取使用者的作業系統、版本號、手機型號等資訊)資訊與啟用時的 IP、UA 進行關聯匹配實現歸因分析,一般來說使用短鏈來收集這兩個資訊,好處是使用者友好、方便管理、方便資訊收集和設定。


IP+UA 歸因主要應用在 Web 站內導流、SEM 推廣和一些無法通過裝置號及渠道號歸因的廣告投放場景下使用,如 HTML5 廣告、WAP 廣告等。所以 IP + UA 雖然也是一種主要的歸因方式,但本質上是一種模糊匹配的歸因,因為這種方式無法直接獲取使用者客戶端的裝置號等精準資訊,並且使用者的 IP、UA 兩個引數容易隨環境變動和重複,因此使用的優先順序也較低。

比如在辦公環境網路下,多個使用者使用同一個 IP,或者多個啟用 App 的使用者使用的手機品牌和型號完全相同等情況下,很難實現精準歸因。更糟糕的是使用者點選廣告的 IP 與啟用時的 IP 很有可能是不一致的,比如使用者在 Wi-Fi 環境下點選並下載了 App,但是在 4G 環境下進行了啟用,由於網路環境的改變,IP 地址也會隨之改變;再如,同一個網路環境下 IP 相同,A 使用者點選了廣告但未下載,B 使用者沒看到廣告,但通過應用市場直接下載 App 激活了,並且這兩個使用者的手機品牌和型號完全相同,也就是 UA 一致,這些情況下 IP+UA 的歸因方式都是完全無效的。

由於 IP+UA 存在的這些問題導致這種方式的使用優先順序較低,但又會導致上文提到的 HTML5 廣告推廣會被匹配到資訊流廣告渠道中。

小結

綜上所述,提高對不同渠道歸因方式的精準度,降低分析誤差產生的可能性非常重要。

在調研的過程中發現,我們瞭解到現有一些方案在 IP+UA 方式的基礎上進行了一些優化,比如通過註冊使用者和短鏈節點計算關聯度來進行歸因,以及在現有 IP+UA 的基礎上更改匹配演算法來達到歸因的目的。但這些方法基本還是在圍繞 IP 和 UA 兩個引數進行調優,對於上文中所說的 IP 更改或 UA 有效資訊相同情況下的歸因錯誤問題,仍然無法避免。

 

基於剪貼簿的使用者唯一標識歸因分析

為了應對獲取裝置號失敗 (如使用者關閉廣告追蹤),或在 HTML5、WAP 廣告投放場景下使用 IP+UA 精準度不高的問題,我們設計了一種基於「剪貼簿」歸因的方案,來提升渠道歸因的精準度。

使用剪貼簿進行歸因分析的特點在於,可以通過獲取唯一標識的方式,提升在 HTML5、WAP 等無法獲取裝置號的廣告投放場景下的歸因準確性,同時減少由裝置號匹配帶來的噪音。

1. 實現流程

具體流程如下圖所示:


(1)在 HTML5、WAP 等廣告投放中,當用戶點選廣告時向剪貼簿寫入唯一標識;

(2)寫入系統剪貼簿的同時由伺服器記錄使用者唯一標識;

(3)使用者下載 App 啟用後,由 App 讀取剪貼簿符合規則的資訊並上報到伺服器;

(4)伺服器關聯點選時記錄的唯一標識和 App 啟用後上報的唯一標識進行歸因。

2. 主要優勢

(1) 使使用者具有唯一確定性

上文提到 IP+UA 的短鏈匹配存在的主要問題包括:

  • 使用者點選資料的 IP 地址與啟用 IP 地址發生改變則完全不能進行歸因,而使用者網路環境切換是較為普遍的情況;

  • 相同網路環境(IP 相同)、不同使用者但裝置型別(UA 相同)相同而導致的歸因錯誤

在剪貼簿歸因的方式下,當用戶觸發點選時會向用戶的不同作業系統(Android 、iOS)剪貼簿寫入一個形如特殊字元+隨機字串+特色字元的標記,(例:$f803489a$),形成當前點選廣告資訊使用者的唯一標識。當用戶下載 App 進行啟用時,客戶端就會讀取到剪貼簿中這個唯一標識並上報給伺服器,伺服器接收資訊後進行規則驗證和儲存,在 App 啟用時進行唯一標識的關聯匹配,最終實現精準歸因,從而有效解決了 HTML5、WAP 等投放場景下通過 IP+UA 方式的歸因誤差問題。

(2) 通用於 Android、iOS 系統,資料獲取簡便

使用剪貼簿可以通用於 Android、iOS 系統,資料讀取獲取簡單,有效架設了 HTML5、WAP 等廣告投放與客戶端 App 之間的橋樑。並且,由於在 Android Q 版本之後將獲取不到 IMEI(安卓手機裝置號),剪貼簿歸因將有可能應用到更多的場景。

(3) 標識資訊生成規則靈活

寫入剪貼簿的唯一標識資訊可按照任意規則進行生成,只要是可以區別於其他剪貼簿的內容,能夠用來唯一表示一次廣告點選來源的口令即可。同時可以在該標識中加入投放站點的標識資訊,這樣後面 App 在讀取剪貼簿資訊時可以進行渠道資訊的初步驗證,從而減少無用資訊的上報。

3. 應用

目前在馬蜂窩使用者增長啟用歸因分析中,應用了剪貼簿歸因方式後,整體歸因準確率提升超過 11% 。

在進行歸因分析時,由於唯一標識可以明確使用者的渠道來源,因此可以優先應用剪貼簿歸因,再用 IP+UA 作為輔助驗證手段來提高歸因分析的準確性。建議可以將基於剪貼簿的唯一標識歸因方式與裝置號歸因放到同一個優先順序進行匹配,如採用 Last Click 判定形式時,可根據裝置號查詢裝置資訊的最近一條點選,同時與唯一標識對應的廣告點選進行時間比對,取時間距離最近的一條點選作為推廣來源,達到減少裝置號歸因誤差的目的。

 

總結

精準的歸因在 App 推廣中非常重要。比如當前推廣一個旅遊 App 的成本大概在幾元到幾十元不等,傳統歸因方式引發的分析誤差很可能會造成雙倍損失,更重要的是如果不能精確分析是哪種渠道帶來的使用者,我們就不能準確評估推廣效果,使用者增長的持續優化更是無從談起。

精準的歸因分析是精細化運營的利刃,馬蜂窩使用者增長團隊也會不斷探索,儘可能多地到哪些被忽視的場景中,挖掘那些飽有價值的流量與新增入口。

最後,也歡迎更多夥伴加入馬蜂窩使用者增長團隊,現有前端、服務端、演算法、測試多個坑位在持續招聘中,有意向的朋友可以傳送簡歷至:[email protected].

本文作者:徐練勝,馬蜂窩使用者增長團隊服務端研發工程師。

(馬蜂窩技術公眾號原創內容)

相關推薦

多渠道推廣場景如何實現 App 使用者增長歸因

為了實現使用者的快速增長,以推廣 App 為目標的線上廣告投放是很多平臺獲取新使用者的重要方式。隨道移動網際網路的發展,現在 App 推廣的渠道越來越豐富,除了 WAP 站點、第三方 App 之外,HTML5 成了 App 推廣的又一個主戰場。 選好了合適的推廣平臺,預算(理論上)也到位了,作為直面使用者的重

"1,問題: 應用長期在後臺的場景進入前臺時fragment顯示為空白 2,app框架大體實現: 1個activity+多個Fragment,使用的是add()方法以及 hide(),show(

程式碼如下:                                                                                                                                                     

關於並發場景通過雙重檢查鎖實現延遲初始化的優化問題隱患的記錄

ron href 修飾符 屬性 tin 記錄 targe turn 優化問題   首先,這個問題是從《阿裏巴巴Java開發手冊》的1.6.12(P31)上面看到的,裏面有這樣一句話,並列出一種反例代碼(以下為仿寫,並非與書上一致):   在並發場景下,通過雙重檢查鎖(do

微博直播場景如何實現百萬併發的答題互動系統

內容來源:2018 年 09 月 07 日,新浪微博系統開發工程師陳浩在“RTC2018 實時網際網路大會”進行《微博直播場景下百萬併發的訊息互動系統》演講分享。IT 大咖說作為獨家視訊合作方,經主辦方和講者審閱授權釋出。 閱讀字數:2867

複雜運維場景如何實現分鐘級的故障根因定位

作者介紹 熊亞軍 靈犀技術總監,原百度系統部高階專案經理,負責百度IT基礎設施監控團隊,其帶領的團隊經歷了百度伺服器規模邁入幾十萬量級,網路架構數次演進,對伺服器尤其是網路層的監控和運維自動化智慧化有豐富的經驗。 開篇: 在超級網際網路公司,隨著伺服器規模都早早邁過 10 萬臺量級,加之業務模式的

【nginx】App打點場景用nginx的log捕獲http協議的$request_body的正確方法

【應用場景】 App裡面的打點資料想自己收集,可以考慮向nginx發一個json,通過nginx生成的日誌實現實時獲取資料。 所以問題就歸結為nginx日誌的生成。 正如  http://www.cnblogs.com/meteorx/p/3188647.html 這篇作

關於具有全國範圍的廣域網企業集中idc場景分支企業使用私有地址分布到ospf的防範措施。

ospf路由過濾在大型集團廣域網中的實用一、問題介紹 集團專網是集團總公司及下屬各企業之間進行信息交互,資源共享的重要平臺。集團專網具有接入企業數量多,接入方式多樣化等特點。因此,有效合理的網絡規劃及部署成為實現整體網絡高效運轉的唯一途徑。集團數據中心核心網絡和下屬企業局域網已遵循集團IT基礎設施建設標準,按

特殊場景如何判斷當前系統的發行版。

pretty root 判斷 oot 系統 linu rhel pre version [root@localhost ~]# cat /etc/*releaseCentOS Linux release 7.4.1708 (Core)NAME="CentOS Li

在不劃分vlan的情況實現兩個網段的ip地址互通

add route 網關 tex terminal 劃分VLAN 技術 water term 簡介: 在不配置vlan的情況下,實現兩個網段的ip地址互通 配置命令 PC1和PC2配置好ip地址和網關的ip地址 在R1路由器的F0/0配置ip地址為192.168.

高併發業務量大的業務場景資料庫減庫存的解決方案

1,使用者下單購買商品的情況下,如果有多個人同時下單,減除庫存的情況下,如果遇到了減去庫存的併發問題,這個時候應該怎麼處理呢? 傳統的業務流程場景下,處理流程是這樣的: 1,庫存查詢,通過dao查詢商

redis常見使用場景PHP實現

基於redis字串string型別的簡單快取實現 <?php //簡單字串快取 $redis = new \Redis(); $redis->connect('127.0.0.1',6379); //快取資料 $redis->set('cache_ke

跨資料中心場景kafka叢集部署模式

kafka在多資料中心場景下和單資料中心的場景部署是一樣的嗎?kafka的效能對分散式系統而言,非常重要。一旦延遲較大的情況下,應該如何部署。 一、為什麼要跨資料中心部署? 大型的分散式軟體,發展到一定階段,一個數據中心滿足不了需求,通常在一個城市會有多個

代理、轉發等多種場景如何獲取使用者真實IP?

1 概述 工作中會經常碰到需要進行轉發之類的需求,比如LVS轉發、NAT轉發,或者在BGP網路架設一個埠轉發來提高小運營商網路玩家的網路體驗等。 BGP進行遊戲埠轉發之前提到過,架構也比較簡單清晰明瞭: 這種簡單的轉發架構可以在很多地方應用。不過這裡有個源IP識別的問題,A使用者通過B機器的優質網

【策略與優化 - 001】- 在特定場景如何對雙層循環進行降級加速數據匹配?

減少 cti val 是否 測試 map 大小 準備 獲取 一、場景介紹 假設某次搜索結果中有 100_0000 篇文章,而你的個人收藏中有 10000 篇,如何在短時間內快速識別 100_0000 中哪些是 “已收藏”, 哪些是 “未收藏” ? 二、正常邏輯(雙層fo

資料庫高可用場景VIP(虛擬IP)的作用

高可用性HA(High Availability)指的是通過儘量縮短因日常維護操作(計劃)和突發的系統崩潰(非計劃)所導致的停機時間,以提高系統和應用的可用性。HA系統是目前企業防止核心計算機系統因故障停機的最有效手段。實現HA的方式,一般採用兩臺機器同時完成一項功能,比

iOS 規避蘋果審查實現app store上的app版本強制更新

要想規避蘋果審查,我們需要通過呼叫資料介面來控制呼叫app 版本強制更新功能:當蘋果在審查的時候,我們可以通過後臺數據控制關閉版本強制更新功能,等蘋果稽核通過以後我通過後臺控制開啟版本強制更新功能。下面是app 版本強制更新功能實現的程式碼:AppDelegate.h檔案 #

【演算法之連結串列(四)】在不使用額外節點儲存空間的情況實現單鏈表逆序

下面來看一下很經典的“單鏈表逆序”問題。很多公司的面試題庫中都有這道題,有的公司明確題目要求不能使用額外的節點儲存空間,有的沒有明確說明,但是如果面試者使用了額外的節點儲存空間做中轉,會得到一個比較低的分數。如何在不使用額外儲存節點的情況下使一個單鏈表的所有節點逆序?我們

Docker實現多臺機器之間相互SSH免密碼登入

在Docker下搭建hadoop叢集環境的時候,需要將叢集的機器設定為相互SSH免密碼登入,這裡將整個設定過程總結下來。 機器情況 一共啟動三個容器,都是centos6.7的系統,每個容器的名字和ip如下圖所示: 映象檔案 我們要實現SSH免

無限級分類在edit方法實現上級欄目選中

<volist name="cate" id="vo">                               &n

在只有一個網線的前提實現兩個電腦之間的區域網通訊(伽卡他卡電子教室通訊)...

在現實生活中,會出現只有一個網線,路由器交換機都沒有的情況,這時候怎麼實現兩臺電腦之間的通訊。 舉個簡單例子,實現伽卡他卡電子教室教師端和學生端在一根網線情況下通訊。 我們以Window系統為例,設定IPv4協議IP即可解決。 1、控制面板-網路和Internet-網路連線-本地連線-屬性  2、選擇IPv