本文根據(jù)神策數(shù)據(jù)聯(lián)合創(chuàng)始人 & CTO 曹犟發(fā)表的《數(shù)據(jù)治理中的一些挑戰(zhàn)與應(yīng)用》主題演講整理而成。

本文將為你重點(diǎn)介紹：

• 數(shù)據(jù)治理的概念與重要性
• 數(shù)據(jù)治理面臨的挑戰(zhàn)
• 數(shù)據(jù)治理與組織架構(gòu)
• 數(shù)據(jù)治理中的應(yīng)對(duì)

許多大數(shù)據(jù)公司在過(guò)去一段時(shí)間都得到了較好的發(fā)展，究其原因是因?yàn)榍》陮Ｗ⒂跇I(yè)務(wù)流的信息化建設(shè)正在向數(shù)據(jù)化轉(zhuǎn)型。

但在很多時(shí)候，數(shù)據(jù)其實(shí)還只是 IT 化的“副產(chǎn)品”，早期的工作思路仍然圍繞如何將業(yè)務(wù) IT 化，而數(shù)據(jù)只是這個(gè)過(guò)程中自然而然產(chǎn)生的結(jié)果，即所謂的“副產(chǎn)品”。

由于在數(shù)據(jù)生產(chǎn)的過(guò)程中并未做到足夠重視，數(shù)據(jù)質(zhì)量與可靠性則很難得到保證，這也是數(shù)據(jù)治理在現(xiàn)在得以被重視的重要原因。

在業(yè)務(wù) IT 化的過(guò)程中，企業(yè)通過(guò)第三方廠商、自研等方式構(gòu)建多種數(shù)據(jù)系統(tǒng)，采用多種系統(tǒng)中的數(shù)據(jù)化治理，是實(shí)現(xiàn)數(shù)據(jù)效能、數(shù)據(jù)驅(qū)動(dòng)業(yè)務(wù)的關(guān)鍵步驟。

早期，企業(yè)用信息技術(shù)去構(gòu)建業(yè)務(wù)流，而現(xiàn)在，我們?cè)噲D用信息技術(shù)，特別是互聯(lián)網(wǎng)行業(yè)中的一些大數(shù)據(jù)處理以及分布式處理技術(shù)構(gòu)建數(shù)據(jù)流，但在構(gòu)建過(guò)程中，過(guò)多強(qiáng)調(diào)技術(shù)本身而忽視了對(duì)數(shù)據(jù)的治理。

數(shù)據(jù)治理是整體性問(wèn)題，并非僅是技術(shù)問(wèn)題，市面上數(shù)不勝數(shù)的商業(yè)組件可以解決如何對(duì)數(shù)據(jù)進(jìn)行存儲(chǔ)、查詢等問(wèn)題，但是在實(shí)際的業(yè)務(wù)情況下對(duì)于數(shù)據(jù)治理這樣一個(gè)系統(tǒng)性工程，目前卻并無(wú)現(xiàn)成的產(chǎn)品或技術(shù)可以直接解決。

我們可以嘗試用數(shù)據(jù)治理的角度來(lái)解讀上圖。

構(gòu)建數(shù)據(jù)流的過(guò)程，很大意義上是為了解決分布在 IT 系統(tǒng)里各個(gè)不同子系統(tǒng)之間的數(shù)據(jù)孤島問(wèn)題，用一條完整的數(shù)據(jù)流將不同子系統(tǒng)之間的數(shù)據(jù)孤島打通，同時(shí)應(yīng)用于不同的應(yīng)用場(chǎng)景，這個(gè)打通的過(guò)程，就是某種意義上的數(shù)據(jù)治理。這也反映了我之前尤為推崇的一個(gè)觀點(diǎn)——構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)本身就是一個(gè)數(shù)據(jù)治理的過(guò)程。

