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