一种数据采集方法、装置、终端及存储介质与流程

本发明涉及大数据的数据采集技术领域，特别涉及一种数据采集方法、装置、终端及存储介质。

背景技术：

随着互联网的发展，基于用户行为数据的采集和分析在企业的运营和决策中占有越来越重要的地位。

目前大部分的数据采集都是采用传统的数据埋点技术，数据埋点技术需要经历“梳理线上业务、提出埋点需求、评估埋点排期、技术人员进行集成统计代码并进行埋点、埋点测试验收”等一系列流程；流程比较复杂，人力资源耗费大，开发周期时间长，并且部分埋点会影响应用程序的自身逻辑；另外产品一经上线，即使发现有遗漏的埋点也只能通过发版来补充，同时历史数据也无法追溯，不能灵活的满足相关分析人员(如：产品经理、运营人员或者是后台维护人员等能够获得指标定义权限的人员)的分析需求，效率低下。

技术实现要素：

有鉴于此，本申请提供一种能够自动采集数据，减少人工操作以及简化数据采集流程的数据采集方法、装置、终端及存储介质。

一方面，本申请提供一种数据采集方法，应用程序中集成有数据采集软件开发工具包(softwaredevelopmentkit，sdk)，所述方法包括：

所述数据采集sdk自动获取所述应用程序的运行数据；

所述数据采集sdk将获取到的所述应用程序的运行数据转换为数据文件；

所述数据采集sdk将所述数据文件上传至服务器。

可选地，所述数据采集sdk自动获取所述应用程序的运行数据包括：

监听所述应用程序的用户界面，获取所述用户界面的运行数据；

遍历所述用户界面的元素，采集所述元素的运行数据。

可选地，所述数据采集sdk将所述数据文件上传至服务器包括：

获取所述服务器配置的数据上报方式；

将所述数据文件按照所述数据上报方式上传至服务器。

可选地，所述数据上报方式包括：实时上报和非实时上报；所述非实时上报包括按条数上报、按文件大小上报和/或按时间间隔上报。

另一方面，本申请提供一种数据采集装置，包括应用程序和数据采集sdk，所述应用程序中集成有所述数据采集软件开发工具包sdk，所述数据采集sdk包括：

数据获取模块，用于所述数据采集sdk自动获取所述应用程序的运行数据；

数据转换模块，用于所述数据采集sdk将获取到的所述应用程序的运行数据转换为数据文件；

数据上报模块，用于所述数据采集sdk将所述数据文件上传至服务器。

可选地，所述数据获取模块包括：

监听模块，用于监听所述应用程序的用户界面，获取所述用户界面的运行数据；

遍历模块，用于遍历所述用户界面的元素，采集所述元素的运行数据。

可选地，所述数据上传模块包括：

配置模块，用于获取所述服务器配置的数据上报方式；

上传模块，用于将所述数据文件按照所述数据上报方式上传至服务器。

可选地，所述数据上报方式包括：实时上报和非实时上报；所述非实时上报包括按条数上报、按文件大小上报和/或按时间间隔上报。

另一方面，本申请提供一种数据采集终端，包括处理器和存储器，所述存储器存储集成有数据采集软件开发工具包(softwaredevelopmentkit，sdk)的应用程序，所述处理器调用所述应用程序并执行上述的数据采集方法。

另一方面，本申请提供一种存储介质，存储集成有数据采集软件开发工具包(softwaredevelopmentkit，sdk)的应用程序，所述应用程序执行上述的数据采集方法。

本发明申请实施例提供的一种数据采集方法、装置、终端及存储介质采用在应用程序中集成智能sdk实现自动采集应用程序的运行数据，无需手动埋点，简化数据采集流程，实现历史数据的可追溯；并且采用集成智能sdk还可以规避手动埋点影响应用程序代码逻辑的问题。

附图说明

图1为本申请一实施例提供的数据采集方法的流程图；

图2为本申请一实施例提供的数据采集方法的流程图；