另外，對(duì)于數(shù)據(jù)的本質(zhì)，我一直推崇如下兩個(gè)定義：第一“信息是用來(lái)消除不確定性的”，第二“大數(shù)據(jù)的本質(zhì)，就是用信息來(lái)消除不確定性”。

同樣，對(duì)于數(shù)據(jù)驅(qū)動(dòng)在業(yè)務(wù)決策和產(chǎn)品智能兩大方面的應(yīng)用，也都將建立在數(shù)據(jù)治理的基礎(chǔ)上才有意義。

一、什么是數(shù)據(jù)治理？

數(shù)據(jù)治理的本質(zhì)是組織對(duì)數(shù)據(jù)的可用性、完整性和安全性的整體管理。

1. 數(shù)據(jù)治理的本質(zhì)

可用性指數(shù)據(jù)可用、可信且有質(zhì)量保證，不會(huì)因?yàn)榉治鼋Y(jié)果的準(zhǔn)確性造成偏差，從業(yè)者可以放心地根據(jù)數(shù)據(jù)結(jié)果做業(yè)務(wù)決策；完整性分為兩個(gè)方面，一方面指數(shù)據(jù)需覆蓋各類數(shù)據(jù)應(yīng)用的需要，另一方面指不會(huì)因?yàn)閿?shù)據(jù)治理沒(méi)有到位而造成數(shù)據(jù)資產(chǎn)的流失，也即影響數(shù)據(jù)資產(chǎn)的積累，這也是神策數(shù)據(jù)在創(chuàng)業(yè)伊始便開(kāi)展私有化部署的原因；安全性指治理和分享過(guò)程需安全可控，不侵犯用戶隱私，且不會(huì)給組織留下安全隱患。

2. 數(shù)據(jù)治理的重要性

數(shù)據(jù)治理是所有數(shù)據(jù)應(yīng)用的根基，數(shù)據(jù)治理的好壞直接影響所有數(shù)據(jù)應(yīng)用的價(jià)值。

無(wú)論是基于數(shù)據(jù)看報(bào)表，還是做交互式的多維分析，還是做更復(fù)雜的個(gè)性化推薦，所有的數(shù)據(jù)應(yīng)用都需要有一個(gè)良好的數(shù)據(jù)治理結(jié)果。

神策本身就擁有一款推薦產(chǎn)品——神策智能推薦，通過(guò)這款產(chǎn)品的實(shí)踐，我們發(fā)現(xiàn)，它的實(shí)施周期相比其它幾個(gè)產(chǎn)品普遍偏長(zhǎng)，這也是因?yàn)閭€(gè)性化推薦對(duì)于數(shù)據(jù)的質(zhì)量和準(zhǔn)確性要求相對(duì)更高。

簡(jiǎn)而言之，數(shù)據(jù)應(yīng)用做得越深入，所需數(shù)據(jù)就會(huì)更多，對(duì)數(shù)據(jù)質(zhì)量也會(huì)有更高的要求。

數(shù)據(jù)治理是組織數(shù)據(jù)資產(chǎn)沉淀的基礎(chǔ)，數(shù)據(jù)治理的好壞直接決定了組織的數(shù)據(jù)資產(chǎn)能否得到沉淀，能否充分地發(fā)揮價(jià)值。

經(jīng)常會(huì)有客戶主動(dòng)來(lái)詢問(wèn)：

“領(lǐng)導(dǎo)說(shuō)我們要做一個(gè)數(shù)據(jù)中臺(tái)沉淀數(shù)據(jù)，但不知具體原因，亦不清楚搭建中臺(tái)的具體目的，可能要等搭建之后尋找數(shù)據(jù)價(jià)值時(shí)，再去探索具體應(yīng)用?！?/p>

