起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識數據分析入門：初始數據埋點（二）
本文主要針對Key-Value字段的價值展開討論，并簡析其靈活運用的方法。
Hi，各位看官老爺們好O(∩_∩)O~，在第一篇《數據分析-初識數據埋點》中已經對工作中應用的數據埋點的基礎概念、基本分類、定義規范、流程以及應用場景做了簡單的介紹，基于部分看官老爺反饋Key-Value字段晦澀不易讀的一些問題。
所以本篇將在之前介紹的基礎之上，深入一步，詳細討論Key-Value字段的價值，以及靈活運用的方法。期望能幫助各位看官老爺基于業務需求在自己進行產品的埋點方案設計時提供一些解決問題的思路。
在第一篇文章埋點定義規范部分對應Key-Value字段沒有向看官老爺交代清楚，本汪痛定思痛，面壁思過，還望各位海涵。在本篇中針對遺留問題做了詳細的圖文解釋，還望之前留言的看官笑納。
正文
在上篇中我們已經知道，一個完整的埋點需要定義哪些字段，回顧如下：
- 功能字段
- 中文名字段
- 事件類型字段
- 事件ID字段
- Key字段
- Value字段
- 記錄規則字段
- 備注字段
寫到這里，看官老爺可能會問：埋點中定義Key-Value有什么價值？接下來本篇第一部分的篇幅將與大家一起一探究竟。討論到底Key-Value是做什么用的。
先寫結論：
設計事件埋點時：
- 同種屬性的多個事件，建議命名一個埋點事件ID，并通過Key-Value鍵值對進行區分。
- 不同屬性的多個事件，建議命名多個埋點事件ID，不建議使用Key-Value鍵值對進行區分。
乍一看，可能有些晦澀難懂，以下將舉兩個實例，自然就能明白易懂。
實例背景：某汽車互聯網公司，領導對負責新車業務的產品經理X君、負責二手車業務的產品經理Y君提出需求：對新車APP和二手車APP銷售線索數據指標進行數據監控，如有超過5%的數據變動，則需要向上級匯報波動數值以及波動原因。
名詞注釋：
- 銷售線索：通過事件記錄到用戶有明確的購買意向，記錄行為的事件例如：電話咨詢、短信詢價、加入心愿單、收藏、特別關注等類型事件。記錄一個用戶即代表一個線索。
- 數據波動：即(（當日數據-昨天數據）/昨日數據)*100%=環比數據波動
根據領導需求，假設定義短信砍價按鈕與電話咨詢按鈕為銷售線索指標，銷售線索按鈕頁面的入口來源頁面包含：頁面A與頁面B。
X君與Y君分別設計了埋點方案，如圖所示：
X君埋點方案：
X君經梳理得出，在商品詳情頁共計有兩個按鈕是銷售線索的核心指標分別是按鈕一：短信砍價、按鈕二：電話咨詢。并且有外部入口導流到詳情頁的有兩個頁面，分別是：頁面A、頁面B。根據流量來源的不同與事件類型的不同分為4個埋點事件，每一個埋點事件代表一種情況，如上圖所示。
方案分析：
X君對每一種情況都單獨設置了一個埋點事件ID，初步看上去還沒什么問題，X君只需每天用這四個事件ID去后臺搜索即可滿足領導的需求：對核心指標進行監控。
假設隨著業務的快速增長，新增更多的外部入口頁面，由原來的頁面A、頁面B的2個入口頁面增加至4個、8個、12個，同樣隨著產品優化需求的上線，新增更多的銷售線索事件，由原短信砍價和電話咨詢2個銷售線索事件增加至4個、8個、12個。
在極限情況（12個外部頁面入口、12個銷售線索事件）下X均需要共計維護：
12*12=144個埋點事件ID。
假設分析場景：12個流量來源、12個銷售線索事件，分析X天共計提交了多少線索？，來自頁面A的有多少？
問題一：分析X天提交的銷售線索中來自頁面A的有多少？
解決以上問題，X君首先需要將流量來源是：頁面A的12個不同類型銷售線索埋點事件ID找出來求合算出數值。
問題二：分析X天用戶共計提交了多少線索？
其次需要將剩下的11個流量來源各維度下12個不同銷售線索事件的ID一一取出數據加上流量來源是頁面A維度下的所有類型線索取出的數據，并進行最終求合算出X天共計提交線索數…寫到這里，各位客官老爺可能會說：X君好累啊~，其實不僅累，并且會帶來嚴重效率問題：
- 產品經理自身的工作效率會極大的降低，埋點事件ID越多，效率越低，最后極限情況下會無限逼近于零效率、零產出。
- 埋點事件無論是普通埋點還是關鍵核心指標埋點，不僅產品經理需要監控自身產品健康情況，兄弟部門像：數據運營同事、數據分析同事都會基于部門需求對產品進行數據分析與監控，如果像剛才這種情況，數據運營同事每周寫數據周報時，單單是一個埋點事件就要計算12個流量來源進行求合，效率極低，會嚴重拖累運營同事的工作效率。并且對于數據分析師來說，假設在統計整體的銷售線索指標時，如通過X君定義的埋點進行分析，在寫查詢語句SQL時，單是事件ID就要寫144個，（大家腦補下數據分析師有節奏的拷貝事件ID 144下時這個畫面），數據分析時會毫不猶豫的說：“來來來，X君我有事找你談談~~”可能有的看官會說：一個按鈕用一個埋點事件ID記錄就好了，不用區分頁面流量來源，那問題來了：當數據產生異常波動時怎么確定是哪個頁面的流量入口的流量變動導致最終的結果？
- 由于每天產品經理需要大量的埋點事件ID來統計一個指標，導致工作效率低下，可能會讓領導對你產生工作能力差，產出效率低下的不好印象…
那客官老爺會問：那怎么辦？稍安勿躁，馬上揭曉，請繼續向下看。
Y君埋點方案：
首先Y君對于銷售線索有關的內容從各個維度，按照邏輯關系進行拆分，梳理出以下腦圖：
寫到這里就不賣關子了，基于思維導圖中的邏輯關系，Key-Value閃亮登場?。。?/p>
Y君基于思維導圖中的邏輯關系，使用Key字段表示分析的維度，使用Value字段表示不同維度下對應的唯一參數標識，從而將每個維度下眾多不同的參數區分開來。通過Key-Value與同屬性事件ID的配合，像銷售線索這個指標就可以用一個事件ID來表示。在未來即使擴展N個外部入口流量頁面，也只需要在當前事件ID在表示流量來源Key維度下在首次開發時新增N個Value參數即可。在未來應用于數據分析時，只需要搜索或寫一個事件ID即可對各維度（Key）下不同參數（Value）進行分析，簡介、高效。
例如假設分析場景：12個流量來源、12個銷售線索事件，分析X天共計提交了多少線索？，來自頁面A的有多少？
問題一：分析X天提交的銷售線索中來自頁面A的有多少？
Y君只需在后臺查一個事件ID，并指定維度Key=指標來源（source）、Value=對應維度下參數為：頁面A，最終求出的結果，即代表來自頁面A的總數。
問題二：分析X天共計提交了多少線索？
同理，Y君只需要寫一個事件ID，并指定維度Key=指標來源（source）,Value=無。最終查詢出的結果即代表總的線索數。
注釋：
- 當不指定Value時，默認為包含該維度下所有參數（本例中即代表所有來源）。
- 各位看官可能會問：當不指定Value參數，且不指定Key維度，Key=無，Value=無 時，對最終總線索數有影響嗎？答案是沒有。
- 同理，一個事件ID，指定Key=其他的維度，例如：Key=指標類別（type）,不指定Value參數，例如Value=無，對最終總線索數統計有影響嗎？同理答案是沒有。
Y君通過梳理邏輯關系，將同屬性的埋點事件使用一個總事件ID表示，結合Key-Value細分不同維度下的不同參數，方便日后數據分析。通過此方式很好的解決了X君面臨的問題，不僅如此，并且具備以下優點：
- Y君的維護成本低，更加簡潔，新增時只需要首次開發時加一個Value參數即可。
- 提高Y君自身、數據運營、數據分析師等兄弟部門在數據分析時的工作效率。
- 擴展性好，對未來新增業務需求有良好的擴展性。
相信介紹到這里，大家對埋點事件中Key字段、Value字段配合使用帶來的價值已經有了一定的了解。當然如果不同屬性的埋點指標還是建議分開，一個屬性定義一個事件ID，不能將八竿子打不著兩種屬性的埋點強行捆綁在一個埋點事件ID上,為了用Key-Value而用Key-Value，生搬硬套，最后只會適得其反，沒有實際意義。
例如：在實際業務中，將用戶點擊“注冊賬號提交”按鈕的行為放在銷售線索這個屬性事件ID中也通過Key字段、Value字段進行區分標識。結果沒有參考價值，更沒有實際意義。
綜上所述，得出在正本第一篇幅中給出的結論：
設計事件埋點時：
- 同種屬性的多個事件，建議命名一個事件ID，并通過Key-Value鍵值對進行區分。
- 不同屬性的多個事件，建議命名多個事件ID，不建議使用Key-Value鍵值對進行區分。
各位看官老爺可根據自己產品的實際業務需求靈活運用，希望對大家在進行埋點方案設計時提供一些邏輯思路，幫助大家解決實際問題。O(∩_∩)O~
總結：
通過上一篇文章的基礎理論鋪墊，以及本篇中對埋點Key-Value字段的進一步介紹，涉及埋點方案規劃的內容已基本討論完成，期望本文中涉及埋點的篇幅能夠幫助0-1歲的產品老爺在工作中規劃以及維護埋點時提供一些邏輯思路，以及針對不同情況下解決問題的一些方案。
使最終交付的產物具備良好的擴展性、健壯性、易用性、高效性、可維護性等特性，以達到使自己以及兄弟部門花最少的時間成本獲得最高數據價值的目的！
下篇預告：
經過詳細且周密的準備工作以及產品線上各個環節童鞋的齊心協力，需求以及埋點方案終于上線啦。部分看官認為上線了即代表大頭的活都完成了，實際上，上線后才是埋點剛剛開始收集數據的開端，這才剛剛開始~
埋點上線后可能會面臨以下問題：
- 上線后等多長時間取數？1天？…10天？，取幾天是正確反映事實的？取數邏輯是什么？為什么？
- 同一份數據，不同的人給出了不同的結論？該相信誰？是數據錯了還是分析錯了？
基于以上疑問，下篇與大家一起利用統計學上的理論與方法與大家深入討論，幫我們找到真相！敬請期待O(∩_∩)O~
看到這里，看官老爺們會說：看到問題剛勾起了本看官的探索欲，正在勁頭上，文章內容怎么就更寫完了？解決方案呢?。兀?? ?說！雙汪你是不是在偷懶？￣へ￣
各位看官老爺息怒、息怒。且聽我解釋：
本文除了與大家交流學習的目的外，作為一只產品汪，最重要的當然是為各位看官老爺提供一個良好的閱讀體驗啦O(∩_∩)O~ ?因為雙汪通過數據分析垂直資訊類網站的文本內容發現，單篇文章在5000以及5000字以下時，綜合起來給用戶帶來的閱讀體驗是最好的。
讀到這里相信大家也已經有些小累了，不如泡杯熱茶，小憩一會兒，在下篇文章中與各位看官老爺討論解決方案，雙汪加班加點，第三篇已經在路上了，o(*^＠^*)o敬請期待~~
最后一句：以上我說的都是錯的，只有適合你的才是正確的！
再加一句：各位看官老爺，如果您覺的本文對您有幫助，記得給個贊哦，(* ￣3)謝謝啦。
相關閱讀
本文由 @Aaron 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協議
key其實就相當于屬性，value就相當于屬性的具體值。比如飲料，key可以是品類，value包含奶茶、咖啡等
2篇看完了，針對文中Y君的思路，其實開發設計數據庫時2個字段就行：source、type。這里“字段”概念的使用與數據庫“字段”相沖突。應該這樣。
超級干貨，催更催更~
Y君的埋點方案也有一個缺點，如果想要看A頁面的電話咨詢按鈕的銷售數據是沒辦法計算的吧。。只能看A頁面總的數據（即砍價+電話咨詢）
剛入門的我并看不懂在講的什么，，有更白話的解釋么
催個更吧?????♂?
不成熟的思考，歡迎討論：
1、從體系模塊劃分的角度，埋點應該重點解決記錄的問題，分類的問題，應該在埋點的上層系統，比如數據分析系統通過編碼規則等方式解決，Y方案容易導致高耦合；
2、例子中舉的是需要匯總數據的情況，如果需要明細數據，例如各來源各點擊的分布情況，X方案顯然不需要任何操作，所以案例不具有說服力。
求更新！
請問下，用key-value方式，那數據庫建表的時候，是不是應該表里面source和types是2個字段（即表頭，表里面A列第一行和B列第一行），頁面A、頁面B是source的兩個值（表A列第二、A列第三行），短信砍價、電話咨詢是types的兩個值（表B列第二、B列第三行），而不是key,value這兩個是字段（表頭）。然后要查詢A頁面短信砍價按鈕點擊次數，就是篩選source = ‘頁面A’ and types = ‘短信砍價’，然后次數就是有幾行記錄就是有多少次，是這樣嗎？
感謝作者分享
大佬 的兩篇文章都看了，從開始的懵逼到最后的豁然開朗，真是大寫的贊，非常感謝作者分享
很棒的文章，正如作者所說，看了很多零散的文章也只是找到了一小部分線索，這點是說到心坎了，看到作者說要輸出6-8篇成體系的知識按耐不住有些激動，誰知道看完一和二竟然沒有了，多希望作者有時間還能更新后續內容！
基本看懂全文了，但是好奇這個例子”在實際業務中，將用戶點擊“注冊賬號提交”按鈕的行為放在銷售線索這個屬性事件ID中也通過Key字段、Value字段進行區分標識。結果沒有參考價值，更沒有實際意義。”
沒搞懂這句話作者表達的意思，可以請教下看明白的大大們給解釋解釋不？感謝！！
文章里面的例子，核心指標是“銷售線索”，用戶有明確的購買意向的行為才可以；注冊賬號提交這個行為對于購買意向來說沒有意義的，所以不能綁定在一起
使用Y方法，如果我想知道頁面A通過電話方式提交的銷售線索怎么辦？雖然我不知道這個數據有沒有價值，但是通過Y方法好像并不能得到這個結果。
后臺進行搜索的時候，在這個事件里面。source=頁面A，type=電話咨詢，就行了
查詢“頁面A通過電話方式提交的銷售線索”，采用同時篩選2個key的方式，需要有一個前提條件吧：點擊事件是記錄路徑的？即“source=頁面A”的每一次點擊，也隱藏記錄了該點擊的type。作者在文中并沒有提到這點，所以也很是疑惑。
起點學院專門為0基礎的0-2歲互聯網人開設了《15天入門互聯網數據分析》班級哦~課程由數據思維+真實案例+實操相結合，提升你的數據分析能力！戳此了解>>http://996.pm/YNG4e
這篇寫的真的超級棒，頓時解決了上篇文章中 Value-key的疑問，例子舉的特別好，給作者打call
請問有沒有停留時長的案例？？
看得有點懵逼，我的邏輯思維不夠好，身為一個UI向轉交互，有點痛苦
作為過來人，偷偷告訴你，等過了這個階段會很幸福。
我也是 目前在轉交互很痛苦
那我要是想要知道A頁面電話按鈕點擊了多少次怎么搞？
找到事件ID，來源（key）選擇A頁面，類型（type）選擇電話按鈕，這樣不就知道了
這樣的邏輯，有點排列組合的味道
謝謝提供思考，是不是可以這樣理解，這里的一個事件ID代表了一個元事件，而key則代表了事件的某一個屬性，而value則是屬性所對應的屬性值。
怎么樣就是同種屬性
電話咨詢，短信問價，是不是都意向客戶打來的，那么這就都算是銷售線索，舉個更通俗易懂的例子，統計出行方式，那打車，騎車，坐飛機，自己開車，他們的共同屬性（目的）就是出行，所以出行是事件ID的話，出行方式就是key，打車，坐飛機就是value
受教了
Y君的方式無法追蹤數據高低的原因，比如這個月銷售量不好，是什么原因導致的呢？就可能是A頁面中的B按鈕顏色過淺導致的，如果用Y君方式，無法知道每個頁面每個按鈕的點擊情況， 就無法更好的進行產品優化
1.這里是提供數據埋點的方案，在數據量大的時候，y君的維護方法，是不是要比x君的維護方式更高效呢？
2.其次，如果你需要調查這個月的銷量為什么不好，首先你可以將這個事件id（銷售線索）不添加任何key和value導出，即導出全部數據，再自己利用第三方的軟件做數據分析，因為你現在就是在查找業績不好的原因，銷售線索只算其中一個，但是這樣的導出可以保證數據的完全性
贊同，Y君的方式是一種更加高效的數據埋點方式，后期便于擴展和維護。沒有哪種數據埋點方案是能夠一步到位解決實際業務問題的
同樣是查詢短信砍價次數，兩個key同時查詢時，在source里記了一次，在type里也記了一次，這兩次的次數含義是相同的，那最后查出來的次數數據不就有重復的么？
你在篩選導出的時候，key是必選的。意味你導出時肯定要選擇一個key，所以：
1.你同時選擇key=source，value=無和key=type，value=無得出來的數據是一樣的，他是標記所有的頁面的所有類型明細，即可以看到頁面a的所有type，頁面b的所有type
2.你單選key=source，value=無時，就是頁面a和頁面b的匯總，不會看出來type
3.你單選key=source，value=無時，就是電話咨詢和提交短信的匯總，不會看出來是哪個頁面來的
多謝作者好文；不過在下還是有兩個疑惑：1.怎么選擇服務器上報還是客戶端上報呢？2.客戶端上傳的話是選擇實時上報呢還是聚合上報？
你好，文中例子是兩個流量來源（頁面）和兩個事件（同屬性），那請問如果有兩個流量來源，統計同一個事件，是不是就只有key=source，兩個value區分開就好了？
“文中例子是兩個流量來源（頁面）和兩個事件（同屬性）”我覺得你的意思是否是：兩個流量來源（頁面）和兩個行為（短信砍價、電話咨詢）。如果是 “只有key=source，兩個value區分開”，到了業務場景中就變成了：只上報頁面A和B的數據（曝光量或者uv），而這個數據直接和銷售線索相關，失去了“短信砍價”“電話咨詢”兩個行為的支撐，是不合理的。
如果是你提這樣，銷售線索相關的數據就是，頁面A和B的曝光量或者uv；
而本文的例子中，key=source，value=無，則來自頁面A和B，短信砍價、電話咨詢的一共的點擊量
就是說要考慮全這一個事件有幾個屬性。還跟事件的統計目的有關
這么說value不一定只能填計算參數是吧？