作者：Aaron（轉(zhuǎn)載已取得作者授權(quán)）

在第一篇《數(shù)據(jù)分析之如何制作數(shù)據(jù)埋點文檔》中已經(jīng)對工作中應用的數(shù)據(jù)埋點的基礎概念、基本分類、定義規(guī)范、流程以及應用場景做了簡單的介紹，基于部分看官老爺反饋Key-Value字段晦澀不易讀的一些問題。

所以本篇將在之前介紹的基礎之上，深入一步，詳細討論Key-Value字段的價值，以及靈活運用的方法。期望能幫助各位看官老爺基于業(yè)務需求在自己進行產(chǎn)品的埋點方案設計時提供一些解決問題的思路。

在第一篇文章埋點定義規(guī)范部分對應Key-Value字段沒有向看官老爺交代清楚，本汪痛定思痛，面壁思過，還望各位海涵。在本篇中針對遺留問題做了詳細的圖文解釋。

正文

在上篇中我們已經(jīng)知道，一個完整的埋點需要定義哪些字段，回顧如下：

• 功能字段

• 中文名字段

• 事件類型字段

• 事件ID字段

• Key字段

• Value字段

• 記錄規(guī)則字段

• 備注字段

寫到這里，看官老爺可能會問：埋點中定義Key-Value有什么價值？接下來本篇第一部分的篇幅將與大家一起一探究竟。討論到底Key-Value是做什么用的。

先寫結(jié)論：

設計事件埋點時：

• 同種屬性的多個事件，建議命名一個埋點事件ID，并通過Key-Value鍵值對進行區(qū)分。

• 不同屬性的多個事件，建議命名多個埋點事件ID，不建議使用Key-Value鍵值對進行區(qū)分。

乍一看，可能有些晦澀難懂，以下將舉兩個實例，自然就能明白易懂。

實例背景：某汽車互聯(lián)網(wǎng)公司，領導對負責新車業(yè)務的產(chǎn)品經(jīng)理X君、負責二手車業(yè)務的產(chǎn)品經(jīng)理Y君提出需求：對新車APP和二手車APP銷售線索數(shù)據(jù)指標進行數(shù)據(jù)監(jiān)控，如有超過5%的數(shù)據(jù)變動，則需要向上級匯報波動數(shù)值以及波動原因。

名詞注釋：

• 銷售線索：通過事件記錄到用戶有明確的購買意向，記錄行為的事件例如：電話咨詢、短信詢價、加入心愿單、收藏、特別關注等類型事件。記錄一個用戶即代表一個線索。

• 數(shù)據(jù)波動：即(（當日數(shù)據(jù)-昨天數(shù)據(jù)）/昨日數(shù)據(jù))*100%=環(huán)比數(shù)據(jù)波動

根據(jù)領導需求，假設定義短信砍價按鈕與電話咨詢按鈕為銷售線索指標，銷售線索按鈕頁面的入口來源頁面包含：頁面A與頁面B。

X君與Y君分別設計了埋點方案，如圖所示：

X君埋點方案：

X君經(jīng)梳理得出，在商品詳情頁共計有兩個按鈕是銷售線索的核心指標分別是按鈕一：短信砍價、按鈕二：電話咨詢。并且有外部入口導流到詳情頁的有兩個頁面，分別是：頁面A、頁面B。根據(jù)流量來源的不同與事件類型的不同分為4個埋點事件，每一個埋點事件代表一種情況，如上圖所示。

方案分析：

X君對每一種情況都單獨設置了一個埋點事件ID，初步看上去還沒什么問題，X君只需每天用這四個事件ID去后臺搜索即可滿足領導的需求：對核心指標進行監(jiān)控。

假設隨著業(yè)務的快速增長，新增更多的外部入口頁面，由原來的頁面A、頁面B的2個入口頁面增加至4個、8個、12個，同樣隨著產(chǎn)品優(yōu)化需求的上線，新增更多的銷售線索事件，由原短信砍價和電話咨詢2個銷售線索事件增加至4個、8個、12個。

在極限情況（12個外部頁面入口、12個銷售線索事件）下X均需要共計維護：

12*12=144個埋點事件ID。

