中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導(dǎo)語：數(shù)據(jù)埋點，就是傳統(tǒng)的數(shù)據(jù)打點，在網(wǎng)站或者APP中加入一些統(tǒng)計代碼進行數(shù)據(jù)采集。埋點的價值以及正確埋點的重要性，基本上所有的產(chǎn)品或者數(shù)據(jù)人員都得需要了解。在本篇文章中，作者為我們分享了應(yīng)該如何建立埋點規(guī)范。

《數(shù)據(jù)埋點，一次講個夠》系列文章的第三篇，討論埋點業(yè)務(wù)的流程規(guī)范，主要討論：

1. ?埋點業(yè)務(wù)過程中涉及的角色及其職責(zé)；
2. 一條完整的埋點 workflow 長什么樣子？

一、角色與職責(zé)

一個完整的埋點業(yè)務(wù)流程會涉及業(yè)務(wù)方、埋點研發(fā)測試團隊、數(shù)據(jù)團隊：

• 業(yè)務(wù)方：產(chǎn)生埋點需求，通常是業(yè)務(wù)線的營運人員、產(chǎn)品經(jīng)理、數(shù)據(jù)分析師，他們根據(jù)業(yè)務(wù)，提埋點需求，埋點完成之后做數(shù)據(jù)分析，他們主要的工作是輸入原始需求、埋點上線后消費數(shù)據(jù)。
• 埋點研發(fā)測試團隊：負責(zé)埋點開發(fā)、測試、上線。
• 數(shù)據(jù)團隊：負責(zé)定義埋點模型，接收埋點數(shù)據(jù)上報，存儲數(shù)據(jù)、處理數(shù)據(jù)、展示數(shù)據(jù)。

不難看出，一個具體的埋點業(yè)務(wù)參與的各方需要大量協(xié)同配合。企業(yè)應(yīng)該有一個與埋點業(yè)務(wù)流相對應(yīng)的組織架構(gòu)，來保證埋點采集的質(zhì)量和效率。根據(jù)多年的埋點工作經(jīng)驗，有三個角色對埋點工作的開展有非常關(guān)鍵的作用。

1. 需要設(shè)置一個角色來統(tǒng)一規(guī)劃整體的埋點工作，負責(zé)組織協(xié)同各個業(yè)務(wù)線，制定埋點流程和規(guī)范，并推廣規(guī)范的落地與執(zhí)行，確保各業(yè)務(wù)線的數(shù)據(jù)接入符合規(guī)范，保障數(shù)據(jù)質(zhì)量，我所在的團隊由數(shù)據(jù)產(chǎn)品經(jīng)理來負責(zé)。
2. 對于公司具體業(yè)務(wù)線的埋點，需要有一個業(yè)務(wù)負責(zé)人，負責(zé)該業(yè)務(wù)線的埋點需求梳理、埋點設(shè)計、數(shù)據(jù)上線應(yīng)用推廣、日常使用支持和培訓(xùn)，這個角色，一般由業(yè)務(wù)線的數(shù)分、有數(shù)據(jù) sense 的產(chǎn)品、或者有業(yè)務(wù) sense 的研發(fā)擔(dān)任。
3. 關(guān)鍵的角色是具體業(yè)務(wù)線的埋點技術(shù)負責(zé)人，一般來說每條業(yè)務(wù)線會有多種客戶端的產(chǎn)品，埋點的開發(fā)可能會涉及 Android 端、iOS 端、微信小程序端、服務(wù)端，需要有一個技術(shù)接口人統(tǒng)籌埋點的開發(fā)工作，這個角色可以由前端開發(fā)負責(zé)人擔(dān)任。

二、埋點業(yè)務(wù)流程

上面這張流程圖貫穿了埋點的全過程，將上面提到的多種不同的角色串聯(lián)協(xié)同起來，保證埋點采集的高質(zhì)量、高效率，主要環(huán)節(jié)如下：

