摘要：歡迎大家收看聊一聊系列，這一套系列文章，可以幫助前端工程師們了解前端的方方面面不僅僅是代碼什么是功能統(tǒng)計(jì)作為一名開發(fā)，我們的產(chǎn)品發(fā)布出去之后，無論是產(chǎn)品還是運(yùn)營(yíng)，其實(shí)都是想及時(shí)了解產(chǎn)品對(duì)用戶產(chǎn)生的影響的。下一章，我們將繼續(xù)聊聊速度統(tǒng)計(jì)。

歡迎大家收看聊一聊系列，這一套系列文章，可以幫助前端工程師們了解前端的方方面面（不僅僅是代碼）：https://segmentfault.com/blog...

作為一名開發(fā)，我們的產(chǎn)品發(fā)布出去之后，無論是產(chǎn)品還是運(yùn)營(yíng)，其實(shí)都是想及時(shí)了解產(chǎn)品對(duì)用戶產(chǎn)生的影響的。用戶到底喜歡什么不喜歡什么。但是如果拉住用戶去一個(gè)個(gè)問的話，也無法得到最真實(shí)的大眾的想法。于是，運(yùn)用大數(shù)據(jù)進(jìn)行分析，就變成了產(chǎn)品們的利器。

那么這些反映了用戶真實(shí)行為的數(shù)據(jù)，就得靠前端工程師們來打印了。

比如，你想看一個(gè)功能有多少用戶進(jìn)行了點(diǎn)擊，來證明用戶是否喜歡這個(gè)功能，亦或是你想看看用戶究竟會(huì)在你的頁面停留多長(zhǎng)時(shí)間，從而判斷用戶的黏性。那么，在用戶點(diǎn)擊那個(gè)功能的時(shí)候，前端發(fā)送一條日志到服務(wù)端，這樣積累下去，我們就能獲得，每天有多少用戶在點(diǎn)擊某一個(gè)功能了。在功能發(fā)生迭代后，我們也能根據(jù)統(tǒng)計(jì)，來判斷用戶是否喜歡新的變化。

一般來講，只要在想統(tǒng)計(jì)的行為發(fā)生時(shí)，發(fā)送一條請(qǐng)求到達(dá)服務(wù)端即可。這樣我們的服務(wù)端就有了相應(yīng)的記錄。我們就能開心的利用記錄數(shù)量來判斷點(diǎn)擊數(shù)量了。

一般來講我們不必為了發(fā)送請(qǐng)求，就在各處點(diǎn)擊的地方加個(gè)ajax，其實(shí)有種發(fā)送請(qǐng)求的方式比ajax更加的簡(jiǎn)單。而且還避免了跨域問題。

其實(shí)直接給一個(gè)圖片、script標(biāo)簽賦值地址，就完成了一次GET請(qǐng)求。

例(如圖2.1所示)：

(new Image()).src = "https://gm.mmstat.com/tmallfp.4202.7";

圖2.1

我們看到，輕輕松松就發(fā)送了一條請(qǐng)求出去，亦或者是使用script標(biāo)簽，或者fetch之類的方式也可以達(dá)到目的。

本人觀察了一下騰訊網(wǎng)和淘寶網(wǎng)，的日志。發(fā)現(xiàn)淘寶網(wǎng)使用的是請(qǐng)求一張空?qǐng)D片到服務(wù)端，以此來實(shí)現(xiàn)的日志打印。

而騰訊網(wǎng)使用的，則是發(fā)送一個(gè)js請(qǐng)求的方式，來打印日志(如圖2.2)

圖2.2

其實(shí)無論使用什么方式，都殊途同歸，最終我們得到的是服務(wù)端的一條access日志，利用這個(gè)日志，就可以記錄了。

我們?cè)陂_發(fā)的時(shí)候，在用戶發(fā)生各個(gè)行為時(shí)，發(fā)送一條記錄了此行為的數(shù)據(jù)。這樣就能記錄自己產(chǎn)品的方方面面了。

一般來講服務(wù)器的server都會(huì)有access日志。這里拿nginx來舉個(gè)例子。我們需要搭建一個(gè)nginx服務(wù)器，然后饞看nginx的conf(安裝路徑/conf/nginx.conf)如圖3.1

圖3.1

nginx可以配置一個(gè)access日志的文件，每當(dāng)有請(qǐng)求打到當(dāng)前的nginx上，都會(huì)產(chǎn)出一條access日志。

