中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

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

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

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

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

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

1. APP數據上報機制

APP數據上報的機制是什么樣的？

基本情況是：

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

以上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個非常技術化的過程，涉及到非常多的技術要點，我們也需要有選擇省略。

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

本文由 @十三先 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Pexels，基于 CC0 協議