假設分析場景：12個流量來源、12個銷售線索事件，分析X天共計提交了多少線索？，來自頁面A的有多少？

問題一：分析X天提交的銷售線索中來自頁面A的有多少？

解決以上問題，X君首先需要將流量來源是：頁面A的12個不同類型銷售線索埋點事件ID找出來求合算出數(shù)值。

問題二：分析X天用戶共計提交了多少線索？

其次需要將剩下的11個流量來源各維度下12個不同銷售線索事件的ID一一取出數(shù)據(jù)加上流量來源是頁面A維度下的所有類型線索取出的數(shù)據(jù)，并進行最終求合算出X天共計提交線索數(shù)…寫到這里，各位客官老爺可能會說：X君好累啊~，其實不僅累，并且會帶來嚴重效率問題：

• 產(chǎn)品經(jīng)理自身的工作效率會極大的降低，埋點事件ID越多，效率越低，最后極限情況下會無限逼近于零效率、零產(chǎn)出。

• 埋點事件無論是普通埋點還是關鍵核心指標埋點，不僅產(chǎn)品經(jīng)理需要監(jiān)控自身產(chǎn)品健康情況，兄弟部門像：數(shù)據(jù)運營同事、數(shù)據(jù)分析同事都會基于部門需求對產(chǎn)品進行數(shù)據(jù)分析與監(jiān)控，如果像剛才這種情況，數(shù)據(jù)運營同事每周寫數(shù)據(jù)周報時，單單是一個埋點事件就要計算12個流量來源進行求合，效率極低，會嚴重拖累運營同事的工作效率。并且對于數(shù)據(jù)分析師來說，假設在統(tǒng)計整體的銷售線索指標時，如通過X君定義的埋點進行分析，在寫查詢語句SQL時，單是事件ID就要寫144個，（大家腦補下數(shù)據(jù)分析師有節(jié)奏的拷貝事件ID 144下時這個畫面），數(shù)據(jù)分析時會毫不猶豫的說：“來來來，X君我有事找你談談~~”可能有的看官會說：一個按鈕用一個埋點事件ID記錄就好了，不用區(qū)分頁面流量來源，那問題來了：當數(shù)據(jù)產(chǎn)生異常波動時怎么確定是哪個頁面的流量入口的流量變動導致最終的結(jié)果？

• 由于每天產(chǎn)品經(jīng)理需要大量的埋點事件ID來統(tǒng)計一個指標，導致工作效率低下，可能會讓領導對你產(chǎn)生工作能力差，產(chǎn)出效率低下的不好印象…

那客官老爺會問：那怎么辦？稍安勿躁，馬上揭曉，請繼續(xù)向下看。

Y君埋點方案：

首先Y君對于銷售線索有關的內(nèi)容從各個維度，按照邏輯關系進行拆分，梳理出以下腦圖：

寫到這里就不賣關子了，基于思維導圖中的邏輯關系，Key-Value閃亮登場！！！

Y君基于思維導圖中的邏輯關系，使用Key字段表示分析的維度，使用Value字段表示不同維度下對應的唯一參數(shù)標識，從而將每個維度下眾多不同的參數(shù)區(qū)分開來。通過Key-Value與同屬性事件ID的配合，像銷售線索這個指標就可以用一個事件ID來表示。在未來即使擴展N個外部入口流量頁面，也只需要在當前事件ID在表示流量來源Key維度下在首次開發(fā)時新增N個Value參數(shù)即可。在未來應用于數(shù)據(jù)分析時，只需要搜索或?qū)懸粋€事件ID即可對各維度（Key）下不同參數(shù)（Value）進行分析，簡介、高效。

例如假設分析場景：12個流量來源、12個銷售線索事件，分析X天共計提交了多少線索？，來自頁面A的有多少？

問題一：分析X天提交的銷售線索中來自頁面A的有多少？

Y君只需在后臺查一個事件ID，并指定維度Key=指標來源（source）、Value=對應維度下參數(shù)為：頁面A，最終求出的結(jié)果，即代表來自頁面A的總數(shù)。

問題二：分析X天共計提交了多少線索？

同理，Y君只需要寫一個事件ID，并指定維度Key=指標來源（source）,Value=無。最終查詢出的結(jié)果即代表總的線索數(shù)。