日志的路徑也是可配置的，甚至可以配置文件的切割，這里就不再贅述。

圖3.2

接著，我們?cè)L問一下這個(gè)服務(wù)，于是就產(chǎn)生了一條access日志(如圖3.2)，我們只要在功能點(diǎn)擊的時(shí)候，往這臺(tái)機(jī)器上發(fā)送一個(gè)簡(jiǎn)單的請(qǐng)求即可產(chǎn)生日志啦。接下來把日志整理整理，就可以產(chǎn)出產(chǎn)品經(jīng)理們想要的反饋了。

如果我們需要各種各樣的日志，那么可以把參數(shù)給多樣化，用參數(shù)來區(qū)分各個(gè)不同地方的點(diǎn)擊或者是各種交互行為。我們的access日志中，會(huì)留存有完整的URL，只要我們將其解析，就能拿到各處的點(diǎn)擊行為了。

為了各位考慮，本小節(jié)的實(shí)驗(yàn)在windows下進(jìn)行。首先，我們將下載一個(gè)nginx（本文最后的示例代碼中也有），然后，更改其conf文件(如圖5.1)。

圖5.1

并將端口改為8091。并且去掉注釋，打開access日志。

圖5.2

雙擊啟動(dòng)即可。然后，我們?cè)L問一下http://localhost:8091/

發(fā)現(xiàn)nginx已然運(yùn)行成功(如圖5.3)

圖5.3

接下來，我們看一下logs/access.log中的記錄(如圖5.4)

圖5.4

多了一條，證明有記錄了。

接著，我們創(chuàng)建一個(gè)html（在哪兒創(chuàng)建都行）--- testlog.html

    
        
    
    
        點(diǎn)我
        
    

運(yùn)行頁面，點(diǎn)擊按鈕。我們發(fā)現(xiàn)，發(fā)送出一條日志(如圖5.5)

圖5.5

我們?cè)俅未蜷_access.log，發(fā)現(xiàn)多了一條日志(如圖5.6)

圖5.6

于是我們的目的達(dá)成了。以后可以用action=log并且，clk=button的記錄，來看有多少用戶點(diǎn)擊了按鈕了。

示例代碼在此：

https://github.com/houyu01/lo...

在日常打日志中，我們會(huì)遇到這樣那樣的問題，這里謹(jǐn)把我再工作中遇到的問題與大家分享一下。

1. 當(dāng)點(diǎn)擊發(fā)生本頁跳轉(zhuǎn)的時(shí)候，同時(shí)發(fā)送日志有一定幾率無法發(fā)出。

當(dāng)a標(biāo)簽發(fā)生點(diǎn)擊的時(shí)候，我們往往會(huì)發(fā)送一條外鏈的點(diǎn)擊日志，但是，如果這個(gè)a標(biāo)簽是本頁跳轉(zhuǎn)（而不是新開頁面）的話，那么在日志發(fā)送之前，頁面有可能就已經(jīng)跳轉(zhuǎn)了，這時(shí)，所有的請(qǐng)求都是發(fā)不出去的。目前應(yīng)對(duì)這種狀況，沒有什么特別好的辦法，

可以嘗試使用先發(fā)日志，在日志的回調(diào)用進(jìn)行跳轉(zhuǎn)，這樣就有可能造成跳轉(zhuǎn)慢。

使用新式API?navigator.sendBeacon()，可以在本頁面跳轉(zhuǎn)之后，堅(jiān)強(qiáng)的發(fā)出一條請(qǐng)求。但是兼容性不太好。

2. 發(fā)送的參數(shù)不要太多，太長(zhǎng)

因?yàn)槲覀兊恼?qǐng)求畢竟算是GET請(qǐng)求，肯定有URL長(zhǎng)度的限制。所以，發(fā)了大量的信息的話，怕會(huì)被截?cái)唷?/p>

3. 有一定丟失率

因?yàn)榫W(wǎng)絡(luò)等等的原因，發(fā)送的日志，丟失率是肯定會(huì)有的，各位如果習(xí)慣的話，也就好了。

不要走開，請(qǐng)關(guān)注我。下一章，我們將繼續(xù)聊聊速度統(tǒng)計(jì)。

https://segmentfault.com/a/11...

原創(chuàng)文章，版權(quán)所有，轉(zhuǎn)載請(qǐng)注明出處