时间: 2021-07-30 10:56:33 人气: 27 评论: 0
我们每天都在使用各式各样的APP，我们的操作行为也不断地被APP的开发商收集，这些APP的开发商通过可视化报表平台，查看APP的用户行为数据。本文将试图揭秘，从用户触发操作，到这些数据形成可视化报表的整个过程。
声明下，本文是分享给产品经理们的。长久以来，关于产品经理要不要懂些技术，一直是1个有争论话题。个人理解，产品经理不需要懂太多技术，但要懂些技术上的基本过程。
所以，本文也将寄希望省略掉非常多的技术细节，说清楚从APP数据上报到展示的整个过程。
从APP端的统计SDK进行数据上报，到最后的可视化报表展示（T+1数据展示），可以概括为下面6个步骤：
以下，假定微信Android端，接入了TalkingData（以下简称TD） 的Android SDK，对SDK上报的部分步骤，进行解释。
按照假定，微信获得了1个TD的分配的APPID。该APPID，就是微信在TD这个统计平台的身份证，用于唯一标识微信自己的身份。
用户使用微信时使用的手机硬件信息，以及在微信上的操作行为，就**通过SDK进行上报了。
APP数据上报的机制是什么样的？
基本情况是：
以上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!
SDK和接入服务器的对话可以包括：
SDK：我已经按照参数格式，提交了数据了，你看下。
那么可能发生以下情形：
（1）正常情况
服务器的回复：哦，我看下，提交成功了。下次什么时候提交，你SDK自己来定哈。
（2）拒绝访
服务器回复：我跟你这个SDK没啥子关系，你无权访问。
（3）其他异常情况
服务器回复：这次提交成功了，不过服务器或者网络好像有点问题，下次提交的时间为30分钟后。
步骤2，接入服务器把数据写入到队列中，是1个写数的过程。
我们着重详细介绍步骤3，对数据进行初步分析。
在步骤3中，服务器将对SDK上报的数据进行写日志操作。比如，可以按照SDK上报的数据格式输出json格式串，将json格式串写入到日志文件中。
定义好每个日志文件的生成规则，比如，每个20分钟生成1个日志文件，每隔1个小时生成1个文件夹（包含3个文件）。
接下来，就是对数据的初步分析，即对日志文件进行初步解析，将1个大文件，按照规则，切割成不同维度的小文件（表）。比如：切换成10个小文件，第1个小文件存储手机硬件信息，第2个文件存储手机的网络信息，第3个文件存储埋点事件，等等。
经过了步骤3之后，原始数据的简单数据分析（分类）已经完成了，计算海量的数据，还需要专门的大数据计算平台，比如：Hadoop之类的。
比如：计算当前应用昨天的新增用户和活跃用户数，就可以使用Hadoop中的 mapreduce进行去重。
设想下，1个日活100万的APP，每个用户每天平均产生100条数据，那么就有1亿条数据，那么对于大数据平台来说，就有1亿个设备号，Hadoop要做的，就是对这1亿个设备号进行去重，得到当天的活跃用户数。
步骤5，是大数据平台将计算好的数据入库的过程。
我们详细介绍步骤6，可视化报表展示，对数据进行展示。
在可视化报表中，我们可以看到多种多样的数据指标，昨日新增、昨日活跃、昨日启动次数、事件的发生次数、事件的发生人数。
以上数据展示，都是大数据计算后的结果。大数据计算的逻辑，来自于可视化报表的展示需求。
举例：昨日活跃用户数，既可以用昨日启动过应用的设备数来计算，也可以用昨日启动过应用的手机号数量来计算。前者就是大数据平台对设备进行去重，后者则是对手机号进行去重了。
在本文的撰写过程中，省略了很多技术细节。
一方面，是因为本人的知识水平有限，无法准确描述；另一方面，本文的出发点，是让读者大致了解下从APP上报到可视化报表的过程，这个过程本是1个非常技术化的过程，涉及到非常多的技术要点，我们也需要有选择省略。
希望，本文对你有所帮助。
本文由 @十三先 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Pexels，基于 CC0 协议
