99999久久久久久亚洲,欧美人与禽猛交狂配,高清日韩av在线影院,一个人在线高清免费观看,啦啦啦在线视频免费观看www

熱線電話:13121318867

登錄
首頁精彩閱讀用R語言分析報表訪問的相關(guān)性
用R語言分析報表訪問的相關(guān)性
2015-11-23
收藏

R語言分析報表訪問的相關(guān)性


R語言分析報表訪問的相關(guān)性


1.起因 


公司有幾個提供數(shù)據(jù)系統(tǒng),我負(fù)責(zé)其中一些系統(tǒng)的日常運維。其中最大的一個系統(tǒng)(有上千張的報表、清單)偶爾會有一些狀況出現(xiàn)。而如果早上有問題,客服中心(呼叫中心)立即會對此進行嚴(yán)重投訴,并強調(diào)所有坐席都受到影響。印象中此類投訴一般出現(xiàn)在上午9點,而到了其他時間段,就算系統(tǒng)出現(xiàn)狀況,他們也不會有投訴了。所以一直想分析一下客服中心的訪問模式、訪問重點是什么。另外,對于報表的總體訪問情況也一直很有興趣看一看。

這個工作一直沒有去做。原因多種多樣。最近有點時間,就打算用R來分析一下看看會有什么結(jié)果。


2.實戰(zhàn)

a.數(shù)據(jù)整理。

進行數(shù)據(jù)分析,不能避免的第一步就是數(shù)據(jù)提取和整理。報表的每次點擊都會有日志存放在數(shù)據(jù)庫中,從最近一次系統(tǒng)升級到現(xiàn)在經(jīng)過了19個月,一共有38萬次點擊,點擊記錄、點擊用戶、用戶所屬單位等信息分別存放在不同的表中。初始的關(guān)聯(lián)工作我就利用數(shù)據(jù)庫來完成了。也嘗試過倒出來用R的merge函數(shù),但是發(fā)現(xiàn)運行后R崩潰了。感覺是幾十萬的數(shù)據(jù)進行merge對我的機器來說可能太大了一些。既然手邊有數(shù)據(jù)庫,那很多初期工作就可以交給sql了,然后再利用R對初步整理好的數(shù)據(jù)框進行后續(xù)的各種處理。


最后生成的數(shù)據(jù)文件是如下格式的(csv文件)(部分字段進行了處理,以下是的簡化版,呃.....實際折騰數(shù)據(jù)的過程總是有點復(fù)雜的):

"date","yyyymm","yyyy","mm","dd","day","hour","rpt_name","tag","dept"

"20120627","201206","2012","06","27","4","10","EVT_電話記錄","事務(wù)報表","客戶服務(wù)中心"
"20120627","201206","2012","06","27","4","10","SSR_投訴清單","投訴報表","東區(qū)"

....

字段的含義很明確,依次是:日期、年月、年、月、日、星期(1代表周日,2代表周一,etc)、小時、報表名、二級單位。


將數(shù)據(jù)讀入。由于每個字段都有分析價值,所以每個字段都設(shè)為因子,并按照字符方式讀入:

rptd <-  read.csv("vis130730.csv",head=TRUE,stringsAsFactors=TRUE,sep=",",na.strings=" ",colClasses=c("character"))


讀入數(shù)據(jù)后,用str(rptd)檢查數(shù)據(jù)框結(jié)構(gòu)時,發(fā)現(xiàn)所有的字段都不是因子。這是為什么?我不是已經(jīng)設(shè)定stringsAsFactors=TRUE了么?看了一下手冊,原來對于指定了字段類型的字段都將作為非因子讀入,該選項無效。那就先這樣吧,等需要的時候再進行因子化。

好了,數(shù)據(jù)初步整理完畢,接下來就要借助可視化分析了。這應(yīng)該是R的強項之一了。


加載所需的加裝包:

library(plyr)

library(reshape)

library(ggplot2)


b.客服中心在一天之中的報表訪問情況是什么樣的呢?

篩選出客服中心的數(shù)據(jù)(約有接近8萬條,是總訪問量的20%):

rptdkf <- rptd[rptd$dept=="客戶服務(wù)中心",]


然后按照小時來繪圖:

qplot(hour,data=rptdkf,xlab="小時",ylab="訪問次數(shù)")

我們看到這樣的結(jié)果:



 

有點令人失望。雖然大量訪問集中在上午,但是并沒有出現(xiàn)我預(yù)想中的“訪問非常集中在8-9點”這樣的情況,而是符合一般上午時點訪問最多(8-11點,8點段訪問少于9點段,應(yīng)該是因為8:30才上班),中午休息,然后下午有一定訪問量這種模式。

那么,在8-10點之間訪問最多的報表是哪些呢?這些報表應(yīng)該是維護的重中之重吧。我們再次進行篩選,并統(tǒng)計所有報表在這段時間的訪問次數(shù),按照訪問次數(shù)的高低進行排序,可以看到有幾張報表的訪問頻次遠遠超過其他報表:

rptdkf1 <- rptd[(rptdkf$hour=="08" | rptdkf$hour=="09" ),]

cnt <- ddply(rptdkf,.(rpt_name),nrow)

cnt <- cnt[order(cnt$V1,decreasing=TRUE),]

cnt

(結(jié)果略,可以發(fā)現(xiàn)有5張報表的訪問量是其他報表的幾倍、十幾倍)


可以預(yù)計這些數(shù)據(jù)對于客服中心的人員是最重要,這些可以作為大家運行保障的重點(嗯,這話很像領(lǐng)導(dǎo)的口氣)。這個信息當(dāng)然也可以通過用戶訪談得到,但是用戶可能出于各種原因夸大重點報表的范圍,對運維形成誤導(dǎo)。而通過訪問數(shù)據(jù)來分析就可能更準(zhǔn)確地反映問題了。這并不是說訪談不重要,可能確實有些報表是少量管理人員每天上班要重點關(guān)注的,這需要通過訪談來甄別發(fā)現(xiàn)。這個工作就暫略了。


c.總體訪問情況:

按照月份繪制了報表總體曲線,如下:

qplot(yyyymm, data=rptd,xlab="月份",ylab="訪問次數(shù)")


 

可以看到訪問量今年有所減少。13年的每個月對應(yīng)12年的相應(yīng)月份看也是在減少。這個可能是其他新的報表系統(tǒng)的替代作用。所以如果結(jié)合對其他報表系統(tǒng)訪問情況的分析能看出一些其他的信息來。


分公司對報表的訪問量占到了總訪問量的60%,我們來看看他們的訪問模式是什么樣的。由于市場部等管理部門對各個分公司的工作有管理、指導(dǎo)的職責(zé),所以我們將他們(他們占總訪問量占10%)也納入分析,我們用%in%篩選出這些單位,并按照個單位作圖。


我們按照按照各個分公司繪制了按月的訪問曲線:

rptdsub <- rptd[rptd$dept %in% c("寶山","北區(qū)","崇明","東區(qū)","奉賢","嘉定","金山","南區(qū)","浦東","青浦","莘閔","松江","西區(qū)","中區(qū)","市場部","政企客戶部","公眾客戶部"),]

qplot(yyyymm, data = rptdsub,xlab="小時",ylab="訪問次數(shù)") + facet_wrap(~ dept)


 

可以看到各個單位的訪問量是有很大差異,雖然總體的訪問次數(shù)是略有下降的,但是對應(yīng)到不同的單位,可以看到有的在增加?;蛟S這些訪問在增加的單位加大了數(shù)據(jù)分析的力度,也可能是他們有分析的需求,但是對其他新的數(shù)據(jù)系統(tǒng)不夠了解,所以沒有好好利用新系統(tǒng),而只能重點使用該系統(tǒng)。我們還可以看到浦東分公司的訪問量最大(實際上超過了管理部門之和),中區(qū)分公司的訪問量下降最明顯。另外市區(qū)公司的訪問量普遍高于郊區(qū)公司。這個可能和郊區(qū)競爭不激烈、人員配備較少有關(guān)。


再按照訪問的鐘點作圖:

qplot(hour, data = rptdsub,xlab="小時",ylab="訪問次數(shù)") + facet_wrap(~ dept)



我們還可以看到有些單位(金山、寶山)上班可能比標(biāo)準(zhǔn)時間早半個小時,因為他們在8點檔的訪問量超過9點檔,與其他單位明顯不同。有些單位下了班后就沒有點擊量了,有些單位明顯勤快很多。另外,我們還可以注意到有些單位8點檔幾乎沒有訪問量,而到了9點的訪問量也不是很多(呃,就不點名了,可能是他們的工作重點有所不同吧.....)


d.訪問相關(guān)性。

最后,我們來看看分公司和市場等管理部門之間的訪問相關(guān)性。我們采用多維定標(biāo)(MDS)算法(參考《機器學(xué)習(xí):實用案例解析》)。

首先我們需要建立一個訪問矩陣,每行是各個單位,每列是各張報表。如果某個單位訪問了某張報表,則對應(yīng)的單元格填1,如果沒有就填0。這個操作在數(shù)據(jù)庫上好像很不好辦(我不知道簡單的實現(xiàn)辦法,如果有人知道,煩請賜教)。原來想用循環(huán)的方式來做,忽然想到了reshape包的cast命令應(yīng)該能完成這樣的工作:

mds1 <- cast(mdsd, abbr~rpt_name)

第一列是單位的名稱,我們需要將其剔除,剩余部分轉(zhuǎn)化為一個矩陣。第一列轉(zhuǎn)化為行名,原來的字段名(剔除第一個的dept)作為列名:

mds.m <- as.matrix(mds[,2:ncol(mds)])

row.names(mds.m) <- t(as.matrix(mds[,1]))[1,]