個(gè)人認(rèn)為，在經(jīng)費(fèi)條件允許的情況下，當(dāng)然可以將企業(yè)的所有數(shù)據(jù)整合在一起，通過(guò)良好的權(quán)限管控，充分的共享，聚合所有的業(yè)務(wù)部門(mén)一起去探索數(shù)據(jù)的應(yīng)用，因?yàn)閿?shù)據(jù)中臺(tái)本身就承載著組織內(nèi)部所有數(shù)據(jù)的整合分享角色。

二、數(shù)據(jù)治理面臨的挑戰(zhàn)

本部分的內(nèi)容將數(shù)據(jù)治理面臨的挑戰(zhàn)分為兩類，一類因“技術(shù)”而起，一類因“人”而起。

由客觀的技術(shù)問(wèn)題對(duì)數(shù)據(jù)治理帶來(lái)的挑戰(zhàn)普遍較好解決，比如如何采集數(shù)據(jù)、如何存儲(chǔ)數(shù)據(jù)等，都可通過(guò)更先進(jìn)的工具、更新的技術(shù)等方式解決。

而由人或組織架構(gòu)帶來(lái)的問(wèn)題相對(duì)復(fù)雜，它的背后包含的是企業(yè)在文化、流程上的問(wèn)題，可以通過(guò)以下實(shí)例說(shuō)明。

1. 多業(yè)務(wù)系統(tǒng)多數(shù)據(jù)源的整合挑戰(zhàn)

企業(yè)想要做的數(shù)據(jù)應(yīng)用越多，所需的數(shù)據(jù)就會(huì)越多，所要去獲取的數(shù)據(jù)源也會(huì)增多，而相應(yīng)的數(shù)據(jù)處理也會(huì)越多，這是一個(gè)極為顯而易見(jiàn)的問(wèn)題。

對(duì)于神策數(shù)據(jù)而言，我們?cè)跀?shù)據(jù)應(yīng)用方面相對(duì)“單純”，主要針對(duì)用戶行為領(lǐng)域，采集用戶行為數(shù)據(jù)，從客戶端、服務(wù)端、數(shù)據(jù)庫(kù)等做對(duì)接。

但即使是這樣一個(gè)限定特殊領(lǐng)域的應(yīng)用，我們?cè)谡隙喾矫鏀?shù)據(jù)源上也會(huì)碰到非常多的挑戰(zhàn)，可想而知在面對(duì)多業(yè)務(wù)系統(tǒng)多數(shù)據(jù)源的情況下將更加困難。

2. 數(shù)據(jù)采集技術(shù)上的挑戰(zhàn)

近年來(lái)，許多公司都在嘗試將自己的業(yè)務(wù)線上化，都需要通過(guò)數(shù)據(jù)對(duì)用戶進(jìn)行分析與運(yùn)營(yíng)，如何精準(zhǔn)采集可用的用戶數(shù)據(jù)以及其他相關(guān)數(shù)據(jù)，都將是數(shù)據(jù)采集在技術(shù)層面上面臨的挑戰(zhàn)。

3. 用戶隱私與安全挑戰(zhàn)

用戶隱私與安全不僅是對(duì)技術(shù)挑戰(zhàn)，更多的是一種意識(shí)上的挑戰(zhàn)。企業(yè)需要準(zhǔn)確把控?cái)?shù)據(jù)采集的紅線，比如針對(duì)歐盟范圍內(nèi)的國(guó)際業(yè)務(wù)，就需要參考 GDPR 的相關(guān)規(guī)范。

在國(guó)內(nèi)，很多銀行券商等企業(yè)也同樣擁有一套完善的數(shù)據(jù)合規(guī)要求，甚至已經(jīng)細(xì)化到“某個(gè)特定字段對(duì)于某一個(gè)特定人可看但不可下載”的程度，這些都是需要在進(jìn)行數(shù)據(jù)治理時(shí)考慮的因素。另外，如果需要在公網(wǎng)傳輸交換數(shù)據(jù)，也同樣需要思考數(shù)據(jù)如何防止竊取和偽造的問(wèn)題

