微信小程序----腾讯有数接入埋点

腾讯有数推出，为品牌商、零售商打造的数据分析与管理平台，融合腾讯数据、技术与生态优势，提供全链路经营数据分析、消费者洞察、精准营销等能力，让企业经营更“有数”。

登录 微信公众平台 ，进入<开发><开发设置><服务器域名>，将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.仔细看 测试点文档 ，以及每个字段需要的类型、以及必填项的默认值！

埋点实施应该注意些什么呢？

埋点实施

下图为一个资讯行业的事件埋点模版，可以参照这个模板去进行梳理并提交给技术。友盟+ 开发者数据银行产品中的智能采集平台就可以按照这个模板，直接帮我们生成对应的埋点方案，并协助我们进行后续的事件管理。

市场上主流支持的四种埋点方式，分别是 代码埋点、服务端埋点、可视化埋点和全埋点。

代码埋点： 支持事件与参数这种结构化的使用方式，弊端是想增加或修改事件，都需要重新发版，用户更新后才能采集。 服务端埋点 ：通常用于业务数据的采集，例如：付费成功、用户注册等，这个场景会选择用服务埋点进行采集。 可视化埋点和全埋点 ：都是解决整个App前端 *** 作的一些点击行为，例如说某些按钮、页面，每一个点击都能监测。但差异点在于可视化埋点只能看到圈定后的数据，那么全埋点则是在圈定时，历史数据也能去追溯。但这两个埋点的弊端是散点采集，每一个点击行为都是一个事件，在数据分析时，事件的量级会较大，不易于分析，而且它只能是取这种点击行为的事件，并不能把参数带过来，你可以理悉斗解为它就是一个纯扁平化的一个事件采集。

针对需求的不同，数据采集方式应该是结合使用的，以友盟+为例，友盟+现在支持两种埋点方式，代码埋点和可视化埋点，开发者可以结合使用，去满足事件方案的采集需求。

 

埋点验证

埋点后可通过三种方式验证：

打印日志，开启debug去打印Log，去验证触发事件log是否有上报，这种方式需要技术来配合验证集成测试睁仔磨，以友盟+为例，只需要让技术注册一个测试设备，就可在你这个测试设备上去启用你的App，在去触发事件，产品、运营的同学就可直接测试埋点情况。也可以使用市场上智能验证的工具，以友盟+为例，可先注册设备，自动去识别整个埋点的情况，且日志是实时的，可产出事件的验证报告。

智能验证，可以帮您智能验证这些事件的点是否采集了，是否有遗漏，最后会定期给出体检报告，详细的明细都会有。在友盟+的智能采集页面就可以智能验证埋点，只需要注册一个测试设备，这个测试设备填加完之后会实时把客户这些埋点的数据戚租进行验证，到底是成功还是异常，以及测试的时间是什么都会有详细的数据。

综上所述：一个公司的埋点要可见、可控、可管，如果一家公司不清楚自己的埋点结构，便是在错误的数据上长期持续经营业务，越走越错。合理的埋点方案，可以使埋点能够智能调试和验证，大幅降低埋点采集的成本，从而最终达成数据质量的根本性提升。

一. 埋点还是埋雷？数据埋点的五大“坑”

在接触过上百家头部客户中，诊断和参与了数百次的数据体系搭建工作。几乎80%的开发者都没有科学的埋点规划，只采集显性数据，而更深层的与事件、参数相关的隐性数据，都没有采集到。埋点规划并不难！但为什么大部分企业都做的不太好？埋点规划需要整合产品、运营、技术和业务等跨部门的需求，运营同学不太懂技术、技术同学不太懂业务、产品同学不太懂埋点。

埋点的常见的问题有那些呢？

遗漏 ：指的是埋点采集不全面，有可能重要的数据并没有采集到，会对数据分析造成比较直接的影响，出现这个问题的原因是前期数据分析需求不清晰。

 

杂乱 ：前期并没有进行事件结构化的设计，想一出是一出。通常是想到一个需求，就答帆把这个需求提供给技术进行埋点。例如：某一个位置或者某一个功能的点击行为尺缓，就当做一个事件进行采集，看上去采集和查看很容易，但随着时间跟需求的增加，当采集了大量零散的事件之后，需要在统计工具中通陵举模过分组分析时，就会比较麻烦。

 

低效： 在事件设计的时候，会去做结构化处理。但事件设计的参数逻辑会有问题，通常都是以大的页面这种框架的思维去进行设计。举个例子：部分客户在设计时，会按照页面的思路去进行事件采集，当产品结构产生变化时，原有事件调整概率会比较大，因为之前都是按页面结构去设计，页面的调整直接影响事件采集。

 

无用 ：指的是数据虽然采集了，但分析时根本用不上，这个问题主要有2个原因导致，一是前期需求不太清晰，另一个是之前的采集需求都是由不同人提出的，由于中间人员变动，很多采集需求就不清楚了，并且也不敢下掉，因为并不清楚这个事件是否还有人使用。

 

复用： 指的是事件重复采集，或者是需求重复，这个同样是与多个人提需求有关，并没有一个人去做整合管理，或者是说，没有一个工具去帮忙我们做管理。

  如果想要避免这些坑，就需要坚守五个原则：

需求清晰合理设计实施规范结果可验规范管理

---