移动应用要如何埋点上传才能收集更多数据？
移动应用要如何埋点上传才能收集更多数据？
程君杰，曾就职于阿里巴巴移动事业部，数据技术专家。主要负责业务数据分析挖掘系统架构和设计，包括大规模数据采集、分析处理、数据挖掘、数据可视化、高性能数据服务等。
最近同事在总结关于业界各种埋点技术，在此基础上，结合之前我的一些经验和想法，讲讲数据的生产和采集。
程君杰，曾就职于阿里巴巴移动事业部，数据技术专家。主要负责业务数据分析挖掘系统架构和设计，包括大规模数据采集、分析处理、数据挖掘、数据可视化、高性能数据服务等。
最近同事在总结关于业界各种埋点技术，在此基础上，结合之前我的一些经验和想法，讲讲数据的生产和采集。
很早之前，也就是当年的PC时代，由于受限于存储和计算能力， 大家一般很少用日志来分析业务。 而是在业务逻辑里，将业务需要分析的数据事先写入到库里， 针对库的数据进行统计分析。 所以之前做OLAP， 需要很高级的硬件支持， 大家都去IOE等买昂贵的服务器来做数据仓库以及进行数据分析。 由于成本的问题， 我们拿到的数据是很少的， 所以进行统计分析和挖掘所得到的收益微乎其微。
随着Hadoop的兴起， 分布式文件系统和分布式计算大大降低了存储成本和计算成本， 使得我们现在用日志分析业务成为了可能。
对于移动端的App来说， 分析的数据大致上都可以分为俩种， 一种是在线数据，一种是离线数据。 在线数据， 即App后端服务所产生的日志数据，例如服务接口的性能数据， 服务接口的调用及其参数等， 通过服务端的日志数据， 我们不但可以统计服务接口的性能指标，还可以针对具体的业务逻辑，做相关的分析，一些常见的App分析指标如新增，活跃，累计，留存等，也都可以通过服务日志来统计出来。
对应的离线数据即是App客户端本身产生的数据， 这种情况一般是发生在客户端不调用底层服务的情况下，需要了解用户在客户端的行为，就需要用到离线数据。 离线日志一般记录用户在客户端的具体行为，如用户在客户端的拖动，上下滚动，翻页等不涉及到后端服务的操作，以及App本身的崩溃行为产生的数据， 都可以被记录， 一般的，记录的内容包括事件类型，控件编号，控件属性及相关参数，事件时间等。
在线日志，一般来讲，有两种：
web服务器的配置化log(如Nginx, apache等web服务器的access.log)这一类日志不需要用户自己做实现， 只需要开启web服务器的相关日志功能，即可完成日志记录。
应用服务器的log一般包括应用服务器的配置化log 以及 用户自定义的log。 用户自定义log包括用户通过相关日志组件自己的debug, waring ,error, info等级别的日志。 这一类日志没有固定的格式，完全有用户自行控制。在线日志一般会伴随业务直接产生在相关的业务服务器上(web服务器日志产生在web服务器上)，但是有的时候，为了将相关服务的监控日志与业务分析日志分离，会将业务日志直接记录在一台独立的日志服务器上。
离线日志，一般也有两种：
客户端的行为日志：用户在操作App的时候，产生的行为，都可以记录下来。 行为日志一般是用来研究用户使用习惯， 分析应用的使用热度的。 同时可以结合客户端异常日志来分析异常原因。
客户端的异常日志：用来监控客户端异常原因， 帮助解决相关问题。
5埋点及上传
不管是在线日志，还是离线日志，我们首先都要确认在什么地方记录日志， 于是我们就引入了埋点的概念。 通俗的讲，在正常业务代码逻辑上， 添加记录日志的代码， 都叫做埋点。 但是一般的，埋点只用来描述客户端日志记录。
由于在线日志是直接产生在服务器端， 日志采集工具可以直接从含有日志的服务器上采集日志数据到相应的文件系统， 所以不存在日志上传的问题。但是对于离线日志来说， 数据是产生在客户端的， 所以上传机制必须考虑。
6离线日志上传机制
业界采用的离线日志上传机制如下:
服务端提供日志记录接口，当客户端有事件时，直接调用日志记录接口将日志记录在服务器端。
服务端提供日志上传接口， 客户端先将日志暂存客户端本地，当达到一定的大小，网络环境允许的情况下， 通过上传接口，将日志文件打包压缩后上传。
第一种上传方式，时效性方面有一定的保障， 在网络环境允许的情况下，能及时的将信息记录到服务器，但是当埋点较多时，记录日志产生的流量会很大，占据很大的带宽，给用户带来损失。 同时， 前端的某些行为，如在某个activity停留时间等也无法通过这种在线的方式捕获。 还有一个重要的问题是， 由于客户端数据没有暂存机制， 当网络暂时无法使用时， 日志记录接口无法正常调用， 所有的日志也就随之丢失。 第二种方式，在时效性上较差，因为它需要等待数据累计到一定程度，或者网络允许的情况下，如在wifi情况下，才发送，但是占用的带宽相对较小， 对客户端动作的捕获较为灵活。
7埋点的三种方案
1、传统埋点：开发者直接在客户端埋点。
优点： 开发者可以随意的在任何地方添加埋点。
缺点： 成本高，每次埋点的增删改都需要发版，很难控制。启明星现在采用的就是传统的埋点方式， 由于之前没有统一的规划， 相关页面的同一个按钮，不同的版本功能不同， 但却埋了同一个点， 造成统计比较混乱。之后我们引入了埋点下发平台，虽然一定程度上缓解了这种问题，但是由于其灵活性以及主观性， 问题依然无法避免。
2、可视化埋点：由于传统埋点的一系列问题， 自然而然的就产生了可视化埋点的方案， 用可视化交互的手段来代替写代码，将核心代码和配置，资源分开， 在App启动是通过网络更新配置和资源来实现埋点功能。
可视化埋点的大体流程如下：
首先埋点服务平台与埋点客户机做关联， 包括客户机包含的埋点模块扫描当前整个客户端页面的控件，形成控件树，并将当前页面截图，发送给埋点服务端平台；
埋点服务端平台接收到截图和控件树数据后，在服务端重新绘制App界面，通过可视化交互的方式，给当前页面需要埋点的控件上添加事件，添加完毕后，形成配置文件， 并发布上线；
装有埋点模块的所有客户端，接收到配置文件并解析， 根据配置为页面中相关的控件添加监听事件， 当这些控件出发事件时记录日志。
其中有很多细节的地方需要注意：
可视化埋点也需要考虑不同版本之间埋点的差异；
可视化埋点在分发埋点配置文件的时候，会有延迟或者丢失的情况， 有的客户端有可能收不到或者很久才能收到配置文件，这样埋点的时效性会大打折扣。
3、无埋点：所谓的无埋点，其实也就是全埋点， 它和可视化埋点很像， 可视化埋点是根据埋点配置来收集数据，而无埋点方案则是尽可能的收集所有控件的操作数据。 实现原理也很简单， 客户端添加扫描代码， 为每个扫描到的控件添加监听事件。 当事件被触发后，记录日志。
其实我想，大家对此也不陌生，比如很早之前，对PC站点的统计， 各大分析平台，都需要在网页
之间添加一段js代码。 其实那段js代码， 就是我们现在提到的无埋点的扫描代码。
这里强调一下， 由于可视化埋点是在需要的时候才埋点， 所以它并不能回溯事件，也就是说，我们只能统计需求提出后，埋点开始的所有的数据，埋点之前的数据我们是拿不到的。 而无埋点方案， 在开始埋点的时候，所有的数据已经都被记录了， 所以它可以查看之前的数据 (这里的之前也是相对与提统计需求的时间，而不是相对于埋点的时间)， 也就是说它可以做回溯。 而这种回溯是建立在大量存储要求的基础上的。
不管是哪种解决方案，我们的目的只有一条，就是尽可能多的收集需要的数据， 所以在实际操作过程中， 我们可以根据具体情况，多种方案相结合使用。
本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：
用云栖社区APP，舒服~
【云栖快讯】Apache旗下顶级开源盛会 HBasecon Asia 2018将于8月17日在京举行，现场仅600席，免费赠票领取入口&&
用配置管理（Application Configuration Management，简称 ...
充分利用阿里云现有资源管理和服务体系，引入中间件成熟的整套分布式计算框架，以应用为中心，帮助...
阿里云推出的一款移动App数据统计分析产品，为开发者提供一站式数据化运营服务
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效...
阿里云总监课正式启航什么是埋点？埋点的目的是什么？
我是一枚运营，运营的工作无非就是拉新用户，促进用户活跃推广产品，所以会定期策划些活动来炒热社区的活跃度，然而上次举办了活动之后发现效果貌似没之前那么好，用户的参与度不高，反馈了这个问题之后我们老大直接来了一句，做个数据的埋点监控用户行为。我：？？？然后，就没有然后了（高冷的上司抛下一句话后留下风中凌乱的我）所以想请问各位，数据埋点是什么东西？怎么监控用户行为？
一周前 115.7K人阅读
微信扫码，立即分享
与更多互联网人一起讨论，共同成长
是否确认删除，删除后将无法恢复
绑定邮箱，互动信息不遗漏
您好，作为天天问会员可享受专属通知服务
绑定邮箱，您的提问或回答有新动态，我们将会通知您
人人都是产品经理注册 | 登录
SensorsData.cn
从零开始学运营，10年经验运营总监亲授，2天线下集训+1年在线学习，做个有竞争力的运营人。
行业差异性明显、企业实际需求不同，因此埋点方式也应有所不同。究竟该如何科学采集数据？要真正实现精细化运营，企业数据采集所采用的埋点方式不应“千企一面”，而应该“因企而异”。
一、适合前端埋点的企业业务需求
无论是自建数据分析平台，还是采用第三方数据分析工具，梳理企业需求是第一步，随后按照企业需求完成事件和埋点方案的设计，这也正是神策数据为客户提供多维度数据分析的根基与前提。一般而言，以全埋点（无埋点）为典型代表的前端埋点方案，适合有以下需求的企业。
1、处于运营初级阶段，产品功能相对简单
例如，如阅读类、词典类工具性APP的企业客户，在其发展初期的产品运营阶段，产品功能较为基础，无明确业务数据、交易数据，仅通过UV、PV、点击量等基本指标分析即可满足需求。由于神策分析（Sensors Analytics）支持全埋点，SDK支持默认采集APP或者网页浏览页面、激活、启动等前端数据，这类客户可以基于此衡量用户留存以及活跃度。如图1，某广告企业了解用户渠道来源，并判断不同渠道和不同推广方式的投放效果。
图1 不同渠道和推广方式的效果分析（图片来源：神策数据产品）
2、需要分析与后端没有交互的前端行为
若运营人员工作需要判断前端界面设计是否合理，是必须采用前端埋点方案的。这也是后端代码埋点无法完全代替全埋点的原因。
二、强烈建议后端埋点的业务需求
除了支持“前端埋点”（全埋点）方式，神策数据为保证数据采集做到“大、全、细、时”，更推荐“后端埋点”：当前后端都可以实现数据采集时，应优先考虑后端（代码）埋点，尤其在各行业中有特殊业务需求的数据，更是强烈建议通过后端（代码）埋点方式采集。总的来说，后端（代码）埋点，或者“后端（代码）埋点+全埋点”方案，适合有以下需求的企业。
1、追求精细化运营，需要进行多维数据分析的企业
更多的企业有精细化运营的诉求，科学埋点为运营人员后续进行多维度分析提供保障。《迷城物语》是玩心（上海）网络科技有限公司所研发游戏之一，首日即在各地区App Store和Google Play商店登顶并持续霸榜。其技术负责人马宗骥，在近日公开分享数据驱动游戏设计中介绍：在游戏领域想实现实现精准运营，进行多维数据分析应该优先考虑后端埋点，单纯依赖前端数据采集有许多弊端。
例如，有时玩家已经退出游戏，但是链接还在，则前端采集不准，此时PCU数据无法正确衡量服务器的负载情况、数据库的压力情况等，而通过后端代码埋点解决了这一问题。再如，他介绍：“NPC（非玩家控制角色）状态、副本状态、经济系统实时状态等统计类数据，这些是前端埋点无法统计到的，而在后端采集数据可根据实际情节灵活完成数据统计工作。”
如图2，运营人员精准找到游戏流失点。在100～110级流失的玩家所操控的角色大多停留在“打怪”动作上，机械地打怪练级,玩家开始感觉枯燥甚至疲惫。找到这一“流失点”后，《迷城物语》运营人员可以适当调整该关卡的怪物数量，并增加新鲜因素，从而平衡游戏趣味性和玩家精力。
图2 《迷城物语》玩家“流失点”分析（图片来源：神策数据产品）
2、包含用户资产数据、用户账户体系相关数据、风控辅助数据等重要业务数据的网站或APP的企业
如电商客户、互联网金融包含用户认证身份信息、手机号码、充值账户信息等数据，前端数据无法进行深入分析。再如，在互联网金融企业，最大痛点莫过于揪出“羊毛党”了。“羊毛党”手里握着大量的代理IP、手机虚拟号。这一群体特征十分明显，通常是经过注册、领取福利、流失。这就需要运营人员从IP、设备信息、注册信息、活跃度等进行多维度分析。用户留存是互联网金融企业判断客户是否是“羊毛党”的方式之一。如图3，一般用户完成新手项目（领取福利后），未进行第二次投资，则可能是“羊毛党”成员，在该平台上点击相关数字，人员明细会详细展示出来。
图3 “羊毛党”用户甄别——留存数据细查（图片来源：神策数据产品）
3、对数据安全要求比较高的企业
从后端采集数据，例如采集后端的日志，实质上是将数据采集的传输与加密交给了产品本身，认为产品本身的后端数据是可信的。而后端采集数据到分析系统中则是通过内网进行传输，这个阶段不存在安全和隐私性问题。同时，内网传输基本不会因为网络原因丢失数据，所以传输的数据可以非常真实地反应用户行为在系统中的真实体现。基于后端采集此优势，神策分析目前提供了 Java、PHP、Python、Ruby 等后端语言的 SDK，以及 LogAgent、BatchImporter、FormatImporter 等导入工具，支持在后端采集。
图5 适合“前端全埋点”的企业需求与适合“后端代码埋点”的企业需求（图片来源：神策数据产品）
综上所属，笔者做出如下总结：
没有任何一种通用数据采集方式，是适合所有企业业务诉求的。根据行业领先企业实践来看，后端代码埋点才是距精细化运营最近的数据采集方式；
不从行业特性、自身实际需求出发的数据采集方案，都是耍流氓。
作者：张乔，神策数据内容营销高级经理，用户行为洞察研究院负责人。公众号：用户行为洞察研究院
本文由 @张乔-神策 原创发布于人人都是产品经理。未经许可，禁止转载。
赞赏是对原创者的最大认可
赞赏5人打赏
收藏已收藏 | 141赞已赞 | 20
SensorsData.cn
产品经理群
运营交流群
品牌营销群
文案交流群
Axure交流群
关注微信公众号
大家都在问
7个回答3人关注
5个回答3人关注
20个回答21人关注
12个回答16人关注
9个回答9人关注
10个回答13人关注posts - 2,&
comments - 0,&
trackbacks - 0
关于数据采集（也就是所谓的埋点），有很多中形式，或者说方法。所有的数据采集都时围绕一个核心的三个点来做区别的处理。
数据采集核心思维三个点：
　　要采集谁，一个页面、一个按钮，页面或者按钮，就是我们要采集数据的对象，对象是个结果，数据采集代码/埋点，首先就是要完成定位的功能；
2、动作/条件；
　　用户触发什么动作、发生什么事件，完成什么条件，也就是触发做数据采集的引线；
　　在特定的对象上，触发了需要监控的动作，需要记录那些数据，来表示用户这个行为的东西/字段，统称为数据。
在当理解了这三个点，再去理解现在所谓的，可视化埋点、无埋点、GTM标签管理工具，就简单很多了。
可视化埋点
　　对象：运营人员在后端，设置需要采集那个点；
　　动作：点击；
　　数据：点击的位置信息/按钮名称；
　　对象：任何位置；
　　动作：点击；
　　数据：点击的位置信息
无埋点/可视化埋点的共同点：都是把数据采集三要素中的（动作/条件），都固定为点击，采集的（数据）都是用户点击的位置，或者是按钮的名称；
无埋点/可视化埋点区别：（对象）不同；无埋点对对象的筛选/定位，在接收服务器端做，可视化埋点对对象的筛选/定位，在用户端实现。
标签管理工具
主流的标签管理工具，像Google的DTM，Adobe的DTM，在数据采集功能（埋点）上（注：标签管理工具里面还有很多非数据采集的功能点），都是把对象、动作/条件、数据，这三点，区分在不同的功能模块中，在埋点时，一步一步的完成这三个流程，来实现数据采集（埋点）。
以GTM为例：
GTM里面有触发器、代码、变量三块，他们分别的对应关系如下：
触发器，就是完成数据采集中，（动作/条件）的这个点
代码，主要就是控制我们需要传输的字段（数据）以及，把数据采集三个核心点串联起来；
变量，是数据采集中的（对象）；
当我们遇到问题（数据采集不到，不知道怎么采集数据）&可以把问题分拆成上述三部分，重新整理思路，找到问题点。
阅读(...) 评论()从数据产品经理视角，聊聊埋点的意义
什么是埋点？怎么埋点呢？本文作者从数据产品经理的角度来为你讲解。
一、数据过程
数据生产-数据采集-数据处理-数据分析和挖掘-数据驱动/用户反馈-产品优化/迭代。
用户操作app时产生行为数据，通过数据采集系统采集，对采集的数据进行处理（实时数据处理+离线数据处理）得到统计数据进行数据分析，并将结果呈现出来以复盘总结当前版本并驱动下一个产品迭代，或者清洗后的数据进行数据挖掘，实时反馈给用户（如推荐）。
数据采集，顾名思义采集相应的数据，是整个数据流的起点，采集的全不全、对不对，直接决定数据广度和质量，影响后续所有的环节。
在数据采集失效性、完整性不好的公司，经常会有业务方发现数据发生的大幅度变化，追其所以时发现是数据采集的问题（见附注）。而另一方面，采集什么数据才能有效的得到数据分析结论，才能有效的进行推荐，就需要提前规划埋点。
当前数据采集普遍遇到的几个问题：
实时性，对于工具性产品在无网条件下的数据，无法实时上报；
完整性，由于用户隐私协议&欧盟通用数据保护条例的，部分数据无法采集；
异常，android_id、idfa、idfv 随版本升级变化或无法获取。
二、数据埋点
接下来用5w2h的思路来看埋点。
1. 埋点是什么？
所谓“埋点”，是数据采集领域（尤其是用户行为数据采集领域）的术语，指的是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。比如用户某个icon点击次数、观看某个视频的时长等等。
埋点的技术实质，是先监听软件应用运行过程中的事件，当需要关注的事件发生时进行判断和捕获。
特别注意需要明确事件发生时间点、判别条件，这里如果遇到不清楚的，需要和开发沟通清楚，避免采集数据与理想存在差异。例如：期望采集某个app的某个广告的有效曝光数，有效曝光的判别条件是停留时长超过1秒且有效加载出广告内容。
2. 埋点是谁的工作？
现在公司通常都会有数据产品经理或业务线数据分析师，结合版本迭代过程进行埋点规划。如果是代码埋点，还需要开发完成相应的埋点代码。
3. 在什么时间点&在哪里埋点呢？
埋点是目的导向。
在产品规划时就要思考数据埋点问题，如果在产品外发后再考虑怎么埋点，就会导致前期版本用户的数据无法收集，想要看某个数据时就会非常无奈，只有等到新版本完善来弥补。
思考要埋哪些点、埋点的形式，需要紧密结合产品迭代的方向、运营需求，并和数据开发等进行充分沟通以确认：
埋点能够得到想要的数据解决/支持；
能够得到当前版本的复盘情况；
后续版本的数据支撑。
通常的沟通过程以 埋点文档为载体；数据埋点评审为终结。
当前版本的复盘情况：
新版本功能使用情况，是否符合预期；
新功能上线后对其他功能点的影响？是否为整体均有积极作用；
版本运营活动目标群体的特征获取;
新增商业化目标的监测……
后续版本的数据支撑：
规划方向的用户行为分析
画像特征分析
4. 怎么埋点呢？
4.1 埋点技术：代码埋点、可视化埋点、无埋点
接着第一节：埋点是什么？来看下埋点技术层面的区分：代码埋点、可视化埋点和无埋点。
（1）代码埋点
以为需要监测网站上/app上用户的行为，是需要在网页/app中加上一些代码的，当用户触发相应行为时，进行数据上报，也就是代码埋点。这样的代码，在网站上叫监测代码，在app中叫SDK（Software Development Kit）。市场上的第三方数据采集均支持代码埋点，GA, GrowingIO，神策等。
优点：可以详细的设置某一个事件自定义属性；
缺点：时间、人力成本大，数据传输的时效性。
（2）可视化埋点
利用可视化交互手段，数据产品/数据分析师可以通过可视化界面（管理后台连接设备） 配置事件，如下是腾讯移动分析的可视化埋点界面。可视化埋点仍需要先配置相关事件，再采集。
优点：埋点只需业务同学接入，无需开发支持；
缺点：仅支持客户端行为。
（3）无埋点
无埋点是指开发人员集成采集 SDK 后，SDK 便直接开始捕捉和监测用户在应用里的所有行为，并全部上报，不需要开发人员添加额外代码。
数据分析师/数据产品 通过管理后台的圈选功能来选出自己关注的用户行为，并给出事件命名。之后就可以结合时间属性、用户属性、事件进行分析了。所以无埋点并不是真的不用埋点了。
无需开发，业务人员埋点即可；
支持先上报数据，后进行埋点。
数据量大；
仅仅支持客户端。
无埋点和可视化埋点均不需要开发支持，仅数据业务同学进行设置即可。但两者数据上报-埋点设置存在加大的差异：无埋点支持在数据上报之后再进行埋点设置，因而数据采集/上报的量远大于可视化埋点。
因而无埋点的数据大都有清空机制，例如growingIO，允许版本发布后7天内设置埋点，超过7天数据清空，无法追溯。
4.2 埋点技术：客户端埋点 & 服务端埋点
（1）客户端埋点
能够搜集页面展示、点击行为；
可以收集不需要请求服务器的数据，如音乐的本地播放、页面停留时长等。
由于数据上报需要网络，当用户产生行为而没有网络时，则会延迟上报数据，影响数据的实时性。这点在工具型产品上表现尤其强烈。
如果用户删除自己的APP操作记录，或者无网连接时数据存储达到上限，则会造成数据丢失，影响数据的完整性。
当需要改变埋点时，需要更新版本才行，但是会存在有些用户不更新版本情况，影响数据质量。
（2）服务端埋点
实时性好：实时收集，数据很准确，不存在延时上报；
变更成本小：当要改变埋点时，只要改变，上报数据就会改变；
能够收集不在APP内发生的行为，只要请求服务器就行，而客户端只能收集在客户端中的操作行为，如统计从其他APP引流的安装量。
不能收集不需要请求服务器的数据；
用户没联网的时候不能够采集数据。
当前大多数产品&公司都是客户端、服务端相结合。
（3）各种埋点场景&埋点建议
服务端数据：安装数据，下载后安装情况；内容数据，比如某个视频内容 曝光/展示/播放数据；搜索内容。
以视频产品为例的一次埋点过程：
1. 明确产品动态，梳理数据需求；
当前为一个视频社区软件，增加了**舞蹈跟拍**功能，用户可以根据不用的舞蹈来进行拍摄（运营同学对舞蹈进行了分类，主打几个舞蹈），目的是为了给用户提供低成本创造视频内容的方式。
基于上述的产品目的，期望能了解：
a.该功能的使用情况（uv，pv，使用过程漏斗）;
b.生产的视频情况（视频数,视频的互动情况），是否能实现促进内容生产带动社区氛围的目标。
2. 数据需求转化为指标&埋点，并与数据开发进行讨论；
a.功能使用uv、pv；
b.对其他拍摄功能的影响；
a，b：可以服务端打点，也可以客户端打点，但因为视频社区的基于内容的互动行为基本都在服务端，所以建议服务端打点。
c.拍摄流程的转化漏斗；拍摄流程主要是页面的点击过程，故使用客户端埋点，并记录uv，pv。
d.跟拍视频的播放、点赞、评论、分享、关注、二次被跟拍的情况；
f.跟拍舞蹈的类型，明确用户是否偏向于某个类型的舞蹈跟拍；
d，f服务端，基于内容的互动行为基本都在服务端。
3. 版本上线；
4. 按照预期进行数据分析，产品迭代复盘。数据分析过程，注意查看是否与预期相符，是否有优化点。
在了解埋点知识时，参考的文章，在此非常感谢：
https://blog.csdn.net/heatdeath/article/details/
http://www.chinawebanalytics.cn/auto-event-tracking-good-bad-ugly/
https://blog.csdn.net/wangyiyungw/article/details/
https://www.cnblogs.com/111testing/p/7672833.html
https://blog.csdn.net/wangyiyungw/article/details/
https://www.zhihu.com/question//answer/
本文由 @cecil 原创发布于人人都是产品经理。未经许可，禁止转载
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点