微信小程序选项卡功能开发步骤与方法全解析
3948
2023-02-15
小程序全埋点方案（全埋点解决方案）
本篇文章给大家谈谈小程序全埋点方案，以及全埋点解决方案对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
今天给各位分享小程序全埋点方案的知识，其中也会对全埋点解决方案进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
数据埋点非常看重两件事，一个是数据记录的准确性，另一个则是数据记录的完备性。
先讲数据的准确性。数据埋点非常强调规范和流程，因为参数的规范与合法，将直接影响到数据分析的准确性，如果准确性得不到保障，那么所有基于埋点得出的结论，都是不可信的。辛辛苦苦做了很久的方案，一旦因为一个疏忽的小问题，导致下游集中投诉，其实非常划不来。
道理每个人都懂，但现实情况中，数据埋点所面对的客观环境，其实非常复杂，例如：
因此本文有非常长的篇幅来写流程问题，其实是非常有必要的。
再讲数据的完备性。因为埋点主要是面向分析使用，对用户而言是个额外的功能，因此埋点的业务侵入性很强，很容易对用户体验造成影响。别的不说，仅仅是流量的消耗，就很容被用户喷。因此，要提前想清楚，我们要采集哪些东西，因为修改方案的成本，是伤不起的。
通常情况下，我们需要记录用户在使用产品过程中的操作行为，通过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，行为、事件的发生数量。
很多时候，数据是需要多方验证的，存在一定的上下游信息不同步问题，比如对某个默认值的定义有歧义，日志统计会有效的发现这类问题。
第五步，发布上线。
应用的发布上线通常会有不同的周期，例如移动端会有统一的发版时间，而网页版只需要根据自己的节奏走，因此数据开始统计的时间是不同的。最后，应用应当对所有已发布的埋点数据，有统一的管理方法。
大多数时候，数据埋点的技术方案，只需要设计一次，但数据准确性的验证，却需要随着产品的生命周期持续下去，因此仅仅依靠人肉来准确性验证是不够的，我们需要平台来支持自动化的工作。埋点的准确性，大体有两种方法保障：一种是灰度环境下验证真实用户数据的准确性；另一种则是在线上环境中，验证全量数据的准确性。因此，发布上线之后，后续的管理动作，应该是对现有流程的自动化管理，因为团队大了，需要埋点的东西多种多样，让平台自己测试、自动化测试，就是很多测试团队必须走的路
自定义分析创建完之后，不能更改英文名和中文名，可以更改页面、埋点事件以及参数信息。
事件发布到线上后、只能对生产环境的埋点数据进行收集
可以分别在正式版、体验版、开发版进行埋点
登录 微信公众平台 ，进入<开发<开发设置<服务器域名，将https://zhls.qq.com添加为 request 合法域名。
在开发环境中还有SDK版本检查可供进行查看。
配置接口，用来调整SDK的基础机制。官方建议init初始化应该在App()调用之前调用，如果自己改造，只要测试通过即可。
在app中初始化如下：
有数小程序数据上报SDK是一个小程序环境的数据采集工具，它提供了简单的接口帮助你快速将数据接入数据中心。
上报队列 数据上报任务通过队列发送，降低数据丢失率。
自动采集 可自动对常见的行为进行埋点，并收集通用的属性，可通过配置打开和关闭，具体见文档 微信小程序SDK 中的使用方法。
SDK 默认上报小程序的 启动 、显示 、隐藏 事件，可以在初始化的时候配置 trackApp: false 关闭该功能。
未使用小程序插件，SDK 提供proxyPage开关对Page开启代理模式。 会自动上报页面相关的预置事件，如browse_wxapp_page。
已使用小程序插件，SDK 提供 sdk.page 支持对 Page 的改造。
也可以选择使用 track 自己上报预置事件。
注意：在小程序里有如下几种异步数据容易导致问题：通过wx.login获取 openid ，通过wx.getShareInfo获取 openGId 。
在有数的官方接入数据文档中，接入指引都较为详细，行为可进行手动上报
比如订单状态变更 custom_order
可以查看各种行为的接入进度
1、初始化时配置 trackApp:true启用自动上报小程序的 启动 、显示 、隐藏 事件；
2.未使用小程序插件，SDK 提供 proxyPage:true 开关对 Page 开启代理模式。 会自动上报页面相关的预置事件，如 browse_wxapp_page等 。
3.已使用小程序插件，SDK 提供 sdk.page 支持对 Page 的改造，另外需配置usePlugin: true， 是否使用插件，默认是：false。
4.建议文档从头到尾的读，读3遍！！！包括官方 产品介绍 和 产品接入 文档。
5.仔细看 测试点文档 ，以及每个字段需要的类型、以及必填项的默认值！
但是在之前的PC互联网时代，除了网页端有百度统计、谷歌分析等，客户端的埋点似乎没有一套能拿出来可供大家讨论的解决方案，我就基于我的工作经验和理解，给大家分享一下PC客户端的埋点。
PC客户端的埋点
首先，在PC上，我们得知道我们需要统计些什么内容。
一个PC客户端，无论是工具类的还是内容类的，我们都希望知道我们提供的服务的效果。那么，我们从一个客户端安装、运行到最终被卸载来看看。
就拿产品使用较多的工具“Axure RP”来举例吧。如果“Axure RP”是我们自己的软件，首先我们需要知道被安装了，之后，我们关注激活情况，也就是使用，到最后，被卸载了，这一整个环节，构成了一个生命周期。 重点来了，对于这个生命周期，所有你想知道的关于“Axure RP”的情况你都可以统计到。
1.软件的安装
在PC客户端安装的过程中，流程一般是这样的：①运行安装包②弹出安装界面提供给用户操作③执行安装过程-写注册表、启动项、计划任务等④执行安装过程-创建安装的文件夹（③和④可以交换）。
在这个环节，我们一般需要知道：
安装包被运行了
在安装界面用户做了哪些操作
我们的安装过程是否正常执行
我们最终是否安装成功
在PC上，只要我们的安装包运行起来了，无论是弹出安装界面、写注册表还是创建文件，这些都是安装包可以控制的，所以我们能通过安装包进程，将整个安装环节的所有数据记录下来发送到我们的后台并记录下来 （这里要重点记住，由于安装是一次性的动作，所以统计一定要发实时的） 。
2.软件的使用
软件的使用，包括启动软件、使用功能和退出软件。
在PC上，软件的启动有很多种方式，例如开机自启动、计划任务、手动点击快捷方式，我们继续以“Axure RP”举例，当我们装上了“Axure RP”后，会在桌面、开始菜单中，创建快捷方式（有些程序会在任务栏上也创建），同时，会将后缀名为“rp”的文件默认打开方式调整为“Axure RP”。
对于启动， 我们就有了三种方式：桌面快捷方式、开始菜单快捷方式和默认软件打开，所以我们需要统计软件是否被启动了，是如何启动的。
对于使用功能， 当软件运行起来后，其进程就会启动，这个时候就跟移动端的应用类似，我们需要统计一系列事件，每个功能的使用情况、功能状态、付费、登录等一系列信息（区别于移动端的是，在PC上一般这些统计都是做单点统计，例如统计弹窗的弹出、功能的点击、某个状态，对于相互关联的一组事件统计是比较复杂的，需要定义结构体，在一条统计中包含很多组字段信息，因为没有成熟的SDK集成，所以基本都要自己定义埋点，复用性较差）。
这部分统计分为公共统计和专用统计。公共统计就是基本信息，常用的是用户标识、用户基本信息、计算机硬件信息和其他的可复用的；专用统计就是针对你的功能，你想了解哪些情况，针对性进行埋点统计。
对于软件退出， 这就比较简单了，是正常退出还是异常退出？软件使用了多久退出？
3.软件的卸载
软件卸载的流程包括启动卸载程序、用户操作、删除注册表及文件等操作、完成卸载。
在这个过程中，我们主要关注两方面的信息，一方面是用户怎么卸载的？是主动使用卸载程序，还是通过一些管理软件进行卸载；另一方面是用户为什么要卸载，这个时候我们可以在卸载的界面中给用户提供选择，以获取用户的反馈。
该怎么埋点
1.埋点的分类
（1）时效性
PC客户端一般情况下都比较复杂，子功能很多，可统计的内容很多，为了节省带宽，我们不可能每次都实时将数据传输回来，而且很多时效性不是很强的功能没有必要实时上报。
实时统计
当功能触发时或达到一定条件，立即将统计回传，一般情况下用于时效性比较强的功能，例如活跃统计、营收类统计，我们需要实时分析并调整策略。
延时统计
统计不立即回传，将统计积累，达到一定的条件或者一定的时间，统一将这部分统计回传，一般情况用于时效性不强的功能，例如采集设备信息、获取某些功能的状态、常规功能的统计，这部分统计使用范围比较广，一般都是隔日发送，有一天的延迟，统计的信息晚一天不会对分析产生较大的影响。
（2）埋点的作用
常规的基础统计
每次统计都需要发送，可以理解为公用统计，这部分统计是将几乎所有的统计都需要的部分包括进来，封装成一个统一的部分，每次发送统计都会带上这些内容，方便管理，节省后续埋点时间。
功能统计
针对特定功能，当功能被使用或者生效的时候，我们需要统计效果或者状态，可以理解为专用统计，不同于移动端，PC一般没有第三方提供的SDK，需要每个专用统计自己埋点，维护大量的统计内容，不过在一个公司内部，可以统一设计规范，方便维护。
（3）数据类型
结构体
统计连贯的事件，各项信息之间的关联很重要。
计数
统计某个行为发生的次数。
字符串
统计内容。
整形
统计数值，也可用来统计状态。
布尔型
统计需要判断的类型，一般使用场景较少，为了方便计算，大部分被整形和字符串替代。
2.数据埋点实例
（1）软件安装
场景：统计安装过程中的信息
（2）软件的使用
场景：软件启动后，用户使用了分享功能，将自己做的原型分享到了云端，最后用户关闭了软件。
要注意的是，软件启动和关闭，看需要是可以调整的，如果你只是想知道是不是启动了，来判断活跃，那么仅仅需要启动的时候发送个整型的值标识即可；如果想知道更详细的信息，比如启动方式、启动时间等等，可以定义结构体，将这一刻更多的信息发送回来，可灵活定义。
（3）软件卸载
卸载跟软件安装类似，这里就不赘述了。
在这里，如果希望收集用户的卸载原因，可以定义一个字符串，将用户填写的内容上报，这种形式的数据如果太多，不太利于分析，所以看产品情况可灵活设置。 关于小程序全埋点方案和全埋点解决方案的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 小程序全埋点方案的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于全埋点解决方案、小程序全埋点方案的信息别忘了在本站进行查找喔。
本文目录一览：
- 1、支付宝小程序： 如何做好小程序埋点？Part IV 埋点实施实战
- 2、支付宝小程序： 如何做好小程序埋点？
- 3、关于数据埋点，你需要知道的技术方案和规范流程
- 4、小程序：埋点
- 5、微信小程序----腾讯有数接入埋点
- 6、数据埋点技巧
支付宝小程序： 如何做好小程序埋点？Part IV 埋点实施实战
埋点实施应该注意些什么呢？
下图为一个资讯行业的事件埋点模版小程序全埋点方案，可以参照这个模板去进行梳理并提交给技术。友盟+ 开发者数据银行产品中的智能采集平台就可以按照这个模板小程序全埋点方案，直接帮小程序全埋点方案我们生成对应的埋点方案，并协助我们进行后续的事件管理。
市场上主流支持的四种埋点方式，分别是 代码埋点、服务端埋点、可视化埋点和全埋点。
针对需求的不同，数据采集方式应该是结合使用的，以友盟+为例，友盟+现在支持两种埋点方式，代码埋点和可视化埋点，开发者可以结合使用，去满足事件方案的采集需求。
埋点后可通过三种方式验证：
智能验证，可以帮您智能验证这些事件的点是否采集小程序全埋点方案了，是否有遗漏，最后会定期给出体检报告，详细的明细都会有。在友盟+的智能采集页面就可以智能验证埋点，只需要注册一个测试设备，这个测试设备填加完之后会实时把客户这些埋点的数据进行验证，到底是成功还是异常，以及测试的时间是什么都会有详细的数据。
综上所述：一个公司的埋点要可见、可控、可管，如果一家公司不清楚自己的埋点结构，便是在错误的数据上长期持续经营业务，越走越错。合理的埋点方案，可以使埋点能够智能调试和验证，大幅降低埋点采集的成本，从而最终达成数据质量的根本性提升。
支付宝小程序： 如何做好小程序埋点？
一. 埋点还是埋雷？数据埋点的五大“坑”
在接触过上百家头部客户中，诊断和参与了数百次的数据体系搭建工作。几乎80%的开发者都没有科学的埋点规划，只采集显性数据，而更深层的与事件、参数相关的隐性数据，都没有采集到。埋点规划并不难！但为什么大部分企业都做的不太好？埋点规划需要整合产品、运营、技术和业务等跨部门的需求，运营同学不太懂技术、技术同学不太懂业务、产品同学不太懂埋点。
埋点的常见的问题有那些呢？
杂乱 ：前期并没有进行事件结构化的设计，想一出是一出。通常是想到一个需求，就把这个需求提供给技术进行埋点。例如：某一个位置或者某一个功能的点击行为，就当做一个事件进行采集，看上去采集和查看很容易，但随着时间跟需求的增加，当采集了大量零散的事件之后，需要在统计工具中通过分组分析时，就会比较麻烦。
低效： 在事件设计的时候，会去做结构化处理。但事件设计的参数逻辑会有问题，通常都是以大的页面这种框架的思维去进行设计。举个例子：部分客户在设计时，会按照页面的思路去进行事件采集，当产品结构产生变化时，原有事件调整概率会比较大，因为之前都是按页面结构去设计，页面的调整直接影响事件采集。
无用 ：指的是数据虽然采集了，但分析时根本用不上，这个问题主要有2个原因导致，一是前期需求不太清晰，另一个是之前的采集需求都是由不同人提出的，由于中间人员变动，很多采集需求就不清楚了，并且也不敢下掉，因为并不清楚这个事件是否还有人使用。
复用： 指的是事件重复采集，或者是需求重复，这个同样是与多个人提需求有关，并没有一个人去做整合管理，或者是说，没有一个工具去帮忙我们做管理。
如果想要避免这些坑，就需要坚守五个原则：
关于数据埋点，你需要知道的技术方案和规范流程
埋点是数据采集的专用术语，在数据驱动型业务中，如营销策略、产品迭代、业务分析、用户画像等，都依赖于数据提供决策支持，希望通过数据来捕捉特定的用户行为，如按钮点击量、阅读时长等统计信息。因此，数据埋点可以简单理解为：针对特定业务场景进行数据采集和上报的技术方案。数据埋点非常看重两件事，一个是数据记录的准确性，另一个则是数据记录的完备性。
先讲数据的准确性。数据埋点非常强调规范和流程，因为参数的规范与合法，将直接影响到数据分析的准确性，如果准确性得不到保障，那么所有基于埋点得出的结论，都是不可信的。辛辛苦苦做了很久的方案，一旦因为一个疏忽的小问题，导致下游集中投诉，其实非常划不来。
道理每个人都懂，但现实情况中，数据埋点所面对的客观环境，其实非常复杂，例如：
因此本文有非常长的篇幅来写流程问题，其实是非常有必要的。
再讲数据的完备性。因为埋点主要是面向分析使用，对用户而言是个额外的功能，因此埋点的业务侵入性很强，很容易对用户体验造成影响。别的不说，仅仅是流量的消耗，就很容被用户喷。因此，要提前想清楚，我们要采集哪些东西，因为修改方案的成本，是伤不起的。
通常情况下，我们需要记录用户在使用产品过程中的操作行为，通过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，行为、事件的发生数量。
很多时候，数据是需要多方验证的，存在一定的上下游信息不同步问题，比如对某个默认值的定义有歧义，日志统计会有效的发现这类问题。
第五步，发布上线。
应用的发布上线通常会有不同的周期，例如移动端会有统一的发版时间，而网页版只需要根据自己的节奏走，因此数据开始统计的时间是不同的。最后，应用应当对所有已发布的埋点数据，有统一的管理方法。
大多数时候，数据埋点的技术方案，只需要设计一次，但数据准确性的验证，却需要随着产品的生命周期持续下去，因此仅仅依靠人肉来准确性验证是不够的，我们需要平台来支持自动化的工作。埋点的准确性，大体有两种方法保障：一种是灰度环境下验证真实用户数据的准确性；另一种则是在线上环境中，验证全量数据的准确性。因此，发布上线之后，后续的管理动作，应该是对现有流程的自动化管理，因为团队大了，需要埋点的东西多种多样，让平台自己测试、自动化测试，就是很多测试团队必须走的路
小程序：埋点
这两个地方都可以给小程序进行埋点，个人觉得We分析的数据会更丰富一些。自定义分析创建完之后，不能更改英文名和中文名，可以更改页面、埋点事件以及参数信息。
事件发布到线上后、只能对生产环境的埋点数据进行收集
可以分别在正式版、体验版、开发版进行埋点
微信小程序----腾讯有数接入埋点
腾讯有数推出，为品牌商、零售商打造的数据分析与管理平台，融合腾讯数据、技术与生态优势，提供全链路经营数据分析、消费者洞察、精准营销等能力，让企业经营更“有数”。登录 微信公众平台 ，进入<开发<开发设置<服务器域名，将https://zhls.qq.com添加为 request 合法域名。
在开发环境中还有SDK版本检查可供进行查看。
配置接口，用来调整SDK的基础机制。官方建议init初始化应该在App()调用之前调用，如果自己改造，只要测试通过即可。
在app中初始化如下：
有数小程序数据上报SDK是一个小程序环境的数据采集工具，它提供了简单的接口帮助你快速将数据接入数据中心。
上报队列 数据上报任务通过队列发送，降低数据丢失率。
自动采集 可自动对常见的行为进行埋点，并收集通用的属性，可通过配置打开和关闭，具体见文档 微信小程序SDK 中的使用方法。
SDK 默认上报小程序的 启动 、显示 、隐藏 事件，可以在初始化的时候配置 trackApp: false 关闭该功能。
未使用小程序插件，SDK 提供proxyPage开关对Page开启代理模式。 会自动上报页面相关的预置事件，如browse_wxapp_page。
已使用小程序插件，SDK 提供 sdk.page 支持对 Page 的改造。
也可以选择使用 track 自己上报预置事件。
注意：在小程序里有如下几种异步数据容易导致问题：通过wx.login获取 openid ，通过wx.getShareInfo获取 openGId 。
在有数的官方接入数据文档中，接入指引都较为详细，行为可进行手动上报
比如订单状态变更 custom_order
可以查看各种行为的接入进度
1、初始化时配置 trackApp:true启用自动上报小程序的 启动 、显示 、隐藏 事件；
2.未使用小程序插件，SDK 提供 proxyPage:true 开关对 Page 开启代理模式。 会自动上报页面相关的预置事件，如 browse_wxapp_page等 。
3.已使用小程序插件，SDK 提供 sdk.page 支持对 Page 的改造，另外需配置usePlugin: true， 是否使用插件，默认是：false。
4.建议文档从头到尾的读，读3遍！！！包括官方 产品介绍 和 产品接入 文档。
5.仔细看 测试点文档 ，以及每个字段需要的类型、以及必填项的默认值！
数据埋点技巧
移动互联网时代，无论是Android、iOS还是小程序，都有很多成熟的解决方案，无需花费很多的时间去处理埋点的事情，而且基于第三方提供的SDK进行埋点，在数据处理和分析上也有很大的优势。但是在之前的PC互联网时代，除了网页端有百度统计、谷歌分析等，客户端的埋点似乎没有一套能拿出来可供大家讨论的解决方案，我就基于我的工作经验和理解，给大家分享一下PC客户端的埋点。
PC客户端的埋点
首先，在PC上，我们得知道我们需要统计些什么内容。
一个PC客户端，无论是工具类的还是内容类的，我们都希望知道我们提供的服务的效果。那么，我们从一个客户端安装、运行到最终被卸载来看看。
就拿产品使用较多的工具“Axure RP”来举例吧。如果“Axure RP”是我们自己的软件，首先我们需要知道被安装了，之后，我们关注激活情况，也就是使用，到最后，被卸载了，这一整个环节，构成了一个生命周期。 重点来了，对于这个生命周期，所有你想知道的关于“Axure RP”的情况你都可以统计到。
1.软件的安装
在PC客户端安装的过程中，流程一般是这样的：①运行安装包②弹出安装界面提供给用户操作③执行安装过程-写注册表、启动项、计划任务等④执行安装过程-创建安装的文件夹（③和④可以交换）。
在这个环节，我们一般需要知道：
安装包被运行了
在安装界面用户做了哪些操作
我们的安装过程是否正常执行
我们最终是否安装成功
在PC上，只要我们的安装包运行起来了，无论是弹出安装界面、写注册表还是创建文件，这些都是安装包可以控制的，所以我们能通过安装包进程，将整个安装环节的所有数据记录下来发送到我们的后台并记录下来 （这里要重点记住，由于安装是一次性的动作，所以统计一定要发实时的） 。
2.软件的使用
软件的使用，包括启动软件、使用功能和退出软件。
在PC上，软件的启动有很多种方式，例如开机自启动、计划任务、手动点击快捷方式，我们继续以“Axure RP”举例，当我们装上了“Axure RP”后，会在桌面、开始菜单中，创建快捷方式（有些程序会在任务栏上也创建），同时，会将后缀名为“rp”的文件默认打开方式调整为“Axure RP”。
对于启动， 我们就有了三种方式：桌面快捷方式、开始菜单快捷方式和默认软件打开，所以我们需要统计软件是否被启动了，是如何启动的。
对于使用功能， 当软件运行起来后，其进程就会启动，这个时候就跟移动端的应用类似，我们需要统计一系列事件，每个功能的使用情况、功能状态、付费、登录等一系列信息（区别于移动端的是，在PC上一般这些统计都是做单点统计，例如统计弹窗的弹出、功能的点击、某个状态，对于相互关联的一组事件统计是比较复杂的，需要定义结构体，在一条统计中包含很多组字段信息，因为没有成熟的SDK集成，所以基本都要自己定义埋点，复用性较差）。
这部分统计分为公共统计和专用统计。公共统计就是基本信息，常用的是用户标识、用户基本信息、计算机硬件信息和其他的可复用的；专用统计就是针对你的功能，你想了解哪些情况，针对性进行埋点统计。
对于软件退出， 这就比较简单了，是正常退出还是异常退出？软件使用了多久退出？
3.软件的卸载
软件卸载的流程包括启动卸载程序、用户操作、删除注册表及文件等操作、完成卸载。
在这个过程中，我们主要关注两方面的信息，一方面是用户怎么卸载的？是主动使用卸载程序，还是通过一些管理软件进行卸载；另一方面是用户为什么要卸载，这个时候我们可以在卸载的界面中给用户提供选择，以获取用户的反馈。
该怎么埋点
1.埋点的分类
（1）时效性
PC客户端一般情况下都比较复杂，子功能很多，可统计的内容很多，为了节省带宽，我们不可能每次都实时将数据传输回来，而且很多时效性不是很强的功能没有必要实时上报。
实时统计
当功能触发时或达到一定条件，立即将统计回传，一般情况下用于时效性比较强的功能，例如活跃统计、营收类统计，我们需要实时分析并调整策略。
延时统计
统计不立即回传，将统计积累，达到一定的条件或者一定的时间，统一将这部分统计回传，一般情况用于时效性不强的功能，例如采集设备信息、获取某些功能的状态、常规功能的统计，这部分统计使用范围比较广，一般都是隔日发送，有一天的延迟，统计的信息晚一天不会对分析产生较大的影响。
（2）埋点的作用
常规的基础统计
每次统计都需要发送，可以理解为公用统计，这部分统计是将几乎所有的统计都需要的部分包括进来，封装成一个统一的部分，每次发送统计都会带上这些内容，方便管理，节省后续埋点时间。
功能统计
针对特定功能，当功能被使用或者生效的时候，我们需要统计效果或者状态，可以理解为专用统计，不同于移动端，PC一般没有第三方提供的SDK，需要每个专用统计自己埋点，维护大量的统计内容，不过在一个公司内部，可以统一设计规范，方便维护。
（3）数据类型
结构体
统计连贯的事件，各项信息之间的关联很重要。
计数
统计某个行为发生的次数。
字符串
统计内容。
整形
统计数值，也可用来统计状态。
布尔型
统计需要判断的类型，一般使用场景较少，为了方便计算，大部分被整形和字符串替代。
2.数据埋点实例
（1）软件安装
场景：统计安装过程中的信息
（2）软件的使用
场景：软件启动后，用户使用了分享功能，将自己做的原型分享到了云端，最后用户关闭了软件。
要注意的是，软件启动和关闭，看需要是可以调整的，如果你只是想知道是不是启动了，来判断活跃，那么仅仅需要启动的时候发送个整型的值标识即可；如果想知道更详细的信息，比如启动方式、启动时间等等，可以定义结构体，将这一刻更多的信息发送回来，可灵活定义。
（3）软件卸载
卸载跟软件安装类似，这里就不赘述了。
在这里，如果希望收集用户的卸载原因，可以定义一个字符串，将用户填写的内容上报，这种形式的数据如果太多，不太利于分析，所以看产品情况可灵活设置。 关于小程序全埋点方案和全埋点解决方案的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 小程序全埋点方案的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于全埋点解决方案、小程序全埋点方案的信息别忘了在本站进行查找喔。
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
相关文章
发表评论
最近发表
推荐文章
热评文章
暂时没有评论，来抢沙发吧~