《一週數據埋點之旅》第四天:埋點设计(下)

0x00 前言

在上節中我們介紹了埋點設計時四種主要思維方式,本節我們挑選典型的疑難埋點場景進行埋點設計。通過本節的閱讀,你將獲得以下典型場景埋點設計的認知:

  • 刷新流

0x01 刷新流

刷新流又稱服務流,是在新聞資訊類APP中常見的交互形式,隨著用戶不斷的滑動,內容不聽的更新,根據刷新的方式有分為全部刷新和增量刷新,而增量刷新有時候在頁面的頂部,有時在頁面的底部。對於刷新流埋點我們要終端關注上報的數據資訊和上報時機。

上報數據:

refresh_num:第幾次刷新(0代表首次進入,沒有刷新)

refresh_id:刷新id(包括下拉刷新和加載更多)

refresh_type:是否系統自動刷新,sys-系統自動刷新,manual-用戶觸發刷新

position:元素刷新部分的位置(在每次刷新中的位置)

rn:元素位於列表位置(在所有刷新中的位置)

sessionid:用戶一次連續使用id(用戶首次進入首頁生成,頂部刷新時更新

上報時機:

一般先加入緩存,緩存滿多少條上報,或者結合一些其他的上報時機。上報完成之後清空緩存,新曝光的加入緩存,等待新的上報時機被觸發。

用戶來回滑動也正常加入到緩存中,回滑加入緩存不去重

0x02 列表式

曝光事件的處理是埋點設計中最難的部分,其中尤以上報時機和上報格式最為考研埋點設計人員的能力,下麵結合給出作者的經驗設計。

上報時機

曝光上報的一個基本原則是用戶可見(離開之後再次可見算二次曝光),上報時機有以下幾種處理方式:

簡單式:

離開頁面的時候上報所有已曝光過的內容,但可能出現的問題對於刷新流的內容形式,一次上報的內容可能超出了限制,造成數據丟失。

混合式:

混合式的上報在簡單式的離開上報基礎上增加了緩存條數的觸發上報條件,緩存達到了指定數目之後,則將緩存過的數據進行上報,同時清空緩存等待新的曝光條目加入。

綜合起來,在處理曝光事件的上報時機的時候要充分的考慮以下場景:

緩存數據滿上下滑動等的重複曝光是否加入緩存快速滑動是否加入緩存

離開tab切換(內容是否刷新)實體鍵返回/軟鍵返回息屏(息屏之後解鎖)折疊展開隱藏的內容浮層/彈窗等遮擋進下級頁面

上報格式

列表式的曝光常採用多條一起上報的方式,每個條目有共性和個性屬性兩部分,一般設計如下:

# 公共屬性
page:xx
src:xxx
# 個性屬性:個性元素之間用‘;’分割,同元素不同屬性之間‘,’分割
contentlist:”a=1,b=2,c=3,d=4;a=5,b=6,c=7"

其中對於個性屬性的上報,又有以下兩種常用的方式(以某頭條新聞推薦tab下的列表項為例):

json嵌套

— 多源埋點(info:string(json格式)) {
“page”:”mp”, /*不要求key唯一,高擴展性*/ “contenlits”:[
{“type”:”娛樂”,”auth_id”:”111",”rn”:1,”id”:”v111"}, {“type”:”政治”,”auth_id”:”222",”rn”:2,”id”:”v222"}, {“type”:”科技”,”auth_id”:”333",”rn”:3,”id”:”v333"},
],
/*要求key唯一*/ “contentlist2”:{
} }
“v111”:{“type”:”娛樂”,”auth_id”:”111",”rn”:1}, “v222”:{“type”:”政治”,”auth_id”:”222",”rn”:2},

固定分割

# 內容公共屬性
page:mp
# 內容個性屬性
contentlist:
“type=娛樂,auth_id=111,rn=1,id=v111; type=政治,auth_id=222,rn=2,id=v222; type=科技,auth_id=333,rn=3,id=v333;”

注意事項

在處理曝光內容的時候,有以下幾點需要提前考慮:

重複曝光是否計算在內,即集合和列表的區別。

懸浮的授權彈窗下的頁面曝光,需要授權彈窗消失後才能上報

0x03 點擊相關

點擊延後

點擊埋點的上報時機一般不存在疑問,即點擊發生時候或者點擊結果返回時上上報,但在處理一些特殊場景的時候合理的制定上報時機,會給後續數據處理帶來極大便捷性。典型的使用場景是單頁面批量操作,具體如下:

單選或多選、然後一起操作(操作結果:關注/刪除/移動)

單選,每個選擇有單獨的操作結果(頁面不發生跳轉),整個頁面是每個操作的結果組合

以上兩種場景,建議離開當前頁的時候上報該頁面操作的結果,可以選擇上報所有操作之後的最終態,也可以記錄修改態(增什麼減什麼保留了什麼,開什麼關什麼不變什麼)

點擊附著

具有附加資訊的點擊事件上報,建議單獨拿出來,這是因為每個點擊對象都導致不一樣的結果,而這些 結果有時候又沒有共性(有共性的情況下可抽象成一個點擊事件)。具體的點擊附著場景如下:

點擊評論這個事件,就附著了評論的id、評論作者的id等資訊,如果歸結到統一的點擊事件,就需要加額外的信 息。而這些資訊是其他的點擊事件所不具備的,例如點擊返回(就沒有附著的對象id)

點擊具有跳轉能力的對象,就要記錄點擊的位置,跳轉前的屬性(比如當前url)和跳轉後的屬性(比如跳轉url) — 點擊具有紅點提示和消息條數提示的控件,則需要上報控件的狀態(是否有紅點或消息條目的多少)

點擊具有附帶結果,比如關注等,附帶結果是否要上報(牽涉到上報時機)

點擊資訊表

對於某些特殊的入口型應用,或者具有豐富內容形態的產品,有很多的交互設計,點擊不同的地方,跳轉不同的位置,甚至相同的位置,隨著後臺的配置不同而跳轉不同的地方。這種具有豐富的複雜的跳轉關係情況下,如果繼續採用屬性和屬性值堆疊的方式,不僅不能很好的體現屬性值之間的組合情況,以便測試和其他人員進行針對性的測試,也不利於使用人員快捷的進行點擊資訊的統計,此時建議採用資訊表的方式來設計,其形式如下:

按鈕/非按鈕等

具體的點擊位置

應用自身/第三方等

具體的跳轉目標

說明:

點擊區分重點按是否點擊率計算的分之來區分

跳轉區分是否跳轉跳轉到應用自身還是第三方

跳轉地址若是應用內部的跳轉,直接用對應的頁面編碼即可應用外部的跳轉,若是拉起具體的應用,則給出具體的包名,若是地址形式,則直接給出地址

0x04 聯動演化

聯動

聯動是指顯性的某些操作引起其他地方狀態改變的一些關聯變動(而這些變動同樣可有其他的顯性操作引起),這個時候要注意被聯動的狀態改變的上報(同時也要注意區分出狀態改變的原因),這些聯動可以是層級的關係(上層關閉,下層自動關閉),也可以是平級的關係。比如一些內容服務類的app,提供內容類型的關注,並同時可定制內容子類型,當子類型全部刪除後,則父類型自動取消關注。這種情形下,父類型的取消關注就會有兩種方式,一種是直接取消父類型,一種是通過對子類型的操作聯動父類型的改變。另外一些隱性的聯動也可以通過事件映射的方式下沉到埋點層解決,如果沒有這個將同類型操作結果的事件在底層映射成一個,很容易造成埋點遺漏,如果後面又利用此事件建立了開關累積表,則統計的準確性大大降低,而且修復起來也很複雜。

演化

演化是指在一個行為發生的過程中該行為附帶的屬性會發生變化,比如在一次播放過程中清晰度的切換、暫停和繼續、播放器介面的小屏和大屏切換等,或者隨著時間推移彈窗內容的改變等,這些存在演化的行為,一般的建議是用一個標示符串聯起來,比如播放用的sessionid串聯一次完整的播放,下單過程的產生訂單id(注意區分成功之後的訂單id),在某些場景要求不細的情況,可合併到事件的某個階段一起來上報,不用拆分階段來追蹤整個鏈條。

0x05 總結

本節對埋點設計中常見的刷新流、列表式、點擊相關、聯動演化四種常見情形講解了埋點設計的方式,當然埋點中並不僅僅這幾種方式,從統計需求出發,結合實際的場景,才是埋點設計的根本出發點。

數據科學系列文回顧:

十週入門數據分析系列文回顧:

關注數據君的臉書:

我是「數據分析那些事」。常年分享數據分析乾貨,不定期分享好用的職場技能工具。按贊我的臉書,會有豐富資料包贈送唷!

這是一個專注於數據分析職場的內容部落格,聚焦一批數據分析愛好者,在這裡,我會分享數據分析相關知識點推送、(工具/書籍)等推薦、職場心得、熱點資訊剖析以及資源大盤點,希望同樣熱愛數據的我們一同進步! 臉書會有更多互動喔:https://www.facebook.com/shujvfenxi/

這是一個專注於數據分析職場的內容部落格,聚焦一批數據分析愛好者,在這裡,我會分享數據分析相關知識點推送、(工具/書籍)等推薦、職場心得、熱點資訊剖析以及資源大盤點,希望同樣熱愛數據的我們一同進步! 臉書會有更多互動喔:https://www.facebook.com/shujvfenxi/