• 埋點需求提交：該環(huán)節(jié)由業(yè)務(wù)線需求方發(fā)起。通常是業(yè)務(wù)線的營運、產(chǎn)品、推廣，或者是數(shù)分，他們根據(jù)業(yè)務(wù)數(shù)據(jù)分析需要，提出埋點需求。業(yè)務(wù)方需要發(fā)出正式的需求郵件給埋點研發(fā)測試團隊、數(shù)據(jù)團隊。
• 需求評審：埋點需求評審由數(shù)據(jù)團隊主導(dǎo)，埋點研發(fā)測試團隊參與，業(yè)務(wù)方確認。數(shù)據(jù)團隊根據(jù)業(yè)務(wù)方需求進行埋點方案設(shè)計，輸出 DRD，組織需求評審。在需求評審會上，埋點研發(fā)測試團隊確認需求可行性，業(yè)務(wù)方確認事件設(shè)計方案符合業(yè)務(wù)需求。如一次評審沒有達成一致，將多次組織需求 review，直到三個團隊達成一致。
• 埋點開發(fā)：在埋點開發(fā)之前，業(yè)務(wù)方需要在線注冊埋點信息，信息的內(nèi)容須和最終評審?fù)ㄟ^的 DRD 保持一致。埋點研發(fā)團隊必須以線上注冊的埋點信息為準進行埋點開發(fā)。
• 埋點測試&驗收&部署上線：埋點數(shù)據(jù)測試由測試人員完成，測試完成后由數(shù)據(jù)團隊、業(yè)務(wù) 方驗收后，由研發(fā)人員部署上線。
• 埋點應(yīng)用（數(shù)據(jù)分析）：埋點上線后，業(yè)務(wù)方可通過數(shù)據(jù)提取、用戶行為分析平臺、用戶畫像標簽系統(tǒng)等方式消費埋點數(shù)據(jù)。

理想的情況下，一個埋點上線要經(jīng)歷上述五個步驟。

而在實際中，很多團隊在處理埋點業(yè)務(wù)時沒有形成內(nèi)部的流程規(guī)范，帶來的后果是埋點數(shù)據(jù)質(zhì)量差，數(shù)據(jù)的價值難以發(fā)揮。

比如：要統(tǒng)計某個行為的觸發(fā)人數(shù)時發(fā)現(xiàn)沒有埋點，數(shù)分在提取數(shù)據(jù)時發(fā)現(xiàn)有很多相似的字段不知道該用哪個，研發(fā)說某個埋點已經(jīng)上線了可數(shù)據(jù)庫里怎么也查不到數(shù)據(jù)，某個埋點起初上線的時候是正常的但從某個時候開始就沒有數(shù)據(jù)上報了。

要解決這些問題，需要把埋點當(dāng)做一條獨立的研發(fā)任務(wù)來看待，而不是產(chǎn)品開發(fā)過程中順便做一下的任務(wù)。

還有一點需要強調(diào)的是，流程的制定是很簡單的，畫一個圖，發(fā)一個文，但如果流程規(guī)范只是流于形式，無法真正的落到實際的環(huán)節(jié)中去，一切努力也只是白費。

因此，我們還需要進一步對流程規(guī)范中每一個環(huán)節(jié)的輸入輸出做更詳細的要求。

1. 埋點需求提交

1）提需求并不容易

埋點需求通常是業(yè)務(wù)方的營運人員、產(chǎn)品經(jīng)理、數(shù)據(jù)分析師根據(jù)業(yè)務(wù)數(shù)據(jù)分析需要， 提出埋點需求。提需求并不是一件顯而易見的事情，也需要學(xué)習(xí)。

Thea 之前所在的團隊，在埋點需求提交環(huán)節(jié)，只要求業(yè)務(wù)方描述清楚要在哪些維度下看哪些指標，數(shù)分會梳理指標、維度完成埋點設(shè)計。

這樣的流程對提需求的業(yè)務(wù)人員來說是非常友好的，他們不需要去說明為什么要看這個指標、在這些維度下分析指標對業(yè)務(wù)的價值，甚至在很多時候業(yè)務(wù)人員并不清楚業(yè)務(wù)路徑的全貌，他們只關(guān)注路徑上的某個環(huán)節(jié)上的指標，提上來的需求都是「局部的」、「臨時的」、「一次性」的。

基于這樣的需求設(shè)計出來的埋點也同樣是「局部的」「臨時的」「一次性」的，后續(xù)隨著業(yè)務(wù)路徑的調(diào)整，哪怕是小小的微調(diào)，也會導(dǎo)致埋點不可用要重新設(shè)計。

比較抽象，來一個具體的例子，用戶在社區(qū)中發(fā)帖子。

當(dāng)前，用戶在社區(qū)中發(fā)帖子有兩個入口，入口 A、入口 B，點擊發(fā)送帖子后，會進入編輯帖子的內(nèi)容頁面，內(nèi)容頁面編輯好之后，點擊發(fā)布就可以發(fā)布帖子。

業(yè)務(wù)方希望分析發(fā)帖子的漏斗，但由于業(yè)務(wù)方只知道入口 A，不知道入口 B 的存在，于是提出的漏斗是：點擊入口 A 的用戶數(shù) > 進入編輯頁面的用戶數(shù) > 點擊發(fā)布并成功發(fā)布帖子的用戶數(shù)。

