从APP数据上报到可视化报表展示

一、引言

我们每天都在使用各式各样的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个非常技术化的过程,涉及到非常多的技术要点,我们也需要有选择省略。

希望,本文对你有所帮助。

本文由@十三先原创发表,转载请注明出处。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,240评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,328评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,182评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,121评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,135评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,093评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,013评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,854评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,295评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,513评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,678评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,398评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,989评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,636评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,801评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,657评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,558评论 2 352

推荐阅读更多精彩内容