图3为本申请一实施例提供的数据采集装置的结构示意图；

图4为本申请一实施例提供的数据采集装置的结构示意图；

图5为本申请一实施例提供的数据采集终端执行数据采集方法流程图一；

图6为本申请一实施例提供的数据采集终端执行数据采集方法流程图二；

图7为本申请一实施例提供的数据采集sdk的内部工作流程图；

图8为本申请一实施例提供的实现可视化操作的工作流程图；

图9-1为本申请一实施例提供的可视化页面指标定义界面图；

图9-2为本申请一实施例提供的可视化元素指标定义界面图；

图9-3为本申请一实施例提供的定义指标完成在后台的展示图；

图10为本申请一实施例提供的电子设备的硬件结构示意图。

具体实施方式

传统的数据埋点技术需要经历“梳理线上业务、提出埋点需求、评估埋点排期、技术人员进行集成统计代码并进行埋点、埋点测试验收”的流程。流程复杂，耗费较大的人力，需要付出较高的时间成本和沟通成本；而且部分埋点会影响应用自身逻辑；另外产品一经上线，即使发现有遗漏的埋点也只能通过发版来补充，同时历史数据也无法追溯，不能灵活的满足相关分析人员(如：产品经理、运营人员或者是后台维护人员等能够获得指标定义权限的人员)的分析需求，效率低下。

基于现有技术中数据采集方法的不足，本申请实施例提供的一种数据采集方法及装置，能够自动采集数据，无需埋点，简化数据采集流程，并且实现历史数据的可追溯。

下面结合本发明的附图对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

参见图1，本申请一实施例提供的数据采集方法，包括步骤101至步骤104。

步骤101：应用程序中集成有数据采集软件开发工具包(softwaredevelopmentkit，sdk)。

所述应用程序包括手机应用程序和电脑应用程序。

步骤102：所述数据采集sdk自动获取所述应用程序的运行数据。

所述数据采集sdk为智能采集sdk，所述智能采集sdk自动获取的运行数据是约定好规范的数据和自定义数据；在采集页面时将页面类名作为唯一标识，采集元素时将元素的路径和元素上的文字作为元素的唯一标识。

步骤103：所述数据采集sdk将获取到的所述应用程序的运行数据转换为数据文件。

步骤104：所述数据采集sdk将所述数据文件上传至服务器。

本实施例中，所述数据采集sdk集成在应用程序中，规避了手动埋点影响应用程序代码逻辑的问题；当所述应用程序启动后，无需人工埋点就可以对用户在应用程序操作过程中产生的交互数据进行自动采集，极大的节省了人力成本和时间成本，并且相关分析人员(如：产品经理、运营人员或者是后台维护人员等能够获得指标定义权限的人员)能够随时去查看元素的历史数据来辅助优化以及决策。

本申请一实施例中，数据采集sdk自动获取所述应用程序的运行数据包括：

监听所述应用程序的用户界面，获取所述用户界面的运行数据；监听所述应用程序的启动和退出事件，监听应用程序的锁屏和应用程序解锁屏幕，所述应用程序进入后台和切回前台、应用崩溃和应用报错以及界面类名(安卓中的activity、ios中的controller、js中的url)变化等。

遍历所述用户界面的元素，采集所述元素的运行数据；通过监听获得所述应用程序的当前用户界面，获取到当前用户界面的整个布局结构，拆解所述应用程序中的布局，然后通过递归算法遍历查询所述当前用户界面整个布局中的节点元素，为所述元素分配唯一id，方便在服务器通过id对所述元素进行统计计算，这个id保证在所述应用程序的所有版本是一致的，所述id和界面类名的唯一性都是保证采集的数据在时间轴上连续可识别的重要保证。

所述数据采集sdk基于对于页面布局的拆解，为全局的ui元素分配了唯一id，当所述数据采集sdk将获取到的运行数据上传至服务器后，无论是历史版本还是当前版本的元素，相关分析人员都可以通过数据统计客户端对用户界面元素进行可视化的定义，无需撰写代码，直接为需要统计的元素命名即可创建统计指标。