4. 組織架構(gòu)與部門(mén)隔閡帶來(lái)的配合

部分組織在數(shù)據(jù)治理的過(guò)程中速度過(guò)慢，成效不好，其中一個(gè)很重要的原因是權(quán)責(zé)、部門(mén)配合等方面存在問(wèn)題。很多情況下，生產(chǎn)數(shù)據(jù)、使用數(shù)據(jù)、分析數(shù)據(jù)的工作人員分布在不同的職能線與部門(mén)，角色不同，立場(chǎng)也不同，這些客觀存在的影響因素都會(huì)影響整個(gè)數(shù)據(jù)治理的最終結(jié)果。

5.業(yè)務(wù)持續(xù)迭代中帶來(lái)的挑戰(zhàn)

在互聯(lián)網(wǎng)行業(yè)中，尤其是業(yè)務(wù)迭代較為迅速的團(tuán)隊(duì)里，通常存在“1.0 版本的數(shù)據(jù)質(zhì)量最優(yōu)，1.1 版本不行，2.0 版本完全不可用”的說(shuō)法，說(shuō)明第一次做數(shù)據(jù)治理時(shí)，極重視數(shù)據(jù)質(zhì)量，會(huì)有完善的流程來(lái)保證埋點(diǎn)的準(zhǔn)確性，本身也沒(méi)有太多的包袱；而在后續(xù)的產(chǎn)品迭代中，如果流程和標(biāo)準(zhǔn)的迭代相對(duì)滯后，整個(gè)數(shù)據(jù)治理的結(jié)果也會(huì)隨著受影響，最終導(dǎo)致整個(gè)數(shù)據(jù)質(zhì)量低劣，直至所謂的“完全不可用”。

下面舉兩個(gè)具體實(shí)例說(shuō)明。

實(shí)例 1.

某公司的業(yè)務(wù)部門(mén)向第三方數(shù)據(jù)分析平臺(tái)提出數(shù)據(jù)需求，該公司內(nèi)部有多個(gè) App 頻道，每個(gè)頻道隸屬于一個(gè)單獨(dú)的部門(mén)，而第三方數(shù)據(jù)分析平臺(tái)在埋點(diǎn)采集階段需要不同部門(mén)的團(tuán)隊(duì)相互配合。由于缺乏統(tǒng)一各部門(mén)需求與任務(wù)的統(tǒng)籌角色，實(shí)施過(guò)程中很難清楚劃分相關(guān)責(zé)任，再加上管理、測(cè)試等工具的缺失，最終導(dǎo)致每次發(fā)版都會(huì)發(fā)生埋點(diǎn)丟失和報(bào)錯(cuò)。

實(shí)例 2.

某企業(yè)的所有用戶相關(guān)數(shù)據(jù)分散在不同的系統(tǒng)里面，試圖通過(guò)第三方數(shù)據(jù)分析平臺(tái)整合統(tǒng)一的用戶標(biāo)簽數(shù)據(jù)系統(tǒng)。然而在收集數(shù)據(jù)的過(guò)程中，每跨一次部門(mén)就需要提一次全套的審批流程，好不容易收集齊各部門(mén)各系統(tǒng)中的數(shù)據(jù)之后，卻發(fā)現(xiàn)數(shù)據(jù)統(tǒng)計(jì)口徑不一致，無(wú)法得到一個(gè)公司統(tǒng)一的用戶標(biāo)簽數(shù)據(jù)。

三、數(shù)據(jù)治理與組織架構(gòu)

上述內(nèi)容已經(jīng)提到關(guān)于組織架構(gòu)的內(nèi)容，因其重要性將在本部分單獨(dú)說(shuō)明。

1. 數(shù)據(jù)治理是一個(gè)動(dòng)態(tài)的過(guò)程

