共计 5500 个字符，预计需要花费 14 分钟才能阅读完成。
1. 前言
埋点设计文档面向开发的埋点需要说明书，目标是让开发了解须要在什么状况下做哪些埋点采集，以及具体须要的属性参数类型、取值，确保采集的准确性和欠缺性。为实现整体指标体系，数据产品落地、应用，须要对开发进行埋点方案设计，利于日后对立治理，批改，保护。保障口径对立，可追溯，易了解。
埋点设计作为数据建设的重要组成的局部，间接影响到后续的数据利用品质和数据回溯，而咱们在日常中是不是常常会碰到如下问题：
作为一个入职一家新公司的数据产品（分析师），面对环境中的几百个事件，或者 afsdfgfhtr 无任何标注的属性名，茫然手足无措，不知所以然，而后任留下的文档也是似有若无，询问身边的老员工则众口不一，之前埋点的研发也到职了，罗唆我就从新埋点吧……
作为一个经营人员，流动策动写好了，流动页面做好了，哈哈，到了大展身手的时候啦，想详细分析不同人群的数据反馈。忽然发现很多属性信息没有，不足以细分，好的，什么也不必干了……
作为一个产品人员，新版本上线后，想详细分析新版本上线后的数据变动。心田 os：还好之前提了埋点的需要，不像下面那个经营没有数据能够查。几分钟后……等等，为什么这个数据和后盾业务数据很不一样……
作为公司的业务人员，据说公司新上了一个数据产品零碎，而我前一阵子才学习了一些数据分析基础知识，心田：我也要不断进步。关上零碎……几分钟后，分析模型懂，事件涵义懂，属性涵义懂，就是不晓得这里传值的 afsdfgfhtr，123，456……都是什么意思呀……
……
通过下面的情景再现，所以大家意识到了吧，负责埋点设计的咱们，不仅仅是一个工具人，如果底层建设不好，就会造成大量的资源节约和工夫老本，以及自身数据可用价值性大大降低。作为一个埋点设计的人员要给咱们本人，还有给外部，尤其给管理人员，正确建立起看待埋点建设的态度，这是一个零碎的工程，只有埋点要做到定义分明可回溯、业务变动可迭代、重要需要可笼罩等，才能够防止前期返工、缩小不必要的工夫老本节约，提高效率，进步数据准确度，进步数据使用率。
那么问题来了，如何做好埋点设计的兼顾，做好这个工程项目的治理呢？可分为以下三个局部：
- 埋点我的项目布局
- 埋点设计方案
- 埋点数据推广应用
2. 埋点我的项目布局
一个公司内不仅仅有火山引擎的增长剖析的数据产品，还会有业务数据库、机器学习平台、bi 零碎等各种数据系统，而增长剖析的数据产品须要承接什么样的需要，怎么买通各个数据产品之间的连贯，是一开始最须要思考的问题。
因而初期咱们可设定：
增长剖析数据产品：次要承接行为数据和局部和行为相干的业务数据（例如领取、注册、实名认证等）的需要。
确立惟一用户的标识 id，保障各数据系统传输 id-mapping 老本不高。
2.1 建设标准化流程
埋点建设的阶段咱们分为两个重要的阶段。
初建设，0-1。初期从 0 开始建设埋点体系。
长期迭代，1-N。曾经有一些埋点体系，从原来的根底上进行迭代建设。
倡议流程如下：
- 初期建设，0-1
- 长期迭代，1-N
2.2 确认各角色责任人
以上不论是初期建设或者长期迭代，总共角色分为以下几种。
注意事项：
- 埋点需要源于业务需要，为避免浪费数据资源，不能为了埋点而埋点，切莫一味谋求多而全。
- 对于角色安顿
- 同一人可同时负责需要评审方与埋点设计方案方，其余角色不倡议有人员重合。
需求方通常为产品、经营、数据分析等应用数据业务方，埋点设计与需要评审方通常为数据分析师、数据产品等数据中台建设者。
在埋点验收之前减少业务验收环节，是思考局部测试人员不能精确了解业务需要，或者有脱漏，为保障埋点合乎业务人员预期，如果在此环节，需求方或者埋点设计方发现不对，可在上线前及时调整。
2.3 治理小技巧
流程化治理如果有需要管理系统最好，例如。如果没有为了保障可追溯以及各部门人员了解统一，要制订严格的文档标准，对于需要提出的日期、背景形容、提出人、评审意见、评审人、埋点设计方案、埋点设计人、开发人员、测试人员等都要进行具体记录。
定期进行清理，例如对近半年没有数据接入的事件或者近半年没有被查问的事件，经业务确认后，可进行暗藏或者停用治理。
3. 首次埋点设计步骤
埋点设计可参考上述步骤进行设计，步骤具体注意事项如下：
3.1 明确用户标识
3.1.1 用户标识底层逻辑
火山引擎增长剖析应用 device_id、user_unique_id、ssid 三种 id 标识设施和用户。
3.2 明确是否开启全埋点 + 预置事件计划
3.2.1 预置事件采集
预置事件接入根底 SDK 可默认主动采集，依照具体需要，抉择接入对应端的 SDK。
3.2.2 全埋点采集事件
全埋点事件接入根底 SDK 可抉择开启或者不开启，须要留神的是，全埋点长处是采集便当，节约投入老本，毛病是耗费事件量大，且只满足个别的根底 PV,UV 采集指标需要，利用范畴窄，请审慎开启。如不明确是否开启，可征询相干服务反对人员。
bav2b_page 全埋点页面拜访，仅开启全埋点后上报
bav2b_click 全埋点元素点击，仅开启全埋点后上报
开启、不开启形式详见各个端 SDK 接入文档、下图为 IOS SDK 开启形式示例。
3.3 设计自定义埋点计划
如果想要深入分析业务，造成数据驱动，肯定是须要在预置事件的根底上，补充更多的自定义代码埋点。自定义埋点的灵活性、自主性、应用性更高。设计埋点人员应依据业务外围诉求，造成事件设计文档，交付给研发团队进行数据接入。
自定义埋点计划示例：
事件表 - 自定埋点设计因素：
（1）序号
每个事件一个固定编号，编号惟一且不可批改，不便文档查阅、回溯，进行治理。
（2）事件名称
每个形象的行为事件，一个中文名、一个英文名，中英文必须是一一对应关系，不能够反复，代表涵义统一。
对于事件英文的命名，防止混淆不堪，需采纳对立标准进行命名。倡议规定有 –
可采纳下划线辨别 -regist_submit, 或者驼峰命名辨别 registSubmit（由一个或多个单词连结在一起，第一个单词以小写字母开始，从第二个单词开始当前的每个单词的首字母都采纳大写字母）。
采纳动词_名词或者名词_动词进行对立。
如果有多条业务线，可在事件前加业务线名称的标识，例如 a_regist_submit.
大小写敏感，如果传了 Name，就不倡议传 name。
自定义事件英文名不得以 $ 结尾。
（3）事件属性名称
每个事件属性，一个中文名、一个英文名，中英文必须是一一对应关系，代表涵义统一。
但同一个属性可被多个事件援用，例如浏览商品详情页事件和珍藏商品详情事件，能够共用属性，商品名称、商品 ID 等。同一属性在不同事件中字面意义相近，但实际意义有差异时，不倡议复用，倡议基于属性的理论含意对属性进行辨别。例如：在“动画加载”的事件中，“时长”这个属性代表的意义是“加载时长”；而在“视频播放”的事件中，“时长”代表的意义是“播放时长”。在这样的状况下，不倡议复用“时长”这个字段，而是拆解为两个字段别离命名。
属性命名采取 snake 命名法，即单词全副小写，单词间用 ”_” 宰割。
- 属性命名时通常应用名词的模式。例如：product_type，product_id 等。
- 自定义属性英文名不得以 $ 结尾。
- 自定义属性的英文名与中文名需放弃严格的一一对应。
- 大小写敏感，如果传了 Name，就不倡议传 name。
事件 & 属性限度： - 单个利用的事件数量不超过 1000 个（不同利用之间互不影响）；
- 单个事件的属性数量举荐 300 个以内，最多不超过 500 个（不同事件之间互不影响）；
- 单个利用自定义公共属性数量不超过 100；
- 事件名称和属性名称长度倡议在 50 字节以内，事件属性名最长不超过 80 字节，公共属性名最长不超过 64 字节；
- 属性值长度倡议不超过 255 字节，非凡状况如 url 等最大反对 1024 字节。
- 超过上述限度时，超过的事件、属性数据可能会被零碎主动抛弃。
- 预置的事件和属性不可进行批改。另外服务端埋点时，无奈主动采集预置公共属性，须要手动传输。
-
多端传输肯定要对立好事件和属性命名，保障传输统一。
（4）属性类型
bool，是否，true/false
（5）属性值含意或示例
此列意在为研发人员明确属性字段的含意，以及非凡状况的阐明，便于研发人员了解与施行。
（6）事件的触发机会
需阐明每一个事件应在何时触发，如一个事件在多个机会均有可能会被触发，则须要整顿出所有的触发机会。例如：“点击开始注册事件”的触发机会应为点击注册时，但注册通常有多个不同的入口，因而，业务人员须要明确地枚举出哪些注册入口是须要研发人员进行埋点的，如果有属性值的辨别也要标注，防止脱漏。
（7）埋点模式
事件埋点模式反对前端、后端两种。不同机会触发，失去数据后果不统一。例如注册事件，前端提交注册时触发，无奈明确注册胜利还是失败。后端注册返回后果后触发，既能够明确注册后果，又能够防止前端数据失落。个别状况下，外围业务流程事件倡议后端埋点，保证数据准确性，例如：产品购买、注册胜利等。在非凡状况下，也能够采纳前后端合作的形式进行埋点，由一端将收集到的数据传给另一端后，再由数据接收端触发事件埋点。
（8）备注
可做排期优先级标注，以及其余非凡状况备注。
用户表设计因素
（1）用户属性
用户属性需是形容用户较为长期状态的属性，例如人口学信息、账号信息等。
（2）发生变化的用户属性
首先用户属性可进行更新，例如 VIP 等级、最近一次领取工夫等。
须要留神的是，比方用户的 VIP 等级，用户属性只记录以后最新状态，比方 VIP 等级能够从 level1 变成 level2，也可从 level4 变为非 VIP，用户属性只记录该用户以后 VIP 等级的最新状态。如果想要获取用户在历史状态操作时的 VIP 等级需要，还须要减少事件属性 VIP 等级，可依据具体需要进行抉择。如果有不明确的中央，可征询相干服务反对人员。
公共属性
公共属性为所有事件均有的属性，例如：事件产生的平台，事件所属的业务模块等。没有该业务需要时可疏忽公共属性。
整体的设计思路
（1）确立察看指标
依据后期建设的指标体系，一一梳理。
（2）形象过程行为
形象察看指标的行为事件，例如想要察看领取转化率？明确领取转化率的定义为利用启动 - 进入商品列表页 - 浏览商品详情页 - 提交订单 - 领取胜利转化率，把每个行为形象为一个事件。
（3）补充事件属性
察看领取转化率，业务需要还远远不够，还须要察看不同商品价格的转化率，不同店铺的转化率，不同商品分类的转化率等，因而须要在可能记录这些相干信息的事件减少事件属性，不便前期做维度拆分。如图所示，浏览商品详情页可减少商品相干属性。
（4）设计事件因素
将事件的触发模式、英文命名、埋点端、属性值类型、属性值示例补充残缺。
（5）补充用户属性
如果想看不同性别、不同注册月份的用户转化率区别，则须要减少用户属性。
3.4 确认是否须要导入后盾业务数据库、标签等数据
在更多的业务场景中，有许多数据比较复杂，例如银行贷款业务数据库中，对每个用户计算的风控等级，可作为用户属性导入。
例如批发在线下交易，产生行为不在线上，或者在线教育中，对客户的线下电话促活召回，不可作为线上行为数据采集，这种存储在业务数据库的数据，也可做事件和属性的形象，用业务数据库导入形式，并确定导入周期频率（按天、按周等），定期导入。
3.5 确认可行性和排期。
设计人员应与研发一一确认事件和属性采集的可行性与老本，对于实现老本高，须要重要性不高的需要可做取舍，并制订整体埋点优先级的排期。
4. 常见问题
4.1 类似场景是合并一个事件还是分不同的事件
设计为同一事件
例如类似场景下的按钮点击可合并，不用一个点击一个事件，需合并为一个事件。
对于全局性的事件，咱们倡议设计为同一事件，通过特定的属性值对特定操作进行辨别，而不是针对每一个操作设计一个事件。
设计为同一事件
例如：点击 banner、点击热门流动位，都是点击首页的举荐位，可通过减少属性辨别。
各事件所需属性相差不大，平时剖析场景多整体剖析。
设计为不同事件
例如一个内容平台，有视频，有文章，因视频和文章所记录属性差别较大，浏览内容详情应辨别为浏览视频详情和浏览文章详情
各事件所需属性相差很大，剖析场景多别离剖析。
设计为不同事件
例如：珍藏商品、浏览商品详情，虽属性差别不大，然而珍藏和浏览业务关系不大，且通常为独自剖析。
各事件所需属性相差不大，但平时剖析场景繁多剖析，并且业务涵义区别较大。
4.2 多重身份用户的设计
在在线教育用户中，有多重用户身份，例如老师、学生、家长等，要做好用户属性的辨别，对不同身份用户的属性进行不同的设置。
4.3 主被动事件的解决
在线上行为中，很多须要记录的埋点事件非用户被动触发，为被动触发，例如平台审核，发放优惠券，被其他人关注，所以这种场景下不存在被动事件，被动触发行为的不是用户，用户是行为的接受者，被动受到影响。然而在剖析需要比方审核通过率，须要提交审核 - 审核通过的主体 ID 为一人，此时被动事件的上报主体会影响到剖析后果。
4.4 曝光事件的解决
和其余事件一样，只是曝光事件的触发机会须要留神，例如某平台内容曝光事件触发机会为：
1、内容露出全副，且 feed 流静止状态超过 2s 算曝光
2、限度繁多内容一次申请只会呈现一次曝光。（比方高低滑动屏幕，只有不刷新产生新申请，算一次曝光）
当然具体的规定可依据需要和研发的实现老本灵便变动，以上仅为示例，可做调整。另外，须要留神的是，曝光触发事件量微小，个别剖析 CTR，或者有举荐算法数据需要时须要曝光事件，其余场景请依据需要审慎埋点。
4.5 虚构事件
虚构事件是对元事件的合并和拆分，是一个非凡性能。所以在事件埋点设计时，如果虚构事件可满足，不用减少新埋点。
立刻跳转火山引擎增长剖析 DataFinder 理解详情