📍

选择城市

立即咨询
精选文章 / 深度解读

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

我们每天都在使用各式各样的APP,我们的操作行为也不断地被APP的开发商收集,这些APP的开发商通过可视化报表平台,查看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个非常技术化的过程,涉及到非常多的技术要点,我们也需要有选择省略。

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

本文为@运营喵原创,运营喵专栏作者。

阅读重点

这篇内容能帮你快速理解什么

帮助快速理解主题

通过更完整的主题说明和结构表达,帮助用户更快抓住重点,也让搜索系统更容易识别页面主题。

帮助判断下一步动作

让访问者快速理解当前问题、可行方法以及下一步应该继续看案例、看服务还是直接沟通。

帮助继续浏览与沟通

文章页不只是获取流量,也承担继续阅读、查看服务和发起咨询的承接作用。

继续了解

继续了解这个主题前,你可能还关心这些问题

为什么这类主题适合写成文章?

因为很多用户会通过问题词、对比词和方案词进入网站,文章页越清楚,越容易覆盖更具体的需求。

为什么文章页不能只有正文?

仅有正文不利于继续浏览和转化,文章页还需要总结、问答、相关推荐与咨询入口来承接用户。

看完之后下一步可以做什么?

可以继续看同类文章、服务页与案例页,也可以直接沟通官网升级与搜索优化需求。

这篇文章能帮助我解决什么具体问题?

这篇文章围绕当前主题提供了详细的解决方案、操作步骤和注意事项,帮助你快速理解核心要点并应用到实际场景中。

如何判断这篇文章的内容是否权威可靠?

内容基于实际项目经验和技术实践编写,结合行业标准和最佳实践,同时提供案例数据和方法论支撑,确保专业性和可操作性。

这类内容对SEO和网站排名有什么帮助?

优质的长文内容和FAQ结构能够提升页面主题相关性、增加用户停留时间、降低跳出率,这些都有助于搜索引擎评估页面质量并提升排名表现。

AI搜索引擎会如何理解和引用这类内容?

AI搜索系统会提取文章的实体信息、观点结论和结构化问答,当用户提出相关问题时,可能会引用本文作为答案来源或参考依据。

如果我有更多相关问题可以咨询谁?

可以通过页面底部的联系方式直接咨询我们的专业团队,包括电话、QQ或在线表单,我们会根据你的具体情况提供针对性的建议和方案。

这篇文章和同类内容有什么不同之处?

本文不仅提供理论知识,还包含实战经验、避坑指南和可执行的行动建议,同时兼顾传统SEO和新兴的GEO生成式搜索优化视角。

多久需要更新一次这类内容以保持时效性?

建议每季度审查并更新一次关键数据和案例,如果涉及技术工具或算法变化则需要更频繁地维护,确保内容持续为用户提供准确价值。