自动采集文章内容( 埋点自动收集方案的三篇文章，你知道吗？ )

　　自动采集文章内容(

埋点自动收集方案的三篇文章，你知道吗？

)

　　

　　导言

　　由于涉及的内容较多，且考虑到长度，埋点自动采集方案将分为三部分文章

　　其他两篇文章将于稍后发表

　　这篇文章文章很长。对最终效果感到好奇的学生可以优先选择“背景预览”屏幕截图

　　痛点

　　埋点，作为跟踪在线业务效果的核心手段

　　它的文档也是最重要的，但在许多公司或团队中都以最原创的方式进行维护

　　即使一些团队有一个统一的埋点平台，总体运营成本也很高

　　

　　1）维护费用

　　每次提出请求时，PM都需要花费大量时间维护埋藏点文档

　　可以添加新的埋葬点。直接添加即可

　　如果旧埋点被删除或修改，首先要找到开发学生确认，然后更新文档

　　如果您担心麻烦，文档只会被添加，不会被删除。。你知道，已经很久了~

　　2）谁将维护埋点文件

　　如前所述，添加很好，主要用于删除或更新埋点。谁将推动埋点文件的更新

　　培养学生促进项目管理

　　PM找到开发点以更新列表

　　直接开发和更新埋点文件

　　开发学生还应在开发过程中记录埋点更新列表

　　开发和PM会互相争吵吗

　　3）非阻塞过程

　　在整个过程中，单靠一个角色是很难达到目的的

　　最后，不管谁来维护，如果没有阻塞过程，都将依赖于自我意识

　　凭自我意识，如果它持续下去，地狱~

　　4）埋点文件不准确

　　由于上述原因，埋藏点文档与实际报告代码之间的距离越来越远

　　很长一段时间后，我看不出来，尤其是在人事变动或业务调整的情况下

　　新学生接班后，额头上直接出现了三条黑线

　　5）学生有很强的抵抗力

　　PM：“帮我检查XX项目的埋葬点，我急需它”

　　PM：“你能帮我检查一下XX活动的埋葬点吗？”

　　PM：“在上一次需求迭代中，请更新列表并给我一份副本”

　　特别是对于赶上逆向计划周期的项目

　　

　　作为Fe，你也有同样的感受吗

　　触发思维

　　在任何情况下，在线数据都是通过埋点反馈的，业务调整的基础是数据

　　这是客观事实

　　因此，必须解决嵌入文档的难点

　　一些学生可能会问，为什么不使用第三方嵌入方案（如growingio、Shence等）

　　无论采用哪种方案，报告埋点的主流方法有两种：

　　所有埋点报告（包括区域报告）

　　SDK活动报告（单埋藏点和多购买点报告）

　　全埋点报告需要由PM根据页面结构进行配置（主要维护人员在PM中）。页面结构一旦更改，就需要重新配置

　　另外，公司目前的情况是有自己的数据平台，但是如果采用全埋点报告，数据分析的层次会有很大的负担，每个业务条线本身都采用代码主动报告的方式

　　如果SDK主动上报，就会遇到上述问题

　　一些学生可能会说，“这是PM应该做的。我只对我的部分负责。”

　　这本身是可以的，但我们基本上希望提高整个团队的效率

　　在制定此计划时，我们还与许多团队的PM进行了沟通。维护可用的埋藏点文档确实会消耗大量的精力

　　这也让我更加坚定

　　

　　方案构思

　　前面所有问题的核心是两个：

　　在小组内部进行了多次讨论之后，问题被细分了

　　相应的解决方案如下：

　　问题解决方案

　　保持角色模糊

　　PM只提供要计数的隐藏点，并且更新自动保持在代码级别

　　维护费用高

　　通过JSDoc代码注释，在编译代码时从文件中提取并解释嵌入点

　　文件可用性

　　埋点提取完成后，直接向埋点背景报告

　　旧项目访问

　　提供统一的自动注释添加工具

　　新项目访问

　　方案整合到脚手架中，并提供装载机检查完整性

　　提高业务效率

　　建立埋点背景，提供埋点和数据预览

　　在查看表单时，您可能仍然感到困惑。让我们先来看一下总体思路：

　　

　　解释过程：

　　PM编制埋点文件（仅用于开发）

　　Fe根据文件准备提交逻辑

　　当代码联机时，它需要执行build。此时，它会触发webpack嵌入点以拔出插件

　　拔出嵌入点插件，并根据页面采集其所有嵌入点

　　采集后，向埋设点服务机构报告

　　PM可通过埋点平台查看埋点及相应数据

　　这个过程很清楚，但肯定有一些问题。让我们分别解释一下：

　　问题1：如何采集埋点

　　以Vue项目为例，我们在Vue.prototype下挂起了公共报告埋点法：

　　prototype.$log=function（actionType，backup=null）{…}

　　如果报告了页面PV，则附加参数为通道号，即：

　　this.$log('PAGE_SHOW',{channel:'xxx'})