colnames(mds.m) <- colnames(mds)[2:ncol(mds)]


矩陣做好了,代碼非常簡潔,我相信,光憑reshape包,R就物超所值了。看了一下,發(fā)現(xiàn)交叉點上的值不是0和1,而是訪問次數(shù)。我們再將所有非0的值都賦為1:

mds.m[mds.m>0] <- 1


好了,我們得到我們要的矩陣了,以下就是按部就班的操作:計算距離并作圖:

mds.mute <- mds.m %*% t(mds.m)

mds.dist <-dist(mds.mute)

mds.g <- cmdscale(mds.dist)


plot(mds.g, type='n')

text(mds.g, row.names(mds.g))


最終看到的圖如下:


真是令人意外:各個分公司與管理部門之間所看的報表情況竟然如此旗幟鮮明地分成兩個聚類。這說明什么呢?二級公司與管理部門之間的分析思路和重點不同?管理部門沒有將管理思路貫徹到各個分公司?還是說管理部門有秘而不宣的武器呢?

另外,分公司之間也有比較明顯的區(qū)分:市區(qū)公司和郊區(qū)公司的關(guān)注重點明顯有一定的差異。這個在IT部門以后開發(fā)支持分公司經(jīng)營的數(shù)據(jù)應(yīng)用時,也可以作為調(diào)研訪談的參考吧。


對于報表點擊情況的簡要分析就到此為止了。我到達了分析的目標(biāo),也順便演練了數(shù)據(jù)篩選、作圖、相關(guān)性分析等工作。除掉數(shù)據(jù)整理的工作,核心代碼也就不到二十句,就做出了有點意思的功能了。

數(shù)據(jù)分析咨詢請掃描二維碼

若不方便掃碼,搜微信號:CDAshujufenxi

數(shù)據(jù)分析師資訊
更多

OK
客服在線
立即咨詢
客服在線
立即咨詢
') } function initGt() { var handler = function (captchaObj) { captchaObj.appendTo('#captcha'); captchaObj.onReady(function () { $("#wait").hide(); }).onSuccess(function(){ $('.getcheckcode').removeClass('dis'); $('.getcheckcode').trigger('click'); }); window.captchaObj = captchaObj; }; $('#captcha').show(); $.ajax({ url: "/login/gtstart?t=" + (new Date()).getTime(), // 加隨機數(shù)防止緩存 type: "get", dataType: "json", success: function (data) { $('#text').hide(); $('#wait').show(); // 調(diào)用 initGeetest 進行初始化 // 參數(shù)1:配置參數(shù) // 參數(shù)2:回調(diào),回調(diào)的第一個參數(shù)驗證碼對象,之后可以使用它調(diào)用相應(yīng)的接口 initGeetest({ // 以下 4 個配置參數(shù)為必須,不能缺少 gt: data.gt, challenge: data.challenge, offline: !data.success, // 表示用戶后臺檢測極驗服務(wù)器是否宕機 new_captcha: data.new_captcha, // 用于宕機時表示是新驗證碼的宕機 product: "float", // 產(chǎn)品形式,包括:float,popup width: "280px", https: true // 更多配置參數(shù)說明請參見:http://docs.geetest.com/install/client/web-front/ }, handler); } }); } function codeCutdown() { if(_wait == 0){ //倒計時完成 $(".getcheckcode").removeClass('dis').html("重新獲取"); }else{ $(".getcheckcode").addClass('dis').html("重新獲取("+_wait+"s)"); _wait--; setTimeout(function () { codeCutdown(); },1000); } } function inputValidate(ele,telInput) { var oInput = ele; var inputVal = oInput.val(); var oType = ele.attr('data-type'); var oEtag = $('#etag').val(); var oErr = oInput.closest('.form_box').next('.err_txt'); var empTxt = '請輸入'+oInput.attr('placeholder')+'!'; var errTxt = '請輸入正確的'+oInput.attr('placeholder')+'!'; var pattern; if(inputVal==""){ if(!telInput){ errFun(oErr,empTxt); } return false; }else { switch (oType){ case 'login_mobile': pattern = /^1[3456789]\d{9}$/; if(inputVal.length==11) { $.ajax({ url: '/login/checkmobile', type: "post", dataType: "json", data: { mobile: inputVal, etag: oEtag, page_ur: window.location.href, page_referer: document.referrer }, success: function (data) { } }); } break; case 'login_yzm': pattern = /^\d{6}$/; break; } if(oType=='login_mobile'){ } if(!!validateFun(pattern,inputVal)){ errFun(oErr,'') if(telInput){ $('.getcheckcode').removeClass('dis'); } }else { if(!telInput) { errFun(oErr, errTxt); }else { $('.getcheckcode').addClass('dis'); } return false; } } return true; } function errFun(obj,msg) { obj.html(msg); if(msg==''){ $('.login_submit').removeClass('dis'); }else { $('.login_submit').addClass('dis'); } } function validateFun(pat,val) { return pat.test(val); }