本人為一枚小小的數(shù)據(jù)產(chǎn)品從業(yè)者棒搜，3年數(shù)據(jù)分析及數(shù)據(jù)產(chǎn)品經(jīng)驗(yàn)，本文將以筆者實(shí)際工作為基礎(chǔ)活箕，以需求的口徑問(wèn)題為角度力麸，講解拿到數(shù)據(jù)需求后，該如何從0到1的過(guò)程育韩。
數(shù)據(jù)從業(yè)者大多體會(huì)過(guò)克蚂，需求方提出的數(shù)據(jù)需求，有時(shí)候簡(jiǎn)單明了筋讨，但是實(shí)則遍地是坑埃叭，有數(shù)不盡的定義，口徑需要我們要能夠提前想到悉罕，并給出建議和解決方案赤屋。
所以本文也只是從我的小角度，小案例出發(fā)壁袄，來(lái)探討如何做數(shù)據(jù)的需求分析类早，拋磚引玉。
本文涉及以下關(guān)鍵詞： 需求分析嗜逻，用戶行為涩僻，SQL
需求背景
現(xiàn)在我們的app有h5頁(yè)面版本，h5頁(yè)面的入口來(lái)源也有眾多，其中最主要的便是我們公司的主要app逆日，入口分布在主要app的各個(gè)位置嵌巷，比如搜索框，播放器頁(yè)面屏富，首頁(yè)推薦卡片晴竞。
需求目的
本需求方為部門(mén)的流量產(chǎn)品經(jīng)理，其目前負(fù)責(zé)h5的渠道入口的流量管理狠半，她需要對(duì)這些入口質(zhì)量進(jìn)行評(píng)估噩死，方便做對(duì)比，后續(xù)優(yōu)化做abtest神年。
數(shù)據(jù)需求
獲取通過(guò)每個(gè)渠道入口進(jìn)入h5頁(yè)面的pv已维，并統(tǒng)計(jì)這些用戶在后續(xù)是否在h5的下載提示點(diǎn)擊量，最后得到點(diǎn)擊率
數(shù)據(jù)邏輯
本文的數(shù)據(jù)邏輯是指將使用的表邏輯已日，目前有2張埋點(diǎn)表記錄了用戶在h5的行為垛耳，分別名為web_show,web_click，展現(xiàn)在文中的表已經(jīng)是經(jīng)過(guò)了數(shù)據(jù)清洗飘千，去除了無(wú)用字段
web_show
| http_refer | buvid | timestamp |
|---|---|---|
| http://xxx.com?from=a | sdfasd | 1559148871742 |
| http://xxx.com?from=b | sdfasd | 1559149871742 |
| http://xxx.com | sdfasd | 1559148875134 |
字段釋義
- http_refer堂鲜，用戶瀏覽了h5頁(yè)面時(shí)，會(huì)攜帶from=护奈，在來(lái)源頁(yè)面進(jìn)行埋點(diǎn)后缔莲，可在url中攜帶跳轉(zhuǎn)來(lái)源
- buvid，我司定義的用戶唯一身份識(shí)別霉旗，不同公司情況不同
- timestamp痴奏，觸發(fā)的時(shí)間戳
web_click
| buvid | timestamp |
|---|---|
| sdfasd | 1559148890000 |
字段與web_show表一致，該表數(shù)據(jù)記錄了在某時(shí)刻點(diǎn)擊了下載提示
分析思路
以下分析思路僅供參考厌秒，不一定百分百正確读拆，方法可以有多種，所以希望讀者能有所收獲或者給出更好的方案
明確口徑
拿到需求鸵闪，確認(rèn)了方案的可行性后檐晕，要對(duì)結(jié)果的口徑進(jìn)行探究，需求方提出的需求是否已經(jīng)完整地明確了定義岛马，根據(jù)其需求棉姐，我們可以初步判定：
由于表中沒(méi)有識(shí)別用戶的會(huì)話id，我們只知道用戶經(jīng)歷了a頁(yè)面—b頁(yè)面啦逆，b頁(yè)面—c頁(yè)面伞矩，無(wú)法得知用戶是否在同一會(huì)話中從主app的入口進(jìn)入頁(yè)面后，在頁(yè)面點(diǎn)擊了下載提示夏志，也即a頁(yè)面—b頁(yè)面—c頁(yè)面 or c事件乃坤。所以需要定義用戶如何操作才會(huì)被算為有效的渠道來(lái)源并點(diǎn)擊苛让。
頁(yè)面路徑可能性
可以發(fā)現(xiàn)，用戶從主app的渠道進(jìn)入h5頁(yè)面后湿诊，在頁(yè)面路徑上有非常多的可能性狱杰，例如：
- 離開(kāi)
- 進(jìn)入h5頁(yè)面的另一個(gè)頁(yè)面，產(chǎn)生了不帶from的瀏覽記錄厅须，也就是上文web_show的第三條記錄
- 點(diǎn)擊了下載提示
- 點(diǎn)擊了下載提示后仿畸，返回h5頁(yè)面 或 時(shí)隔幾小時(shí)后 點(diǎn)擊了下載提示
- 瀏覽了部分頁(yè)面，因?yàn)橛惺玛P(guān)閉屏幕朗和，時(shí)隔6小時(shí)繼續(xù)瀏覽并點(diǎn)擊下載
- 點(diǎn)擊下載错沽，時(shí)隔5小時(shí)，從主app的另一個(gè)渠道進(jìn)入h5頁(yè)面眶拉，點(diǎn)擊下載
- 未點(diǎn)擊下載千埃，時(shí)隔5小時(shí)，從主app的另一個(gè)渠道進(jìn)入h5頁(yè)面忆植，點(diǎn)擊下載
拋出疑問(wèn)
根據(jù)上述情況放可，需要解決以下問(wèn)題：
- 用戶多次下載是否需要去重？
- 多次下載如果去重朝刊，選擇用戶的哪次下載作為計(jì)算其渠道來(lái)源的基礎(chǔ)耀里？判斷的依據(jù)是什么？
- 選擇好有效下載后拾氓，如何確定本次下載的有效入口备韧？
- 如果從渠道進(jìn)入的時(shí)機(jī)與下載時(shí)機(jī)間隔長(zhǎng)達(dá)5小時(shí)，是否算同一次會(huì)話?
問(wèn)題解決
上述問(wèn)題無(wú)標(biāo)準(zhǔn)答案痪枫，我只提出本人見(jiàn)解：
用戶的多次下載需要去重，找到其在當(dāng)日的首次下載叠艳，其有效來(lái)源入口如果有多個(gè)不同來(lái)源記錄奶陈，選擇時(shí)間最近的記錄。
而對(duì)于時(shí)間間隔的選擇附较，我傾向于選擇在1天內(nèi)都算吃粒，如果4小時(shí)，那上文提到的拒课，時(shí)隔5小時(shí)下載徐勃，難道認(rèn)定不算有效下載？
時(shí)間導(dǎo)致的誤差解決
因?yàn)閿?shù)據(jù)的計(jì)算都是t+1早像，所以按每日的維度來(lái)計(jì)算僻肖，會(huì)產(chǎn)生如下問(wèn)題：如果在23點(diǎn)50分用戶從渠道入口進(jìn)入，隔日0點(diǎn)5分下載卢鹦，在本計(jì)算方案中無(wú)法被判定為有效下載臀脏，該問(wèn)題無(wú)法繞過(guò)。
所以我們可以結(jié)合實(shí)際業(yè)務(wù)數(shù)據(jù)來(lái)將數(shù)據(jù)的準(zhǔn)確性提高到最大，本人給出的方案是：
用戶在24小時(shí)內(nèi)揉稚，在每個(gè)時(shí)間點(diǎn)上有使用分布秒啦，根據(jù)數(shù)據(jù)表現(xiàn)得出用戶在每日的24點(diǎn)左右活躍數(shù)非常高，但在每日的5點(diǎn)活躍數(shù)最小搀玖，所以我們可以將數(shù)據(jù)的計(jì)算周期不再固定為每天余境，而是在每天凌晨4點(diǎn)后的任意時(shí)間點(diǎn)開(kāi)始自動(dòng)化跑報(bào)表，時(shí)間范圍為：昨日凌晨4點(diǎn)到當(dāng)日凌晨4點(diǎn)灌诅，這樣可以將誤差的數(shù)量降到最低
SQL
由于筆者所面臨的表芳来，往往是復(fù)雜，量級(jí)大延塑，使用的查詢引擎也是hive绣张，試錯(cuò)成本高，所以通常選擇建立中間表关带，篩選后所需數(shù)據(jù)后再進(jìn)行數(shù)據(jù)的統(tǒng)一及匯總侥涵。
具體sql的思路為
- 篩選掉show表的所有不帶from的記錄，并建中間表
- 清洗click表宋雏，找出每個(gè)buvid的min(timestamp)
- 將click表作為左表芜飘，join show中間表，on click.buvid=show.buvid and click.timestamp>show.timestamp
- 用窗口函數(shù)給show的timestamp降序排序磨总，找出排名等于1的嗦明，該記錄即為其有效渠道入口
- 使用聚合函數(shù)求出每日不同渠道的有效下載數(shù)
- 最后調(diào)度，形成自動(dòng)化報(bào)表
總結(jié)
數(shù)據(jù)分析往往面臨的業(yè)務(wù)需求蚪燕，看似簡(jiǎn)單娶牌，問(wèn)題頗多，口徑問(wèn)題首先確定馆纳，在初期的數(shù)據(jù)探索過(guò)程中诗良，不停拋出疑問(wèn)，作出假設(shè)鲁驶，并用數(shù)據(jù)驗(yàn)證鉴裹，成為自己完成業(yè)務(wù)數(shù)據(jù)需求的依據(jù)。也要與需求方多溝通钥弯，在不斷的磨合中径荔，碰撞出新的思路與解題方案。