數(shù)據(jù)治理實(shí)際反映的是組織問(wèn)題、文化問(wèn)題，這也是許多公司為了明確權(quán)責(zé)劃分而建立數(shù)據(jù)治理委員會(huì)的原因。同時(shí)，還需要明確的程序與執(zhí)行程序的計(jì)劃，明確的程序指對(duì)數(shù)據(jù)進(jìn)行治理所需經(jīng)歷的階段、問(wèn)題有明細(xì)的了解，執(zhí)行程序的計(jì)劃指每一步需要解決哪些問(wèn)題。當(dāng)公司的主流業(yè)務(wù)發(fā)生變化時(shí)，組織架構(gòu)會(huì)隨之改變，接而帶來(lái)數(shù)據(jù)治理層面的變更，所以，數(shù)據(jù)治理是一個(gè)動(dòng)態(tài)的過(guò)程，伴隨整個(gè)業(yè)務(wù)變更與組織架構(gòu)變更。

2. 數(shù)據(jù)治理中的兩個(gè)核心角色

• 第一，數(shù)據(jù)使用者，通常集中在產(chǎn)品經(jīng)理、數(shù)據(jù)分析師、營(yíng)銷(xiāo)經(jīng)理、運(yùn)營(yíng)經(jīng)理等崗位，有查看報(bào)表、數(shù)據(jù)分析、用戶畫(huà)像、用戶運(yùn)營(yíng)等需求，他們屬于數(shù)據(jù)治理的受益者。
• 第二，數(shù)據(jù)生產(chǎn)者，通常集中在前端開(kāi)發(fā)、后端開(kāi)發(fā)、數(shù)據(jù)工程師、ETL 工程師，有埋點(diǎn)、打日志、做數(shù)據(jù) ETL 的需求，他們屬于數(shù)據(jù)治理的付出者，可能看不到直接收益，反而增加工作負(fù)擔(dān)。

由于數(shù)據(jù)使用者屬于數(shù)據(jù)治理中受益的一方，多數(shù)情況下需由其來(lái)推動(dòng)數(shù)據(jù)治理任務(wù)進(jìn)行。

在神策數(shù)據(jù)的具體實(shí)踐中，我們非常強(qiáng)調(diào)對(duì)客戶接口人，通常情況下也就是數(shù)據(jù)使用者的培訓(xùn)，由他去推動(dòng)整個(gè)流程，去了解數(shù)據(jù)生產(chǎn)者的實(shí)際情況，從而讓數(shù)據(jù)治理工作更好地進(jìn)行。

四、數(shù)據(jù)治理中的應(yīng)對(duì)

首先，數(shù)據(jù)治理的核心認(rèn)識(shí)是，數(shù)據(jù)治理是一個(gè)持續(xù)并且長(zhǎng)久的一個(gè)過(guò)程，不同的產(chǎn)品可以解決比如采集、傳輸?shù)葦?shù)據(jù)治理層面上的不同問(wèn)題，但并不存在一款所謂的“數(shù)據(jù)治理產(chǎn)品”，可以用來(lái)解決所有問(wèn)題。

其次，數(shù)據(jù)治理的整體方法論是“從應(yīng)用倒推”。先確定數(shù)據(jù)應(yīng)用、數(shù)據(jù)資產(chǎn)的需求，接著確定需要哪些數(shù)據(jù)，之后確定需要從哪種數(shù)據(jù)源獲取數(shù)據(jù)，最終確定具體的數(shù)據(jù)治理方案。

神策憑借近年在實(shí)際業(yè)務(wù)中的經(jīng)驗(yàn)，圍繞用戶行為分析領(lǐng)域，總結(jié)出一套數(shù)據(jù)治理方法論。

