我們每天都在使用各式各樣的APP，我們的操作行為也不斷地被APP的開發商收集，這些APP的開發商通過可視化報表平臺，查看APP的用戶行為數據。本文將試圖揭秘，從用戶觸發操作，到這些數據形成可視化報表的整個過程。
聲明下，本文是分享給產品經理們的。長久以來，關于產品經理要不要懂些技術，一直是1個有爭論話題。個人理解，產品經理不需要懂太多技術，但要懂些技術上的基本過程。
所以，本文也將寄希望省略掉非常多的技術細節，說清楚從APP數據上報到展示的整個過程。
一、從SDK到可視化報表的整個過程
從APP端的統計SDK進行數據上報，到最后的可視化報表展示（T+1數據展示），可以概括為下面6個步驟：
- 統計SDK進行原始數據上報，上報到對應的接入服務器；
- 接入服務器把數據寫入到隊列中；
- 數據分析服務器對隊列中的數據進行過濾分析，分析后寫入到本地磁盤；
- 大數據計算服務器定時拉取本地磁盤的數據，進行大數據計算；
- 大數據計算的結果寫入到報表數據庫；
- 讀取報表數據庫數據，進行可視化報表展示。
以下，假定微信Android端，接入了TalkingData（以下簡稱TD） 的Android SDK，對SDK上報的部分步驟，進行解釋。
按照假定，微信獲得了1個TD的分配的APPID。該APPID，就是微信在TD這個統計平臺的身份證，用于唯一標識微信自己的身份。
用戶使用微信時使用的手機硬件信息，以及在微信上的操作行為，就會通過SDK進行上報了。
1. APP數據上報機制
APP數據上報的機制是什么樣的？
基本情況是：
- 重新打開微信時，立即上報一次當前的啟動數據以及上一次的緩存數據；
- 在使用微信的過程中，每隔2分鐘（時間間隔可調整）上報一次數據；
- 將微信退到后臺運行時，立即上報一次數據；
- 正在使用微信時，將微信殺死后，數據將緩存在本地，待下一次啟動微信時進行上報。
以上4個上報機制，每個統計平臺采用的不盡相同，有些平臺提供可選項，由APP方自行決定上報的機制。
一個節省用戶流量的極端上報機制是：本次啟動所產生的數據，一直緩存在客戶端，待下次啟動時進行一次性上報（將上報的時間間隔設為24小時，即等同于本次啟動中的數據，全部緩存在本地）。
通過Android的控制臺，看到最后一行日志時，表示數據上報成功了。
09-24 11:40:31.810 I/TDSDKLog(11497): New data found, Submitting…
09-24 11:40:31.820 I/TDSDKLog(11497): New data len : 2804
09-24 11:40:32.240 I/TDSDKLog(11497): Data submitting Succeed!
2. SDK與服務器之間的對話
SDK和接入服務器的對話可以包括：
SDK：我已經按照參數格式，提交了數據了，你看下。
那么可能發生以下情形：
（1）正常情況
服務器的回復：哦，我看下，提交成功了。下次什么時候提交，你SDK自己來定哈。
（2）拒絕訪
服務器回復：我跟你這個SDK沒啥子關系，你無權訪問。
（3）其他異常情況
服務器回復：這次提交成功了，不過服務器或者網絡好像有點問題，下次提交的時間為30分鐘后。
3. 對數據進行初步分析
步驟2，接入服務器把數據寫入到隊列中，是1個寫數的過程。
我們著重詳細介紹步驟3，對數據進行初步分析。
在步驟3中，服務器將對SDK上報的數據進行寫日志操作。比如，可以按照SDK上報的數據格式輸出json格式串，將json格式串寫入到日志文件中。
定義好每個日志文件的生成規則，比如，每個20分鐘生成1個日志文件，每隔1個小時生成1個文件夾（包含3個文件）。
接下來，就是對數據的初步分析，即對日志文件進行初步解析，將1個大文件，按照規則，切割成不同維度的小文件（表）。比如：切換成10個小文件，第1個小文件存儲手機硬件信息，第2個文件存儲手機的網絡信息，第3個文件存儲埋點事件，等等。
4. 進行大數據計算
經過了步驟3之后，原始數據的簡單數據分析（分類）已經完成了，計算海量的數據，還需要專門的大數據計算平臺，比如：Hadoop之類的。
比如：計算當前應用昨天的新增用戶和活躍用戶數，就可以使用Hadoop中的 mapreduce進行去重。
設想下，1個日活100萬的APP，每個用戶每天平均產生100條數據，那么就有1億條數據，那么對于大數據平臺來說，就有1億個設備號，Hadoop要做的，就是對這1億個設備號進行去重，得到當天的活躍用戶數。
5. 可視化報表展示
步驟5，是大數據平臺將計算好的數據入庫的過程。
我們詳細介紹步驟6，可視化報表展示，對數據進行展示。
在可視化報表中，我們可以看到多種多樣的數據指標，昨日新增、昨日活躍、昨日啟動次數、事件的發生次數、事件的發生人數。
以上數據展示，都是大數據計算后的結果。大數據計算的邏輯，來自于可視化報表的展示需求。
舉例：昨日活躍用戶數，既可以用昨日啟動過應用的設備數來計算，也可以用昨日啟動過應用的手機號數量來計算。前者就是大數據平臺對設備進行去重，后者則是對手機號進行去重了。
三、小結
在本文的撰寫過程中，省略了很多技術細節。
一方面，是因為本人的知識水平有限，無法準確描述；另一方面，本文的出發點，是讓讀者大致了解下從APP上報到可視化報表的過程，這個過程本是1個非常技術化的過程，涉及到非常多的技術要點，我們也需要有選擇省略。
希望，本文對你有所幫助。
本文為@運營喵原創，運營喵專欄作者。