基于此數(shù)分設(shè)計了兩個事件「進入編輯帖子頁」、「發(fā)布帖子」兩個事件（因為數(shù)分認為編輯帖子頁面只有唯一入口 A，基本上點擊 入口 A 的人數(shù) = 訪問帖子編輯頁面的人數(shù)）。

在埋點上線后的某一天，業(yè)務(wù)方說埋點數(shù)據(jù)有問題，來找數(shù)分核對數(shù)據(jù)，發(fā)生了如下對話。

• 業(yè)務(wù)方：「發(fā)布帖子的埋點數(shù)據(jù)有問題。」
• 數(shù)分：「什么問題？看起來沒毛病啊，昨天有 10000 個人進入了編輯帖子的頁面，有 5000 個人成功發(fā)布了帖子?！?/li>
• 業(yè)務(wù)方：「可以入口 A 所在的頁面一的瀏覽人數(shù)只有 2000 人，怎么可能有 10000 多人點了入口 A 呢？這不符合邏輯，是埋點上報出錯了吧？」
• 數(shù)分：「怎么可能？我來看看入口 A 頁面一的訪問人數(shù)。」

…

• 數(shù)分：「這不科學(xué)啊，難道發(fā)布帖子的入口不止 A？」
• 業(yè)務(wù)方：「我了解到的，只有入口 A?！?/li>
• 數(shù)分：「那我們?nèi)フ疑鐓^(qū)的產(chǎn)品經(jīng)理溝通確認下?！?/li>

…

• 數(shù)分：「果然，還有一個入口 B 也能發(fā)布帖子。這樣就清楚了，這是合理的，埋點數(shù)據(jù)上報沒有問題?！?/li>
• 業(yè)務(wù)方：「好吧，如果是這樣的話，我希望能夠區(qū)分通過不同入口發(fā)布帖子的用戶數(shù)?！?/li>
• 數(shù)分：「額，你之前提需求的時候也沒說，當(dāng)前的埋點做不到，要區(qū)分的話，只有加埋點字段，要等下個版本才能上線，并且只有在新版本中才能區(qū)分?！?/li>
• 業(yè)務(wù)方：「好吧，也只能這樣了?！?/li>
• 數(shù)分：「你看一下，新的埋點字段，沒問題的話研發(fā)就這樣開發(fā)了?！?/li>

這是數(shù)據(jù)團隊和業(yè)務(wù)團隊之間時常出現(xiàn)的場景。究其原因是掌握更多業(yè)務(wù)知識的業(yè)務(wù)方?jīng)]有向數(shù)分提供完整的信息（當(dāng)然數(shù)據(jù)分析也沒有進一步詢問，業(yè)務(wù)怎么說怎么做），數(shù)據(jù)分析設(shè)計的埋點沒有覆蓋完整的流程，導(dǎo)致埋點不可用。

為了避免這樣的問題發(fā)生，在埋點需求提交階段，要求業(yè)務(wù)方對業(yè)務(wù)流程給出詳細的說明，包括業(yè)務(wù)功能要引導(dǎo)用戶達成什么目標，業(yè)務(wù)完成的路徑如何，最好能提供用戶體驗地圖。

總之，要求業(yè)務(wù)方自己先能把業(yè)務(wù)路徑梳理清楚，提供盡可能多的業(yè)務(wù)背景。

2）提交需求

我們要求業(yè)務(wù)?發(fā)正式的需求郵件，下面的截圖是我們團隊在用的模板。

模板要求的信息和業(yè)務(wù)方要做的業(yè)務(wù)梳理是高度相關(guān)的，業(yè)務(wù)方須嚴格按照線下郵件流程進?提交，在郵件中說明要埋點的產(chǎn)品、端的類型、所屬業(yè)務(wù)、業(yè)務(wù)路徑、統(tǒng)計指標、維度、期望上線日期等信息。

收到郵件后，數(shù)據(jù)團隊在兩個工作日內(nèi)對接業(yè)務(wù)方溝通需求細節(jié)。

2. 需求評審

需求評審環(huán)節(jié)由數(shù)據(jù)團隊主導(dǎo)，通常是負責(zé)該條業(yè)務(wù)線的數(shù)據(jù)分析師。又分為三步：一是設(shè)計埋點，二是組織埋點需求評審會議，三是埋點注冊。

1）埋點設(shè)計

數(shù)分在收到埋點需求郵件之后，仔細閱讀需求，找業(yè)務(wù)?溝通需求細節(jié)，基于業(yè)務(wù)路徑設(shè)計埋點，盡量做到對業(yè)務(wù)流程全面覆蓋。