本实施例中，用户客户端中的应用程序中集成数据采集sdk，所述数据采集sdk自动获取所述客户端中的应用程序的运行数据，再将所述运行数据压缩成数据文件按照服务器的数据上报方式提交至服务器，相关分析人员通过数据统计客户端与所述服务器的数据接口可以对用户界面元素进行可视化的定义，无需撰写代码，直接为需要统计的元素命名即可创建统计指标。

所述运行数据包括用户的点击行为数据和用户的浏览行为数据，所述用户行为数据包括用户的点击行为、浏览行为等，所述智能sdk还会采集启动应用程序各个终端的设备、网络、位置信息，界面切换和元素被点击是用户行为触发的，通过页面和元素的监听实现对用户行为数据的采集，元素被点击产生数据，数据记录了用户的行为。

本申请一实施例中，数据采集sdk能够为设备生成唯一标识来标记用户的设备，能够将用户在界面中的跳转路径(包括原生与h5界面之间的跳转)通过日志的形式记录下来，能够通过生成会话标记来拆解用户使用应用的次数；追踪用户行为的日志，在应用被启动、监测到网络、应用锁屏、应用进入后台时均会上传到服务器。

数据采集sdk在应用程序的用户界面发生切换时，记录界面切换及相关属性信息；在所述用户界面的元素被点击时，记录点击事件及相关属性信息；在所述应用程序被启动时，记录所述应用程序的启动事件及相关属性信息；在所述应用程序发生异常时，记录所述应用程序的异常事件及相关属性信息；并且将上述所有信息通过日志的形式记录并上传至服务器，日志的形式为logname:{key1:value；key2:value2…keyn:valuen}，日志遵循一定的数据规范，上述日志均为数据采集sdk采集应用程序的运行数据。

所述数据采集sdk能够采集的数据覆盖接入应用程序以下相关数据：应用程序版本号；应用程序的账号相关信息：如用户标识；终端的相关信息：如设备型号；应用程序终端的相关时间信息：如事件发生的时间、网络环境信息：如网络运营商；应用程序终端的位置信息：如经纬度；应用程序页面信息：如页面类名；应用程序的事件信息：如被点击元素的路径；应用程序的会话信息：如所述数据采集sdk分配的会话id；应用程序的异常信息：如崩溃原因；广告相关信息：如广告来源等；所述数据采集sdk可以获取全量用户行为数据，并且用户行为数据的采集项目不会发生变化。

本申请一实施例，数据采集sdk将所述数据文件上传至服务器包括：

获取所述服务器配置的数据上报方式；所述服务器搭建后，配置好数据接口就可以接收数据采集sdk的运行数据，配置方式可以选择批量上报数据也可以选择实时上报数据，即所述应用程序启动，行为发生即刻产生日志数据上传给服务器；

将所述数据文件按照所述数据上报方式上传至服务器；所述数据采集sdk将采集到的运行数据进行压缩，压缩成数据文件按照所述服务器配置的数据上报方式发送至服务器；在服务器没有进行配置的情况下，默认数据上报方式：5条/批；如果有配置则按照配置方式进行数据上报。

本申请一实施例中所述数据上报方式包括：实时上报和非实时上报；所述非实时上报包括按条数上报、按文件大小上报和/或按时间间隔上报；在有网络的情况下，数据采集sdk将获取的应用程序的运行数据压缩成数据文件按照服务器数据上报方式进行数据文件的批量上报，当用户进行锁屏或者切入后台，所述应用程序都进入了后台，这时用户如果没有杀进程，所述数据采集sdk会在后台进行数据文件的上传，减少数据的丢失，最大可能的将获取到的数据上传至服务器。

参见图2，本申请一实施例中，以服务器端为例，一种数据采集方法，包括步骤201至步骤203。

