聊聊效果優化跟蹤的埋點方案
一 場景描述
做電商的同學們是不是一直在為GMV上不去而頭疼不已,設計了好多的展示頁面,引流點,希望能夠為最後的下單付款添磚加瓦。
但是展示位做多了,分析展示位帶來的最終效果似乎會有些復雜,這麽多的展示位,我們如何能夠很好的跟蹤其對最終轉化行為的貢獻程度呢?沒關系,我們設計一套簡單易行的埋點方案就好啦~
二 關鍵詞
2.1 展示位
用戶能夠接觸到我們網站的各個花裏胡哨的頁面裏,因為展示的目的,組織邏輯不同,會有不同的小豆腐塊,像報紙的專欄一樣排的密密麻麻的。這一個小豆腐塊,就是一個展示位。
每一個展示位,我們可以設計如下幾個屬性:
-展示位ID:用來作為這個展示位的唯一標誌
-展示位名稱:給這個展示位取一個容易記的名字吧,如果可以最好唯一不重復,和展示位ID一一對應
-展示位類型:給這個展示位定一個類型,這樣我們更容易統計某一類的展示位帶來的綜合效果呢
-展示位描述:可以記錄一下這個展示位的一些主要的作用,設計的目的啥的,以免以後忘了
2.2 行為點
好啦,當展示位曝光在用戶眼前的那一刻起,其實我們和用戶的交互就已經開始了,從這時起,我們需要做的就是把用戶和系統的每一次重點的交互操作都記錄下來,這樣的每一次操作,都叫一個行為點。
每一個行為點,我們可以設計如下幾個屬性:
-行為點ID:同樣是用來唯一標誌這個行為點的
-行為點名稱:方便人工閱讀,見名知義的一個名字,依然最好是唯一不重復,和行為點ID一一對應
-展示位ID:觸發這個行為點的起始展示位ID,方便我們跟蹤嘍
-行為鏈路ID:多個行為點按照時間串聯起來,會形成一個行為鏈路,這裏明確的指定一個行為鏈路ID,用來方便分析日誌的時候關聯行為點
-AB Test ID:其實在同樣的一個行為點的時候,可能觸發的後臺邏輯是不同的,比如搜索展示行為點,有可能會嘗試使用不同的展示策略,所以在行為點的屬性中,可以設計一個AB Test ID,用來表示當前行為點具體是根據哪種策略觸發的
2.3 行為鏈路
在上個小節中,提到了行為鏈路ID,沒錯,這個行為鏈路ID就是唯一代表了一個行為鏈路的標誌ID。
和展示位,行為點不同,展示位和行為點,都是事先已知的,各個屬性都是產品同學或者運營同學提前指定好的,有需要的時候再添加;而行為鏈路則不同,它純粹是在用戶使用我們的產品時,動態生成的,所以行為鏈路ID一般都是系統通過程序自動去產生一個,比如md5(uid+timestamp+展示位ID+random_seed)等等方法。
三 效果追蹤
有了上述的埋點方案之後,其實後續的效果追蹤的工作就會變的十分方便了。
3.1日誌采集
各家會有各家自己的日誌收集的中間件,比如Flume等等。主要目的都是從客戶端把日誌收集到服務器端,並且進行一些簡單的數據預處理。
3.2 日誌中間層
收集好的日誌一般都是純文本格式,並不一定方便大數據工具進行直接處理,所以可以按照行為點的屬性字段切分,將日誌數據落在數據倉庫的日誌中間層中,這樣可以方便後續使用hive,spark等大數據工具進行分析。
3.3 行為鏈路分析
這一塊的具體操作就和業務關系比較緊密了,一般會把一些行為點作為轉化行為,會把一些前置的行為點作為行為鏈路的中間節點,通過行為鏈路ID,就可以很容易的知道到底哪些展示位為轉化行為帶來的貢獻比較大,具體是多少;而且通過AB TEST ID字段,也很容易對比系統中觸發不同行為點的背後的邏輯優劣,以便我們系統後端的工程師們,可以方便的調整自己的行為觸發策略~
聊聊效果優化跟蹤的埋點方案