1.數(shù)據(jù)采集的完整性問(wèn)題：因?yàn)樵诳蛻舳瞬杉瘮?shù)據(jù)，為了保證盡量不影響用戶體驗(yàn)，所以在采集數(shù)據(jù)時(shí)，一般不會(huì)同步發(fā)送數(shù)據(jù)，而是在本地先做緩存，然后再整體壓縮、打包并在網(wǎng)絡(luò)好時(shí)一起通過(guò)公網(wǎng)進(jìn)行傳輸。如果客戶端一直網(wǎng)絡(luò)不好，傳輸失敗時(shí)，則會(huì)累計(jì)在本地，而本地緩存會(huì)有限額，或者緩存數(shù)據(jù)全部發(fā)送完畢前，App 就被卸載則都會(huì)丟掉部分?jǐn)?shù)據(jù)。在 Web 端使用 JS 傳輸數(shù)據(jù)時(shí)，雖然是同步發(fā)送，不過(guò)由于公網(wǎng)傳輸?shù)木W(wǎng)絡(luò)問(wèn)題，一般也會(huì)有 3% 到 7% 的數(shù)據(jù)丟失，并且基本難以避免。
2.數(shù)據(jù)采集的隱私性問(wèn)題：第三方可能會(huì)在傳輸過(guò)程中截獲傳輸?shù)臄?shù)據(jù)，從而拿到傳輸?shù)倪@些用戶行為數(shù)據(jù)。這些用戶數(shù)據(jù)都是體現(xiàn)用戶在客戶端的一些具體的用戶行為，蘊(yùn)含著用戶的隱私。
3.數(shù)據(jù)采集的準(zhǔn)確性問(wèn)題：第三方可能會(huì)在傳輸過(guò)程中偽造數(shù)據(jù)，從而讓后臺(tái)的分析結(jié)果不準(zhǔn)確。這種偽造可能是直接調(diào)用傳輸?shù)?API，可能是在多個(gè)模擬器上運(yùn)行 App，甚至可能是直接人工作在真實(shí)設(shè)備上操作 App，都會(huì)導(dǎo)致傳輸?shù)椒⻊?wù)端的數(shù)據(jù)不準(zhǔn)確。
在這三大類(lèi)問(wèn)題中，第二類(lèi)問(wèn)題由于涉及到用戶隱私，所以一般會(huì)認(rèn)為非常嚴(yán)重；第一類(lèi)問(wèn)題會(huì)影響最終分析結(jié)果的準(zhǔn)確性，也應(yīng)該盡量著力解決；而第三類(lèi)問(wèn)題，對(duì)于惡意第三方來(lái)說(shuō)相當(dāng)于是一個(gè)“損人不利己”的事情，對(duì)于很多并不出名的創(chuàng)業(yè)公司來(lái)講一般也不會(huì)被人惡意針對(duì)，所以相對(duì)而言并沒(méi)有那么嚴(yán)重。
2. 常見(jiàn)解決方案分析
2.1 使用 HTTPS 作為傳輸協(xié)議
HTTPS 是一種網(wǎng)絡(luò)安全傳輸協(xié)議，它經(jīng)由超文本傳輸協(xié)議(HTTP)進(jìn)行通信，但利用SSL/TLS來(lái)對(duì)數(shù)據(jù)包進(jìn)行加密。HTTPS開(kāi)發(fā)的主要目的，是提供對(duì)網(wǎng)絡(luò)服務(wù)器的身份認(rèn)證，保護(hù)交換數(shù)據(jù)的隱私與完整性。
簡(jiǎn)單來(lái)說(shuō)，不考慮太多技術(shù)細(xì)節(jié)，在有 HTTPS 作加密的情況下，可以認(rèn)為，除了服務(wù)端與客戶端，在中間的傳輸環(huán)節(jié)，是拿不到也無(wú)法修改傳輸?shù)膬?nèi)容的，因此，采用 HTTPS 作為傳輸協(xié)議，可以很好地防止數(shù)據(jù)被竊取，神策分析(Sensors Analytics)也提供了采用 HTTPS 傳輸數(shù)據(jù)的方案。
由于依然是在客戶端采集數(shù)據(jù)，依然是通過(guò)網(wǎng)絡(luò)傳輸數(shù)據(jù)，所以采用 HTTPS 作為傳輸協(xié)議并不能解決數(shù)據(jù)完整性的問(wèn)題。
同時(shí)，HTTPS 也不能阻止數(shù)據(jù)的偽造，偽造者在客戶端是可以直接抓包拿到傳輸?shù)膬?nèi)容的，從中獲取傳輸 API 與傳輸協(xié)議后，就可以直接調(diào)用 API 通過(guò) HTTPS 傳輸偽造的數(shù)據(jù)了，更別說(shuō)通過(guò)模擬器運(yùn)行 App 或者直接用機(jī)器運(yùn)行 App 來(lái)偽造數(shù)據(jù)了。
2.2 傳輸內(nèi)容加密
如前面所描述的那樣，HTTPS 是在傳輸環(huán)節(jié)進(jìn)行傳輸協(xié)議加密的，并不能阻止惡意第三方在客戶端抓包獲取數(shù)據(jù)，從而獲取傳輸?shù)膬?nèi)容與傳輸協(xié)議。因此，自然可以考慮更進(jìn)一步，不僅僅通過(guò)傳輸協(xié)議加密，對(duì)于傳輸?shù)膬?nèi)容也進(jìn)行加密。
這樣做的好處，是可以阻止惡意第三方拿到傳輸協(xié)議，從而沒(méi)有辦法通過(guò)直接調(diào)用 API 的方式來(lái)進(jìn)行數(shù)據(jù)偽造，但是，對(duì)于模擬器運(yùn)行 App 或者直接用機(jī)器運(yùn)行 App 來(lái)偽造數(shù)據(jù)的手段，依然是無(wú)能為力。同時(shí)，對(duì)傳輸內(nèi)容進(jìn)行加密，也不能改變是在客戶端采集數(shù)據(jù)，以及通過(guò)公網(wǎng)傳輸數(shù)據(jù)的本質(zhì)，所以并不能解決數(shù)據(jù)完整性的問(wèn)題。
與此同時(shí)，由于需要對(duì)傳輸內(nèi)容進(jìn)行加密，所以數(shù)據(jù)采集的代碼和傳輸協(xié)議都不再能夠開(kāi)源了，否則就很容易被惡意第三方破解加密方案。對(duì)于公司內(nèi)部的第一方數(shù)據(jù)采集方案，并沒(méi)有問(wèn)題，但是，如果是第三方分析工具，它的代碼如果不開(kāi)源，一些對(duì)于安全與隱私比較敏感的客戶，可能就不敢集成了。同時(shí)，由于傳輸協(xié)議不開(kāi)源，也大大降低了系統(tǒng)的開(kāi)放性。正因?yàn)檫@些原因，神策分析還是選擇了優(yōu)先保證 SDK 和傳輸協(xié)議的開(kāi)放性，以打消客戶集成 SDK 時(shí)的顧慮，所以并沒(méi)有采用傳輸內(nèi)容加密的方案。
2.3 后端采集
在后端采集數(shù)據(jù)，例如采集后端的日志，其實(shí)就是將數(shù)據(jù)采集的傳輸與加密交給了產(chǎn)品本身，認(rèn)為產(chǎn)品本身的后端數(shù)據(jù)是可信的。而后端采集數(shù)據(jù)到分析系統(tǒng)中則是通過(guò)內(nèi)網(wǎng)進(jìn)行傳輸，這個(gè)階段不存在安全和隱私性問(wèn)題。同時(shí)，內(nèi)網(wǎng)傳輸基本不會(huì)因?yàn)榫W(wǎng)絡(luò)原因丟失數(shù)據(jù)，所以傳輸?shù)臄?shù)據(jù)可以非常真實(shí)地反應(yīng)用戶行為在系統(tǒng)中的真實(shí)體現(xiàn)。
因此，基于后端采集的上述優(yōu)勢(shì)，神策分析目前提供了 Java、PHP、Python、Ruby 等后端語(yǔ)言的 SDK，以及 LogAgent、BatchImporter、FormatImporter 等導(dǎo)入工具，支持在后端采集。
當(dāng)然，對(duì)于模擬器運(yùn)行 App 或者直接用機(jī)器運(yùn)行 App 來(lái)偽造用戶行為，由于后端拿到的就是偽造后的數(shù)據(jù)，所以對(duì)于這種偽造行為，依然是無(wú)能為力。
2.4 采集后再 antispam
對(duì)于之前提到的模擬器運(yùn)行 App 或者直接用機(jī)器運(yùn)行 App 來(lái)偽造用戶行為這一類(lèi)技術(shù)手段，只能依托于在采集數(shù)據(jù)后，再進(jìn)行 antisapm 清洗數(shù)據(jù)。這些清洗有很多不同的策略，比較常見(jiàn)的有：
基于統(tǒng)計(jì)信息進(jìn)行清洗：例如，把那些流量明顯大于平均值的設(shè)備或者 IP 的用戶行為過(guò)濾掉，把那些行為頻率明顯超過(guò)正常人限度的用戶行為過(guò)濾掉等；
基于用戶行為特征進(jìn)行清洗：主要是用到一些機(jī)器學(xué)習(xí)的手段，通過(guò)對(duì)整體的用戶行為進(jìn)行訓(xùn)練，然后找到那些行為特征明顯異于常人的用戶；
基于設(shè)備真實(shí)性進(jìn)行清洗：目前有一些第三方供應(yīng)商提供了類(lèi)似的方案，通過(guò)識(shí)別一個(gè)設(shè)備是一個(gè)真實(shí)的設(shè)備，還是一個(gè)模擬器，來(lái)解決虛擬機(jī)造假問(wèn)題。
神策分析后面將會(huì)提供類(lèi)似的 antispam 方案，并且將識(shí)別出來(lái)的用戶作弊概率直接作為一個(gè)用戶的 profile，以供使用者來(lái)選擇使用。
3. 一些題外話
其實(shí)，除了數(shù)據(jù)采集這個(gè)環(huán)節(jié)以外，很多互聯(lián)網(wǎng)產(chǎn)品，都會(huì)面臨著網(wǎng)絡(luò)傳輸中的“安全”與“隱私”這兩類(lèi)問(wèn)題，而且也都會(huì)有所取舍與折衷。
我們以百度，這樣一個(gè)典型的互聯(lián)網(wǎng)產(chǎn)品為例，來(lái)看看它的網(wǎng)頁(yè)端是如何選擇來(lái)解決這些問(wèn)題。
首先，百度選擇了全站采用 HTTPS 進(jìn)行加密，主要目的其實(shí)是為了避免第三方(如運(yùn)營(yíng)商等)篡改返回給用戶的網(wǎng)頁(yè)在其中加入第三方的廣告，當(dāng)然，這一做法，也客觀保證了用戶的操作不被第三方竊��；
其次，對(duì)于通過(guò) Spider 等非人工的訪問(wèn)方式來(lái)抓取搜索結(jié)果的行為，則并沒(méi)有在訪問(wèn)時(shí)就進(jìn)行封禁等處理，而是在進(jìn)行統(tǒng)計(jì)時(shí)再進(jìn)行復(fù)雜的流量清洗等 antispam 手段，以獲得準(zhǔn)確的流量，這主要是為了在保持用戶體驗(yàn)，避免因?yàn)檎`封禁而影響正常用戶的訪問(wèn)，同時(shí)，也可以在后處理時(shí)可以加入復(fù)雜的策略保證最好的清洗效果；
第三，對(duì)于使用某些非法手段來(lái)對(duì)廣告點(diǎn)擊進(jìn)行造假的行為，由于涉及到經(jīng)濟(jì)隱私，相比抓取搜索結(jié)果危害要更大，所以雖然都是采用后處理 antispam 的方式，但是時(shí)效性會(huì)更好，一般是會(huì)先做完 antispam，然后再扣費(fèi)，從而避免作弊點(diǎn)擊導(dǎo)致廣告費(fèi)用扣光，影響點(diǎn)擊。廣告點(diǎn)擊的 antispam 是百度的核心策略與競(jìng)爭(zhēng)優(yōu)勢(shì)，也是投入很多成本進(jìn)行研發(fā)與維護(hù)的領(lǐng)域。
..
|