步骤201：接收集成在应用程序的数据采集软件开发工具包(softwaredevelopmentkit，sdk)自动获取的数据文件。

本实施例中，数据文件包括：对运行数据进行转换，得到数据文件。

步骤202：分析所述数据文件，得到所述应用程序不同类型的运行数据。

本实施例中，服务器根据数据采集sdk获取运行数据的日志类型开发数据接口，接收所述数据采集sdk获取的运行数据文件后将所述数据文件解压成运行数据。

步骤203：将所述不同类型的运行数据分别存储到对应的数据表中。

本实施例中，服务器根据数据采集sdk获取运行数据的日志类型开发数据接口，接收所述数据采集sdk获取的运行数据文件后将所述数据文件解压成运行数据，然后按照所述运行数据的日志类型分别存储在所述服务器的数据表中，相关分析人员能够随时去查看历史数据来辅助优化以及决策。

本实施例中，所述接收集成在应用程序的数据集成sdk获取的数据文件还包括：若所述数据文件接收成功，则删除所述数据文件在所述应用程序的缓存；若所述数据文件接收不成功，则继续接收来自所述应用程序的数据文件。

本实施例中，服务器接收数据成功会给所述应用程序所在客户端返回值，客户端得知接收成功则删除本地数据，否则会在下一个触发上传数据的点继续进行上传。

参见图3，本申请一实施例提供一种数据采集装置，包括应用程序和数据采集sdk，所述应用程序中集成有所述数据采集软件开发工具包sdk，所述数据采集sdk包括：

数据获取模块301，用于所述数据采集sdk自动获取所述应用程序的运行数据；

数据转换模块302，用于所述数据采集sdk将获取到的所述应用程序的运行数据转换为数据文件；

数据上报模块303，用于所述数据采集sdk将所述数据文件上传至服务器。

可选地，所述数据获取模块301包括：

监听模块，用于监听所述应用程序的用户界面，获取所述用户界面的运行数据；

遍历模块，用于遍历所述用户界面的元素，采集所述元素的运行数据。

可选地，所述数据上传模块303包括：

配置模块，用于获取所述服务器配置的数据上报方式；

上传模块，用于将所述数据文件按照所述数据上报方式上传至服务器；

可选地，所述数据上报方式包括：实时上报和非实时上报；所述非实时上报包括按条数上报、按文件大小上报和/或按时间间隔上报。

本实施例中，智能数据采集sdk动态获取服务器配置的数据上传策略参数，另外在用户锁屏及进入后台的场景下也能够进行数据的上传；同时，数据采集sdk会对网络状态进行实时监控，以在监测到网络讯号时进行数据的上传；对于应用程序的启动，以及用户在对用户界面元素操作过程中产生的交互数据，不需要人工手动埋点，数据采集sdk可通过优化的递归算法进行全量数据的采集。

上述为本实施例的数据采集装置的示意性方案。需要说明的是，该数据采集装置的技术方案与上述的数据采集方法的技术方案属于同一构思，数据采集装置的技术方案未详细描述的细节内容，均可以参见上述数据采集方法的技术方案的描述。

参见图4，本申请一实施例提供一种数据采集装置，设置于服务器中，包括：

数据接收模块401，用于接收集成在应用程序的数据采集sdk获取的数据文件；

数据分析模块402，用于分析所述数据文件，得到所述应用程序不同类型的运行数据；

所述运行数据包括用户的点击行为数据和用户的浏览行为数据，所述用户行为数据包括用户的点击行为、浏览行为等，所述智能sdk还会采集启动应用程序各个终端的设备、网络、位置信息，界面切换和元素被点击是用户行为触发的，通过页面和元素的监听实现对用户行为数据的采集，元素被点击产生数据，数据记录了用户的行为。

数据存储模块403，用于将所述不同类型的运行数据分别存储到对应的数据表中。

可选地，所述数据文件包括：对运行数据进行转换，得到数据文件。

可选地，所述数据接收模块401还包括：

