1. 數據采集面臨的安全與隱私挑戰不管是第三方分析工具，還是企業的第一方分析系統，在分析用戶行為時，通常都會選擇在客戶端（一般是安卓、iOS 和 Web 端）采集用戶的行為，然后經過打包、壓縮等一系列處理步驟，發送給服務端，再進行存儲和分析。

由于客戶端是在用戶自己的網絡環境下運行的，客戶端與服務端 之間的數據傳輸，是需要通過公網的，因此，也會帶來一系列數據采集上的安全與隱私的問題。

這些問題包括：·數據采集的完整性問題：因為在客戶端采集數據，為了保證盡量不影響用戶體驗，所以在采集數據時，一般不會同步發送數據，而是在本地先做緩存，然后 再整體壓縮、打包并在網絡好時一起通過公網進行傳輸。

如果客戶端一直網絡不好，傳輸失敗時，則會累計在本地，而本地緩存會有限額，或者緩存數據全部發送完 畢前，App 就被卸載則都會丟掉部分數據。

在 Web 端使用 JS 傳輸數據時，雖然是同步發送，不過由于公網傳輸的網絡問題，一般也會有 3% 到 7% 的數據丟失，并且基本難以避免。

·數據采集的隱私性問題：第三方可能會在傳輸過程中截獲傳輸的數據，從而拿到傳輸的這些用戶行為數據。

這些用戶數據都是體現用戶在客戶端的一些具體的用戶行為，蘊含著用戶的隱私。

·數據采集的準確性問題：第三方可能會在傳輸過程中偽造數據，從而讓后臺的分析結果不準確。

這種偽造可能是直接調用傳輸的 API，可能是在多個模擬器上運行 App，甚至可能是直接人工作在真實設備上操作 App，都會導致傳輸到服務端的數據不準確。

在這三大類問題中，第二類問題由于涉及到用戶隱私，所以一般會認為非常嚴重；第一類問題會影響最終分析結果的準確性，也應該盡量著力解決；而第三類 問題，對于惡意第三方來說相當于是一個“損人不利己”的事情，對于很多并不出名的創業公司來講一般也不會被人惡意針對，所以相對而言并沒有那么嚴重。

2. 常見解決方案分析

2.1 使用 HTTPS 作為傳輸協議HTTPS 是一種網絡安全傳輸協議，它經由超文本傳輸協議（HTTP）進行通信，但利用SSL/TLS來對數據包進行加密。

HTTPS開發的主要目的，是提供對網絡服務器的身份認證，保護交換數據的隱私與完整性。

簡單來說，不考慮太多技術細節，在有 HTTPS 作加密的情況下，可以認為，除了服務端與客戶端，在中間的傳輸環節，是拿不到也無法修改傳輸的內容的，因此，采用 HTTPS 作為傳輸協議，可以很好地防止數據被竊取，神策分析（Sensors Analytics）也提供了采用 HTTPS 傳輸數據的方案。

由于依然是在客戶端采集數據，依然是通過網絡傳輸數據，所以采用 HTTPS 作為傳輸協議并不能解決數據完整性的問題。

同時，HTTPS 也不能阻止數據的偽造，偽造者在客戶端是可以直接抓包拿到傳輸的內容的，從中獲取傳輸 API 與傳輸協議后，就可以直接調用 API 通過 HTTPS 傳輸偽造的數據了，更別說通過模擬器運行 App 或者直接用機器運行 App 來偽造數據了。

2.2 傳輸內容加密如前面所描述的那樣，HTTPS 是在傳輸環節進行傳輸協議加密的，并不能阻止惡意第三方在客戶端抓包獲取數據，從而獲取傳輸的內容與傳輸協議。

因此，自然可以考慮更進一步，不僅僅通過傳輸協議加密，對于傳輸的內容也進行加密。

這樣做的好處，是可以阻止惡意第三方拿到傳輸協議，從而沒有辦法通過直接調用 API 的方式來進行數據偽造，但是，對于模擬器運行 App 或者直接用機器運行 App 來偽造數據的手段，依然是無能為力。