注釋：

• 當不指定Value時，默認為包含該維度下所有參數(shù)（本例中即代表所有來源）。

• 各位看官可能會問：當不指定Value參數(shù)，且不指定Key維度，Key=無，Value=無 時，對最終總線索數(shù)有影響嗎？答案是沒有。

• 同理，一個事件ID，指定Key=其他的維度，例如：Key=指標類別（type）,不指定Value參數(shù)，例如Value=無，對最終總線索數(shù)統(tǒng)計有影響嗎？同理答案是沒有。

Y君通過梳理邏輯關系，將同屬性的埋點事件使用一個總事件ID表示，結(jié)合Key-Value細分不同維度下的不同參數(shù)，方便日后數(shù)據(jù)分析。通過此方式很好的解決了X君面臨的問題，不僅如此，并且具備以下優(yōu)點：

• Y君的維護成本低，更加簡潔，新增時只需要首次開發(fā)時加一個Value參數(shù)即可。

• 提高Y君自身、數(shù)據(jù)運營、數(shù)據(jù)分析師等兄弟部門在數(shù)據(jù)分析時的工作效率。

• 擴展性好，對未來新增業(yè)務需求有良好的擴展性。

相信介紹到這里，大家對埋點事件中Key字段、Value字段配合使用帶來的價值已經(jīng)有了一定的了解。當然如果不同屬性的埋點指標還是建議分開，一個屬性定義一個事件ID，不能將八竿子打不著兩種屬性的埋點強行捆綁在一個埋點事件ID上,為了用Key-Value而用Key-Value，生搬硬套，最后只會適得其反，沒有實際意義。

例如：在實際業(yè)務中，將用戶點擊“注冊賬號提交”按鈕的行為放在銷售線索這個屬性事件ID中也通過Key字段、Value字段進行區(qū)分標識。結(jié)果沒有參考價值，更沒有實際意義。

綜上所述，得出在正本第一篇幅中給出的結(jié)論：

設計事件埋點時：

• 同種屬性的多個事件，建議命名一個事件ID，并通過Key-Value鍵值對進行區(qū)分。

• 不同屬性的多個事件，建議命名多個事件ID，不建議使用Key-Value鍵值對進行區(qū)分。

各位看官老爺可根據(jù)自己產(chǎn)品的實際業(yè)務需求靈活運用，希望對大家在進行埋點方案設計時提供一些邏輯思路，幫助大家解決實際問題。O(∩_∩)O~

總結(jié)：

通過上一篇文章的基礎理論鋪墊，以及本篇中對埋點Key-Value字段的進一步介紹，涉及埋點方案規(guī)劃的內(nèi)容已基本討論完成，期望本文中涉及埋點的篇幅能夠幫助0-1歲的產(chǎn)品老爺在工作中規(guī)劃以及維護埋點時提供一些邏輯思路，以及針對不同情況下解決問題的一些方案。

使最終交付的產(chǎn)物具備良好的擴展性、健壯性、易用性、高效性、可維護性等特性，以達到使自己以及兄弟部門花最少的時間成本獲得最高數(shù)據(jù)價值的目的！

此外，視頻號晚上直播答疑，歡迎有問題的老鐵來聊聊。

最后，我建立了各大城市的產(chǎn)品交流群，想進群小伙伴加微信：yw5201a1??我拉你進群。

關注微信公眾號：產(chǎn)品劉?可領取大禮包一份。

··················END··················

今日研報：普華永道發(fā)布《亞洲食品市場挑戰(zhàn)：了解亞洲新消費群體》，公眾號后臺回復“?亞洲食品”，即可下載完整PDF文件。

RECOMMEND

推薦閱讀

實戰(zhàn) | 手把手教你設計優(yōu)惠券前后臺

手把手教你做B端產(chǎn)品經(jīng)理

產(chǎn)品經(jīng)理如何寫好MRD文檔

面試題，你有看過啥產(chǎn)品經(jīng)理書籍嘛？

點擊“閱讀原文”

查看更多干貨

總結(jié)

以上是生活随笔為你收集整理的数据分析之如何制作数据埋点文档（二）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。