判断模块，若所述数据文件接收成功，则删除所述数据文件在所述应用程序的缓存；若所述数据文件接收不成功，则继续接收来自所述应用程序的数据文件。

传统埋点逻辑中，没有手动埋点的元素的用户界面事件是不可追溯历史的，通过本实施例数据采集sdk对全量数据的采集，相关分析人员能够随时去查看元素的历史数据来辅助优化以及决策；所述数据采集sdk对于应用程序来说是通用的统计工具，不需要手动埋点的同时，规避了手动埋点影响应用代码逻辑的问题。

上述为本实施例的数据采集装置的示意性方案。需要说明的是，该数据采集装置的技术方案与上述的数据采集方法的技术方案属于同一构思，数据采集装置的技术方案未详细描述的细节内容，均可以参见上述数据采集方法的技术方案的描述。

参见图5，本申请提供一种数据采集终端，包括处理器和存储器，所述存储器存储集成有数据采集软件开发工具包(sdk)的应用程序，所述处理器调用所述应用程序并执行步骤501至步骤503的数据采集方法。

步骤501：所述数据采集sdk自动获取所述应用程序的运行数据。

步骤502：所述数据采集sdk将获取到的所述应用程序的运行数据转换为数据文件。

步骤503：所述数据采集sdk将所述数据文件上传至服务器。

可选地，所述数据采集sdk自动获取所述应用程序的运行数据包括：

监听所述应用程序的用户界面，获取所述用户界面的运行数据；

遍历所述用户界面的元素，采集所述元素的运行数据；

可选地，所述数据采集sdk将所述数据文件上传至服务器包括：

获取所述服务器配置的数据上报方式；

将所述数据文件按照所述数据上报方式上传至服务器。

可选地，所述数据上报方式包括：实时上报和非实时上报；所述非实时上报包括按条数上报、按文件大小上报和/或按时间间隔上报。

本实施例中，智能数据采集sdk动态获取服务器配置的数据上传策略参数，另外在用户锁屏及进入后台的场景下也能够进行数据的上传；同时，数据采集sdk会对网络状态进行实时监控，以在监测到网络讯号时进行数据的上传；对于应用程序的启动，以及用户在对用户界面元素操作过程中产生的交互数据，不需要人工手动埋点，数据采集sdk可通过优化的递归算法进行全量数据的采集

上述为本实施例的数据采集终端的示意性方案。需要说明的是，该数据采集终端的技术方案与上述的数据采集方法的技术方案属于同一构思，数据采集终端的技术方案未详细描述的细节内容，均可以参见上述数据采集方法的技术方案的描述。

参见图6，本申请一实施例提供一种数据采集终端，包括处理器和存储有计算机程序的存储器，所述处理器调用所述计算机程序并执行步骤601至步骤603的数据采集方法。

步骤601：接收集成在应用程序的数据采集软件开发工具包(softwaredevelopmentkit，sdk)自动获取的数据文件。

步骤602：分析所述数据文件，得到所述应用程序不同类型的运行数据。

步骤603：将所述不同类型的运行数据分别存储到对应的数据表中。

可选地，所述数据文件包括：对运行数据进行转换，得到数据文件。

可选地，所述接收集成在应用程序的数据集成sdk获取的数据文件还包括：

若所述数据文件接收成功，则删除所述数据文件在所述应用程序的缓存；

若所述数据文件接收不成功，则继续接收来自所述应用程序的数据文件。

传统埋点逻辑中，没有手动埋点的元素的用户界面事件是不可追溯历史的，通过本实施例数据采集sdk对全量数据的采集，相关分析人员能够随时去查看元素的历史数据来辅助优化以及决策；所述数据采集sdk对于应用程序来说是通用的统计工具，不需要手动埋点的同时，规避了手动埋点影响应用代码逻辑的问题。

