天天看點

關于資料埋點,看這一篇就夠了

資料埋點是資料化營運的根基,尤其是對于App、小程式形态的線上業務,沒有埋點資料驅動的精細化營運就是無源之水,巧婦難為無米之炊。

一、埋點資料的應用場景及價值

1.廣告投放效果分析

相比較粗放式的營運,精細化營運追求營銷費用ROI的最大化,是以需要将站外廣告投放資料與使用者進站之後通路、激活、下單等行為串聯起來,進而進行管道投放效果的歸因,及時調整廣告投放政策。對于三方的流量管道來說,在使用者未注冊登入狀态,隻能擷取裝置資訊,如DeviceID、IMAC、IDFA以及廣告管道辨別UTM參數或者App商店的産品包ID等。通過埋點将使用者點選入口的ID資訊以及後續在站内的通路的行為鍊路串聯起來。

2.産品功能使用分析

很多C端産品的新人,在做産品功能時甚至不知道要埋點,隻提了産品功能需求而忽略了埋點需求,找資料團隊要資料分析報告時,發現連點都沒有。這個時候就為時已晚。針對上線的産品功能,營銷活動,需要同時提埋點需求。(無埋點也需要進行事件的圈選或定義才能擷取到資料)

3.個性化推薦服務

在内容、産品的千人千面服務中,使用者浏覽、點選、互動、下單等行為是算法模型重要的特征輸入,比如你刷抖音搜尋或者點選“娛樂八卦”的内容,推薦系統會實時給你更新相關的内容,沒有埋點,推薦就是事後諸葛亮,體驗大大降低。

4.精準營銷的實時觸景營銷應用

在精細化營運中,除了離線的批量推送場景外,為了提升使用者的實時互動感,會配置很多場景化的營銷方式。比如使用者浏覽了很多商品詳情都沒有下單,是不是因為價格不滿意?實時下發優惠券,激發使用者下單欲望。沒有埋點,就無法實作

5.産品流量轉化分析

使用者使用産品的行為路徑,不同流量入口進來的使用者轉化漏鬥分析,關鍵流失環節挖掘,離不開埋點資料

6.黑産及風險使用者判斷(風控場景)

在反欺詐領域,更要對使用者的實時欺詐行為進行識别和攔截,把羊毛黨、欺詐使用者帶來的業務損失降到最小。

二、關于埋點的常見問題

1.埋點規範不統一

如果業務在發展過程中資料部門是後來才成立的,首先要解決的就是埋點不規範的問題,不同業務線、不同産品甚至同一個産品的不同版本埋在規則都不一緻,這樣資料分析的清洗成本就非常高,比如,同一個位置的埋點,homepage_1_poiid,有的叫homepage^1^poid,那麼在分流量入口統計轉化漏鬥時,就需要單獨處理,進而導緻後期的分析成本每次隻能case by case的處理。

2.漏埋、錯埋問題頻發

一般來說負責埋點的是業務端的前後端開發,負責埋點資料清洗處理的是資料團隊,資料輸出是下遊的業務應用方。一方面是埋點需求流程不清晰,另一方面則是業務研發對資料不了解,而且有時也會認為埋點是增加自己工作量,如此一來就會導緻漏埋、錯埋的現象。

三、如何更好地承接和管理埋點需求

對于企業來說,統一埋點規範雖然會有短期的陣痛,但卻是一勞永逸的事情。如果說因為埋點統一事情推進涉及的部門多,周期長,成本高,風險大,一直沒人願意牽頭去做這件事情,那麼随着業務發展複雜的增大,未來統計的可能性就更低,由此帶來的資料品質問題、資料清洗成本會更高。是以在資料治理工作中,埋點治理是源端的治理。

第一是要協同不同團隊,建立大家認可的标準化埋點流程規範。這裡一方面是埋點的流程要清晰,從業務端産品、研發、資料團隊各司其職。其次是,要通過多方協商,建立一個可以盡可能滿足多方的資料采集模型和埋點的規範,比如點位命名規範、分隔方式等。

關于資料埋點,看這一篇就夠了

在埋點工作中,業務端的産品或者營運主要從業務需求場景的角度送出資料分析需求,和初步的埋點需求,資料團隊需要有人負責埋點的稽核(一般是BI或者資料産品經理),從埋點設計到上線後資料品質監控,都需要建立規範的管理流程。

關于資料埋點,看這一篇就夠了

此外,僅有規範,如果涉及人員的交替,也會導緻規範變形,是以需要産品化的方式把規範融入到系統當中,對應的就需要埋點管理系統了,不僅要把埋點的規則内化到埋點需求建立流程當中,還可以把所有的曆史埋點統一管理起來,友善查詢和使用埋點資訊。

