1.什么是數據埋點？
大數據業務中涉及的數據分為兩部分，
- 流量數據：以用戶瀏覽產品，記錄用戶瀏覽行為的日志
- 業務數據：以生產系統中產生的業務數據庫記錄
例如我在刷淘寶，並且瀏覽了一個商品，並加入購物車，淘寶記錄了我加入購物車的行為或者記錄了我瀏覽這個商品的時長等等數據，這類型的數據是流量數據。
而后來我支付了訂單，這時候淘寶會將我的訂單記錄放在數據庫里，此時的訂單數據就是業務數據。
流量數據的獲取就是依靠數據埋點實現的，我理解的數據埋點是，我們所用的App、Web端、小程序等等都植入了數據埋點的SDK，會將用戶行為發送到后端。
2.數據埋點的作用
數據埋點是為了設計用戶動作的方案，探索用戶動作的意圖，記錄用戶動作發生的場景。
3.常見的數據埋點案例以及日常生活的例子
1）案例1
常見的埋點數據類型和數據如下：
[{ //Part1：配置信息 "user_id":"123", //埋點負責人的賬號id "business":"xx業務", //埋點數據的業務分類 "label":"標簽屬性"，//對埋點數據進行分類，對每個分類打標簽 //Part2：環境信息 "uid":"123", //用戶唯一ID，只要訪問就生成一個新的身份標示 "user_id":"123", //用戶的賬戶ID，僅登錄用戶可獲取得到 "name":"joker",//用戶的賬戶名稱，僅登錄用戶可獲取得到 "city_id":"2",//如果用戶訪問的頁面有城市屬性，這里可以獲取頁面的城市屬性id "city_name":"上海",//如果用戶訪問的頁面有城市屬性，這里可以獲取頁面的城市屬性值 "locate_city_id":"1",//用戶訪問時候所定位的城市id "locate_city_name":"北京"，//用戶訪問時候所定位的城市屬性值 "wifi":"on",//用戶訪問時候wifi的開關狀態 "app_version":"10.9.2",//用戶當前使用的app版本 "os_version":"11.8.2", //用戶當前手機系統的版本 "os_souce":"android" //用戶當前的手機系統（Android，iPhone，小程序、web…） //Part3：事件信息 "evs":[{ "id":"a1234"//坑位模塊的全app唯一標示id "val_val":{ //以下所有數據為同時攜帶的想要獲取的數據內容 "user_id":"123", //訪問用戶的賬號id； "content_id":"123234", //商品唯一id標示 "title":"conklab連帽潮牌oversize情侶裝",//商品標題； "price":"298",//商品價格； "business_id":"4",//商品分類屬性id "business":"女裝",//商品分類屬性 "strategy":"abc123",//不同策略的策略id，用於區分不同策略的數據效果 "shop_id":"123",//商品所屬的店鋪id "mark":"雙十一",//個性化的數據標簽，比如雙十一代表此商品正在參加雙十一活動 "position":"2",//商品在列表中展示排序的第幾個位置 } }] }]
上報策略：實際展示曝光上報策略，即只有當事件實際曝光顯示在屏幕當中才會上報（露出像素>0）
- 滑動：頁面上下滑動時，不重復上報
- 點擊事件：觸發上報
- 刷新：刷新頁面時，重復上報(?)
- 翻頁：翻到下一頁又返回上一頁時，不重復上報
- 事件點擊落地頁后自動跳轉，不重復上報
- 鎖屏后又回到原頁面時，不重復上報；或者應用或瀏覽器在后台喚醒，也不重復上報
- 沒有特殊限制定義，埋點需要根據坑位顆粒度(?)逐條上報，不做去重處理
例子：
案例1適用於站內埋點方式，例如各種Web端、App、小程序。
例如日常使用淘寶、京東等各大電商網站時，瀏覽過一些商品但沒有實際購買，這些瀏覽動作是有進行數據埋點的，因為在瀏覽商品過后，主頁就會出現同類或相似商品的推薦。
2）案例2
假設有個運營促銷的活動，url是https://www.xxxabc.com/about/1.html，我們將這個活動投放在某網站用於引流。最有效的埋點方案是在url中添加參數如下
https://www.xxxabc.com/about/1.html?source=sina_joker_ad_about_01
- source是字段名稱
- sina表示來源渠道
- joker表示來源渠道的負責人
- ad表示廣告類型，這里以ad表示一類廣告
- about是表示about這次活動
- 01:為圖片素材的編號
例子：
常用的站外，站內數埋點方式，多用於WEB、小程序平台；可以延伸出很多種不同的數據埋點方式，例如用source=abc123來代替source=sina_joker_ad_about_01以避免url長度過長，參數過多。
在騰訊視頻Web端，純甄小蠻腰的圖片的html標簽如下：
<a class="ad_square_item" href="https://pro.jd.com/mall/active/2oa4uPkaXxHPQj6X4A4bbrjoQuom/index.html" target="_blank" _stat="new_vs3_banner2:item">
<img alt="純甄" class="ad_pic" src="//puui.qpic.cn/tv/0/69353361_280260/0" style="visibility: visible;">
<span class="ad_title">純甄</span>
<span class="ad_desc">純甄小蠻腰 好喝到底 撐腰到底</span>
</a>
與正常的京東url:https://mall.jd.com/index-1000014803.html是有區別的，還是比較懷疑這里是否有在url上埋點
3）案例3
storymark: //業務場景標示，可以對應到不同的業務類型場景
-
“key1:”value" //頁面跳轉的時候傳遞的參數，采用key：value的形式寫入參數值 -
“key2:”value" //保留盡可能多的keyxid，寫入更多參數值 -
“key3:”value" //保留盡可能多的keyxid，寫入更多參數值
數據觸發上報說明：
我們希望統計瀏覽小視頻的入口，比如是通過搜索來的，還是關注來的。
1.當用戶通過搜索進行篩選進入小視頻時，在觸發搜索任務時上報如下埋點數據：
storymark: //業務場景標示，可以對應到不同的業務類型場景 “index:”search" //key（index）定義為是首頁，value（search）標示是來自搜索功能 “content:”美女" //key（conten）定義的是攜帶的內容參數，value（美女）標示內容參數
2.當用戶到達小視頻頁時，觸發上報埋點參數
通過關注瀏覽小視頻的目標頁也是類似的參數。
storymark: //業務場景標示，可以對應到不同的業務類型場景 “index:”guanzhu" //key（index）定義為是首頁，value（guanzhu）標示是來自guanzhu功能 “content:”guanzhu" //key（conten）定義的是攜帶的內容參數，value（guanzhu）標示內容參數
注意這種埋點具有強烈的抹除邏輯，例如用戶搜索了關鍵詞但最終沒有點開小視頻，而是回到關注頁點開，則搜索事件發生后的埋點數據需要刪除，而改為上報關注的埋點數據。
例子：
數據埋點中的一種透傳方案，主要用於統計站內的來源入口，適用於WEB、APP、小程序。
例如在刷微博時，微博會記錄用戶是通過搜索還是關注瀏覽到的博文。
4.數據埋點的解讀
從案例1可以看出，埋點數據的信息一般包含以下三個部分
- 數據埋點的業務配置信息(例如某商品的名稱，id等等)
- 在管理埋點時，我們已經對埋點的業務很明確，比如埋點事件的id，我們很清楚是誰負責的，中文名稱是什么，所以用戶在訪問產品時，可以選擇不上報，以減少收集的數據量，當我們在寫入數據庫時，再進行數據的補充。
- 用戶的環境信息(例如用戶所在的城市，用的App版本，登陸賬號，手機系統，手機品牌等等）
- 一般因為在一次會話中基本不變，所以在一次會話中通常只獲取一次，后在加工處理數據再補上這些信息
- 觸發埋點的事件信息(瀏覽)
5.關於數據埋點的問題
1）案例1中為什么刷新瀏覽頁需要重復記錄呢？
2）案例3中透傳方案的作用是什么？
3）埋點數據一般是入數據庫還是直接進入到數據倉庫？