上述为本实施例的数据采集终端的示意性方案。需要说明的是，该数据采集终端的技术方案与上述的数据采集方法的技术方案属于同一构思，数据采集终端的技术方案未详细描述的细节内容，均可以参见上述数据采集方法的技术方案的描述。

本申请一实施例提供一种存储介质，存储集成有数据采集软件开发工具包(sdk)的应用程序，所述应用程序执行以下数据采集方法：

所述数据采集sdk自动获取所述应用程序的运行数据；

所述数据采集sdk将获取到的所述应用程序的运行数据转换为数据文件；

所述数据采集sdk将所述数据文件上传至服务器。

上述为本实施例的一种存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的数据采集方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述数据采集方法的技术方案的描述。

本申请一实施例提供一种存储介质，存储有计算机程序，所述计算机程序执行以下数据采集方法：

接收集成在应用程序的数据采集软件开发工具包(softwaredevelopmentkit，sdk)自动获取的数据文件；

分析所述数据文件，得到所述应用程序不同类型的运行数据；

将所述不同类型的运行数据分别存储到对应的数据表中。

上述为本实施例的一种存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的数据采集方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述数据采集方法的技术方案的描述。

参见图7，本申请一实施例中，数据采集sdk工作流程包括如下步骤701至步骤719。

步骤701：流程开始。

步骤702：启动应用程序，获取上报方式。

向服务器申请数据的上传方式，在获取不到的情况下，会按照默认方式5条/批进行数据上传；在获取成功的情况下，按照服务器配置的数据上报方式进行数据上报。

步骤703：打印启动日志，写入缓存。

数据采集sdk打印应用程序的启动日志，记录用户启动应用程序的相关信息，其中包括“项目标识、包名、应用版本号、渠道号、设备唯一标识、设备型号、操作系统、操作系统版本号、屏幕分辨率、广告标识符号、处理器、日志打印客户端时间、联网方式、网络运营商、联网ip、经度、纬度”，并且分配会话id，会话id的分配规则是“时间戳_随机数”，用于划分用户与应用的每一次交互。

步骤704：判断是否有网络。

若有网络，则进入步骤705；若没有网络则判断无网络情况下应用程序内是否可以进行操作，不可以操作就不产生日志，反之可以产生日志，若可以操作则进入步骤717，若不可以操作则进入步骤716；其中用户的行为日志会主要是用户切换页面的日志和用户的点击行为日志。

用户切换页面日志会采集进入ui界面的相关信息及用户的相关信息，包括“项目标识、应用版本号、渠道号、用户id、广告标识符号、设备唯一标识、操作系统、页面类名、进入页面的客户端时间、会话id、联网ip、页面类型”；用户的点击行为日志会采集用户点击元素的信息，点击元素所在页面信息及用户信息，具体包括“事件id、项目标识、应用版本号、渠道号、用户id、广告标识符号、设备唯一标识、操作系统、日志打印客户端时间、操作类型、操作横坐标、操作纵坐标、元素上文字、元素路径、元素类型、各层级元素索引md5加密形式、元素所在页面、会话id、页面类型、联网ip”。

步骤705：需要上报启动/崩溃日志；判断本地缓存中是否有需要上报的启动日志或崩溃日志，若需要上报则进入步骤706；若不需要上报则进入步骤707。

步骤706：上报启动日志/崩溃日志。

进行启动日志或崩溃日志的上报，崩溃日志在app发生崩溃的时候会产生并且保存在本地缓存，崩溃日志采集了应用发生崩溃时的相关信息，包括“项目标识、异常类型、异常信息详情、应用运行内存、应用版本号、渠道号、用户id、设备唯一标识、设备型号、操作系统、日志打印客户端时间、操作系统版本号、广告标识符号、处理器、是否越狱、是否破解、当前剩余内存、会话id联网ip”。

步骤707：判断用户对否进行其他操作。

判断用户是否有点击或切换页面的操作，如果有的话进入步骤708，没有的话进入步骤716。

步骤708：打印日志写入缓存。

生成用户的交互日志并写入本地缓存。