　　解决方案：使用自定义JSDoc插件和自定义标记采集注释

　　/**

* @log 页面展现

* @backup channel: 渠道号

*/

this.$log('PAGE_SHOW',{channel:'xxx'})

　　其中，@log和@backup是JSDoc的自定义标记。还需要指定JSDoc仅监视$log的方法

　　因此，为了保持整个插件的行为一致，需要引入一个公共配置文件JS_udoc.conf.JS

　　js_uudoc.conf.js

　　module.exports = {

// 让jsdoc识别 @log

tag: 'log',

// 告知插件this.$log是发送埋点的方法，定义成数组是因为有的项目可能存在多个

method: ['$log']，

// pageType前缀，即会给项目pageType加前缀来区分不同项目

prefix: 'H5BOOK',

// pageType具体生成规则，不同项目可能规则不同

pageTypeGen: function({ prefix, routeName, dir, path, fileName }) {

return (prefix + routeName).toUpperCase();

},

// 公共的backup说明，最终单个埋点backup由公共的和私有的拼接而成

backup: 'uid：用户id',

// 项目信息，埋点上报用

projectInfo: {

projectId: '工程id，一般用项目名称',

projectName: '中文名称',

projectDesc: '项目描述',

projectIsShowOldMark: false // 是否展示老数据

}

}

　　配置文件是JS_udoc插件，以及后面提到的文件依赖性分析插件和自动添加嵌入点注释的工具

　　具体实现方法将在后续的埋点自动采集方案-埋点提取中特别说明。本文主要阐述了总体方案的原理

　　通过此步骤，您可以成功采集每个行为隐藏点，以及相应的注释和参数描述，即actiontype和相应的注释

　　当然，确定埋点有两个核心因素

　　页面类型通常是在页面运行时通过引用当前页面路由获得的。这就是问题所在

　　问题2：如何在编译时获取pagetype

　　还有一种常见情况，即通用组件，如下图所示

　　

　　组件A被多个页面引用

　　或者组件A被辅助组件B引用，然后直接或间接引入页面

　　然后，必须将组件a中的埋点采集到相应的第1页和第2页中

　　这个怎么样

　　问题是：

　　解决方案：

　　本部分的具体实现方案将在埋点自动采集方案——路由依赖性分析中具体描述

　　例如：

　　// 附近的人

export default {

routes: [

// 首页

{

path: '/page1',

name: 'page1',

meta: {

title: '转转活动页',

desc: 'xx首页'

},

component: () => import('../views/page1/index.vue')

},

...

]

}

　　当然，实际情况会非常复杂：

　　对于复杂的编写，可以通过ast语法分析来兼容，但确实需要耐心~

　　至此，核心信息采集完成

　　前面的JSDoc部分：获取每个文件的所有ActionType和相应注释

　　在这一步中，我们获得项目的所有页面路由引用和相应的组件文件依赖项

　　页面描述的取值方法：meta.desc | meta.title | name | path

　　由于页面的描述不一定与真实标题相同，因此单独添加了desc字段

　　想想看。如果您得到这些，您可以将组织行为的点数据隐藏在页面的单位中

　　在访问过程中，我们也遇到了一个问题，那就是

　　各业务页型的生成规则不统一

　　考虑到这个问题，我们在配置文件中定义了以下内容：

　　module.exports = {

...

// pageType前缀，即会给项目pageType加前缀来区分不同项目

prefix: 'H5BOOK',

// pageType具体生成规则，不同项目可能规则不同

pageTypeGen: function({ prefix, routeName, dir, path, fileName }) {

return (prefix + routeName).toUpperCase();

},

...

}

　　前缀：作为项目的个性化前缀（主要用于区分不同的项目，因为不同的项目可能定义相同的路线）

　　Pagetypegen：业务部门使用此方法定义生成pagetype的规则。我们将前缀（项目前缀）、路由名称（路由名称）、目录（文件目录）、路径（路由）和文件名（文件名）返回给用户。有了这些参数，我们基本上可以涵盖所有的路由生成方法

　　好的，最终数据结构表：

　　{

// 项目所有页面

pageList: [

// 单个页面

{

// 该页面的路由信息

routeInfo: {

routeName: 'page1',

description: 'xx首页'

},

// 该页面对应所有的行为埋点

actionList: [

{

actionType: 'PAGE_SHOW',

pageType: 'H5BOOK_page1',

backup: 'channel: 渠道号',

description: '页面展现'

},

...

]

},

...

],

// 项目信息

projectInfo: {

projectId: '项目id',

projectName: '项目名称',

projectDesc: '项目描述信息',

projectMark: '项目标记',

projectLogsMark: '埋点标记',

projectType: '项目类型',

projectIsShowOldMark: false, // 是否展示老的埋点数据，默认false

projectDefBackup: '默认参数说明'

}

}

　　埋点采集完成

　　然后添加项目相关信息，通过接口批量上报到埋点后台保存

　　后台埋点

　　我们使用eggjs+mongoose构建后台服务

　　背景系统