元数据管理
1. 概述
元数据管理是系统中的数据管理模块，是用户用以统一管理元数据的地方。
TapDB 采用元数据预登记模式，在接收 SDK 数据前，必须将需要收集的事件、属性登记到元数据管理相应的功能模块中，系统在接收数据时，需按照预登记的元数据进行校对，对于符合条件的数据进行入库，不符合要求的数据将被拒绝。
该模式可以有效地提高数据的准确性，从根本上解决数据报告和存储不正确的问题。
元数据管理由事件管理、事件属性管理和用户属性管理 3 部分构成。
2. 适用角色与用途
| 角色 | 用途 |
|---|---|
| 管理员 | 录入埋点方案，管理系统元数据 |
| 业务人员 | 查看元数据，了解数据业务含义 |
| 客户端 / 前端工程师 | 查看埋点需求 |
3. 事件管理
「事件」是系统中各类数据分析模型的基本分析对象，系统内置「预置事件」，并提供上报「自定义事件」的功能。
在「事件管理」功能中，可在对「自定义事件」在上报前进行预登记，并从多方面对「事件」进行管理。
前端工程师通过查看「曾否上报」为「否」的预登记自定义事件，进行埋点开发。
3.1 概念解释
「事件」相关的「概念」及其「解释」如下：
| 概念 | 解释 |
|---|---|
| 事件名 | 事件的唯一标识 |
| 显示名 | 事件在分析模型中的显示名称 |
| 说明 | 描述埋点的各方面信息，如：描述触发时机，帮助技术人员更准确埋点；描述业务内涵，帮助业务人员更深入理解 |
| 事件类型 | 目前分为「预置」、「自定义」两类： 预置：系统内置的事件，广泛适用于各类游戏项目，仅需在 SDK 中打开埋点开关即可上报 自定义：自定义创建的事件，满足游戏项目的个性化需求，上报前需在事件管理中录入 |
| 曾否上报 | 事件是否有过上报记录 |
| 接收开关 | 系统接收事件上报与否的开关 |
| 状态 | 目前分为「正常」、「隐藏」、「删除中」、「已删除」四种状态： 正常：处于正常状态的事件 隐藏：不在分析模型中展示 删除中：已上报数据的事件在被删除后将进入「删除中」状态，72 小时内可撤回，在此期间依然接收数据，但不展示在分析模型中 已删除：已上报数据的事件在被最终删除后，将以「已删除」状态记录在元数据管理中，不再接收数据与展示在分析模型中，且不占用自定义事件数据使用进度 |
| 事件属性 | 事件所需采集的属性信息，在新建、编辑事件中可选择绑定相应的事件属性。目前事件属性分为「预置」、「自定义」两类： 预置：新建的事件默认处于「调试」状态，不在分析模型中展示 自定义：自定义创建的事件属性，满足游戏项目的个性化需求。 |
| 数据限制 | 为保证系统性能，处于「正常」、「隐藏」、「删除中」状态的自定义事件数不可超过 100。「已删除」的自定义事件不占用使用进度，可通过删除自定义事件释放使用进度。 |
3.2 创建自定义事件
填写事件的基本信息，此时系统默认关联所有的预置属性，且默认不关联所有的自定义属性。
选择需要关联的自定义属性，若不满足需求可新建自定义事件属性，以及解绑不需要关联的预置属性，即完成自定义事件的创建。
3.3 查看、编辑、删除事件
点击事件名可查看到此事件的基本信息，以及所有关联属性。
在操作栏，可编辑事件的基本信息以及变更与事件属性的关联关系，对于已发生上报的事件，「事件名」不可再被编辑。
在操作栏，可对已有的自定义事件进行删除操作。未上报数据的事件将被彻底删除，不留下任何记录；已发生上报的事件，将进入「删除中」状态，72 小时内可进行撤销操作，否则将进入「已删除」状态，不再接收数据与展示在分析模型中，同时释放自定义事件数据使用进度限制。
3.4 Q&A
Q1：为什么有的事件被删除后不保留任何记录，而有的事件被删除后以「已删除」状态留在元数据管理中？
A1：未发生上报的事件不保留记录，已发生上报的事件则会保留。在埋点的设计过程中，业务人员会因为需求变更、需求合并处理等问题对埋点设计进行多次变动，因而在没有进行上报行为之前，可以认为所有的录入行为都是在「打草稿」，我们希望用户在此过程中可以无所顾忌，不用担心把事件管理列表弄得一团糟；而一旦数据发生上报，相当于定稿，我们希望系统可以忠实的记录项目曾经采用的所有数据采集方案。
4. 事件属性管理
「事件属性」是用来描述「事件」的属性信息，TapDB 内置「预置事件属性」，并提供上报「自定义事件属性」功能。
在「事件属性管理」功能中，可在对「自定义事件属性」进行预登记，并从多方面对「事件属性」进行管理。
前端工程师通过查看「曾否上报」为「否」的预登记自定义事件属性，进行埋点开发。
4.1 概念解释
「事件属性」相关的「概念」及其「解释」如下：
| 概念 | 解释 |
|---|---|
| 属性名 | 事件属性的唯一标识 |
| 显示名 | 事件属性在分析模型中的显示名称 |
| 说明 | 描述属性的各方面信息，如：描述业务内涵，帮助业务人员更深入理解 |
| 数据类型 | 属性的数据类型，类型相符的数据方可入库 |
| 单位 | 统计值的单位，在分析模型、报表中作相应展示 |
| 属性类型 | 目前分为「预置」、「自定义」两类： 预置：系统内置的事件属性，广泛适用于游戏项目中的各个事件，仅需在 SDK 中打开埋点开关即可上报： 自定义：自定义创建的事件属性，满足游戏项目的个性化需求，上报前需在事件属性管理中录入 |
| 曾否上报 | 事件属性是否有过上报记录 |
| 接收开关 | 系统接收事件属性上报与否的开关 |
| 状态 | 目前分为「正常」、「隐藏」两种状态： 正常：处于正常状态的事件 隐藏：不在各个分析模型中展示 |
| 数据限制 | 为保证系统性能，自定义事件属性数不可超过 300 |
4.2 创建
填写事件属性的基本信息，即完成自定义属性的创建。可在「事件管理」中将其与事件进行关联。
4.3. 查看与编辑
点击属性名可查看到此属性的基本信息，以及所有关联事件。
在操作栏，可编辑除「属性名」、「数据类型」之外的其他事件属性基本信息。
4.4 Q&A
Q1：为什么不能删除未进行任何数据上报行为的自定义事件属性，而自定义事件却可以被删除？
A1：增加一个新事件在数据表中仅为一条数据记录，而增加一个新属性则需要在数据表中增加新的一列，改变原有的数据结构，两者在实现上难度相差很大。因而在初版中暂不支持删除自定义属性功能，后续会迭代删除自定义属性功能，敬请期待。
5. 用户属性管理
「用户属性」是用来描述于「用户」的属性信息，TapDB 内置「预置用户属性」，并提供上报「自定义用户属性」功能。
TapDB 分别以「账号」、「设备」作为用户标识对不同主体进行分析，在用户属性管理中，「账号」、「设备」也将分别作为用户标识的组成部分
在「用户属性管理」功能中，可在对「自定义用户属性」进行预登记，并从多方面对「用户属性」进行管理。
前端工程师通过查看「曾否上报」为「否」的预登记自定义用户属性，进行埋点开发。
5.1 概念解释
「用户属性」相关的「概念」及其「解释」如下：
| 概念 | 解释 |
|---|---|
| 用户标识 | 用户属性的标识之一，分为「账号」、「设备」两类 |
| 属性名 | 用户属性的标识之一，与「用户标识」共同组成唯一标识 |
| 显示名 | 用户属性在分析模型中的显示名称 |
| 说明 | 描述属性的各方面信息，如：描述触发时机，帮助技术人员更准确埋点；描述业务内涵，帮助业务人员更深入理解 |
| 数据类型 | 属性的数据类型，类型相符的数据方可入库 |
| 单位 | 统计值的单位，在分析模型、报表中作相应展示 |
| 属性类型 | 目前分为「预置」、「自定义」两类： 预置：系统内置的用户属性，广泛适用于游戏项目中的各个事件，仅需在 SDK 中打开埋点开关即可上报 自定义：自定义创建的用户属性，满足游戏项目的个性化需求，上报前需在用户属性管理中录入 |
| 曾否上报 | 用户属性是否有过上报记录 |
| 接收开关 | 系统接收用户属性上报与否的开关 |
| 状态 | 目前分为「正常」、「隐藏」两种状态： 正常：处于正常状态的事件 隐藏：不在分析模型中展示 |
| 数据限制 | 为保证系统性能，自定义用户属性数不可超过 100 |
5.2 创建
填写用户属性的基本信息，即完成自定义属性的创建。目前，自定义用户属性一旦被创建便不可被删除。
5.3 查看、编辑与复制
点击属性名可查看到此属性的基本信息。
在操作栏，可编辑除「属性名」、「数据类型」之外的其他事件属性基本信息。
在操作栏，可通过复制功能新建一个各项信息相同但切换了用户标识的自定义用户属性，方便快速对设备、账号两个用户识别体快速同步创建自定义用户属性。
5.4 Q&A
Q1：为什么需要区分「设备」、「账号」两个主体？
A1：在不同场景中，以不同的主体来标识用户，从而更能切合业务需求。如广告投放相关业务中，设备是更好的用户标识，而分析用户具体游玩行为时，账号可能是更好的用户标识。另外，可善用复制操作，对两类标识的用户属性进行同步创建。