四、常見的埋點方案與優劣勢對比分析

雖然說現在埋點方案已經非常成熟了,很多人入職公司後更多是負責埋點的具體工作,很少涉及埋點方案的選型,但常見的埋點方案及其優劣勢卻是在資料産品面試中的高頻問題。是以作為資料産品經理也需要了解

1.代碼埋點

代碼埋點是最早的埋點方式,根據業務的分析需求,将埋點的采集代碼加入到應用端。按照埋點實施方,又分為前端(用戶端)埋點和後端(服務端)埋點兩種類型。

(1)用戶端埋點

由前端開發手動定義資料采集時機、内容等将資料采集的代碼代碼段加入到前端業務代碼中,當使用者在前端産生對應行為時,觸發資料采集代碼。

優點:

  • 按需埋點,采集資料更全面,幾乎可覆寫所有資料采集場景
  • 行為資料和業務資料可充分聯合分析

缺點:

  • 延遲上報,資料丢失率高(5%-10%)
  • 需要用戶端發版,使用者端更新App
  • 埋點開發工作量大
  • 埋點流程需要多方協作,容易漏埋、錯埋

适用場景:

全面分析使用者在用戶端的操作行為,對于一些電商交易類的産品,需要把行為和業務資料充分結合分析

(2)服務端埋點

由服務端開發将埋點采集代碼加入到後端服務請求中,當使用者前端操作請求服務端資料時,按照約定規則觸發埋點代碼

優點

  • 按需埋點,采集資料更全面,幾乎可覆寫所有資料采集場景
  • 行為資料和業務資料可充分聯合分析
  • 資料采集實時上報,準确性高,丢失率低
  • 服務端更新,不需要用戶端發版或使用者更新版本

缺點

  • 純前端操作不觸發服務請求的按鈕點選無法采集資料
  • 埋點開發工作量大
  • 埋點流程需要多方協作,容易漏埋、錯埋

适用場景:

對于一些非點選、不可見的行為,或者要擷取使用者身份資訊、更多的業務相關的屬性資訊。如果前後端都可以采集到,優先後端埋點

2.全埋點

全埋點也有稱之為無埋點或無痕埋點的,主要是将埋點采集代碼封裝成标準的SDK,應用端接入後,按照SDK的采集規則自動化地進行資料采集和上報

優點:

接入SDK後,可自動采集資料,無需按需開發,節省開發成本

頁面可見元素均可自動采集,資料更全面

埋點流程簡單,業務使用埋點系統自助定義事件,新增埋點需求無需業務開發參與

缺點

動态頁面或頁面不可見行為資料無法采集

和業務強相關的屬性資訊采集困難

資料全部采集,資料存儲壓力大

适用場景:

業務場景簡單,如工具、應用類的産品,或者業務發展初期,産品快速疊代需求比精細化分析優先級更高,隻需要分析簡單的PV、UV

3.可視化埋點

預設不采集資料,當資料分析人員通過裝置連接配接使用者行為分析工具的資料接入管理界面,在頁面可視化定義需要采集的位點後下發采集請求,采集代碼生效

優點:

預設不上報資料,可視化圈選才按需觸發埋點,節約存儲和傳輸成本

業務可視化圈選,埋點操作簡單友善

缺點

資料隻在埋點圈標明義之後才有,曆史資料無法回溯

隻能覆寫基本的點選、展示等使用者行為,和業務強相關的屬性資訊采集困難

适用場景:

業務場景簡單,如工具、應用類的産品,或者業務發展初期,産品快速疊代需求比精細化分析優先級更高,隻需要分析簡單的PV、UV

關于資料埋點,看這一篇就夠了

五、如何提埋點需求?埋點需求文檔模闆

例如,團購App新上線了金剛位,來進行不同業務品類的流量分發。金剛位内容可能不同使用者看到的是不一樣的,在實際分析時,平台營運側,偏重于按照位置分析,看哪一個位置的點選效果好,而品類營運則會聚焦于内容哪一個品類的轉化更好。埋點需求的關鍵要素包括:

  • 事件名:點選金剛位
  • 事件ID:clickjingangwei
  • 事件類型:click
  • 頁面:首頁homepage
  • 區域:金剛區
  • 元素:item位置、item内容
  • 平台:微信小程式、APP(android、iOS)、PC
  • 應用版本:8.0.1
  • 使用者屬性:城市、裝置機型等SDK可以采集的通用屬性
關于資料埋點,看這一篇就夠了

以上僅做示例,實際上,每個公司的埋點模型定義的字段是不一樣的,對于可以SDK預設收集的字段不需要提需求,僅對可以明确定義唯一事件的内容進行說明即可。

繼續閱讀