埋點設(shè)計的結(jié)果是輸出埋點 DRD，關(guān)于如何設(shè)計埋點，在系列上一篇文章中已經(jīng)有很多描述，請點擊閱讀。

2）埋點需求評審

數(shù)分組織埋點研發(fā)測試團隊、業(yè)務(wù)方進行埋點需求評審，評審需要確認以下要點：

1. 埋點研發(fā)測試團隊確認需求可行性
2. 業(yè)務(wù)方確認埋點設(shè)計方案符合業(yè)務(wù)需求

如一次評審沒有達成一致，將多次組織需求 review，直到三個團隊達成一致。需求評審?fù)瓿芍?，后續(xù)的開發(fā)埋點嚴格按照文檔進?，如有需求調(diào)整需要通過數(shù)分變更，并由數(shù)分通知相關(guān)方。

3）注冊埋點

埋點注冊要做的是將埋點 DRD 中的信息錄入到線上的系統(tǒng)，這么做的目的和埋點管理有關(guān)，整個埋點生命周期：新增、回數(shù)、迭代、下線都在線管理，這樣可以保證埋點不會越用越亂。

這塊的內(nèi)容會在下一篇再來討論，這里先不展開。

3. 埋點開發(fā)

完成埋點注冊之后，研發(fā)就可以開始 coding 了。研發(fā)團隊可以自研埋點 SDK，自己實現(xiàn)全埋點、代碼埋點、可視化埋點這些采集方式，也可以采用開源的埋點SDK，這樣可以節(jié)省很大的工作量。

下面的表格是比較了市面上主流用戶行為數(shù)據(jù)分析公司的埋點方式。

可以看出，如果想要節(jié)省開發(fā)人力選擇一款開源的埋點 SDK，神策埋點幾乎可以說是唯一的選擇。

但這個唯一的選擇也是相當(dāng)不錯的，神策埋點采用的是事件模型，SDK 支持的端非常全面，支持前端、后端、服務(wù)端埋點，還支持數(shù)據(jù)庫數(shù)據(jù)導(dǎo)入，Thea 目前就職的公司就采用了神策埋點 SDK。

4. 埋點測試&驗收&上線

埋點數(shù)據(jù)測試由測試人員完成，測試通過后由研發(fā)部署上線，上線之后業(yè)務(wù)方應(yīng)對埋點數(shù)據(jù)進行驗收。這里的重點工作是測試埋點，埋點驗證需要完成以下任務(wù)：

• 校驗觸發(fā)時機下前端/服務(wù)端埋點數(shù)據(jù)是否正常報出
• 校驗數(shù)據(jù)庫里是否收到上報的埋點數(shù)據(jù)
• 對事件和屬性的完整性及數(shù)據(jù)類型進?校驗

埋點的測試需要覆蓋主流機型，驗收完成后，由測試?員發(fā)測試報告，研發(fā)人員部署上線。

5. 埋點應(yīng)用（數(shù)據(jù)分析）

最后一個步驟，基于埋點數(shù)據(jù)做數(shù)據(jù)分析，需要有一個前端的分析工具支持，這里要展開的話會是龐大的篇幅，以后有機會我們再來討論用戶行為分析工具。

這是《數(shù)據(jù)埋點，一次講個夠》系列文章的第三篇，這一系列的文章會和大家系統(tǒng)地分享我對埋點體系建設(shè)的實踐與思考，討論問題：

• 如何讓業(yè)務(wù)線的產(chǎn)品/運營更高效地提埋點需求？
• 如何更快的響應(yīng)業(yè)務(wù)需求，輸出 DRD？
• 如何設(shè)計更簡潔、更靈活、拓展性更強的埋點模型？
• 如何協(xié)調(diào)好參與埋點工作的各方，快速產(chǎn)出高質(zhì)量的埋點？
• 如何有效地管理成千上萬個已線上、未上線、需要下線的埋點？

Thea，微信公眾號：Thea的若干好奇；從事大數(shù)據(jù)產(chǎn)品工作六年，設(shè)計、管理埋點已有三年，在大廠做過商業(yè)化大數(shù)據(jù)產(chǎn)品，也在幾十億美金估值的創(chuàng)業(yè)公司參與過數(shù)據(jù)中臺的建設(shè)。

經(jīng)手過上萬個埋點，經(jīng)歷過從 0 到 1 自建埋點體系，也使用過第三方的埋點服務(wù)。喜歡研究各種產(chǎn)品，不止限于數(shù)據(jù)產(chǎn)品相關(guān)的。相信優(yōu)雅的工具有很大的能量，可以減少工作和生活的摩擦。

本文由@Thea 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議。