步骤709：判断是否有网络。

若网络服务正常，则进入步骤710，若网络服务异常则进入步骤718。

步骤710：判断是否达到服务器配置上报条件。

数据采集sdk判断是否达到服务器配置的上报条件，若已经达到条件则进入步骤711，根据配置上传缓存日志；若没有达到条件则进入步骤712。

步骤711：根据服务器配置上传缓存日志。

步骤712：判断是否进入后台或锁屏或退出应用。

判断此时app是否进入后台、用户是否进行了锁屏或退出应用的操作，若满足上述三个条件之一，则数据采集sdk会开始执行步骤713，开始批量上报缓存中的日志。

步骤713：批量上报缓存中的日志。

步骤714：判断服务器是否接收成功。

服务器接收成功则进入步骤715，删除已经上报成功的日志在本地的缓存；若服务器没有反馈接收成功，则进入步骤709。

步骤715：删除已经上传成功日志在本地缓存。

步骤716：判断是否退出应用。

若没有退出则进入步骤704，若退出应用则进入步骤719，结束全部流程。

步骤717：打印行为日志写入缓存。

步骤718：判断app内是否可操作。

步骤719：结束。

参见图8、图9-1至图9-3，本申请一实施例中，相关分析人员对数据采集sdk获取到的数据实现可视化操作包括如下步骤801至步骤813。

步骤801：流程开始。

步骤802：启动app；所述app为相关分析人员才能获得权限来进行操作，普通用户无法进行操作。

步骤803：选中内容。

在app页面通过蓝色光标来选择需要进行定义的元素，若点击光标表示选中了当前页面；通过移动光标覆盖元素来选中具体的元素。

步骤804：高亮选中内容；即选中的元素突出显示。

步骤805：进入指标定义页面；填写完整定义指标的必要信息。

所述指标包括页面的指标和元素的指标等可视化行为指标，具体指标包括页面的浏览量、浏览用户数、浏览帐号数；元素的点击量、元素点击用户数据、元素点击帐号数等。

步骤806：判断是否保存指标；分析人员填写完整定义指标的必要信息并提交保存则进入步骤807，反之则进入步骤803，重新选择需要定义的元素。

步骤807：判断指标是否名称重复/指标定义重复。

若出现名称重复则会进入步骤809提示用户修改指标，用户修改之后会进入步骤806进行保存；若在没有重复则进入步骤808。

步骤808：判断服务器是否反馈成功保存；若保存成功则进入步骤811。若保存失败则进入步骤810。

步骤809：提示用户修改指标。

步骤810：指标定义失败。

步骤811：指标定义成功。

步骤812：判断是否退出指标定义；步骤810和步骤811结束后进入步骤812判断分析人员是否退出指标定义，若相关分析人员退出指标定义则进入步骤813，若没有退出指标定义则进入步骤803。

步骤813：结束。

本实施例中，所述数据采集sdk自动获取所述客户端中的应用程序的运行数据，再将所述运行数据压缩成数据文件按照服务器的数据上报方式提交至服务器，相关分析人员通过数据统计客户端与所述服务器的数据接口对用户界面元素进行可视化的定义，无需撰写代码，直接为需要统计的的元素命名即可创建统计指标。

下面以集成有智能数据采集sdk的安卓系统客户端的应用程序为例进行说明。

获取页面跳转浏览日志：通过注册一个安卓系统activity生命周期的监听，对原生页面获取焦点和销毁的时候分别去做监听，获取页面的变化，就可以记录上一个页面到当前页面的数据日志。当手机切到后台超过30s的时间就代表用户的一个操作会话结束，当用户锁屏超过30s的时间也代表用户的一个操作会话结束，这个时候会打印一条页面跳转结束的日志。

抓取用户行为点击日志：当应用程序启动，界面呈现给用户时，智能采集sdk会自动监听获取当前页面，然后可以获取到页面的整个布局结构，通过列递归算法遍历查询布局结构中的所有节点元素；

