整合營(yíng)銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
據(jù)分析能夠幫助我們更好地進(jìn)行運(yùn)營(yíng)決策，數(shù)據(jù)分析能夠很好的為轉(zhuǎn)化用戶提供參考與數(shù)據(jù)支撐。
商業(yè)領(lǐng)域的數(shù)據(jù)分析，就是為了給商業(yè)行為提供良好的數(shù)據(jù)預(yù)測(cè)以及效果評(píng)估，在互聯(lián)網(wǎng)界也是如此。我們?cè)谀壳吧虡I(yè)環(huán)境所做的每一項(xiàng)活動(dòng)都直接或者間接與用戶有著聯(lián)系，其目的本質(zhì)都是一樣，為了讓用戶成為你的消費(fèi)者，更進(jìn)一步的持久消費(fèi)者。因此數(shù)據(jù)分析，也應(yīng)該為轉(zhuǎn)化用戶提供參考與數(shù)據(jù)支撐。畢竟沒有用戶轉(zhuǎn)化為消費(fèi)者這個(gè)過(guò)程，所有的分析都是天方夜譚。數(shù)據(jù)的結(jié)論與行為的預(yù)測(cè)彼此就是一個(gè)循環(huán)論證的過(guò)程。
首先澄清一下數(shù)據(jù)分析其實(shí)并不是什么高深的學(xué)問，在現(xiàn)實(shí)的職場(chǎng)實(shí)戰(zhàn)中，涉及涵蓋的數(shù)據(jù)分析的方法以及復(fù)雜性是遠(yuǎn)低于在學(xué)校里習(xí)得的專業(yè)知識(shí)。什么卡方檢驗(yàn)，方差分析，回歸分析顯著性檢驗(yàn)等等在非用研以及非專業(yè)統(tǒng)計(jì)分析領(lǐng)域是很少涉及的。（當(dāng)然那些學(xué)過(guò)數(shù)理統(tǒng)計(jì)學(xué)的專業(yè)人士也不屑于本文提到的內(nèi)容，如果大家對(duì)這些看起來(lái)比較高深的分析方法有興趣可以自行腦補(bǔ)）。本文只給運(yùn)營(yíng)以及一些涉及產(chǎn)品方向的崗位提供分析思路并結(jié)合實(shí)際案例對(duì)我所涉及的領(lǐng)域，抽絲剝繭，給大家一個(gè)更加直觀的用戶轉(zhuǎn)化方面涉及數(shù)據(jù)分析的知識(shí)覆蓋。
互聯(lián)網(wǎng)的大用戶概念我們可以直接簡(jiǎn)單粗暴認(rèn)定為流量，這里的流量并不是指的簡(jiǎn)單的IP,UV,PV也可以指來(lái)電數(shù)，訪客人數(shù)，人流量等概念既然是流量也就有其自身的數(shù)量。我們?cè)趯?duì)流量轉(zhuǎn)化的數(shù)據(jù)分析時(shí)都會(huì)基于一種邏輯方案———流量漏斗轉(zhuǎn)化模型進(jìn)行分析。
原理很簡(jiǎn)單，我們可以形象的認(rèn)為自身的互聯(lián)網(wǎng)產(chǎn)品其本身就是一個(gè)虛擬的漏斗，用戶在進(jìn)行瀏覽到最終完成下單行為（或者其他我們認(rèn)定的轉(zhuǎn)化行為比如注冊(cè)，關(guān)注，轉(zhuǎn)發(fā)等）有多少被直接阻擋在了“濾網(wǎng)”之上，有多少順利的達(dá)到了我們預(yù)設(shè)的“轉(zhuǎn)化行為區(qū)域”。當(dāng)然，我們所有的活動(dòng)都并不是一錘子買賣，因此也要從橫向（時(shí)間）維度來(lái)分析問題。持續(xù)的轉(zhuǎn)化用戶，保持老用戶的消費(fèi)活力也是分析工作的重中之重。當(dāng)然，我們?cè)谵D(zhuǎn)化流量不僅僅是指的轉(zhuǎn)化的數(shù)量而且還指轉(zhuǎn)化的質(zhì)量，說(shuō)的比較簡(jiǎn)單點(diǎn)，就是要提高單個(gè)用戶的消費(fèi)價(jià)值。在橫縱兩個(gè)維度方面，在這些層層“濾網(wǎng)”中，我們是如何透過(guò)這些數(shù)據(jù)分析問題的呢。
以大型電商網(wǎng)站下單流程為例，我將從流量來(lái)源-中間頁(yè)面訪問-詳情頁(yè)-加入購(gòu)物車-提交訂單-復(fù)購(gòu)這幾個(gè)階段展開說(shuō)明。
流量進(jìn)入主站的第一道障礙通過(guò)不同渠道進(jìn)入的主站（或者該渠道引入流量的承接頁(yè)），主站頁(yè)面即是第一層“濾網(wǎng)”我們用穿過(guò)第一層濾網(wǎng)進(jìn)入二級(jí)頁(yè)面的通過(guò)率來(lái)衡量渠道的流量的質(zhì)量。通常我們用來(lái)衡量頁(yè)面的流量質(zhì)量的指標(biāo)包含如下：頁(yè)面UV點(diǎn)擊率，頁(yè)面停留時(shí)間，跳失率。
想要通過(guò)第一層“濾網(wǎng)”，需要必要的動(dòng)作就是產(chǎn)生點(diǎn)擊行為，而點(diǎn)擊行為會(huì)產(chǎn)生兩個(gè)數(shù)據(jù)：頁(yè)面UV點(diǎn)擊率=頁(yè)面點(diǎn)擊總次數(shù)/頁(yè)面UV數(shù)；跳失率=通過(guò)一個(gè)入口進(jìn)入就離開的次數(shù)/通過(guò)該入口訪問的總次數(shù)。點(diǎn)擊率越高，說(shuō)明頁(yè)面呈現(xiàn)的內(nèi)容有吸引力能夠有效的吸引用戶的關(guān)注；跳失率越高，說(shuō)明頁(yè)面呈現(xiàn)內(nèi)容具備欺騙性，所呈現(xiàn)的鏈接內(nèi)容和文案不具備吸引力。因此在進(jìn)行第一層濾網(wǎng)的優(yōu)化方面盡量提高頁(yè)面的點(diǎn)擊率，降低頁(yè)面的跳失率。盡量讓用戶下沉到二級(jí)頁(yè)面（或者目標(biāo)頁(yè)面）。同時(shí)通過(guò)這個(gè)數(shù)據(jù)也可以判斷流量來(lái)源的質(zhì)量是否過(guò)關(guān)。
一般而言，頁(yè)面低質(zhì)量的流量判斷往往符合以下幾個(gè)特點(diǎn)：在排除頁(yè)面問題的情況下產(chǎn)生的：1，低點(diǎn)擊率；2，高跳失率；3低頁(yè)面停留時(shí)間。
這些低質(zhì)量流量產(chǎn)生的原因主要有幾個(gè)方面：1，渠道引流上呈現(xiàn)的文案內(nèi)容與承接落地頁(yè)面不符。2，投放渠道上，與目標(biāo)用戶活躍范圍不符的渠道，也就是說(shuō)投放的渠道不精準(zhǔn)。3，承接頁(yè)出錯(cuò)等以及其他原因（包含但不限于404錯(cuò)誤網(wǎng)頁(yè)過(guò)期，跳轉(zhuǎn)出錯(cuò)等）。
既然說(shuō)到這，順便也給大家看看外部渠道的各種引流的優(yōu)劣：
以上表格內(nèi)容，并不一定十分準(zhǔn)確，大家可以抱著批判的態(tài)度研究論證一下。
在頁(yè)面訪問階段，流量成功通過(guò)第一道“濾網(wǎng)”進(jìn)入到中間頁(yè)階段，中間頁(yè)包含：搜索列表頁(yè)，專題活動(dòng)頁(yè)面，頻道頁(yè)面等。不同的中間頁(yè)也有不同的數(shù)據(jù)指標(biāo)反映著頁(yè)面內(nèi)容的好壞以及流量的走向。中間頁(yè)的好壞考量最終是有多少訪客進(jìn)入到了商品詳情頁(yè)，因此有一個(gè)指標(biāo)非常重要：UV到達(dá)詳情頁(yè)轉(zhuǎn)化率=詳情頁(yè)UV/中間頁(yè)UV
搜索列表頁(yè)在大型電商網(wǎng)站中有著不可代替的重要作用，也是站內(nèi)流量的主要來(lái)源，承接著站內(nèi)商品檢索，品類布局的重任，區(qū)分搜索頁(yè)面與列表頁(yè)面主要是看鏈接字符，搜索頁(yè)面的鏈接往往包含search字符，列表頁(yè)（或者可以叫類目頁(yè)）鏈接包含list字符。搜索頁(yè)為依據(jù)用戶輸入的關(guān)鍵詞來(lái)進(jìn)行整體檢索后呈現(xiàn)給用戶商品陳列頁(yè)面。而列表頁(yè)則是與網(wǎng)站商品類目后臺(tái)直接關(guān)聯(lián)，呈現(xiàn)品類最全的頁(yè)面。兩者的功能都是為了給予用戶更好和更快的定位到想要查看的商品（或者內(nèi)容）。以下為分別為幾個(gè)B2C電商的的搜索和類目頁(yè)鏈接的開頭：
其他就不一一列舉了，搜索列表頁(yè)的數(shù)據(jù)指標(biāo)的考核目的就是為了能讓用戶更加精確快速的找到自己的想要的產(chǎn)品，因此在這一級(jí)的頁(yè)面中數(shù)據(jù)指標(biāo)包含如下：
搜索點(diǎn)擊率=點(diǎn)擊次數(shù)/搜索次數(shù)；這個(gè)指標(biāo)衡量搜索頁(yè)面的呈現(xiàn)質(zhì)量，理論上而言搜索點(diǎn)擊率要在200%及以上才是比較健康。（不絕對(duì)）
UV到詳情頁(yè)轉(zhuǎn)化率=詳情頁(yè)UV/搜索或者列表頁(yè)UV；該指標(biāo)在搜索和列表中同樣適用，用來(lái)平衡點(diǎn)擊率的作弊可能，也是反映三級(jí)頁(yè)面呈現(xiàn)質(zhì)量的指標(biāo)之一。
搜索無(wú)結(jié)果次數(shù)：用以反映關(guān)鍵詞涉及的品牌品類缺失或者未關(guān)聯(lián)指標(biāo)。當(dāng)然搜索無(wú)結(jié)果詞的次數(shù)是越低越好。對(duì)于搜索詞呈現(xiàn)結(jié)果為空的品類，需要綜合評(píng)估后決定是否對(duì)相關(guān)類目開啟招商，引進(jìn)產(chǎn)品線；對(duì)于未關(guān)聯(lián)的品類需要著重優(yōu)化頁(yè)面重新關(guān)聯(lián)。
搜索結(jié)果頁(yè)首屏點(diǎn)擊率=搜索首屏點(diǎn)擊次數(shù)/搜索次數(shù)；該指標(biāo)用以衡量搜索結(jié)果首屏的商品排序質(zhì)量與呈現(xiàn)質(zhì)量。該數(shù)據(jù)指標(biāo)的好壞可以間接的反映出搜索詞呈現(xiàn)的頁(yè)面排序是否合理，是否符合用戶的需求。同理列表頁(yè)的首屏指標(biāo)也與此一樣只是名稱不同而已即列表頁(yè)首屏點(diǎn)擊率=列表頁(yè)首屏點(diǎn)擊次數(shù)/列表頁(yè)P(yáng)V.
搜索次數(shù)：搜索詞產(chǎn)生的搜索次數(shù)。（可以理解為搜索PV）一個(gè)搜索詞的搜索次數(shù)高表示該詞所涉及的類目需求量高，反之亦然；如果是在列表頁(yè)則為訪問PV
搜索人數(shù)：搜索詞被多少人搜索的數(shù)量（可以理解為搜索UV）；一個(gè)搜索詞的搜索人數(shù)高表示該詞所涉及的類目需求量高-主要是為了防止出現(xiàn)搜索次數(shù)作弊的情況，反之亦然如果是在列表頁(yè)則為訪問UV
高級(jí)篩選項(xiàng)點(diǎn)擊次數(shù)：在搜索列表頁(yè)中，頁(yè)面頂部的高級(jí)篩選項(xiàng)是為提供快速定位而設(shè)立的，高級(jí)篩選項(xiàng)的點(diǎn)擊次數(shù)和使用率也可以為運(yùn)營(yíng)人員提供商品熱度參考。舉個(gè)例子：在客人搜索“單肩包”或者訪問單肩包的列表頁(yè)，在這些頁(yè)面中都會(huì)出現(xiàn)比如材質(zhì)，價(jià)格款式等參數(shù)項(xiàng)來(lái)給用戶選擇篩選，通過(guò)監(jiān)控頁(yè)面的篩選參數(shù)的點(diǎn)擊次數(shù)，可以得到相關(guān)“單肩包”哪些款式哪些材質(zhì)多少價(jià)位是消費(fèi)者主要關(guān)注的，并以此來(lái)進(jìn)行主推產(chǎn)品的規(guī)劃。
在理出了這些指標(biāo)之后，如何分析這些指標(biāo)數(shù)據(jù)呢？
總結(jié)歸納：針對(duì)搜索列表頁(yè)的數(shù)據(jù)分析歸為3點(diǎn)：高搜索詞重點(diǎn)優(yōu)化提高點(diǎn)擊轉(zhuǎn)化；無(wú)結(jié)果詞分析反饋；頁(yè)面點(diǎn)擊注重高篩適用率方便用戶快速定位。
分析邏輯：以讓用戶下沉到詳情頁(yè)為目的逐一分析，各個(gè)擊破。
頻道頁(yè)和活動(dòng)頁(yè)是常規(guī)三級(jí)頁(yè)面，在B2C電商中起著常規(guī)類目集合體和活動(dòng)流量承接頁(yè)的作用，在頻道頁(yè)和活動(dòng)專題頁(yè)上也有著數(shù)據(jù)的計(jì)算和分析邏輯，其主要的數(shù)據(jù)指標(biāo)也是讓用戶下沉至詳情頁(yè)。（基于這樣一種假設(shè)，用戶只有在詳情頁(yè)才有可能產(chǎn)生轉(zhuǎn)化，這種假設(shè)已經(jīng)被證明-至少絕大部分情況是這樣。）頻道頁(yè)和活動(dòng)頁(yè)雖然具體的數(shù)據(jù)指標(biāo)與搜素列表頁(yè)有所不同，但是他們的最終目的都是相同的。頻道頁(yè)活動(dòng)頁(yè)的數(shù)據(jù)指標(biāo)包含：
低點(diǎn)擊率的區(qū)域可能存在以下幾種原因，一，是圖片以及圖片里的文案不能吸引消費(fèi)者點(diǎn)擊，需要調(diào)整。二，產(chǎn)品頭圖展示樣式不合理需要調(diào)整圖片內(nèi)容或者調(diào)換商品。三，展示區(qū)域位于首屏以下，關(guān)注度不高-需要調(diào)整展示位置。
分析邏輯：還是以用戶下沉為目的，分析涉及的元素逐個(gè)排查。
詳情頁(yè)作為流量轉(zhuǎn)化的關(guān)鍵頁(yè)面，是前臺(tái)承載商品信息的最基本單位。也是用戶是否決定下單購(gòu)買的最最重要的一環(huán)。因此在分析詳情頁(yè)的時(shí)候，數(shù)據(jù)指標(biāo)更多的是詳情頁(yè)的質(zhì)量和它的轉(zhuǎn)化率。當(dāng)然這兩者是相互聯(lián)系的，從現(xiàn)有的數(shù)據(jù)來(lái)看，詳情頁(yè)的質(zhì)量高低與其轉(zhuǎn)化率確實(shí)是存在正相關(guān)的關(guān)系。而詳情頁(yè)質(zhì)量的高低從數(shù)據(jù)的量化反映來(lái)看有兩個(gè)數(shù)據(jù)指標(biāo)：一，平均頁(yè)面停留時(shí)間；二，加入購(gòu)物車數(shù)。
平均頁(yè)面停留時(shí)間=頁(yè)面停留總時(shí)間/訪問UV數(shù)該指標(biāo)與頁(yè)面的呈現(xiàn)布局有著明顯關(guān)聯(lián)，包含商品參數(shù)介紹，詳情圖片描述，客服在線情況，好評(píng)率等。
加入購(gòu)物車數(shù)：用以反映該商品有多少有意向購(gòu)買者，為即將轉(zhuǎn)化的關(guān)鍵步驟。加入購(gòu)物車的數(shù)量多少由基本以下幾個(gè)因素決定：
從數(shù)據(jù)的角度講，詳情頁(yè)反映出的問題僅僅通過(guò)一個(gè)平均訪問時(shí)長(zhǎng)是很難概括的，沒辦法分解到具體某一個(gè)細(xì)節(jié)來(lái)層層分解問題。不過(guò)這個(gè)時(shí)候“經(jīng)驗(yàn)”的加入就能很好的平衡這一點(diǎn)。這里的經(jīng)驗(yàn)表示已經(jīng)經(jīng)過(guò)了長(zhǎng)期的實(shí)踐且數(shù)據(jù)論證的結(jié)論。（這里給大家安利一下數(shù)據(jù)觀點(diǎn)：數(shù)據(jù)不是萬(wàn)能的，有時(shí)主觀的判斷更具代表性，這也是為什么這個(gè)世界上有著那么多的出人意料產(chǎn)品和逆風(fēng)而上的創(chuàng)意）
購(gòu)物車是一個(gè)特別有趣的設(shè)置，對(duì)于快消品標(biāo)準(zhǔn)品的電商網(wǎng)站來(lái)說(shuō)，設(shè)置購(gòu)物車一方面是為了節(jié)省用戶挑選多個(gè)商品的付款時(shí)間，更出現(xiàn)了一個(gè)更加意想不到的好處，就是提高了客單價(jià)。在配合滿減用券等促銷手段的幫助下購(gòu)物車必然能夠起到事半功倍的作用。
在購(gòu)物車中如果大量積壓了客戶選購(gòu)的商品，如果用戶始終沒有進(jìn)行下單支付，即加入購(gòu)物車數(shù)較大，這個(gè)時(shí)候則需要采用短信催付，郵件催付，以及apppush等手段來(lái)促進(jìn)用戶轉(zhuǎn)化。
訂單頁(yè)面是縱向轉(zhuǎn)化的最后一環(huán)，在這個(gè)界面最主要的目的就是盡量讓用戶盡快付款，達(dá)到最后的轉(zhuǎn)化。考核的數(shù)據(jù)為：有效訂單轉(zhuǎn)化率=成交訂單數(shù)/有效訂單數(shù)，在這個(gè)階段促成轉(zhuǎn)化是較為簡(jiǎn)單的如果有效訂單轉(zhuǎn)化率較低就要分析是否支付頁(yè)面存在問題，系統(tǒng)提交流程是否出錯(cuò)等。在排除系統(tǒng)問題后同樣可以使用短信apppush郵件等手段進(jìn)行催付。
最后作為總覽全局的用戶轉(zhuǎn)化指標(biāo)：UV成交轉(zhuǎn)化率=成交訂單數(shù)/頁(yè)面UV數(shù)
作為考核整體用戶轉(zhuǎn)化的指標(biāo)；平均UV價(jià)值=成交金額/頁(yè)面UV數(shù)作為考核整體用戶質(zhì)量的指標(biāo)，值越高，表示質(zhì)量越高。
總結(jié)：層層下探，逐個(gè)擊破直到完成付款
有句老話說(shuō)的好，叫不做一錘子買賣，因此這里就涉及到一個(gè)新的指標(biāo)：
復(fù)夠率=一段時(shí)間內(nèi)重復(fù)購(gòu)買的客戶數(shù)/一段時(shí)間內(nèi)產(chǎn)生購(gòu)買的客戶數(shù)，該指標(biāo)則要求我們從橫向時(shí)間維度來(lái)分析數(shù)據(jù)，也很容易理解。有據(jù)可查，一個(gè)成熟期的購(gòu)物網(wǎng)站其老用戶貢獻(xiàn)的銷售額占據(jù)總數(shù)的60%-70%之多。因此我們?cè)诳吹搅髁柯┒返霓D(zhuǎn)化模型的同時(shí)，更加要加深對(duì)會(huì)員的分層管理，用良好的服務(wù)于產(chǎn)品以及具有創(chuàng)意和力度的活動(dòng)維系你的老用戶。
復(fù)夠率過(guò)低：1，表示沒有對(duì)老會(huì)員進(jìn)行足夠的喚醒，可通過(guò)短信push線下廣告等等活動(dòng)進(jìn)行推廣激活；2，也有可能近期投入的拉新的資源較多，導(dǎo)致新客增多降低了復(fù)夠率，需要核實(shí)拉新活動(dòng)的數(shù)據(jù)；3，超低價(jià)或者超優(yōu)惠活動(dòng)引流也會(huì)導(dǎo)致大量新用戶引入，也會(huì)對(duì)復(fù)夠率產(chǎn)生影響。上面的兩點(diǎn)并不是對(duì)復(fù)夠率有壞的影響，針對(duì)的客群不同，數(shù)據(jù)也應(yīng)有所取舍。
以上就是針對(duì)電商下單流程的整個(gè)過(guò)程，當(dāng)然有很多模塊并沒有提及，比如智能交叉推薦等。大家只需要理解其中的數(shù)據(jù)分析的邏輯即可。不同的頁(yè)面，不同的時(shí)間，轉(zhuǎn)化用戶的目的不同，根據(jù)各個(gè)階段的目的，分析不同事件節(jié)點(diǎn)的數(shù)據(jù)，層層推理即用戶數(shù)據(jù)的分析之道。有關(guān)會(huì)員管理的相關(guān)數(shù)據(jù)（喚醒激活留存）大家可以自行度娘腦補(bǔ)，不再贅述。
安利幾個(gè)針對(duì)數(shù)據(jù)分析中的幾點(diǎn)小tips：
以上觀點(diǎn)，均屬于個(gè)人見解，不代表權(quán)威性不代表絕對(duì)準(zhǔn)確，謹(jǐn)慎采納。
作者：王小命兒，微信號(hào)：wanghuan314400
本文由@王小命兒原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。
者 | 李剛
本文經(jīng)授權(quán)轉(zhuǎn)載自阿里巴巴中間件（ID:ilieyun）
餓了么監(jiān)控系統(tǒng) EMonitor ：是一款服務(wù)于餓了么所有技術(shù)部門的一站式監(jiān)控系統(tǒng)，覆蓋了系統(tǒng)監(jiān)控、容器監(jiān)控、網(wǎng)絡(luò)監(jiān)控、中間件監(jiān)控、業(yè)務(wù)監(jiān)控、接入層監(jiān)控以及前端監(jiān)控的數(shù)據(jù)存儲(chǔ)與查詢。每日處理總數(shù)據(jù)量近 PB ，每日寫入指標(biāo)數(shù)據(jù)量百T，每日指標(biāo)查詢量幾千萬(wàn)，配置圖表個(gè)數(shù)上萬(wàn)，看板個(gè)數(shù)上千。
CAT：是基于 Java 開發(fā)的實(shí)時(shí)應(yīng)用監(jiān)控平臺(tái)，為美團(tuán)點(diǎn)評(píng)提供了全面的實(shí)時(shí)監(jiān)控告警服務(wù)。
本文通過(guò)對(duì)比分析下兩者所做的事情為契機(jī)討論監(jiān)控系統(tǒng)或許該有的面貌，以及淺談下監(jiān)控系統(tǒng)發(fā)展的各個(gè)階段。
首先要強(qiáng)調(diào)的是這里我們只能拿到 GitHub 上開源版 CAT 的最新版 3.0.0 ，所以是基于此進(jìn)行對(duì)比。接下來(lái)說(shuō)說(shuō) CAT 做了哪些事情？
抽象出 Transaction、Event、Heartbeat、Metric 4 種監(jiān)控模型。
Transaction：用來(lái)記錄一段代碼的執(zhí)行時(shí)間和次數(shù)。
Event：用來(lái)記錄一件事發(fā)生的次數(shù)。
Heartbeat：表示程序內(nèi)定期產(chǎn)生的統(tǒng)計(jì)信息, 如CPU利用率。
Metric：用于記錄業(yè)務(wù)指標(biāo)，可以記錄次數(shù)和總和。
針對(duì) Transaction 和 Event 都固定了兩個(gè)維度， type 和 name ，并且針對(duì) type 和 name 進(jìn)行分鐘級(jí)聚合成報(bào)表并展示曲線。
針對(duì)上述 Transaction、Event 的 type 和 name 分別有對(duì)應(yīng)的分鐘級(jí)的采樣鏈路。
目前支持 Counter 和 Timer 類型的打點(diǎn)，支持 tag ，單機(jī)內(nèi)單個(gè) Metric 的 tag 組合數(shù)限制 1000 。并且有簡(jiǎn)單的監(jiān)控看板，如下圖所示：
與其他組件集成
比如和 Mybatis 集成，在客戶端開啟相關(guān)的 sql 執(zhí)行統(tǒng)計(jì)，并將該統(tǒng)計(jì)劃分到 Transaction 統(tǒng)計(jì)看板中的 type=SQL 的一欄下。
可以針對(duì)上述的 Transaction、Event 等做一些簡(jiǎn)單的閾值告警。
餓了么 EMonitor 借鑒了 CAT 的相關(guān)思想，同時(shí)又進(jìn)行了改進(jìn)。
針對(duì) Transaction 和 Event 都固定了兩個(gè)維度， type 和 name ，不同地方在于聚合用戶發(fā)過(guò)來(lái)的數(shù)據(jù)。
CAT 的架構(gòu)圖如下所示：
CAT 的消費(fèi)機(jī)需要做如下兩件事情：
對(duì) Transaction、Event 等消息模型按照 type 和 name 進(jìn)行當(dāng)前小時(shí)的聚合，歷史小時(shí)的聚合數(shù)據(jù)寫入到 mysql 中；
將鏈路數(shù)據(jù)寫入到本地文件或者遠(yuǎn)程 HDFS 上。
EMonitor 的架構(gòu)圖如下所示：
EMonitor 分兩路對(duì)數(shù)據(jù)進(jìn)行隔離處理：
Real-Time Streaming Compute：對(duì)用戶發(fā)過(guò)來(lái)的鏈路中的 Transaction 、Event 等監(jiān)控模型轉(zhuǎn)變成指標(biāo)數(shù)據(jù)并進(jìn)行 10s 的預(yù)聚合，同時(shí)也對(duì)用戶發(fā)過(guò)來(lái)的 Metric 數(shù)據(jù)進(jìn)行 10s 預(yù)聚合。最后將 10s 預(yù)聚合的數(shù)據(jù)寫入到 LinDB 時(shí)序數(shù)據(jù)庫(kù)（已開源，有興趣的可以關(guān)注 star 下）中，以及 kafka 中，讓告警模塊 watchdog 去消費(fèi) kafka 做實(shí)時(shí)告警；
Real-Time Data Writer：對(duì)用戶發(fā)過(guò)來(lái)的鏈路數(shù)據(jù)構(gòu)建鏈路索引、向 HDFS 和 HBase 寫入索引和鏈路數(shù)據(jù)，同時(shí)會(huì)構(gòu)建應(yīng)用之間的依賴關(guān)系，將依賴關(guān)系寫入到 Neo4j 中。
所以 EMonitor 和 CAT 的一個(gè)很大不同點(diǎn)就在于對(duì)指標(biāo)的處理上， EMonitor 交給專業(yè)的時(shí)序數(shù)據(jù)庫(kù)來(lái)做，而 CAT 自己做聚合就顯得功能非常受限，如下所示：
CAT 只能整小時(shí)的查看 type 和 name 數(shù)據(jù)，不能跨小時(shí)，即不能查看任意兩個(gè)時(shí)間之間的報(bào)表數(shù)據(jù)， EMonitor 沒有此限制；
CAT 沒法查看所有 type 匯總后的響應(yīng)時(shí)間和 QPS ， EMonitor 可以靈活的自由組合 type 和 name 進(jìn)行聚合；
CAT 的 type 和 name 報(bào)表是分鐘級(jí)的， EMonitor 是 10s 級(jí)別的；
CAT 的 type 和 name 沒能和歷史報(bào)表曲線直接對(duì)比， EMonitor 可以對(duì)比歷史報(bào)表曲線，更容易發(fā)現(xiàn)問題；
CAT 的 type 和 name 列表首頁(yè)展示了一堆數(shù)字，無(wú)法立即獲取一些直觀信息，比如給出了響應(yīng)時(shí)間 TP99 100ms 這個(gè)到底是好還是壞， EMonitor 有當(dāng)前曲線和歷史曲線，相對(duì)來(lái)說(shuō)可以直接判斷到底 ok 不 ok ；
CAT的TP99、TP999基于單機(jī)內(nèi)某個(gè)小時(shí)內(nèi)的報(bào)表是準(zhǔn)確的，除此之外多機(jī)或者多個(gè)小時(shí)的聚合TP99、TP999是用加權(quán)平均來(lái)計(jì)算的，準(zhǔn)確性有待提高。
但是CAT也有自己的優(yōu)勢(shì)：
CAT 含有 TP999、TP9999 線(但是準(zhǔn)確性還有些問題)， EMonitor 只能細(xì)到 TP99 ；
CAT 的 type 和 name 可以按照機(jī)器維度進(jìn)行過(guò)濾， EMonitor 沒有做到這么細(xì)粒度。
目前 CAT 和 EMonitor 都可以通過(guò) type 和 name 來(lái)過(guò)濾采樣鏈路，不同點(diǎn)在于：
CAT 的采樣鏈路是分鐘級(jí)別的， EMonitor 是 10s 級(jí)別的；
針對(duì)某一個(gè) type 和 name ，CAT 目前無(wú)法輕松找想要的鏈路， EMonitor 可以輕松的找到某個(gè)時(shí)刻或者說(shuō)某段時(shí)間內(nèi)響應(yīng)時(shí)間想要的鏈路（目前已經(jīng)申請(qǐng)專利）。
EMonitor 的鏈路如下所示：
這張圖是某個(gè)10s 時(shí)刻、某個(gè) type 和 name 過(guò)濾條件下的采樣鏈路；
第一行是這 10s 內(nèi)的采樣鏈路，按照響應(yīng)時(shí)間進(jìn)行了排序；
可以隨意點(diǎn)擊某個(gè)響應(yīng)時(shí)間來(lái)查看對(duì)應(yīng)的鏈路詳情。
EMonitor 支持 Counter、Timer、Histogram、Payload、Gauge 等等多種形式的打點(diǎn)方式，并且支持 tag ：
Counter：計(jì)數(shù)累加類型；
Timer：可以記錄一段代碼的耗時(shí)，包含執(zhí)行次數(shù)、耗時(shí)最大值、最小值、平均值；
Histogram：包含 Timer 的所有東西，同時(shí)支持計(jì)算 TP99 線，以及其他任意 TP 線(從 0 到 100 )；
Payload：可以記錄一個(gè)數(shù)據(jù)包的大小，包含數(shù)據(jù)包個(gè)數(shù)、包的最大值、最小值、平均值；
Gauge：測(cè)量值，一般用于衡量隊(duì)列大小、連接數(shù)、CPU、內(nèi)存等等。
也就是任意 Metric 打點(diǎn)都可以流經(jīng) EMonitor 進(jìn)行處理了并輸送到LinDB時(shí)序數(shù)據(jù)庫(kù)中。至此， EMonitor 就可以將任何監(jiān)控指標(biāo)統(tǒng)一在一起了，比如機(jī)器監(jiān)控都可以通過(guò) EMonitor 來(lái)保存了，這為一站式監(jiān)控系統(tǒng)奠定了基礎(chǔ)。
自定義 Metric 看板
CAT只有一個(gè)簡(jiǎn)易的 Metric 看板 EMonitor 針對(duì) Metric 開發(fā)了一套可以媲美Grafana 的指標(biāo)看板，相比 Grafana 的優(yōu)勢(shì)：
有一套類似 SQL 的非常簡(jiǎn)單的配置指標(biāo)的方式；
跟公司人員組織架構(gòu)集成，更加優(yōu)雅的權(quán)限控制，不同的部門可以建屬于自己的看板；
指標(biāo)和看板的收藏，當(dāng)源指標(biāo)或看板改動(dòng)后，無(wú)需收藏人員再改動(dòng)；
alpha、beta、prod 不同環(huán)境之間的一鍵同步指標(biāo)和看板，無(wú)需配置多次；
PC端和移動(dòng)端的同步查看指標(biāo)和看板。
類 SQL 的配置查詢指標(biāo)方式如下所示：
可以配置圖表的展現(xiàn)形式；
可以配置要查詢的字段以及字段之間的加減乘除等豐富的表達(dá)式；
可以配置多個(gè)任意 tag 的過(guò)濾條件；
可以配置 group by 以及 order by。
看板整體如下所示：
移動(dòng)端顯示如下：
目前 EMonitor 已經(jīng)打通了 IaaS 層、 PaaS 層、應(yīng)用層的所有鏈路和指標(biāo)的監(jiān)控，再也不用在多個(gè)監(jiān)控系統(tǒng)中切換來(lái)切換去了，如下所示：
IaaS層物理機(jī)、機(jī)房網(wǎng)絡(luò)交換機(jī)等的監(jiān)控指標(biāo)；
PaaS 層中間件服務(wù)端的監(jiān)控指標(biāo)；
應(yīng)用層 SOA、Exception、JVM、MQ 等客戶端的相關(guān)指標(biāo)；
應(yīng)用層自定義的監(jiān)控指標(biāo)。
以打通餓了么分庫(kù)分表中間件 DAL 為例：
可以根據(jù)機(jī)房、執(zhí)行狀態(tài)、表、操作類型（比如 Insert、Update、Select 等）進(jìn)行過(guò)濾查看：
左邊列表給出每條 SQL 的執(zhí)行的平均耗時(shí)；
右邊2個(gè)圖表給出該條 SQL 在 DAL 中間件層面、 DB 層面的耗時(shí)以及調(diào)用 QPS；
可以給出該 SQL 打在后端 DAL 中間、 DB 上的分布情況，可以用于排查是否存在一些熱點(diǎn)的情況；
還有一些 SQL 查詢結(jié)果的數(shù)據(jù)包大小的曲線、 SQL 被 DAL 限流的情況等等；
可以查看任何時(shí)間點(diǎn)上該 SQL 的調(diào)用鏈路信息。
再以打通餓了么 SOA 服務(wù)為例：
可以根據(jù)機(jī)房和狀態(tài)信息進(jìn)行過(guò)濾；
左邊一欄列出該應(yīng)用提供的 SOA 服務(wù)接口，同時(shí)給出平均響應(yīng)時(shí)間以及和昨天的對(duì)比情況；
右邊的兩個(gè)圖表分別給出了對(duì)應(yīng)服務(wù)接口的服務(wù)響應(yīng)時(shí)間和 QPS 以及和昨天的對(duì)比情況，同時(shí)可以切換平均響應(yīng)時(shí)間到 TP99 或者其他 TP 值，同時(shí)配有可以快速對(duì)相關(guān)曲線添加告警的跳轉(zhuǎn)鏈接；
可以切換到單機(jī)維度來(lái)查看每臺(tái)機(jī)器該 SOA 接口的響應(yīng)時(shí)間和 QPS ，用來(lái)定位某臺(tái)機(jī)器的問題；
可以給出該 SOA 接口調(diào)用在不同集群的分布占比；
可以給出該 SOA 接口的所有調(diào)用方以及他們的 QPS；
可以查看任何時(shí)間點(diǎn)上該 SOA 接口的調(diào)用鏈路信息。
可以針對(duì)所有的監(jiān)控指標(biāo)配置如下告警方式：
閾值：簡(jiǎn)單的閾值告警，適用于 CPU 、內(nèi)存等；
同環(huán)比：與過(guò)去同期比較的告警；
趨勢(shì)：適合于相對(duì)平滑連續(xù)的無(wú)需閾值的智能告警；
其他告警形式。
本階段實(shí)現(xiàn)方式：程序打日志，使用ELK來(lái)存儲(chǔ)和查詢程序的運(yùn)行日志， ELK 也能簡(jiǎn)單顯示指標(biāo)曲線。
排障過(guò)程：一旦有問題，則去 ELK 中搜索可能的異常日志來(lái)進(jìn)行分析排障。
上一個(gè)階段存在的問題：ELK 只是基于一行一行日志進(jìn)行聚合或者搜索分析，日志之間沒有上下文關(guān)聯(lián)。很難知道一次請(qǐng)求耗時(shí)較長(zhǎng)究竟耗時(shí)在哪個(gè)階段。
本階段實(shí)現(xiàn)方式：CAT 橫空出世，通過(guò)建模抽象出 Transaction、Metric 等監(jiān)控模型，將鏈路分析和簡(jiǎn)單的報(bào)表帶入了大家的視野。
告警方式：針對(duì)報(bào)表可以進(jìn)行閾值監(jiān)控排障過(guò)程：一旦有告警，可以通過(guò)點(diǎn)擊報(bào)表來(lái)詳細(xì)定位到是哪個(gè) type 或 name 有一定問題，順便找到對(duì)應(yīng)的鏈路，查看詳細(xì)的信息。
上一階段存在的問題：CAT 對(duì)自定義指標(biāo)支持的比較弱，也無(wú)法實(shí)現(xiàn)或者展現(xiàn)更加多樣的查詢聚合需求。
本階段的實(shí)現(xiàn)方式：支持豐富的 Metric 指標(biāo)，將鏈路上的一些報(bào)表數(shù)據(jù)也可以劃分到指標(biāo)中，交給專業(yè)的時(shí)序數(shù)據(jù)庫(kù)來(lái)做指標(biāo)的存儲(chǔ)和查詢，對(duì)接或者自研豐富的指標(biāo)看板如 Grafana 。
告警方式：針對(duì)指標(biāo)進(jìn)行更加豐富的告警策略排障過(guò)程：一旦有告警，可能需要到各個(gè)系統(tǒng)上查看指標(biāo)看板，粗略定位根因，再結(jié)合鏈路總和分析。
上一階段存在的問題：系統(tǒng)監(jiān)控、中間件和業(yè)務(wù)監(jiān)控、部分業(yè)務(wù)監(jiān)控、鏈路監(jiān)控與指標(biāo)監(jiān)控都各搞一套數(shù)據(jù)收集、預(yù)處理、存儲(chǔ)、查詢、展現(xiàn)、告警流程，各個(gè)系統(tǒng)處理數(shù)據(jù)格式、使用方式不統(tǒng)一。
本階段的實(shí)現(xiàn)方式：打通從系統(tǒng)層面、容器層面、中間件層面、業(yè)務(wù)層面等等的可能的鏈路和指標(biāo)監(jiān)控，統(tǒng)一數(shù)據(jù)的處理流程，同時(shí)整合發(fā)布、變更、告警與監(jiān)控曲線結(jié)合，成為一站式監(jiān)控平臺(tái)。
告警方式：可以統(tǒng)一的針對(duì)各個(gè)層面的監(jiān)控?cái)?shù)據(jù)做統(tǒng)一化的告警排障過(guò)程：只需要在一個(gè)監(jiān)控系統(tǒng)中就可以查看到所有的監(jiān)控曲線和鏈路信息。
目前我們 EMonitor 已完成這個(gè)階段，將公司之前存在已久的 3 套獨(dú)立的監(jiān)控系統(tǒng)統(tǒng)一整合成現(xiàn)如今的一套監(jiān)控系統(tǒng)。
上一階段存在的問題：
用戶雖然可以在一個(gè)系統(tǒng)中看到所有各個(gè)層面的監(jiān)控?cái)?shù)據(jù)了，但是每次排障時(shí)仍然要花很多的時(shí)間去查看各個(gè)層面是否有問題，一旦漏看一項(xiàng)可能就錯(cuò)過(guò)了問題所在的根因；
沒有整個(gè)業(yè)務(wù)的全局監(jiān)控視角，都停留在各自應(yīng)用的角度。
總之：之前的階段都是去做一個(gè)監(jiān)控平臺(tái)，用戶查詢什么指標(biāo)就展示相應(yīng)的數(shù)據(jù)，監(jiān)控平臺(tái)并不去關(guān)心用戶所存儲(chǔ)數(shù)據(jù)的內(nèi)容。現(xiàn)在呢就需要轉(zhuǎn)變思路，監(jiān)控平臺(tái)需要主動(dòng)去幫用戶分析里面所存儲(chǔ)的數(shù)據(jù)內(nèi)容。
本階段的實(shí)現(xiàn)方式：所要做的就是把幫用戶分析的過(guò)程抽象出來(lái)，為用戶構(gòu)建應(yīng)用大盤和業(yè)務(wù)大盤，以及為大盤做相關(guān)的根因分析。
應(yīng)用大盤：就是為當(dāng)前應(yīng)用構(gòu)建上下游應(yīng)用依賴的監(jiān)控、當(dāng)前應(yīng)用所關(guān)聯(lián)的機(jī)器監(jiān)控、redis、MQ、database 等等監(jiān)控，可以時(shí)刻為應(yīng)用做體檢，來(lái)主動(dòng)暴露出問題，而不是等用戶去一個(gè)個(gè)查指標(biāo)而后發(fā)現(xiàn)問題；
業(yè)務(wù)大盤：就是根據(jù)業(yè)務(wù)來(lái)梳理或者利用鏈路來(lái)自動(dòng)生產(chǎn)大盤，該大盤可以快速告訴用戶是哪些業(yè)務(wù)環(huán)節(jié)出的問題。
根因分析：一個(gè)大盤有很多的環(huán)節(jié)，每個(gè)環(huán)節(jié)綁定有很多的指標(biāo)，每次某個(gè)告警出來(lái)有可能需要詳細(xì)的分析下每個(gè)環(huán)節(jié)的指標(biāo)，比如消費(fèi) kafka 的延遲上升，有各種各樣的原因都可能導(dǎo)致，每次告警排查都需要將分析流程再全部人為分析排查下，非常累，所以需要將定位根因的過(guò)程通過(guò)建模抽象下，來(lái)進(jìn)行統(tǒng)一解決。
趨勢(shì)報(bào)表分析：主動(dòng)幫用戶發(fā)現(xiàn)一些逐漸惡化的問題點(diǎn)，比如用戶發(fā)布之后，接口耗時(shí)增加，很可能用戶沒有發(fā)現(xiàn)，雖然當(dāng)前沒有問題，但是很有可能在明天的高峰期就會(huì)暴露問題，這些都是已經(jīng)實(shí)實(shí)在在發(fā)生的事故。
要想做主動(dòng)分析，還深度依賴指標(biāo)下鉆分析，即某個(gè)指標(biāo)調(diào)用量下降了，能主動(dòng)分析出是哪些 tag 維度組合導(dǎo)致的下降，這是上述很多智能分析的基礎(chǔ)，這一塊也不簡(jiǎn)單。
告警方式：可以統(tǒng)一的針對(duì)各個(gè)層面的監(jiān)控?cái)?shù)據(jù)做統(tǒng)一化的告警排障過(guò)程：NOC 根據(jù)業(yè)務(wù)指標(biāo)或者業(yè)務(wù)大盤快速得知是哪些業(yè)務(wù)或者應(yīng)用出先了問題，應(yīng)用的 owner 通過(guò)應(yīng)用大盤的體檢得知相關(guān)的變動(dòng)信息，比如是 redis 波動(dòng)、database 波動(dòng)、上下游應(yīng)用的某個(gè)方法波動(dòng)等等，來(lái)達(dá)到快速定位問題目的，或者通過(guò)對(duì)大盤執(zhí)行根因分析來(lái)定位到根因。
三者關(guān)系如下圖所示：
三者的確都不可或缺，相輔相成，但是我想說(shuō)以下幾點(diǎn)：
三者在監(jiān)控排障中的所占比例卻大不一樣：Metrics 占據(jù)大頭， Tracing 次之， Logging 最后；
Tracing 含有重要的應(yīng)用之間的依賴信息， Metrics 有更多的可深度分析和挖掘的空間，所以未來(lái)必然是在 Metrics 上大做文章，再結(jié)合 Tracing 中的應(yīng)用依賴來(lái)做更深度全局分析，即 Metrics 和 Tracing 兩者結(jié)合發(fā)揮出更多的可能性。
參考鏈接：
CAT：https://github.com/dianping/cat
深度剖析開源分布式監(jiān)控CAT：
https://tech.meituan.com/2018/11/01/cat-in-depth-java-application-monitoring.html
作者簡(jiǎn)介：李剛，網(wǎng)名乒乓狂魔，餓了么監(jiān)控組研發(fā)專家，餓了么內(nèi)部時(shí)序數(shù)據(jù)庫(kù)LinDB項(xiàng)目負(fù)責(zé)人，目前致力于監(jiān)控的智能分析領(lǐng)域。
本文縮略圖：icon by dmbcjl
【END】
說(shuō)，到2020年，有500億設(shè)備要連接網(wǎng)絡(luò)，這是未來(lái)物聯(lián)網(wǎng)的廣闊前景。好消息，以后運(yùn)營(yíng)商也不用跪著發(fā)展客戶了，坐等設(shè)備連接就好了！
不過(guò)，沒那么樂觀！支持物聯(lián)網(wǎng)的無(wú)線技術(shù)太多，蜂窩網(wǎng)絡(luò)也只是其中一小部分而已。
做個(gè)計(jì)算題，假設(shè)500億連接設(shè)備中，減去100億連接手機(jī)和PC，剩下400億去連接物聯(lián)網(wǎng)，按照目前的蜂窩網(wǎng)技術(shù)，估計(jì)只有2%（約8億）的物聯(lián)網(wǎng)設(shè)備可接入蜂窩網(wǎng)絡(luò)。
才8億？我泱泱中華的手機(jī)用戶數(shù)都超過(guò)啦，何況物聯(lián)網(wǎng)那點(diǎn)流量，呵呵！
為了解決這些問題，Cat.0就來(lái)了！
什么是Cat.0？
Cat.即UE-Category，根據(jù)3GPP的定義，UE-Category分為1~10共10個(gè)等級(jí)，其中Cat.1-5為R8定義，Cat.6-8為R10定義，Cat.9-10為R11定義。
如上圖，UE-Category主要定義了UE終端能支持的上下行速率。
Cat.0是被寫入3GPP Rel.12標(biāo)準(zhǔn)，支持更低速率、更低功耗版本的LTE終端等級(jí)。Cat.0和Cat.1都是指向廣闊的物聯(lián)網(wǎng)市場(chǎng)，實(shí)現(xiàn)更低功耗、更低成本物聯(lián)網(wǎng)設(shè)備連接到LTE網(wǎng)絡(luò)。支持更低Category，對(duì)可穿戴設(shè)備、智慧家庭和智慧電表等物聯(lián)網(wǎng)應(yīng)用非常關(guān)鍵。
不過(guò)，一直以來(lái)，無(wú)論是網(wǎng)絡(luò)還是終端芯片，LTE與物聯(lián)網(wǎng)之間總是存在一條難以跨越的鴻溝，不過(guò)，隨著這些年一些通信設(shè)備公司和芯片公司的積極投入，可望改變市場(chǎng)局勢(shì)，為L(zhǎng)TE網(wǎng)絡(luò)連接物聯(lián)網(wǎng)提供更廣闊的前景。比如，前不久，Sequans與Altair相繼宣布近期將推出Cat.0和Cat.1芯片組。
為什么要定義Cat.0呢？
為了應(yīng)對(duì)物聯(lián)網(wǎng)，LTE-M（M2M）必須對(duì)LTE網(wǎng)絡(luò)進(jìn)行幾個(gè)方面的優(yōu)化：
1）設(shè)備成本
盡管大量設(shè)備接入帶來(lái)巨大價(jià)值，但是，連接設(shè)備的成本卻是一個(gè)大問題。連接蜂窩網(wǎng)絡(luò)的設(shè)備需要芯片支持，為了支持高清視頻、在線游戲，目前LTE芯片主要支持幾十到幾百M(fèi)pbs的高速高性能LTE網(wǎng)絡(luò)。芯片支持的速率越高，硬件就越復(fù)雜，成本也就越高。物聯(lián)網(wǎng)M2M應(yīng)用并不需要這么高的速率，甚至有些設(shè)備間連接只需要幾百bps就夠了。因此，為了減小設(shè)備成本，就得簡(jiǎn)化芯片來(lái)滿足物聯(lián)網(wǎng)M2M應(yīng)用需求。
2）電池壽命
我們可以每天給手機(jī)或平板充電，物聯(lián)網(wǎng)設(shè)備不可能每天甚至每個(gè)月為其充電，不僅不方便，而且維護(hù)成本上升。一些設(shè)備需要長(zhǎng)期保持運(yùn)行狀態(tài)，一旦電池耗盡，通信中斷，可能會(huì)導(dǎo)致重大損失。比如，應(yīng)用于火警聯(lián)動(dòng)的設(shè)備直接將信號(hào)傳送至消防中心。超長(zhǎng)的電池使用時(shí)間，就顯得尤為重要。
3）增強(qiáng)覆蓋
對(duì)于物聯(lián)網(wǎng)M2M應(yīng)用，覆蓋同樣非常重要。一個(gè)簡(jiǎn)單的例子，智能水表都安裝在地下室或建筑物內(nèi)隱蔽的地方。由于信號(hào)衰減，通常這些地方信號(hào)偏弱。所以，需要提升增強(qiáng)網(wǎng)絡(luò)覆蓋來(lái)應(yīng)對(duì)物聯(lián)網(wǎng)。
設(shè)備成本
為了減少設(shè)備成本，R12就制定了Cat.0終端等級(jí)，實(shí)際上，Cat.0指的就是低成本的M2M設(shè)備。為了降低設(shè)備復(fù)雜性和減小設(shè)備成本，Cat.0定義了一系列的簡(jiǎn)化方案，主要包括：
1.半雙工FDD模式（Half duplex FDD)。
半雙工FDD模式允許在FDD模式下時(shí)分復(fù)用。
2.減小設(shè)備接收帶寬到1.4MHz，當(dāng)然，也可以擴(kuò)到20MHz。
3.單接收通路，取消RX分集雙通路。
4.低速數(shù)據(jù)速率。不僅降低速率需求，處理器計(jì)算能力和存儲(chǔ)能力也相對(duì)降低。
在R13版本還會(huì)有進(jìn)一步的優(yōu)化，比如取消發(fā)射分集，不再支持MIMO，支持小于1.4MHz更低的帶寬，支持更低的數(shù)據(jù)速率。
關(guān)于Cat.0、Cat.1、Cat.4和R13版本的Cat.的特征比較如下圖：
為了面向物聯(lián)網(wǎng)，降低設(shè)備成本，除了定義Cat.0終端設(shè)備等級(jí)外，還需要對(duì)電池使用時(shí)長(zhǎng)和覆蓋進(jìn)行優(yōu)化。
電池使用壽命
為了省電，R12采用一種叫power saving mode (PSM，省電模式)的方案。如果設(shè)備支持PSM，在附著或TAU（Tracking Area Update）過(guò)程中，PSM向網(wǎng)絡(luò)申請(qǐng)一個(gè)激活定時(shí)器值。當(dāng)設(shè)備從連接狀態(tài)轉(zhuǎn)移到空閑狀態(tài)后，該定時(shí)器開始運(yùn)行。當(dāng)定時(shí)器終止，設(shè)備進(jìn)入省電模式。當(dāng)設(shè)備進(jìn)入省電模式，設(shè)備不再接收尋呼消息，看起來(lái)設(shè)備和網(wǎng)絡(luò)失聯(lián)，但設(shè)備仍然注冊(cè)在網(wǎng)絡(luò)中。設(shè)備將一直保持這種省電模式，直到設(shè)備需要主動(dòng)向網(wǎng)絡(luò)發(fā)送信息（比如周期性TAU，發(fā)送上行數(shù)據(jù)等）。
據(jù)說(shuō)，采用這種方案，兩節(jié)5號(hào)電池可以用10年以上。
如上圖，如果DRX不連續(xù)接收循環(huán)為10分鐘，設(shè)備每周上傳一次數(shù)據(jù)，這樣，兩節(jié)5號(hào)電池可以用132月（11年）之久。
增強(qiáng)覆蓋
在增強(qiáng)覆蓋方面，LTE-M采用的技術(shù)包括：放大數(shù)據(jù)和參考信號(hào)發(fā)射功率、重傳、和降低性能需求，比如，允許更長(zhǎng)時(shí)延和更高的誤碼率。采用這些技術(shù)，覆蓋性能可以提升20dB。
總之，當(dāng)我們?cè)谝?G網(wǎng)絡(luò)更快、更強(qiáng)時(shí)，物聯(lián)網(wǎng)M2M設(shè)備卻不停在喊，低點(diǎn)，再低點(diǎn)，還能再低么？也許后面還有比Cat.0更低的等級(jí)，不過(guò)應(yīng)該叫Cat.幾呢？
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
