数据分析入门初识数据埋点埋点数据监控 _经验分享

什么是埋点埋点，是网站分析的一种常用的数据采集方法。数据埋点分为初级、中级、高级三种方式。数据埋点是一种良好的私有化部署数据采集方式。
埋点技术如何采集数据，有何优缺点？
数据埋点分为初级、中级、高级三种方式，分别为：
初级：在产品、服务转化关键点植入统计代码，据其独立ID确保数据采集不重复（如购买按钮点击率）；
中级：植入多段代码，追踪用户在平台每个界面上的系列行为，事件之间相互独立（如打开商品详情页——选择商品型号——加入购物车——下订单——购买完成）；
高级：联合公司工程、ETL采集分析用户全量行为，建立用户画像，还原用户行为模型，作为产品分析、优化的基础。
无疑，数据埋点是一种良好的私有化部署数据采集方式。数据采集准确，满足了企业去粗取精，实现产品、服务快速优化迭代的需求。
但，因手动埋点工程量极大，且一不小心容易出错，成为很多工程师的痛。且其开发周期长，耗时费力，很多规模较小的公司并不具备自己埋点的能力。无埋点成为市场新宠。最后埋点、无埋点两种技术谁能成为最后赢家，我们拭目以待。
关于数据埋点，你需要知道的技术方案和规范流程埋点是数据采集的专用术语，在数据驱动型业务中，如营销策略、产品迭代、业务分析、用户画像等，都依赖于数据提供决策支持，希望通过数据来捕捉特定的用户行为，如按钮点击量、阅读时长等统计信息。因此，数据埋点可以简单理解为：针对特定业务场景进行数据采集和上报的技术方案。
数据埋点非常看重两件事，一个是数据记录的准确性，另一个则是数据记录的完备性。
先讲数据的准确性。数据埋点非常强调规范和流程，因为参数的规范与合法，将直接影响到数据分析的准确性，如果准确性得不到保障，那么所有基于埋点得出的结论，都是不可信的。辛辛苦苦做了很久的方案，一旦因为一个疏忽的小问题，导致下游集中投诉，其实非常划不来。
道理每个人都懂，但现实情况中，数据埋点所面对的客观环境，其实非常复杂，例如：
因此本文有非常长的篇幅来写流程问题，其实是非常有必要的。
再讲数据的完备性。因为埋点主要是面向分析使用，对用户而言是个额外的功能，因此埋点的业务侵入性很强，很容易对用户体验造成影响。别的不说，仅仅是流量的消耗，就很容被用户喷。因此，要提前想清楚，我们要采集哪些东西，因为修改方案的成本，是伤不起的。
通常情况下，我们需要记录用户在使用产品过程中的操作行为，通过4W1H模型可以比较好的保障信息是完备的。4W1H包括：
规定好记录信息的基本方法之后，按照固定的频率，如每小时、每天，或者是固定的数量，比如多少条日志，或者是网络环境，比如在Wifi下上传，我们就可以开心的把埋点数据用起来了。
当然，数据记录的时效性也比较重要，但因为埋点数据通常量级会比较大，且各个端数据回传的时间不同，因此想做到实时统计，还是需要分场景来展开。在Flink技术日渐成熟的今天，全链路的实时采集与统计，已经不是什么难题。
在埋点的技术方案中，首先要重视的，是用户唯一标识的建设。如果做不到对用户的唯一识别，那么基础的UV统计，都将是错误的。
因此，在数据埋点方案中，有两个信息是一定要记录的，即设备ID+用户ID 。设备ID代表用户使用哪个设备，如安卓的ANDROID_ID/IMEI ， IOS中的IDFA/UDID ，浏览器的Cookie ，小程序的OpenID等。用户ID ，代表用户在产品中所注册的账号，通常是手机号，也可以是邮箱等其他格式。
当这两个信息能够获得时，不论是用户更换设备，或者是同一台设备不同账号登录，我们都能够根据这两个ID ，来识别出谁在对设备做操作。
其次，我们来看一下Web的数据采集技术。Web端数据采集主要通过三种方式实现：服务器日志、URL解析及JS回传。
浏览器的日志采集种类又可以分为两大类：页面浏览日志和页面交互日志。
除此之外，还有一些针对特定场合统计的日志，例如页面曝光时长日志、用户在线操作监控等，但原理都基于上述两类日志，只是在统计上有所区分。
再次，我们来看下客户端的数据采集。与网页日志对应的，是手机应用为基础的客户端日志，由于早期手机网络通讯能力较差，因而SDK往往采用延迟发送日志的方式，也就是先将日志统计在本地，然后选择在Wifi环境下上传，因而往往会出现统计数据延迟的情况。现如今网络环境好了很多， 4G、5G流量充足，尤其是视频类APP基本上都是一直联网，因而很多统计能够做到实时统计。
客户端的日志统计主要通过SDK来完成，根据不同的用户行为分成不同的事件， “事件”是客户端日志行为的最小单位，根据类型的不同，可以分为页面事件（类比页面浏览）和控件点击事件（类比页面交互）。对于页面事件，不同的SDK有不同的方式，主要区别为是在页面创建时发送日志，还是在页面浏览结束后发送日志，区别在于业务统计是否需要采集用户的页面停留时长。
页面事件的统计主要统计如下三类信息：
埋点其实还需要考虑数据上传的方案，批量的数据可以通过Flume直接上报，流式的可以写到Kafka ，或者直接使用Flink来处理。这些框架相关的内容不是本文考虑的重点，有兴趣的可以自行查阅资料。
有了指导思路和技术方案后，我们就可以着手制定相应的数据埋点流程规范了。
笼统上，流程规范会分成五个步骤，即需求评审、埋点申请、技术开发、埋点验证、发布上线。
第一步，需求评审。
前文提到过，数据埋点的方案一旦确定，返工和排查问题的成本都很高，但数据埋点之后的分析工作，又涉及到了PD、BI、算法、数据等多个角色。因此非常有必要，将需求内容和数据口径统一收口，所有人在一套口径下，将需求定义出来，随后业务侧再介入，进行埋点方案的设计和开发。
以前文提到的4W1H模型为例，常见的记录内容如下：
最后我们统计时，按照上述约定，统计用户在某个时间和地点中，看到了哪些信息，并完成了怎样的动作。上下游的相关人员，在使用这份数据时，产生的歧义或者是分歧，会小很多。
第二步，埋点申请
当下的热门应用，大多是以超级APP的形式出现，比如微信、淘宝、支付宝、抖音，超级APP会承载非常多的业务，因此技术方案上会十分统一。
因此，当我们的技术方案确定后，通常要在相应的埋点平台上，进行埋点申请。申请的内容包括分配的SPM、SCM码是什么，涉及到的平台是哪些，等等。SPM、SCM是什么，有什么用，同样可以自行查阅。
第三步，技术开发
当需求确定、申请通过后，我们就可以开始开发动作了，这里基本上是对研发同学进行约束。埋点的开发，简单讲，是分成行为埋点和事件埋点两个大类，每一类根据端的不同进行相应的开发。具体的技术方案详见前文01章节。
详细的设计规范，是需要留文档的，因为代码不能反应业务的真实意图，而不论是事后复盘与业务交接，都需要完整的文档来阐述设计思路。
第四步，埋点验证
埋点的验证很关键，如果上线后才发现问题，那么历史数据是无法追溯的。
验证有两种方式，一种是实时的功能验证，一种是离线的日志验证。
实时功能验证，指功能开发好后，在灰度环境上测试相应的埋点功能是否正常，比如点击相应的业务模块，日志是否会正确的打印出来。通常而言，我们需要验证如下三个类型的问题：
除去实时验证，我们也需要把日志写到测试环境中，查看数据上报的过程是否正确，以及对上报后的数据进行统计，侧面验证记录的准确性，如统计基本的PV、UV ，行为、事件的发生数量。
很多时候，数据是需要多方验证的，存在一定的上下游信息不同步问题，比如对某个默认值的定义有歧义，日志统计会有效的发现这类问题。
第五步，发布上线。
应用的发布上线通常会有不同的周期，例如移动端会有统一的发版时间，而网页版只需要根据自己的节奏走，因此数据开始统计的时间是不同的。最后，应用应当对所有已发布的埋点数据，有统一的管理方法。
大多数时候，数据埋点的技术方案，只需要设计一次，但数据准确性的验证，却需要随着产品的生命周期持续下去，因此仅仅依靠人肉来准确性验证是不够的，我们需要平台来支持自动化的工作。埋点的准确性，大体有两种方法保障：一种是灰度环境下验证真实用户数据的准确性；另一种则是在线上环境中，验证全量数据的准确性。因此，发布上线之后，后续的管理动作，应该是对现有流程的自动化管理，因为团队大了，需要埋点的东西多种多样，让平台自己测试、自动化测试，就是很多测试团队必须走的路
数据分析与埋点，产品经理必须掌握的知识和技能产品经理必须随时全面而准确地了解自己产品的各项数据，否则只能凭着感性在规划和设计产品，容易犯错误。因此，看哪些数据，如何统计和分析数据，如何进行数据埋点，都是产品经理必须要掌握的知识和技能。
如果你对此还不甚了解，可以通过这篇文章，快速地知道一个大概，然后待到在工作中学习和实践时，就更加容易上手了。
首先简单讲一下什么是数据埋点。数据埋点通常是指开发工程师基于业务、运营或产品经理的需要，在产品前端程序中植入相关代码，以获取用户行为等数据的一种技术手段。
对开发人员而言，埋点需求同性能需求一样都属于非功能性需求，它们与功能性需求一起组成了产品需求。
网页中最常见的埋点方式是通过JS代码来实现的。
比如为了统计用户的点击事件，那么在每个链接或按钮处，都增加一段JS代码，用户一旦点击，无论页面是否有跳转、刷新等，都悄悄地请求了服务器，也就把一大堆信息传给了服务器存下来，包括用户的IP地址、地理信息、浏览器参数、点击的对象、时间等等。
又比如为了统计曝光事件，先定义好何为有效曝光（例如完成加载、渲染并进入用户视界），然后在有效曝光发生时，执行一段JS代码，把相关信息传输到服务器。
如果是手机APP或智能设备，则不同于网页主要使用JS代码的方式，它们往往被植入SDK（Software Development Kit ，即软件开发工具包）来实现数据埋点。同时，为了避免频繁连接网络上传或下载数据，通常会将数据先存储在手机本地或智能设备中，等到一定的时机，再一次性同步至服务器。
一定要记住的是，数据埋点只是数据统计和分析的一种技术手段，并非所有的数据统计都必须要有数据埋点。
比如网页事件。在通过HTTP或HTTPS协议请求时，也就是访问各种网址时，浏览器发送给服务器的数据包中，不仅仅是地址栏中你看得见的那一行链接地址，而且还已经包括了诸如浏览器信息、用户信息、来源URL等，这些信息无需再通过埋点，只需要在后端接受请求的程序中加以解析，把有用的存下来即可。
还有一类数据，也是无需埋点的，比如有多少用户成功收藏了一篇文章，这本就属于功能需求的范畴，业务数据中已有记录。
好了，通过前面提到的各种方式，数据有了，但这还不是最重要的。
有了数据之后，还需要根据需要，从这些可能相当杂乱、冗余的数据中选出有用的，按照有利于查询和分析的方式进行二次加工和存储，使之与生产环境中实时变化着的数据隔离开。然后在此基础上，生成各类报表，或者提供一个可自行敲入SQL语句查询数据的界面。
稍有规模的公司通常会有专门的BI团队，他们的主要工作就是开发并维护一个这样的数据系统，供包括产品经理在内的各方面人员，随时随地地查询和分析数据。
数据埋点是什么【数据分析入门初识数据埋点埋点数据监控】所谓嵌入点，就是在一个应用的特定过程中收集一些信息，用来跟踪应用的使用情况，然后进一步优化产品或者为运营提供数据支持，包括访问量、访客、在站时间、浏览量、跳出率等。
这样的信息收集大致可以分为两种:跟踪这个虚拟页面视图和通过一个事件跟踪这个按钮。
有两种方法可以埋葬主流的观点:
第一种:我公司研发在产品中注入代码统计，并设置相应的后台查询。
第二:第三方统计工具，如友盟、厕神、Talkingdata、GrowingIO等
如果是产品前期，通常采用第二种方法收集数据，直接使用第三方分析工具进行基础分析。对于那些比较注重数据安全、业务相对复杂的公司，通常采用第一种方法来收集数据，并构建相应的数据产品来实现其数据应用或分析的需求。
埋藏点含量
看完这些关键指标，埋点大致可以分为两部分。一部分是应用页面访问量的统计，即页面统计，发生页面访问时会上报；另一部分是统计应用中的操作行为，在页面中操作的时候(比如组件暴露的时候，组件被点击的时候，组件上下滑动的时候)上报。
为了统计所需指标，对应用中的所有页面和事件进行唯一标记，并额外上报用户信息、设备信息、时间参数和满足业务需求的参数等具体内容，即埋点。
埋资料注意:不要太追求完美。
关于隐藏数据，有一点很重要。掩埋数据是为了更好地利用数据。不要试图得到准确的数据。你需要的是高质量的埋藏数据。前面讨论的跳出率就是一个例子。当你获得了可用的数据，你就可以用不完善的数据来实现下一步的行动，你追求的是高质量而不是准确性。这也是很多数据产品容易入坑的地方，所以你要时刻提醒自己。
https://iknow-pic . cdn . BCE Bos . com/622762 d0f 703918 ff 2 DAC 25 a 433d 269759 EEC 413？x-BCE-process = image % 2f resize % 2Cm _ lfit % 2Cw _ 600% 2Ch _ 800% 2c limit _ 1% 2f quality % 2Cq _ 85% 2f format % 2Cf _ auto
埋点，数据产品经理必备的技能数据是数据产品的根基，而埋点是数据的起点；如果没有埋点，那数据产品则是无源之水。
可以说埋点是互联网行业里遇到的关键且无法绕过的问题。
以下是企业不同位置的同学内心OS：
业务同学对于埋点是什么都不知道，也不清楚要埋什么；所以往往会做了功能但是没有做埋点，在需要进行数据分析的时候去找数据团队要数据，数据团队会反问：“你们埋点了吗？”
数据产品，因为他们对于业务的认知并不深刻，所以经常会出现漏埋、错埋的情况，导致最后无数可取的结果。
业务开发，本质上他们是解决业务相关问题，数据开发对他们来说一个比较额外的工作，所以他们的开发成本会随着埋点需求而增加，也有可能伴随项目延期的风险；其次过得的埋点开发需求也会导致代码的冗余。
数据分析，他们更多地是用数据，数据埋点的规则找不到，以至于无法很好的通过数据驱动进行分析。
外部数据的交互：比如API数据的传输、数据文件的传输等；目前某平台的大数据标签系统就是通过这种方式传输补齐企业的人群标签等。
而数据产品在整个数据链路上来说，基本可以划分为以下流程：
首先数据采集我们要从不同的端采集不同的数据，然后进行数据清洗加工处理（ETL），然后汇总到数据仓库中，供用户分析、用户画像、精准营销等使用；
我们知道数据采集、数据埋点的重要性后，在实际的业务功能需求提出的时候，一定是要提相关埋点需求的，那在做数据采集我们需要遵循怎么样的流程呢？
以上环节缺一不可，只有规范的流程，才可以在最后的分析中发现正确的现状问题。
现在互联网行业主流的埋点方案主要分为四种：
1. 第一种：代码埋点，代码埋点又分为前端埋点和后端埋点；前端埋点是通过前端的代码埋点来监控用户触发某个页面的数据采集
前端埋点的优点很明显，但是缺点也很明显，由于前端埋点的数据是通过延迟上报的机制，比如用户点击某个页面按钮它不会立刻上报，而是累计到一定的值以后才会按批上班，受限于当前网络情况，如果遇到网络堵塞等问题就会数据丢包，因此前端埋点丢失率比较高，一般在5%~10% 。
而且前端埋点如果有漏埋和错埋的情况，那就要通过app发版进行优化，而客户端发版就要很久的时间。
优点是在每次用户触发这次请求，都会触发埋点代码进行数据统计，所以无需发版，及时触发及时更新。
缺点是服务端埋点需要依赖服务请求，无法覆盖所有前端交互，以及对于用户路径采集也比较弱。
3. 第三种：全埋点；是目前互联网做用户增资的企业提出的一种埋点思路，通过埋点SDK接入，针对页面所有的采集页面元素的浏览和点击行为做统一的收集，不是按次和需求采集，而是提前全部采集
优点是开发成本高， SDK接入后后期维护成本也低，且埋点流程也很简单；先采集后定义，在一定程度上能避免漏埋错埋。
缺点是数据的冗余，导致很多数据并无用处，且数据采集范围仅仅是页面可见元素，比如像曝光这种就无法采集到；数据准确性也有问题。
4. 第四种：可视化埋点；也是接入埋点SDK ，但是并不是随时随地采集，而是按需采集，通过可视化圈选触发埋点采集
优点是操作简单，且按需埋点不会采集无效数据，开发成本比较低；并且数据埋点是可支持撤销操作的，总体来说比全埋点数据量会小很多。
缺点：历史数据是无法恢复的，因为在我们圈选动作之前的数据是无法进行采集的；统计范围仅支持页面前端的动作，比如曝光也是无法采集到的。
选择埋点方案的参考主要基于三点：
比如我们可以根据业务发展阶段来定，比如说现在业务发展较快，版本迭代速度快、开发投入成本高，那我们做客户端埋点和服务端埋点是不太适合的，因为可能没过多久版本就更新了，所以全埋点和可视化埋点比较适合；
那对于比较强的业务数据分析场景来说，需加上前端客户端埋点；以及需要考虑分析深度，如果仅仅是想看用户前端行为路径的，那全埋点和可视化埋点就能满足需求，但是如果分析业务全流程那一定是需要配合上代码埋点。
我是比较推荐全埋点+代码埋点组合，如何服务端能做，优先服务端做，这样数据准确度会更高。
事件是埋点里最核心的要素，如果我们要清晰的定位埋点，就要从6个维度进行定义，我们可以总结为who、when、where、what、why、How；这几个元素就构建了事件的基本要素。
那对于埋点事件主要可分为三类：
通过以上我们基本就可以判断出我们需要记录用户什么行为，采集什么数据， for后续的什么分析了。
写在最后，在工作生涯中，过往的坑告诉我，一个好的埋点管理平台是多么的重要。
首先流程线上化，我们往往在一封封埋点的邮件中迷失自我，但是如果是线上申请，那需求申请、处理、接入、验证、测试就非常方便和快捷，规避信息沟通中的缺失；
其次可以管理规范，埋点都统一管理，信息集中管理，方便后期的分析和使用；
最重要的是监控实时化，减少漏埋、错埋的问题。
当然如果没有埋点管理平台，确定下规范的埋点流程，选择适合当下业务的埋点方案，我相信你也一定也可以做好埋点以及通过数据完成丰富的场景分析！
作者：Goodnight；专注用户、产品等运营领域。
题图来自 Unsplash ，基于 CC0 协议
数据分析入门初识数据埋点数据分析入门：初识数据埋点
计划将实际工作中最高频的与数据相关的一些工作经验以及技巧与大家做一个交流沟通，初步计划整体分6-8篇文章、每篇1-2周的频率由外到里，由浅入深，并伴随实际工作中案例系统性的分享。根据看官老爷的反应调整后面要写的内容，以及更新文章的速度。
埋点概述
数据埋点是数据产品经理、数据运营以及数据分析师，基于业务需求（例如：CPC点击付费广告中统计每一个广告位的点击次数），产品需求（例如：推荐系统中推荐商品的曝光次数以及点击的人数）对用户行为的每一个事件对应的位置进行开发埋点，并通过SDK上报埋点的数据结果，记录数据汇总后进行分析，推动产品优化或指导运营。
埋点分析，是网站分析的一种常用的数据采集方法。数据埋点分为初级、中级、高级三种方式。数据埋点主流部署的方式有：
私有化部署（即部署在自己公司的服务器上，如果期望提高数据安全性，或者定制化的埋点方案较多，则适合私有部署，并开发一套针对自己公司定制化的数据后台查询系统保证数据的安全性和精确性，缺点是成本较高）。
接入第三方服务，比如国内的某盟和国外的GA（Google Analytics）统计，在以后的文章中会单独介绍，此处不再展开。（优点是成本较低，部分基础服务免费，缺点是：数据会存在不安全的风险，另外一个就是只能进行通用的简单分析，无法定制化埋点方案）
此处只展开初级：在产品、服务转化关键点植入统计代码，据其独立ID确保数据采集不重复（如收藏按钮点击率）；
主要的埋点事件分类：
点击事件：
点击事件，用户点击按钮即算点击事件，不管点击后有无结果；如下图红框标注所示，点击一次记一次。
曝光事件：
成功打开一次页面记一次，刷新页面一次记一次，加载下一页新页，加载一次记一次。home键切换到后台再进入页面，曝光事件不记；
页面停留时间事件：
表示一个用户在X页面的停留时长记为停留时长。例如：小明9:00访问了X网站首页，此时分析工具则开始为小明这个访问者记录1个Session（会话）。接着9:01小明又浏览了另外一个页面列表页，然后离开了网站（离开网站可以是通过关闭浏览器，或在地址栏键入一个不同的网址，或是点击了你网站上链接到其他网站的链接……）为了简单，我们把这个过程当做一个Session 。
则最终小明在首页的页面停留时间：
（Time on Page ，简称Tp）Tp(首页) = 9:01 – 9:00 = 1 分钟
When？什么时间做？
产品经理的需求来源众多，可能来自一线市场人员，可能来自身旁油腻的领导。可能来自用户反馈的一条吐槽…无论需求来自哪里，首先要搞清楚的就是这个需求涉及的问题：
在什么样的场景下？
面向哪些目标用户？
解决了哪些问题？
带来了什么价值？
梳理清楚问题后，拆分问题：
哪些是主要问题？
哪些是次要问题？
重不重要？
紧不紧急？
将每个问题拆解后下一步就是带着PRD文档找亲爱的数据分析师童鞋与产品经理汪一起沟通，解决以下问题：
每个问题应该怎么量化？
量化指标是什么？
怎么通过数据定义每个问题以及整个需求的成功与否？
有哪些辅助指标？
定义好数据指标后，此时则需要数据产品或者数据分析师定义埋点。
How?怎么定义埋点？
无规则不成方圆，良好的定义规范可以帮助埋点相关人员更好的维护，以及理解，极高的提升工作效率，降低推倒重来的风险，基于此分享一份埋点的定义规范帮助各位看官老爷以后维护自己产品的埋点。
使用此规范后，本汪一人就可以维护一个APP版本（包含点击事件、曝光事件、停留事件）累计1500多个埋点，井然有序，完全不会乱。
（怀念那些加班维护埋点跑数的日日夜夜，让我与看门大叔成了挚友，结下了深厚的友谊。咳咳，此处应该有掌声…）
埋点分类概述：
首先从事件属性这个维度上分为三份Excel（点击事件表、曝光事件表、停留事件表）
其次每一个事件表中新建三份子表（Sheet）,以点击事件表为例拆分为：首页事件集合、列表页事件集合、详情页事件集合
每当APP发布新版本时，从上一个版本的埋点中做一份Copy,新版本中新增了哪些埋点，删除了哪些埋点？都用不同的颜色，或者时间标记进行标注说明。
真实环境中分类更为复杂，仅以上面例子说明分类思路，各位看官老爷可以根据业务需求做针对自己产品更合适的分类。
字段明细：
功能字段：
用于说明当前埋点是在哪个页面的哪个功能。例如：收藏功能，对应功能字段名：自定义为我的收藏
中文名字段：
用于描述X功能模块内X位置，例如起名叫：收藏功能-文章收藏
事件类型字段：
用于说明当前埋点是点击事件还是曝光事件还是其他
事件ID字段：
如果是自己公司开发的数据查询系统，则每一个埋点都对应一个事件ID ，上线后用于拿着事件ID去后台取数使用。事件ID的命名规范：事件英文简写_哪一端的产品_产品名称简写_页面名称_模块名称_功能名称。
例如：点击事件_APP端_二手车_个人中心_收藏_文章收藏对应事件ID==click_app_2sc_ Personal Center_ Collection_ Article Collection
如果是用的第三方统计工具：例如某盟，同理定义好事件ID ，上线后去X盟后台，输入事件ID查询相应的数据。
Key字段与value字段：
当一个埋点对应不同类型的多种位置的埋点时，则需要命名当前埋点的key参数与value参数，一个key可以对应1个value或者多个value,但一个value不能对应多个key.只能对应唯一的一个key 例如：二手车信息网站有2个关键按钮，一个是砍价按钮，一个是拨打电话按钮，但是在多个频道中每个频道都有多个砍价按钮多个拨打电话按钮，在这样的场景下就可以设计2个KEY值：
key01=source用于标记当用户点击了一次按钮后是在哪个频道的页面点击的这个按钮X value01=X1 ， value2=X2用于标记不同位置同属性的按钮。
Key02=type用于标记用户是点的砍价还是点的拨打电话按钮，例如：01value用于标记砍价按钮， 02value对应的拨打电话按钮。
记录规则字段：
定义什么情况下触发埋点，例如：在列表页点击一次记录一次
备注：
用于描述当前埋点什么时间新增？什么时间修改过？原因？什么时间被删除？谁删除的？等信息记录，此处好多看官可能以为写不写无所谓，但是为了信息的完整性和可追溯性最好每一次变动都要备注。
关于埋点数据和埋点数据监控的内容就分享到这儿！更多实用知识经验，尽在 www.hubeilong.com

数据分析入门 初识数据埋点 埋点数据监控

数据分析入门初识数据埋点埋点数据监控