• 第一步，確定分析需求。通過(guò)了解數(shù)據(jù)使用者需要看哪些指標(biāo)、用在哪些場(chǎng)景、使用哪些分析模型等方面來(lái)了解具體的數(shù)據(jù)使用需求，完成需求梳理。
• 第二步，映射數(shù)據(jù)模型。在該步驟需確定采集的事件和屬性，并完成事件設(shè)計(jì)。
• 第三步，確定數(shù)據(jù)采集技術(shù)方案。根據(jù)要采的事件和屬性，結(jié)合現(xiàn)有實(shí)際業(yè)務(wù)系統(tǒng)，去確定到底要從何種系統(tǒng)里以何種技術(shù)方案采集數(shù)據(jù)。
• 第四步，數(shù)據(jù)采集與集成。這一步就是指具體的開(kāi)發(fā)、集成工作，包括完成相應(yīng)的 SDK 集成、數(shù)據(jù)采集工具的開(kāi)發(fā)、數(shù)據(jù) ETL 開(kāi)發(fā)等。
• 第五步，數(shù)據(jù)校驗(yàn)和上線。這一步中需要使用必要的測(cè)試工具、利用埋點(diǎn)管理平臺(tái)做數(shù)據(jù)對(duì)比等。

下面，舉例說(shuō)明數(shù)據(jù)治理的三大原則：

數(shù)據(jù)治理原則 1：不要先污染后治理，要從源頭控制

在創(chuàng)立神策數(shù)據(jù)之前，我們?cè)L(zhǎng)期參與百度的日志數(shù)據(jù)相關(guān)的工作。在最開(kāi)始的階段，所謂的日志處理就是通過(guò)中控機(jī)器，從不同的業(yè)務(wù)系統(tǒng)里下載文本日志，跑完腳本后生成報(bào)表，再通過(guò)郵件的形式分發(fā)。

2008 年，團(tuán)隊(duì)解決了之前方案中的技術(shù)架構(gòu)的問(wèn)題，把以前的單機(jī)系統(tǒng)變成了分布式系統(tǒng)，提高了整體性能與計(jì)算效率，用分布式的方式下載日志，用分布式的方式來(lái)計(jì)算報(bào)表。但是，我們本質(zhì)上只提供了一個(gè)計(jì)算的調(diào)度平臺(tái)。就數(shù)據(jù)本身而言，沒(méi)有人知道這些海量數(shù)據(jù)其中的細(xì)節(jié)，數(shù)據(jù)沒(méi)有得到充分的復(fù)用，造成了許多計(jì)算資源的浪費(fèi)。所以，這部分的工作其實(shí)只是解決了一個(gè)技術(shù)問(wèn)題，但并沒(méi)有解決任何數(shù)據(jù)治理方面的問(wèn)題。

意識(shí)到數(shù)據(jù)治理的問(wèn)題之后，團(tuán)隊(duì)中開(kāi)始了百度用戶數(shù)據(jù)倉(cāng)庫(kù)的構(gòu)建工作。有工程師每天將文本日志用程序轉(zhuǎn)成結(jié)構(gòu)化日志，并在進(jìn)行必要的數(shù)據(jù)清洗、Union、Join 等 ETL 的工作之后，將這些結(jié)構(gòu)化日志統(tǒng)一映射到一張大表（今天 event 模型前身），并對(duì)外提供集中訪問(wèn)。

但隨著產(chǎn)品線不斷增多，入庫(kù)周期變得更長(zhǎng)，到后期，每增加一條產(chǎn)品線，都需要付出至少一周時(shí)間去解決。同時(shí)，由于數(shù)據(jù)在產(chǎn)生后需要做 ETL，從產(chǎn)生到傳輸?shù)浇y(tǒng)一的 Hadoop 集群需要時(shí)間， ETL 的計(jì)算也同樣需要時(shí)間，即使在最佳情況下也只能保證半小時(shí)的時(shí)效性。

這是一個(gè)典型的數(shù)據(jù)“先污染后治理”的例子，不僅在治理上需要付出更多的代價(jià)和成本，數(shù)據(jù)本身的可用性和時(shí)效性也會(huì)受到影響。

