數(shù)倉建模—埋點設(shè)計與管理
數(shù)據(jù)倉庫系列文章(持續(xù)更新)
數(shù)倉架構(gòu)發(fā)展史 數(shù)倉建模方法論 數(shù)倉建模分層理論 數(shù)倉建模—寬表的設(shè)計 數(shù)倉建模—指標(biāo)體系 數(shù)據(jù)倉庫之拉鏈表 數(shù)倉—數(shù)據(jù)集成 數(shù)倉—數(shù)據(jù)集市 數(shù)倉—商業(yè)智能系統(tǒng) 數(shù)倉—埋點設(shè)計與管理 數(shù)倉—ID Mapping 數(shù)倉—OneID 數(shù)倉—AARRR海盜模型 數(shù)倉—總線矩陣 數(shù)倉—數(shù)據(jù)安全 數(shù)倉—數(shù)據(jù)質(zhì)量 數(shù)倉—數(shù)倉建模和業(yè)務(wù)建模
關(guān)注公眾號：
大數(shù)據(jù)技術(shù)派，回復(fù):資料，領(lǐng)取1024G資料。
埋點設(shè)計與管理
埋點的作用
開始之前我們先看一下我們?yōu)槭裁匆占顸c數(shù)據(jù)，埋點都可以做什么，埋點主要用于記錄用戶行為,幾乎是應(yīng)用必不可少的功能.埋點的作用包括但不限于
分析用戶轉(zhuǎn)化以及存留例如下載的用戶數(shù)量,注冊的用戶數(shù)量,一段時間之后的存留用戶數(shù)量;
分析用戶偏好例如通過用戶行為的分析,可以對用戶的偏好做一定的概括,便于投其所好針對特性的用戶推送特定的服務(wù),甚至開發(fā)不同的用戶體驗;
收集市場反饋例如針對新功能的用戶行為進行統(tǒng)計,就可以分析出功能的市場反饋,為是否保留功能或者改良方向提供依據(jù);
保障用戶數(shù)據(jù)安全例如用戶的地理位置數(shù)據(jù)在短時間內(nèi)突然發(fā)生了異常變更,這一秒在南京,下一秒突然就在東京登陸了,那就說明賬號發(fā)生了異常,需要對賬號身份進行驗證,以確保用戶數(shù)據(jù)的安全.
定位異常例如特定的數(shù)據(jù)(比如注冊)在某一段時間內(nèi)數(shù)據(jù)突然無緣由發(fā)生持續(xù)性異常,說明該功能可能存在異常,需要及時做排查.
其他作用例如當(dāng)某一個較早機型占比降低到某一個閥值時,就可以在下一個版本中去掉對該設(shè)備的支持.
埋點數(shù)倉設(shè)計
數(shù)據(jù)進入數(shù)倉之前我們就需要設(shè)計好數(shù)倉表，埋點的表的數(shù)據(jù)有幾個特點，所以我們在設(shè)計的時候需要考慮到
數(shù)據(jù)量非常大，可能是所有數(shù)據(jù)集成渠道里面，流量最大的了 數(shù)據(jù)不存在更新，這是埋點表的數(shù)據(jù)特點
面對這兩個特點，我們需要做一些設(shè)計，當(dāng)然還有一些其他設(shè)計方面的點需要注意一下，首先因為量大，而且我們往往關(guān)注的是昨天的數(shù)據(jù)，所以我們的表肯定是分區(qū)表，其次因為我們使用的特點，例如關(guān)注的是頁面瀏覽或者是按鈕點擊，所以我們在時間分區(qū)的基礎(chǔ)上按照事件進行分區(qū)。這樣我們可以在數(shù)據(jù)查詢的時候過濾掉大量的數(shù)據(jù)從而提高查詢的性能。
其次就是埋點表的作為數(shù)據(jù)報表的數(shù)據(jù)來源的時候，可能會大概率遇到計算延遲，或者是一些其他問題，所以在寬表的設(shè)計或者是報表展示中，請盡量地將集成進行后延，從而更好的保證穩(wěn)定性和可用性。關(guān)于這一點，請參考數(shù)倉建模—寬表的設(shè)計
這里是我們公司小程序端的埋點表
下面是web 端的埋點表
埋點的類型
埋點：在期望的點位，埋設(shè)一個記錄的標(biāo)記。這個點位，一般多是指用戶與產(chǎn)品進行一次次交互的接觸點，從而可以在用戶和產(chǎn)品交互的時候，將用戶的數(shù)據(jù)進行上報。
通過收集這些標(biāo)記點的數(shù)據(jù)，可以幫助產(chǎn)品運營及開發(fā)同學(xué)了解功能的整體使用、運行情況，并通過數(shù)據(jù)基礎(chǔ)上做出下一步調(diào)整或優(yōu)化的方向。遇事不拍腦袋，而是用數(shù)據(jù)說話，這是數(shù)據(jù)埋點最大的價值。
在AB測試的場景下，數(shù)據(jù)埋點為實驗組的效果提供數(shù)據(jù)支持，其本質(zhì)也是數(shù)據(jù)決策的基礎(chǔ)。
根據(jù)目前常見的數(shù)據(jù)埋點形式，可以將數(shù)據(jù)埋點分為全埋點、代碼埋點(自定義埋點)，當(dāng)然我們也可以按照產(chǎn)品的類型劃分為，APP埋點、web 埋點、小程序埋點
全埋點
全埋點的邏輯，是指數(shù)據(jù)采集sdk無區(qū)別的對待所有事件的，將所有事件(頁面的加載成功事件、控件的瀏覽和點擊事件)全部獲取后先存下來，到使用的時候，再根據(jù)具體的頁面路徑和控件名稱，去撈取相應(yīng)的數(shù)據(jù)。
可視化埋點
基于此，可視化埋點是指，在全埋點部署成功、已經(jīng)可以獲得全量數(shù)據(jù)的基礎(chǔ)上，以可視化的方式，然后進行數(shù)據(jù)選擇。
這種方案的弊端之一是耗流量和存儲空間，全埋點采集的數(shù)據(jù)一般會根據(jù)情況設(shè)定一個銷毀時限，比如7天。即：全采集過來的數(shù)據(jù)，如果7天之內(nèi)沒有被使用，則會刪除。而一旦對圈選數(shù)據(jù)做了圈選定義之后，則被定義的頁面數(shù)據(jù)、控件數(shù)據(jù)，則會一直采集，且不會刪除。
全埋點，其優(yōu)勢和特點是功能上線時，不需要開發(fā)做額外的埋點定義工作，用的時候再根據(jù)需求去獲取對應(yīng)的數(shù)據(jù)，因此也叫無埋點。
全埋點的缺點：
耗用戶流量、占存儲空間； 一旦版本迭代，對頁面的路徑做修改，或者控件位置、文案有修改，原來的圈選數(shù)據(jù)可能就會出錯，需要重新圈選，之前利用圈選指標(biāo)設(shè)定的分析模型都要替換； 圈選指標(biāo)無法區(qū)分細部參數(shù)，比如：商品詳情頁，無法通過圈選數(shù)據(jù)來區(qū)分是哪一個商品或哪一個類目； 對web的頁面數(shù)據(jù)處理一直不好，尤其是涉及到APP的內(nèi)嵌H5頁時，非常痛苦。
因此，全埋點適用于業(yè)務(wù)多變、經(jīng)常調(diào)整，且分析訴求比較輕量的場景。對于通用的功能，形態(tài)相對比較固定，且對數(shù)據(jù)分析顆粒度、下鉆深度、聚合程度要求比較高，那就需要用到代碼埋點
代碼埋點
代碼埋點也叫自定義埋點，從字面上即可理解：是針對想要的點位單獨定義，并可以通過變量豐富埋點的信息，以支持上下游分析。
代碼埋點分為前端埋點和后端埋點。
前端埋點，包括但不限于APP客戶端、H5、微信小程序、PC網(wǎng)頁，是指對具體的功能場景（如加載成功、瀏覽、點擊等）進行明確的定義，由前端觸發(fā)，采集上來的數(shù)據(jù)相比于全埋點，更準確、穩(wěn)定，且通過變量字段，能夠?qū)崿F(xiàn)更細顆粒度數(shù)據(jù)的拆分、聚合和下鉆。
后端埋點，指觸發(fā)了服務(wù)端接口調(diào)用（如：接口回調(diào)成功觸發(fā)）的事件埋點，如最典型的注冊成功事件、付費成功事件。后端埋點對數(shù)據(jù)的準確度要求更高，同時也可以通過變量字段的擴展支持數(shù)據(jù)拆分、聚合和下鉆。需要強調(diào)的是，后端事件一般采集的是已登錄狀態(tài)下的用戶行為，如果想使用后端埋點事件作為流程分析的其中一環(huán)（如漏斗分析），則可能出現(xiàn)未登錄的用戶會漏掉的情況。
綜合以上，幾種埋點類型的比較
埋點上報方式
對于一個埋點方案來說，數(shù)據(jù)上報有兩個點需要著重考慮：
對跨域做特殊處理。 頁面銷毀后，如何還能夠?qū)⑽瓷蟼鞯穆顸c數(shù)據(jù)成功上報
參考 https://juejin.cn/post/6844904153739706375
圖片請求
有下面幾點優(yōu)勢：
沒有跨域問題，一般這種上報數(shù)據(jù)，代碼要寫通用的，img 天然支持跨域；（排除 ajax） 不會阻塞頁面加載，影響用戶的體驗，只要 new Image 對象就好了, 通過它的onerror和onload事件來檢測發(fā)送狀態(tài)；（排 除 JS/CSS 文件資源方式上報） 在所有圖片中，簡單、安全、相比PNG/JPG體積最小；（比較 PNG/JPG）（tip:最小的BMP文件需要74個字節(jié)，PNG需要67個字節(jié)，而合法的GIF，只需要43個字
這種使用方式也存在缺陷。首先對于src 中的URL內(nèi)容是有大小限制的，太大的數(shù)據(jù)量不適用。詳細看這里。其次，在頁面卸載的時候，若存在數(shù)據(jù)未發(fā)送的情況，會先將對應(yīng)的數(shù)據(jù)發(fā)送完，再執(zhí)行頁面卸載。這種情況下，會在體驗上給使用者帶來不方便。
GET 請求
GET把參數(shù)包含在URL中，也就是說我們的上報的數(shù)據(jù)是在一個url 參數(shù)中或者是幾個參數(shù)中，例如 ?data=XXXX 這里的data 就是我們上報的數(shù)據(jù)
GET 請求 最大的特點就是簡單，但是同時也帶來了很多其他的問題，首先是安全問題因為GET 請求參數(shù)被暴露在IURL 中，GET請求只能進行url編碼，而POST支持多種編碼方式，其次GET請求在URL中傳送的參數(shù)是有長度限制的，也就是如果你上報的數(shù)據(jù)內(nèi)容比較多，可能會被截斷。
POST 請求
POST 請求 相比GET 請求首先就是更加安全，其次是支持多種編碼，而且所能發(fā)送的數(shù)據(jù)量也更大，看起來是個不錯的選擇，但是還是不如圖片請求好
埋點管理設(shè)計
整個埋點的事件我們可以使用4W1H 進行表示
下面是APP 端的一個例子
事件模型
我們使用“事件模型（ Event 模型）”來描述用戶的各種行為，事件模型包括事件（ Event ）和用戶（ User ）兩個核心實體。整個埋點的屬性，我們可以分為兩大類，第一類是事件屬性，第二類是用戶屬性。
為什么這兩個實體結(jié)合在一起就可以清晰地描述清楚用戶行為？實際上，我們在描述用戶行為時，往往只需要描述清楚幾個要點，即可將整個行為描述清楚，要點包括：是誰、什么時間、什么地點、以什么方式、干了什么。而事件（ Event ）和用戶（ User ）這兩個實體結(jié)合在一起就可以達到這一目的。下面分別介紹一下這兩個實體。
一個完整的事件（ Event ），包含如下的幾個關(guān)鍵因素：
Who：即參與這個事件的用戶是誰。
When：即這個事件發(fā)生的實際時間。
Where：即事件發(fā)生的地點。
How：即用戶從事這個事件的方式。這個概念就比較廣了，包括用戶使用的設(shè)備、使用的瀏覽器、使用的 App 版本、操作系統(tǒng)版本、進入的渠道、跳轉(zhuǎn)過來時的 referer 等。
What：以字段的方式記錄用戶所做的事件的具體內(nèi)容。不同的事件需要記錄的信息不同，下面給出一些典型的例子：
對于一個“購買”類型的事件，則可能需要記錄的字段有：商品名稱、商品類型、購買數(shù)量、購買金額、 付款方式等；
對于一個“搜索”類型的事件，則可能需要記錄的字段有：搜索關(guān)鍵詞、搜索類型等；
對于一個“點擊”類型的事件，則可能需要記錄的字段有：點擊 URL、點擊 title、點擊位置等；
對于一個“用戶注冊”類型的事件，則可能需要記錄的字段有：注冊渠道、注冊邀請碼等；
對于一個“用戶投訴”類型的事件，則可能需要記錄的字段有：投訴內(nèi)容、投訴對象、投訴渠道、投訴方式等；
對于一個“申請退貨”類型的事件，則可能需要記錄的字段有：退貨金額、退貨原因、退貨方式等。
描述事件的任意一個字段，都是一個事件屬性。應(yīng)該采集哪些事件，以及每個事件采集哪些事件屬性，完全取決于產(chǎn)品形態(tài)以及分析需求。
事件的設(shè)計
下面分別是 H5、APP 、小程序 端埋點的一個設(shè)計
基本規(guī)范
我們在設(shè)計的時候要注意一些基本的規(guī)范，例如我們屬性的命名，這樣才能可以更好的維護
預(yù)置屬性
設(shè)計原則
整個埋點的設(shè)計我們應(yīng)該遵循一下幾個原則，從而可以更好的維護和管理整個埋點系統(tǒng)
通用基礎(chǔ)事件
埋點時間能通用則不單獨埋點，不是說單獨埋點越多越好，我們應(yīng)該盡可能的從上層設(shè)計比較通用的事件，這樣方便復(fù)用。
重要事件
重要事件單獨處理，統(tǒng)一上報，保證采集的可用性
業(yè)務(wù)主流程
對于主要的業(yè)務(wù)流程，我們可以設(shè)計獨立的事件，從而方便更好的分析
自定義事件
其實所有的事件都是自定義事件，但是我們?yōu)槭裁催€是要區(qū)分自定義事件呢？
這是因為我們在一開始定義可很多通用的事件，所以我們的自定義事件是相對我們的通用事件而言的，但是我們怎么去定義一個自定義事件嗎，其實還要考慮到通用的屬性，因為這樣我們可以復(fù)用通用事件的一些屬性的定義，而不是完全重新設(shè)計一套東西。
舉例來說，一個電商產(chǎn)品可能包含如下事件：用戶注冊、瀏覽商品、添加購物車、支付訂單等，這里我們就那用戶注冊事件來說吧，其實它應(yīng)該是一個點擊事件，但是和點擊事件不一樣的是，我們需要添加一些新的屬性，所以我們可以在點擊事件的基礎(chǔ)上去添加屬性，有點類似編程語言的繼承，但是有的時候我們也可以去組合多個事件的屬性，其實這個是不常見的。
數(shù)據(jù)從生產(chǎn)到應(yīng)用的流程
業(yè)務(wù)流程
確定場景或目標(biāo)
確定一個場景，或者一個目標(biāo)。比如，我們發(fā)現(xiàn)很多用戶訪問了注冊頁面，但是最終完成注冊的很少。那么我們的目標(biāo)就是提高注冊轉(zhuǎn)化率，了解為什么用戶沒有完成注冊，是哪一個步驟擋住用戶了。
數(shù)據(jù)采集規(guī)劃
思考哪些數(shù)據(jù)我們需要了解，以幫助我們實現(xiàn)這個目標(biāo)。比如對于之前的目標(biāo)，我們需要拆解從進入注冊頁面到完成注冊的每一個步驟的數(shù)據(jù)，每一次輸入的數(shù)據(jù)，同時，還有完成或者未完成這些步驟的人的特征數(shù)據(jù)。
埋點采集數(shù)據(jù)
我們需要確定誰來負責(zé)收集數(shù)據(jù)，一般是工程師，有些企業(yè)有專門的數(shù)據(jù)工
程師，負責(zé)埋點采集數(shù)據(jù)。
數(shù)據(jù)評估和數(shù)據(jù)分析
給出優(yōu)化方案
發(fā)現(xiàn)問題后，怎么給出解決方案。比如，是否需要在設(shè)計上改進，或者是否是工程上的 bug。
實施優(yōu)化方案
誰負責(zé)實現(xiàn)解決方案，需要確定方案的實施責(zé)任人。
評估解決方案的效果
進行下一輪數(shù)據(jù)采集和分析，回到第一步繼續(xù)迭代。
知易行難。這整個流程里，第 2 步到第 4 步是關(guān)鍵。目前傳統(tǒng)的服務(wù)商
比如 Google Analytics、百度統(tǒng)計、友盟所采用的方式稱作 Capture 模
式。通過在客戶端埋下確定的點，采集相關(guān)數(shù)據(jù)到云端，最終在云端做呈
現(xiàn)。
開發(fā)流程
首先是基于一定的需求出發(fā)，然后產(chǎn)品/業(yè)務(wù)/分析師 對需求進行評審，主要就是需求同步，信息對齊，接下來就是埋點的開發(fā)與測試，埋點上線之后，數(shù)據(jù)同學(xué)開始進行數(shù)據(jù)需求開發(fā)在此過程中對埋點進行驗收，最后對數(shù)據(jù)需求進行交付
這個過程，需要專門投入專人去做這個事情，企業(yè)需要定制頂層的業(yè)務(wù)規(guī)范，上面的流程中有一個環(huán)節(jié)是沒有的，那就是埋點的下線。
數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析師不僅要考慮到業(yè)務(wù)需求和數(shù)據(jù)分析的工作，還要站在業(yè)務(wù)線數(shù)據(jù)體系和數(shù)據(jù)應(yīng)用負責(zé)人的角度，對埋點實施、管理、迭代、文檔、交付、支持進行掌控和維護
埋點管理系統(tǒng)設(shè)計
其實很多公司針對埋點會維護單獨的一個系統(tǒng)，這個系統(tǒng)主要維護了公司的全部埋點，其實你可以將其理解為和jira 類似的一套系統(tǒng)。下面我們看系統(tǒng)的核心
埋點列表
埋點注冊
埋點詳情
主要提供關(guān)于埋點的基本信息和統(tǒng)計信息
屬性管理
在埋點元數(shù)據(jù)中維護產(chǎn)品/業(yè)務(wù)層面的通用屬性，由數(shù)據(jù)團隊統(tǒng)一維護，所有可見的屬性，都可以在注冊/編輯埋點是添加屬性時搜索到。自定義屬性相對于通用屬性，是某個事件下特有的屬性，由業(yè)務(wù)方根據(jù)埋點方案維護
表設(shè)計/展示設(shè)計
| 字段名稱 | 備注 |
|---|---|
| 埋點ID | 表的自增ID 即可 |
| 埋點域 | 是APP 埋點還是web 埋點還是都是 |
| 埋點中文名稱 | |
| 埋點英文名稱 | |
| 埋點位置 | 這個位置我們要求使用圖片進行展示+文字說明 這里的圖片展示很重要，因為這樣很形象 |
| 埋點開發(fā)負責(zé)人 | 誰負責(zé)開發(fā)，很多時候會涉及到APP 和 Web 同時開發(fā) |
| 埋點業(yè)務(wù)負責(zé)人 | 誰提的需求 |
| 埋點數(shù)據(jù)負責(zé)人 | 誰負責(zé)該埋點對應(yīng)數(shù)據(jù)需求的處理，完成最終埋點的驗收 |
| 埋點業(yè)務(wù)含義 | 為什么埋點，關(guān)于埋點的具體數(shù)據(jù)計算邏輯是什么 |
| 埋點所屬事件 | 埋點所屬的事件,一般情況下我們都可以將一個埋點歸到我們已經(jīng)定義的埋點事件中去 如果是沒有合適的埋點事件，需要先定義事件，再定義該埋點 |
| 埋點通用屬性 | 一旦歸類到某個埋點事件下面，我們要求上報該事件的全部屬性 |
| 自定義屬性 | 該埋點的自定義屬性 |
| 埋點代碼git的PR | 是一個url,方便追蹤埋點代碼 |
| 埋點的Jira | 埋點需求的jira 跟蹤 |
| 埋點的狀態(tài) | 上線、測試、開發(fā)、下線、不可見等狀態(tài) 這里下線，指的是如果埋點的功能不要了或者其他的一些原因，我們需要對埋點進行及時下線 |
| 埋點的創(chuàng)建時間 | |
| 埋點的上線時間 | |
| 埋點的更新時間 |
主要的就是上面這些，我們需要做的就是將這些進行前端展示和前端錄入。
數(shù)據(jù)解析在哪里做
首先我們還是先看一下一個架構(gòu)圖，從而理解一下數(shù)據(jù)流轉(zhuǎn)，下面就是數(shù)據(jù)流轉(zhuǎn)的一個大致方向
最后面的maxcompute 是我們的計算引擎，你可以將其當(dāng)作是hive/spark ,具體是啥不重要，我們的數(shù)據(jù)通過前端(APP/web)前端上報，但是我們需要一個后端服務(wù)用來接收數(shù)據(jù)，然后后端獲取到數(shù)據(jù)之后進入消息隊列，最后我們再通過數(shù)據(jù)同步工具/數(shù)據(jù)消工具 把數(shù)據(jù)同步到大數(shù)據(jù)平臺，從而開始數(shù)據(jù)計算和建模。
這里有一個問題就是我們上報上來的數(shù)據(jù)可能是加密的，或者是我們的消息隊列是支持schema的(kafka 不支持)，這種情況下我們的數(shù)據(jù)要不要解析呢？直接說結(jié)論吧，最好不要解析，將解析的工作放在計算引擎中做，原因很多，下面陳述兩點：
后端服務(wù)在這里扮演的角色其實和消息隊列差不多，如果這個過程有邏輯越多，耦合就越高，可擴展性就差，例如前端上報的數(shù)據(jù)格式變了，或者是有其他的一些升級，這個時候后端也要做對應(yīng)的操作，然后重新發(fā)布。 后端服務(wù)如果在這里有大量的邏輯的話，對性能也不好，因為埋點的數(shù)據(jù)量很大，如果這里出現(xiàn)瓶頸的話，就會出現(xiàn)服務(wù)不穩(wěn)定，從而導(dǎo)致數(shù)據(jù)丟失
其實我看到有的人可能將IP 解析放在這里做，其實這也是不合理的，因為做IP 解析之前你需要先做數(shù)據(jù)解密、JSON 解析，然后數(shù)據(jù)推送到消息隊列之前還要做數(shù)據(jù)加密，可以看出這里的加解密想當(dāng)于白做了。
但是凡事也有例外，你也可以在后端這里做一些數(shù)據(jù)過濾，這樣可以減少后面數(shù)據(jù)處理的壓力，畢竟相比CPU ,網(wǎng)絡(luò)才是最慢的。
數(shù)據(jù)丟失如何處理
這里我們主要關(guān)注前端—>后端—> 消息隊列的這個環(huán)節(jié)的消息丟失，我們認為消息只要成功投遞就不會發(fā)生消息丟失，關(guān)于這一點很多消息隊列都可以保證，我們不做過多討論，可以參考: https://blog.csdn.net/king14bhhb/article/details/114624437
所以我們的消息丟失主要在后端這一塊，當(dāng)然這里丟失的原因，我們可以分為兩類
后端服務(wù)不穩(wěn)定，前端請求得不到影響，數(shù)據(jù)丟失，我們可以認為是前端數(shù)據(jù)丟失 消息隊列服務(wù)不穩(wěn)定，后端消息不能成功投遞，導(dǎo)致消息丟失，我們可以認為是后端數(shù)據(jù)丟失
可以看出來，這里后端是關(guān)鍵，所以我們采取的措施是日志補償?shù)姆绞剑簿褪菍τ谕哆f失敗的消息，我們可以將其追加到特定的日志文件，然后再將抽取到大數(shù)據(jù)計算平臺，這里有一個問題就是最好監(jiān)控，如果有大量的消息投遞失敗，我們一定要及時修復(fù)，防止日志文件過大。
對于后端服務(wù)的不穩(wěn)定導(dǎo)致前端數(shù)據(jù)投遞失敗，我們需要做的就是做好監(jiān)控和高可用，以及自動擴容，因為很多時候是因為流量急劇增加導(dǎo)致后端服務(wù)壓力太大，從而導(dǎo)致不穩(wěn)定。
總結(jié)
埋點是數(shù)據(jù)平臺很重要的一部分，如果只有業(yè)務(wù)數(shù)據(jù)沒有埋點數(shù)據(jù)，那么用戶在我們平臺上的一切行為對我們來說都是黑盒，所以我們想要做到精細化運營埋點是必須的。
由于埋點的數(shù)據(jù)從產(chǎn)生到使用鏈路很長，而且很復(fù)雜，這就需要我們做好設(shè)計和管理工作。
知識星球
其實知識星球我以前就建立了，當(dāng)時覺得自己沒有那么多的精力維護，不能很好的幫助有需要的同學(xué)們，所以一直沒有開放。最近很多同學(xué)私聊我學(xué)習(xí)路線，個人精力也是有限，并不能及時解答所有同學(xué)的問題。
通過調(diào)查，大部分同學(xué)表示愿意加入知識星球，我也覺得這樣讓大家的提問更加有層次和意義，而不是問一些比較膚淺和不太合適的問題，有問題也能自己先查詢一下，這樣更好的交流和解答疑問，提升時間利用率。
這里生成了50張5折優(yōu)惠券，先到先得，領(lǐng)完為止，越早加入越有優(yōu)勢（星球人數(shù)每增加50人，價格上漲10元）。