当用户点击一个页面元素的时候，可以抓取到手指点击所在屏幕的坐标，同时开启一个子线程，用被点击元素的状态变化，过滤不符合条件的元素，再用这个坐标点通过递归算法，计算过滤剩下不符合条件的元素，最终确定是哪个元素被点击了，并记录用户的点击行为数据日志。

安卓原生控件在响应事件的时候，会有一个事件响应状态值的变化，再加上手指触发事件所在的位置和遍历的元素的所在范围做计算，就可以找到响应事件的元素了。

收集数据：抓取到用户的行为数据和业务数据后，根据服务配置的上报的方式上报数据，在没有网络的情况下，会缓存到本地，在有网络或者重新启动或者条件合适的时候再次将本地缓存的数据上报到服务器。

可视化行为指标定义：传统的数据收集的方式比较繁琐，需要在收集的点添加收集数据的方法，造成接入比较混乱，而且在后台维护和使用起来也非常麻烦，集成本实施例的智能数据采集sdk后，可以通过可视化行为指标定义在移动端查看当前指标元素的浏览量或者点击量，使用起来非常方便，不用预先将别名写死。

在可视化行为指标定义的时候，手指移动定位选择圆点，在移动的同时，遍历查询当前页面的所有节点元素，根据当前蓝色小圈的位置(手指的位置)，计算最小范围的页面布局节点，获取这个节点的区域范围，计算手指所在坐标是否在这个元素节点的区域范围内，如果蓝色小圈的坐标点在这个元素节点区域范围内，就根据当前的节点元素的坐标范围，在它上面添加一个蓝色覆盖层，表示目前选中一个元素；当相关分析人员确定要查看这个元素的相关数据信息(比如点击量、浏览量)时松开手指就可以了，智能采集sdk会自动到后台查询这个节点元素的相关数据，然后展示给相关分析人员，相关分析人员可以为选中的元素命名，方便以后在平台上查看。

上述数据采集方法、装置、终端及存储介质适用于所有系统，不仅限于安卓系统，并且可以同时被大量用户使用，各个终端的智能采集sdk分别独立运行，进行数据采集和上传。

图10是本申请实施例提供的数据采集方法的电子设备的硬件结构示意图，如图10所示，该电子设备包括：

一个或多个处理器1001以及存储器1002，图10中以一个处理器1001为例。

执行数据存储方法的设备还可以包括：输入装置1003和输出装置1004。

处理器1001、存储器1002、输入装置1003和输出装置1004可以通过总线或者其他方式连接，图10中以通过总线1005连接为例。

存储器1002作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本申请实施例中的数据存储方法对应的程序指令/模块(例如，附图3所示的各个模块)。处理器1001通过运行存储在存储器1002中的非易失性软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例的数据存储方法。

存储器1002可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据数据存储装置的使用所创建的数据等。此外，存储器1002可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器1002可选包括相对于处理器1001远程设置的存储器，这些远程存储器可以通过网络连接至数据存储装置。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置1003可接收输入的数字或字符信息，以及产生与数据存储装置的用户设置以及功能控制有关的键信号输入。输出装置1004可包括显示屏等显示设备。

所述一个或者多个模块存储在所述存储器1002中，当被所述一个或者多个处理器1001执行时，执行上述任意方法实施例中的数据存储方法。

上述产品可执行本申请实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本申请实施例所提供的方法。

本发明实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括:智能手机、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：掌上电脑(pdapersonaldigitalassistant)、移动互联网设备(mid，mobileinternetdevice)和超级移动个人计算机(umpc，ultra-mobilepersonalcomputer)设备等。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括:音频、视频播放器，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子装置。

在本申请所提供的多个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的检测装置的实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信链接可以是通过一些接口，模块的间接耦合或通信链接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本发明所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本发明优选实施例只是用于帮助阐述本发明。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本发明的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本发明。本发明仅受权利要求书及其全部范围和等效物的限制。