之后，我們嘗試通過(guò)推行全百度統(tǒng)一的 Logging 平臺(tái)，從打日志開(kāi)始就保證數(shù)據(jù)的正確性，并且直接將數(shù)據(jù)傳輸?shù)椒植际郊荷弦员ＷC數(shù)據(jù)的可用，這就是從源頭來(lái)治理數(shù)據(jù)的思路。

在創(chuàng)立神策之后，我們就充分吸取了這些教訓(xùn)，通過(guò) SDK 或者其他工具去嚴(yán)格控制數(shù)據(jù)埋點(diǎn)格式及數(shù)據(jù)模型，盡最大努力減少 ETL 的代價(jià)，從而保證查詢時(shí)效性與導(dǎo)入時(shí)效性。所以，數(shù)據(jù)治理要從源頭開(kāi)始，不要先污染后治理。

數(shù)據(jù)治理原則 2：數(shù)據(jù)治理的過(guò)程要貫穿到整個(gè)業(yè)務(wù)迭代的過(guò)程中

以軟件開(kāi)發(fā)流程為例。

首先，在產(chǎn)品需求階段，同樣需要去明確數(shù)據(jù)需求。在具體設(shè)計(jì)階段，完成產(chǎn)品交互系統(tǒng)架構(gòu)變更的同時(shí)，去確定要加哪些日志、字段等。

在實(shí)際開(kāi)發(fā)階段，完成相應(yīng)的代碼開(kāi)發(fā)、日志變更，單元測(cè)試應(yīng)包括相應(yīng)的日志變更部分，并進(jìn)行日志審計(jì)，不要將埋點(diǎn)當(dāng)成一個(gè)單獨(dú)的開(kāi)發(fā)任務(wù)，而是伴隨的過(guò)程。在

測(cè)試階段，當(dāng)測(cè)試整體性能的正確性的同時(shí)，測(cè)試數(shù)據(jù)、日志的正確性，確保功能符合預(yù)期、日志打印正確，可以滿足分需求。

在上線階段，要實(shí)際查看上線的埋點(diǎn)、日志是否正確，并對(duì)功能進(jìn)行確認(rèn)。

最后，在項(xiàng)目總結(jié)階段，用數(shù)據(jù)說(shuō)明轉(zhuǎn)化率變化、流程優(yōu)化情況，對(duì)功能完成程度的總結(jié)，嘗試真正地用數(shù)據(jù)說(shuō)話。

數(shù)據(jù)治理原則 3：以產(chǎn)品化、組件化的思路來(lái)解決，不能依賴于人工

以產(chǎn)品的方式解決客戶端數(shù)據(jù)采集問(wèn)題。

神策的開(kāi)源 SDK 被許多業(yè)界同仁參考學(xué)習(xí)，究其原因是因?yàn)樗卯a(chǎn)品的方式解決客戶端數(shù)據(jù)采集問(wèn)題的思維，無(wú)論是電商、社交、金融、游戲，還是哪一種產(chǎn)品，都會(huì)在客戶端采集用戶數(shù)據(jù)時(shí)面臨匿名 ID 生成、基礎(chǔ)屬性采集、數(shù)據(jù)打包壓縮加密、本地緩存、網(wǎng)絡(luò)傳輸、時(shí)間校準(zhǔn)、根據(jù)數(shù)據(jù)模型限定了采集數(shù)據(jù)的 Schema、通過(guò)全埋點(diǎn)等方式提供了對(duì)常見(jiàn)數(shù)據(jù)的自動(dòng)采集功能、結(jié)合后端提供了對(duì)于采集端調(diào)試功能等場(chǎng)景，所以，可以用產(chǎn)品思維來(lái)解決的問(wèn)題，不依賴人工。

作者：曹犟，神策數(shù)據(jù)聯(lián)合創(chuàng)始人 & CTO

本文由 @神策數(shù)據(jù) 發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自Unsplash，基于CC0協(xié)議