同時，對傳輸內容進行加密，也不能改變是在客戶端采集數據，以及通過公網傳輸數據的本質，所以并不能解決數據完整性的 問題。

與此同時，由于需要對傳輸內容進行加密，所以數據采集的代碼和傳輸協議都不再能夠開源了，否則就很容易被惡意第三方破解加密方案。

對于公司內部的第 一方數據采集方案，并沒有問題，但是，如果是第三方分析工具，它的代碼如果不開源，一些對于安全與隱私比較敏感的客戶，可能就不敢集成了。

同時，由于傳輸 協議不開源，也大大降低了系統的開放性。

正因為這些原因，神策分析還是選擇了優先保證 SDK 和傳輸協議的開放性，以打消客戶集成 SDK 時的顧慮，所以并沒有采用傳輸內容加密的方案。

2.3 后端采集在后端采集數據，例如采集后端的日志，其實就是將數據采集的傳輸與加密交給了產品本身，認為產品本身的后端數據是可信的。

而后端采集數據到分析系統 中則是通過內網進行傳輸，這個階段不存在安全和隱私性問題。

同時，內網傳輸基本不會因為網絡原因丟失數據，所以傳輸的數據可以非常真實地反應用戶行為在系 統中的真實體現。

因此，基于后端采集的上述優勢，神策分析目前提供了 Java、PHP、Python、Ruby 等后端語言的 SDK，以及 LogAgent、BatchImporter、FormatImporter 等導入工具，支持在后端采集。

當然，對于模擬器運行 App 或者直接用機器運行 App 來偽造用戶行為，由于后端拿到的就是偽造后的數據，所以對于這種偽造行為，依然是無能為力。

2.4 采集后再 antispam對于之前提到的模擬器運行 App 或者直接用機器運行 App 來偽造用戶行為這一類技術手段，只能依托于在采集數據后，再進行 antisapm 清洗數據。

這些清洗有很多不同的策略，比較常見的有：·基于統計信息進行清洗：例如，把那些流量明顯大于平均值的設備或者 IP 的用戶行為過濾掉，把那些行為頻率明顯超過正常人限度的用戶行為過濾掉等；·基于用戶行為特征進行清洗：主要是用到一些機器學習的手段，通過對整體的用戶行為進行訓練，然后找到那些行為特征明顯異于常人的用戶；·基于設備真實性進行清洗：目前有一些第三方供應商提供了類似的方案，通過識別一個設備是一個真實的設備，還是一個模擬器，來解決虛擬機造假問題。

神策分析后面將會提供類似的 antispam 方案，并且將識別出來的用戶作弊概率直接作為一個用戶的 profile，以供使用者來選擇使用。

3. 一些題外話其實，除了數據采集這個環節以外，很多互聯網產品，都會面臨著網絡傳輸中的“安全”與“隱私”這兩類問題，而且也都會有所取舍與折衷。

我們以百度，這樣一個典型的互聯網產品為例，來看看它的網頁端是如何選擇來解決這些問題。

·首先，百度選擇了全站采用 HTTPS 進行加密，主要目的其實是為了避免第三方（如運營商等）篡改返回給用戶的網頁在其中加入第三方的廣告，當然，這一做法，也客觀保證了用戶的操作不被第三方竊取；·其次，對于通過 Spider 等非人工的訪問方式來抓取搜索結果的行為，則并沒有在訪問時就進行封禁等處理，而是在進行統計時再進行復雜的流量清洗等 antispam 手段，以獲得準確的流量，這主要是為了在保持用戶體驗，避免因為誤封禁而影響正常用戶的訪問，同時，也可以在后處理時可以加入復雜的策略保證最好的清洗效 果；·第三，對于使用某些非法手段來對廣告點擊進行造假的行為，由于涉及到經濟隱私，相比抓取搜索結果危害要更大，所以雖然都是采用后處理 antispam 的方式，但是時效性會更好，一般是會先做完 antispam，然后再扣費，從而避免作弊點擊導致廣告費用扣光，影響點擊。

廣告點擊的 antispam 是百度的核心策略與競爭優勢，也是投入很多成本進行研發與維護的領域。