埋点开发
本文档内容为 Quick Tracking 产品使用介绍和技术集成说明文档，不作为销售依据；具体企业采购产品和技术服务内容，以商业采购合同为准。
开发计划
概述
提供开发计划管理功能模块，对埋点开发流程进行工具化管理，实现埋点任务的线上分发与线上流转。
从需求阶段、开发阶段、测试阶段到发布阶段每个环节需要对应不同角色进行管理，涉及产品、研发、测试三种角色，建立开发计划、埋点需求发布、埋点开发、埋点测试、计划发布&归档五个流程。支持对发布后的埋点进行归档，使开发过程透明，开发进展可见。
流程步骤 | owner | 备注 |
建立开发计划 | 产品 | 产品是计划管理员，负责建立和结束计划 |
埋点需求编辑、发布 | 产品 | 方案中的埋点需求加入开发计划 |
埋点开发 | 研发 | 线上仅流程，实际开发过程是离线的 |
埋点测试 | 测试 | 线上仅流程，提供测试工具，测试结论需要人工判断 |
埋点计划发布&归档 | 产品 | 归档后计划完结，无法进行任何修改 |
操作说明
建立开发计划
平台通过开发计划管理埋点开发需求流程，产品针对一次开发需求建立一个开发计划，填入相关角色的负责人。
编辑埋点需求
在本期埋点开发计划中勾选本期会发布的所有埋点导入计划。进入埋点方案并新建需求，弹窗展示所有有权限的方案，勾选并确认后相关事件会加入开发计划中，展示为“需求阶段”。
（1）进入：在开发计划中，进入本期埋点开发计划；
（2）勾选本期埋点：
进入埋点方案：开发计划详情页，右上角新增需求处进入“埋点选择态”
预勾选本期会发布的所有埋点导入计划：
先选择埋点所在方案（会展示有权限的方案），后选择导入方案的埋点
如此处无法在2处看见有权限的方案，请返回事件管理列表，在所属部落将需求发布人名字添加到部落编辑人员名单（下方第2个图）
在所属部落将需求发布人名字添加到部落编辑人员名单，解决无法看到对应权限问题
发布埋点需求
计划的埋点列表中会出现所有勾选埋点，所有埋点标志“需求阶段”；此时可进行埋点信息的最后修改；修改后信息会同步到事件管理页面
勾选需求-->点击“批量转交”-->转交至“开发阶段”-->选择开发名字-->埋点转交给研发、进入开发阶段：
此时如果是双端的埋点，会自动生成两条记录，分别发布给双端不同的研发即可
本流程的重点改进是即支持分批次分人发布
同时可将需求转交给其他需求人（产品），点击转交到“需求阶段”即可
可指派的人员必须先录入到开发计划的开发人员名单中（开发计划详情页中，标题下面的编辑标志）需求埋点从进入“开发状态”到“计划发布”之间，用户在事件管理页面不可修改埋点信息。
需求埋点从进入“开发状态”到“计划发布”之间，用户在事件管理页面不可修改埋点信息。
查看埋点需求
研发同学开发计划方案中，查看需开发埋点信息，流程上同时支持开发完埋点指派给测试，和打回给产品；
埋点指派给研发后，埋点状态变成“开发状态”，处理人名字变成开发名字
研发同学可筛选“我的”，查看当前属于自己的埋点；每条埋点可点击“查看详情”，查看埋点信息进行开发；
研发同学开发完成后转交给测试，勾选需求-->点击“批量转交”-->转交至“测试阶段”-->选择测试名字-->需求进入测试阶段：
如研发同学觉得埋点需求需修改，可打回给产品同学；勾选需求-->点击“批量转交”-->转交至“需求阶段”-->选择产品名字-->需求退回给产品，产品需重新修改需求，再次发布给产品同学
指派给测试或退回产品
埋点开发
研发人员可在系统中筛选出当前属于自己的埋点，每条埋点可点击“查看详情”查看埋点信息进行开发。若需要需求退回，可重新转交给产品修改需求并再次将新计划发布给研发人员，开发完成后转交至“测试阶段”，选择对应的测试人员。
埋点测试
测试同学开发计划方案中，查看需测试埋点信息，流程上同时支持测试完埋点发布，和打回给上一环节；
测试进入埋点验证环节，支持三种验证方式：App验证、web验证、小程序验证。完成测试后回到开发计划详情页发布埋点，勾选已验证通过的埋点进入发布阶段，埋点流程结束。
埋点指派给测试后，埋点状态变成“测试状态”，处理人名字变成测试同学名字
测试同学点击验证进入验证环节：点击APP验证-->进入验证页面
测试完成后，回到开发计划详情页，发布埋点；勾选已测试通过埋点-->点击“批量转交”-->转交至“发布阶段”-->选择产品名字-->需求进入发布阶段；此条埋点流程已结束。
埋点验证的具体操作参考后面埋点验证章节。
测试完成后，将埋点转为待发布
埋点计划发布&归档
本计划中所有埋点进入“发布阶段”后，即代表本计划下埋点开发完成；产品同学以管理员身份，进行计划发布和归档。 发布后，计划不可修改可在开发计划列表中，勾掉“隐藏已发布的计划”，看到历史发布计划
计划发布
已发布的计划
事件需求变化提醒
需求人员在线上修改事件需求后，开发人员可以在开发计划中了解事件需求当前状态，避免遗漏需求变化。
可视化埋点
概述
可视化埋点能够支持在不发版的情况下新增埋点，不同于传统方案只是将全埋点采集到的数据通过可视化进行命名，Quick Tracking可视化埋点仅采集配置过的埋点，有效杜绝全埋点带来的埋点冗余与带宽成本。
可视化埋点是在完成SDK初始化集成后，在Quick Tracking产品后台内以投屏的形式将待埋点的页面关联并在相应位置点击创建事件，操作人懂埋点概念即可，不需要会写代码。适合开发资源较紧张、非长期维护的页面埋点。
可视化埋点必要环节：导入可视化SDK-->可视化埋点域名设置-->进行页面埋点-->页面埋点管理-->可视化埋点使用，其中页面埋点管理和可视化埋点使用是在QuickTracking后台进行，如下内容将重点介绍后台的操作流程，SDK接入相关请参考相关SDK接入说明文档。
操作说明
页面埋点管理
在代码中完成页面埋点后，需要在QT后台“新建页面事件”录入
录入时，选择的生效范围需要包含所需应用；页面编码即为上述代码埋点时，API填入的字符串，QT中会称为pagename。
可视化埋点流程
在产品的埋点开发-->可视化埋点中，点击“新建可视化埋点”，即可开始进行可视化埋点。
选择需要进行可视化埋点的页面
点击“配置埋点”，进入投屏页。
运行代码，可以在app上看到投屏按钮，点击进入投屏码输入页，将QT后台投屏码输入
点击App上的“开始投屏”后，返回QT后台，可以看到，App界面已经展示在QT后台上。需要对哪个控件进行埋点，点击操作即可。
配置完成后，进行验证
验证后，选择生效版本进行发布。发布后及时生效
发布后，需要删除可视化配置相关SDK才可以上线。
相关删除在SDK接入文档中体现
上线后，使用埋点验证即可验证可视化埋点结果。
全埋点
概述
全埋点为预置上报的事件，主要覆盖了页面浏览、按钮点击、启动、退出等常规基础分析事件。全埋点须由开发人员完成，初始化集成Quick Tracking提供的SDK后无需过多研发工作量，由真实客户使用时产生的交互行为自动触发上报，采集面较广，但对存储、带宽等成本有较高要求。
全埋点必要环节：接入集成SDK-->在后台查看上报上来的全埋点数据列表/管理全埋点/圈选管理操作，其中在后台查看上报上来的全埋点数据列表/管理全埋点/圈选管理是在QuickTracking后台进行，如下内容将重点介绍后台的操作流程，SDK接入相关请参考相关SDK接入说明文档。
操作说明
全埋点列表
全埋点上报的事件为采集SDK自动监听捕获的控件点击、曝光和页面浏览的系统事件，这些事件将全部展示在“全埋点列表”中，您可以选择您关心的事件进行管理。全埋点事件上报的内容有：
应用（平台）：事件触发时，所在的应用appkey
事件编码：由SDK自动生成，生成逻辑为“hash（控件path）”，保证可以唯一代表一个控件。SDK也提供了相应的API，您可以在代码中修改该值。
事件名称：未管理的全埋点事件的事件名称默认为空（N/A），不会在分析中展示。您选择您关系的全埋点事件设置其事件名称，设置后，其可在分析中展示。
事件属性：全埋点提供了设置属性的API，如果设置，则会在这里展示，若没有设置则为空（N/A）。
页面编码：控件所在的页面编码，默认值如下，提供了API可以进行修改
android：默认为activity
iOS：默认为classname
小程序：默认为页面path
web：默认为页面url（不带参数）
页面名称：页面编码在QT后台被管理赋予的页面名称，若没有被管理，则为空（N/A）
页面title：页面的title内容
控件类型：控件的官方类型，如“Button”
控件内容：控件上携带的text
控件位置：控件path
控件ID：当控件设置id时，会上报内容
控件筛选器：控件selector
控件名称：只有web有，当控件设置name时，会上报内容
控件样式名：控件的类名
全埋点管理
未管理的全埋点事件可以点击操作中的“管理”进行事件管理、页面管理和属性管理，管理后的事件才会在分析中展示。
设置生效范围：选择该事件展示的应用范围
管理事件所在的页面事件：设置页面名称和携带属性
管理事件：设置事件名称、携带属性和所在页面
管理事件属性：设置属性名称和属性类型
圈选管理
全埋点管理时，由于上报的内容为SDK自动采集，可读性较差，为方便业务同学对全埋点事件进行管理，设置了圈选管理的能力。
点击“圈选管理”，选择需要埋点管理的平台
“圈选管理”连接
App端需要进行SchemeURL的配置，逻辑同埋点验证；
小程序端需要遵循页面提示，将页面上的miniappDebugId设置为“启动参数”；
web端需要将url填写至页面输入框中；
圈选管理
在圈选管理中，您在app/web/小程序端触发控件事件，采集到的全埋点事件就会展示在界面上。您可以触发一个事件，管理一个事件，管理方式和全埋点列表一致。
管理与分析
未管理全埋点事件如何分析？
未管理的全埋点事件会存在在分析的“任意事件（预置）”、“页面浏览事件（预置）”、“控件点击事件（预置）”和“控件曝光事件（预置）”中。具体如下：
App
事件名称 | 页面展示 |
页面浏览（预置） | 1、在事件分析、漏斗分析、留存分析、分布分析、间隔分析中，可在系统属性中使用“是否是自动采集”属性，选择为“是”时，筛选到所有全埋点中页面浏览事件。 2、在系统属性中，针对全埋点页面浏览事件属性还有：页面标题和控件类型。其中控件类型的值有UIViewController、Activity和Fragment。UIViewController指iOS的页面，Activity和Fragment指android的页面。 3、session分析模型，对“页面浏览（预置）”的页面标题、是否自动采集和控件类型属性则在事件属性中。 4、如果您调用了页面属性上报API，那么上报的页面属性：
|
控件点击（预置） | 1、在事件分析、漏斗分析、留存分析、分布分析、间隔分析中，可在系统属性中使用“是否是自动采集”属性，选择为“是”时，筛选到所有全埋点中控件点击事件。 2、在系统属性中，针对全埋点控件点击事件属性还有：控件ID、控件类型、控件筛选器、控件位置、控件内容、控件名字、控件样式名、页面标题。 3、session分析模型，对“控件点击（预置）”的控件ID、控件类型、控件筛选器、控件位置、控件内容、控件名字、控件样式名、页面标题、是否自动采集属性则在事件属性中。 4、如果您调用了全埋点点击事件属性上报API，那么上报的事件属性：
|
任意事件（预置） | 1、在事件分析、漏斗分析、留存分析、分布分析、间隔分析中，可在系统属性中使用“是否是自动采集”属性，选择为“是”时，筛选到所有全埋点事件。 2、在系统属性中，针对全埋点事件属性还有：控件ID、控件类型、控件筛选器、控件位置、控件内容、控件名字、控件样式名、页面标题。 3、session分析模型，对“任意事件（预置）”的控件ID、控件类型、控件筛选器、控件位置、控件内容、控件名字、控件样式名、页面标题、是否自动采集属性则在事件属性中。 4、如果您调用了全埋点属性上报API，那么上报的事件属性：
|
web
事件名称 | 页面展示 |
页面浏览（预置） | 1、在事件分析、漏斗分析、留存分析、分布分析、间隔分析中，可在系统属性中使用“是否是自动采集”属性，选择为“是”时，筛选到所有全埋点中页面浏览事件。 2、在系统属性中，针对全埋点页面浏览事件属性还有：页面标题。 3、session分析模型，对“页面浏览（预置）”的页面标题、是否自动采集属性则在事件属性中。 4、如果您调用了页面属性上报API，那么上报的页面属性：
|
控件点击（预置） | 1、在事件分析、漏斗分析、留存分析、分布分析、间隔分析中，可在系统属性中使用“是否是自动采集”属性，选择为“是”时，筛选到所有全埋点中控件点击事件。 2、在系统属性中，针对全埋点控件点击事件属性还有：控件ID、控件类型、控件筛选器、控件位置、控件内容、控件名字、控件样式名、页面标题。 3、session分析模型，对“控件点击（预置）”的控件ID、控件类型、控件筛选器、控件位置、控件内容、控件名字、控件样式名、页面标题、是否自动采集属性则在事件属性中。 4、如果您调用了全埋点点击事件属性上报API，那么上报的事件属性：
|
控件曝光（预置） | 1、在事件分析、漏斗分析、留存分析、分布分析、间隔分析中，可在系统属性中使用“是否是自动采集”属性，选择为“是”时，筛选到所有全埋点中控件曝光事件。 2、在系统属性中，针对全埋点控件曝光事件属性还有：控件ID、控件类型、控件筛选器、控件位置、控件内容、控件名字、控件样式名、页面标题。 3、session分析模型，对“控件曝光（预置）”的控件ID、控件类型、控件筛选器、控件位置、控件内容、控件名字、控件样式名、页面标题、是否自动采集属性则在事件属性中。 4、如果您调用了全埋点曝光事件属性上报API，那么上报的事件属性：
|
任意事件（预置） | 1、在事件分析、漏斗分析、留存分析、分布分析、间隔分析中，可在系统属性中使用“是否是自动采集”属性，选择为“是”时，筛选到所有全埋点事件。 2、在系统属性中，针对全埋点事件属性还有：控件ID、控件类型、控件筛选器、控件位置、控件内容、控件名字、控件样式名、页面标题。 3、session分析模型，对“任意事件（预置）”的控件ID、控件类型、控件筛选器、控件位置、控件内容、控件名字、控件样式名、页面标题、是否自动采集属性则在事件属性中。 4、如果您调用了全埋点属性上报API，那么上报的事件属性：
|
小程序
事件名称 | 页面展示 |
页面浏览（预置） | 1、在事件分析、漏斗分析、留存分析、分布分析、间隔分析中，可在系统属性中使用“是否是自动采集”属性，选择为“是”时，筛选到所有全埋点中页面浏览事件。 2、session分析模型，对“页面浏览（预置）”的页面标题、是否自动采集和控件类型属性则在事件属性中。 3、如果您调用了页面属性上报API，那么上报的页面属性：
|
控件点击（预置） | 1、在事件分析、漏斗分析、留存分析、分布分析、间隔分析、session分析中，可在系统属性中使用“是否是自动采集”属性，选择为“是”时，筛选到所有全埋点中控件点击事件。 2、如果您调用了全埋点点击事件属性上报API，那么上报的事件属性：
|
控件曝光（预置） | 1、在事件分析、漏斗分析、留存分析、分布分析、间隔分析、session分析中，可在系统属性中使用“是否是自动采集”属性，选择为“是”时，筛选到所有全埋点中控件曝光事件。 2、如果您调用了全埋点曝光事件属性上报API，那么上报的事件属性：
|
任意事件（预置） | 1、在事件分析、漏斗分析、留存分析、分布分析、间隔分析、session分析中，可在系统属性中使用“是否是自动采集”属性，选择为“是”时，筛选到所有全埋点事件。 2、如果您调用了全埋点事件属性上报API，那么上报的事件属性：
|
已管理全埋点事件如何分析？
管理后的全埋点事件会根据事件名称和事件类型，独立的展示出来，分析的属性包含全埋点的属性。
埋点配置
概述
埋点配置模块是远程配置应用端采集行为的模块，发布配置后，应用端再次向服务端发数据时生效。
操作说明
埋点配置列表
该模块记录了各个平台的远程配置情况
添加配置：选择指定平台，进行远程配置。若选择的平台已经存在配置，则会直接进入配置发布台，并显示最近一次配置信息。
编辑配置：对于已经发布配置的平台，可以进行配置更改
历史记录：记录各个平台的发布历史，点击“恢复”，可以恢复线上配置到该版本
埋点配置发布台
埋点配置分为四部分：全埋点控制、事件采样率设置、日志发送限制（仅App端提供）和黑名单用户配置。
全埋点配置
关闭线上配置：全埋点默认线上配置的优先级最高，若线上配置项与API功能有冲突时，默认按照线上配置的要求采集。比如，端上使用API关闭全埋点采集，线上下发配置为打开，则端上依然会采集全埋点事件。当选中“关闭线上配置”时，则线上配置为空，一切设置根据API为准。
全埋点采集功能：设置端上是采集全埋点事件，还是不采集全埋点事件。只有选择采集时，下面的3、4、5区块才会展示。
是否采集页面：开始则会自动采集页面浏览事件，关闭则不会自动采集页面浏览事件。
是否采集控件点击：开启则会采集全埋点控件点击事件，关闭则不会采集全埋点控件点击事件。
需要关闭采集的控件类型：当打开全埋点控件点击事件时，可以选择哪些控件不采集，勾中的则为不采集控件。
注：以上仅影响全埋点采集的事件，不影响手动埋点的页面、点击事件。
事件采样率设置
勾选需要进行设置采样率的事件，勾选完成后，可以统一设置采样率。
每个采样率的设置最多选择200个事件，每次配置最多设置5种采样率。
一个事件只能被设置一个采样率，若在设置采样率时，事件已经被设置了其他采样率，则可以点击“重置”，重新对其设置采样率，原来的采样率则会失效。
日志发送限制
在app端默认日志发送间隔为3s，该值可以进行调整，调整范围为3s-90s
黑名单用户配置
填写设备ID（utdid），则该设备的日志不会被采集和上报。utdid可在用户洞察的个人细查中获取。