我們每天都在使用各式各樣的APP，我們的操作行為也不斷地被APP的開發(fā)商收集，這些APP的開發(fā)商通過可視化報表平臺，查看APP的用戶行為數(shù)據(jù)。本文將試圖揭秘，從用戶觸發(fā)操作，到這些數(shù)據(jù)形成可視化報表的整個過程。

聲明下，本文是分享給產(chǎn)品經(jīng)理們的。長久以來，關(guān)于產(chǎn)品經(jīng)理要不要懂些技術(shù)，一直是1個有爭論話題。個人理解，產(chǎn)品經(jīng)理不需要懂太多技術(shù)，但要懂些技術(shù)上的基本過程。

所以，本文也將寄希望省略掉非常多的技術(shù)細節(jié)，說清楚從APP數(shù)據(jù)上報到展示的整個過程。

一、從SDK到可視化報表的整個過程

從APP端的統(tǒng)計SDK進行數(shù)據(jù)上報，到最后的可視化報表展示（T+1數(shù)據(jù)展示），可以概括為下面6個步驟：

1. 統(tǒng)計SDK進行原始數(shù)據(jù)上報，上報到對應的接入服務(wù)器；
2. 接入服務(wù)器把數(shù)據(jù)寫入到隊列中；
3. 數(shù)據(jù)分析服務(wù)器對隊列中的數(shù)據(jù)進行過濾分析，分析后寫入到本地磁盤；
4. 大數(shù)據(jù)計算服務(wù)器定時拉取本地磁盤的數(shù)據(jù)，進行大數(shù)據(jù)計算；
5. 大數(shù)據(jù)計算的結(jié)果寫入到報表數(shù)據(jù)庫；
6. 讀取報表數(shù)據(jù)庫數(shù)據(jù)，進行可視化報表展示。

以下，假定微信Android端，接入了TalkingData（以下簡稱TD） 的Android SDK，對SDK上報的部分步驟，進行解釋。

按照假定，微信獲得了1個TD的分配的APPID。該APPID，就是微信在TD這個統(tǒng)計平臺的身份證，用于唯一標識微信自己的身份。

用戶使用微信時使用的手機硬件信息，以及在微信上的操作行為，就會通過SDK進行上報了。

1. APP數(shù)據(jù)上報機制

APP數(shù)據(jù)上報的機制是什么樣的？

基本情況是：

1. 重新打開微信時，立即上報一次當前的啟動數(shù)據(jù)以及上一次的緩存數(shù)據(jù)；
2. 在使用微信的過程中，每隔2分鐘（時間間隔可調(diào)整）上報一次數(shù)據(jù)；
3. 將微信退到后臺運行時，立即上報一次數(shù)據(jù)；
4. 正在使用微信時，將微信殺死后，數(shù)據(jù)將緩存在本地，待下一次啟動微信時進行上報。

以上4個上報機制，每個統(tǒng)計平臺采用的不盡相同，有些平臺提供可選項，由APP方自行決定上報的機制。

一個節(jié)省用戶流量的極端上報機制是：本次啟動所產(chǎn)生的數(shù)據(jù)，一直緩存在客戶端，待下次啟動時進行一次性上報（將上報的時間間隔設(shè)為24小時，即等同于本次啟動中的數(shù)據(jù)，全部緩存在本地）。

通過Android的控制臺，看到最后一行日志時，表示數(shù)據(jù)上報成功了。

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與服務(wù)器之間的對話

SDK和接入服務(wù)器的對話可以包括：

SDK：我已經(jīng)按照參數(shù)格式，提交了數(shù)據(jù)了，你看下。

那么可能發(fā)生以下情形：

（1）正常情況

服務(wù)器的回復：哦，我看下，提交成功了。下次什么時候提交，你SDK自己來定哈。

（2）拒絕訪

服務(wù)器回復：我跟你這個SDK沒啥子關(guān)系，你無權(quán)訪問。

（3）其他異常情況

服務(wù)器回復：這次提交成功了，不過服務(wù)器或者網(wǎng)絡(luò)好像有點問題，下次提交的時間為30分鐘后。

3. 對數(shù)據(jù)進行初步分析

步驟2，接入服務(wù)器把數(shù)據(jù)寫入到隊列中，是1個寫數(shù)的過程。

我們著重詳細介紹步驟3，對數(shù)據(jù)進行初步分析。

在步驟3中，服務(wù)器將對SDK上報的數(shù)據(jù)進行寫日志操作。比如，可以按照SDK上報的數(shù)據(jù)格式輸出json格式串，將json格式串寫入到日志文件中。

定義好每個日志文件的生成規(guī)則，比如，每個20分鐘生成1個日志文件，每隔1個小時生成1個文件夾（包含3個文件）。

接下來，就是對數(shù)據(jù)的初步分析，即對日志文件進行初步解析，將1個大文件，按照規(guī)則，切割成不同維度的小文件（表）。比如：切換成10個小文件，第1個小文件存儲手機硬件信息，第2個文件存儲手機的網(wǎng)絡(luò)信息，第3個文件存儲埋點事件，等等。

4. 進行大數(shù)據(jù)計算

經(jīng)過了步驟3之后，原始數(shù)據(jù)的簡單數(shù)據(jù)分析（分類）已經(jīng)完成了，計算海量的數(shù)據(jù)，還需要專門的大數(shù)據(jù)計算平臺，比如：Hadoop之類的。

比如：計算當前應用昨天的新增用戶和活躍用戶數(shù)，就可以使用Hadoop中的 mapreduce進行去重。

設(shè)想下，1個日活100萬的APP，每個用戶每天平均產(chǎn)生100條數(shù)據(jù)，那么就有1億條數(shù)據(jù)，那么對于大數(shù)據(jù)平臺來說，就有1億個設(shè)備號，Hadoop要做的，就是對這1億個設(shè)備號進行去重，得到當天的活躍用戶數(shù)。

5. 可視化報表展示

步驟5，是大數(shù)據(jù)平臺將計算好的數(shù)據(jù)入庫的過程。

我們詳細介紹步驟6，可視化報表展示，對數(shù)據(jù)進行展示。

在可視化報表中，我們可以看到多種多樣的數(shù)據(jù)指標，昨日新增、昨日活躍、昨日啟動次數(shù)、事件的發(fā)生次數(shù)、事件的發(fā)生人數(shù)。

以上數(shù)據(jù)展示，都是大數(shù)據(jù)計算后的結(jié)果。大數(shù)據(jù)計算的邏輯，來自于可視化報表的展示需求。

舉例：昨日活躍用戶數(shù)，既可以用昨日啟動過應用的設(shè)備數(shù)來計算，也可以用昨日啟動過應用的手機號數(shù)量來計算。前者就是大數(shù)據(jù)平臺對設(shè)備進行去重，后者則是對手機號進行去重了。

三、小結(jié)

在本文的撰寫過程中，省略了很多技術(shù)細節(jié)。

一方面，是因為本人的知識水平有限，無法準確描述；另一方面，本文的出發(fā)點，是讓讀者大致了解下從APP上報到可視化報表的過程，這個過程本是1個非常技術(shù)化的過程，涉及到非常多的技術(shù)要點，我們也需要有選擇省略。

希望，本文對你有所幫助。

本文由 @十三先 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Pexels，基于 CC0 協(xié)議