业务埋点和数据分析是在用户行为和业务数据上进行跟踪、收集和分析的关键方法，用于了解用户行为模式、改进产品和服务，并做出数据驱动的决策。

        全文1.5万字，建议阅读时间35min。

目录

业务埋点

埋点的重要性

埋点的类型

全埋点

代码埋点

埋点总结

新增埋点设计

序号

事件名称

事件属性名称

属性类型

属性值含义或示例

设计元素

上报信息

事件的触发时机

用户表设计要素

数据指标地图

版本迭代功能埋点管理

埋点应用

可视化数据大屏

开源数据展示工具 

数据应用平台

数据仓库

建立标准化流程

某些特殊情况

相似场景是合并一个事件还是分不同的事件

多重身份用户的设计

主被动事件的处理

曝光事件的处理

虚拟事件

社交数据采集方案示例

用户表

公共属性

部分自定义事件

预置事件

数据分析

数据分析的作用

描述性分析

诊断性分析

预测性分析

处方性分析

数据分析方法

事件分析

分布分析

留存分析

漏斗分析

路径分析

小结

数据分析切入点

功能交互数据分析

竞品调研

KPI数据

数据报告流程

数据清洗

数据整理

描述分析

数据敏感性

合法化

---

业务埋点

        业务埋点是指在应用程序或网站中插入特定的代码或标记，以捕捉和记录用户的行为和交互数据。这些代码通常由开发人员添加到关键的触点或事件中，例如页面浏览、点击、表单提交等。通过业务埋点，可以跟踪和记录用户在应用程序或网站上的具体行为，生成事件和属性数据。

埋点的重要性

举个栗子。。

今天，辛苦半年做的产品终于上线了。出于对产品的认真负责，你有点好奇今天有多少人使用了这个产品。于是跑去研发同学那，于是……

今天？今天还没过完，还是给个确切的时间范围吧...

这个多少指的PV还是UV？

人的定义是？IMEI？udid？oaid？还是user_id或者什么?

这个怎么算使用？进入首页？注册？还是触发某个事件？

哦 好的 你再完善一下需求吧

正因如此，从另一个角度来说，埋点也是数据分析的完整路径中必不可少的第一步。

GET

1. 什么是“埋点”？“埋点”是互联网产品收集数据的一种基础且被广泛应用的方法。
2. 为什么要“收集数据”？因为我们要获取数据支撑后续的数据分析，并最终驱动业务发展。

埋点的类型

在AB测试的场景下，数据埋点为实验组的效果提供数据支持，其本质也是数据决策的基础。

根据目前常见的数据埋点形式，可以将数据埋点分为全埋点，和代码埋点（自定义埋点）。

全埋点

        全埋点是指数据采集sdk无差别的，将所有页面的加载成功事件，和控件的浏览和点击事件全部获取后先存下来，到使用的时候，再根据具体的页面路径和控件名称，去捞取相应的数据。

        基于此，可视化埋点是指，在全埋点部署成功、已经可以获得全量数据的基础上，以可视化的方式，在对应页面上定义想要的页面数据，或者控件数据。

优点

1. 由于采集的是全量数据，所以产品迭代过程中是不需要关注埋点逻辑的，也不会出现漏埋、误埋等现象；
2. 全埋点方式因为收集的是全量数据，可以大大减少运营和产品的试错成本，试错的可能性高了，可以带来更多启发性的信息；
3. 无需埋点，方便快捷

缺点

1. 缺点与可视化埋点相同，未解决个性化自定义获取数据的问题，缺乏数据获取的灵活性；
2. 无埋点采集全量数据，给数据传输和服务器增加压力；
3. 无法采集自定义属性、事件，上报行为信息容易受限；
4. 对web的页面数据处理一直不好，尤其是涉及到APP的内嵌H5页时，非常痛苦。

可视化埋点优缺点基本一致，业务人员自己按规则操作即可，无需开发再次接入。

        因此，全埋点适用于业务多变、经常调整，且分析诉求比较轻量的场景。对于通用的功能，形态相对比较固定，且对数据分析颗粒度、下钻深度、聚合程度要求比较高，那就需要用到代码埋点

代码埋点

        代码埋点也叫自定义埋点，即针对想要的点位单独定义，并可以通过变量丰富埋点的信息，以支持上下游分析。

代码埋点分为前端埋点和后端埋点。

前端埋点：

        包括但不限于APP客户端、H5、微信小程序、PC网页，是指对具体的功能场景（如加载成功、浏览、点击等）进行明确的定义，由前端触发，采集上来的数据相比于全埋点，更准确、稳定，且通过变量字段，能够实现更细颗粒度数据的拆分、聚合和下钻。

后端埋点：

        指触发了服务端接口调用（如：接口回调成功触发）的事件埋点，如最典型的注册成功事件、付费成功事件。后端埋点对数据的准确度要求更高，同时也可以通过变量字段的扩展支持数据拆分、聚合和下钻。需要强调的是，后端事件一般采集的是已登录状态下的用户行为，如果想使用后端埋点事件作为流程分析的其中一环（如漏斗分析），则可能出现未登录的用户会漏掉的情况。

埋点总结

综合以上，几种埋点类型的比较

埋点类型总结

埋点方案	实施方案	优点	缺点
全埋点	开发人员集成采集 SDK 后，SDK 便直接开始捕捉和监测用户在应用里的所有行为，并全部上报	1.全量数据，可以大大减少运营和产品的试错成本 2.无需埋点，方便快捷 3.产品迭代过程中是不需要关注埋点逻辑的，也不会出现漏埋、误埋等现象	1.未解决个性化自定义获取数据的问题，缺乏数据获取的灵活性 2.全量数据，给数据传输和服务器增加压力 3.无法采集自定义属性、事件
可视化埋点	利用可视化交互手段，业务人员都可以直接在页面上进行简单圈选，以追踪用户的行为	1.人力成本低、更新成本较小 2.只需接入SDK，后续埋点业务人员按规则操作即可，无需开发再次接入	1.无法做到自定义获取数据，覆盖的功能有限 2.上报行为信息容易受限
前端埋点	前端定义的事件触发时,上传对应数据	1.较为准确 2.基本不会受页面改版影响	1.有一定开发工作量 2.设计新功能时需要考虑对原有埋点的影响,维护指标文档 3.会受网络环境等因素影响,出现数据无法上报或延时上报
后端埋点	服务端定义的事件触发时,上传对应数据	1.最为准确 2.不受前台功能改版影响	1.开发和测试的工作都较大 2.不容易发现问题

交互、点击、浏览类前端采集为主。

核心业务例如支付、注册等，建议后端。

新增埋点设计

        一款互联网产品每天产生的数据是庞大杂乱的，全部都存下来会占据硬盘空间，而且，不加定义和标记的数据也很难使用。因此，在初期的数据建设阶段，先要做的是定义想要的数据，告诉前端开发和后台的同事，你想要的数据有哪些，定义这些数据的字段包括但不限于以下字段：

序号	事件名称	事件展示名	属性名称	属性展示名	属性类型	属性值含义或示例	事件触发时机	埋点方式	备注
1	regist_submit	用户 注册	regist_type	注册方式	string	手机号/邮箱...	返回注册结果时触发	服务端
			is_success	是否成功	string	true/false	返回注册结果时触发	服务端
			fail_reason	失败原因	string	网络原因/其他原因	返回注册结果时触发	服务端

序号

每个事件一个固定编号，编号唯一且不可修改，方便文档查阅、回溯，进行管理。

事件名称

每个抽象的行为事件，一个中文名、一个英文名，中英文必须是一一对应关系，不可以重复，代表含义一致。 对于事件英文的命名，避免混杂不堪，需采用统一规范进行命名。建议规则有：

• 可采用下划线区分-regist_submit, 或者驼峰命名区分registSubmit（由一个或多个单词连结在一起，第一个单词以小写字母开始，从第二个单词开始以后的每个单词的首字母都采用大写字母）。

• 采用动词_名词或者名词_动词进行统一。

• 如果有多条业务线，可在事件前加业务线名称的标识，例如 a_regist_submit。

• 大小写敏感，如果传了 Name，就不建议传 name。

• 自定义事件英文名不得以 $ 开头。

事件属性名称

• 单个应用的事件数量不超过 1000 个（不同应用之间互不影响）。

• 单个事件的属性数量推荐 300 个以内，最多不超过 500 个（不同事件之间互不影响）。

• 单个应用自定义公共属性数量不超过100。

• 事件名称和属性名称长度建议在 50 字节以内，事件属性名最长不超过 80 字节，公共属性名最长不超过64字节。

• 属性值长度建议不超过 255 字节，特殊情况如url等最大支持 1024 字节。

• 超过上述限制时，超过的事件、属性数据可能会被系统自动丢弃。

• 预置的事件和属性不可进行修改。另外服务端埋点时，无法自动采集预置公共属性，需要手动传输。

• 多端传输一定要统一好事件和属性命名，保证传输一致。

1. 每个事件属性，一个中文名、一个英文名，中英文必须是一一对应关系，代表含义一致。 但同一个属性可被多个事件引用，例如浏览商品详情页事件和收藏商品详情事件，可以共用属性，商品名称、商品ID等。同一属性在不同事件中字面意义相近，但实际意义有差别时，不建议复用，建议基于属性的实际含义对属性进行区分。例如：在“视频加载”的事件中，“时长”这个属性代表的意义是“加载时长”；而在“视频播放”的事件中，“时长”代表的意义是“播放时长”。在这样的情况下，不建议复用“时长”这个字段，而是拆解为两个字段分别命名。

   事件&属性限制：

   • 属性命名采取 snake 命名法，即单词全部小写，单词间用"_"分割。

   • 属性命名时通常使用名词的形式。例如：product_type，product_id等。

   • 自定义属性英文名不得以 $ 开头。

   • 自定义属性的英文名与中文名需保持严格的一一对应。

   • 大小写敏感，如果传了 Name，就不建议传 name。

属性类型

属性值	含义
int	需要进行聚合运算（例如求和、均值）或者按区间分组的整值，典型的比如年龄、数量等。
float	需要进行聚合运算（例如求和、均值）或者按区间分组的小数值，典型的比如价格、时长等。
string	文本类型属性值类型，支持包含、不包含、等于等计算规则。 各类 ID （例如商品 ID）建议作为字符串类型存储。
list	需在一个字段存储多个值。 例如支付订单时的“优惠券ID”这个字段，由于用户可在一笔订单内享受多个优惠，因此需以列表形式存储所有优惠券的 ID。 例如一个商品有多种分类，【‘分类1’，‘分类2’，‘分类3’】需用列表形式存储。 **list类型存储后，可按单个属性值进行查询，例如选择带折扣标签的商品有多少。
datetime	支持日期时间格式的 string， "2020-06-19 17:51:21"

属性值含义或示例

属性类型	示例
可枚举属性	性别：男、女
不可枚举属性，可举例说明属性	商品品牌：A品牌、B品牌……

设计元素

• 什么时候：时机
• 上服什么信息：属性

时机就是事件场景，因什么而发生，发生了什么，由谁来触发。触发者可以是用户、系统、运营人员，本质还是系统，系统是事件发生的代理者。一个时机应该包含以上的隐含信息。

常见的时机有：

• 点击
• 浏览（访问）
• 曝光
• 播放
• 结果

事件往往站在结果的角度，对业务的影响，更加业务化。这时，事件不会过于关注埋点的触发场景，更多的聚焦在业务结果上。因此，事件往往有很多的时机，多种时机会产生一个事件。

常见的事件有：

• 关注
• 购买
• 收藏
• 下载
• 播放
• 曝光

上报信息

• 公共信息：一般为用户的全局信息，包含设备、网络、个人、页面、位置模块、时间等与业务无关的通用信息
• 业务公共信息：一般为主数据信息，商品、内容、订单等与业务内容相关的信息，一般为企业多个业务共用的信息
• 自定义信息：业务内容的信息
• 扩展信息：特殊场景下上报的信息

例如:

埋点信息：

• SDK版本
• 事件产生的时间
• 服务端接收的时间
• 本次启动的时间
• Sessionid

用户信息：

• 账号ID
• 用户昵称
• idfa/imei md5加密值
• 设备id
• 是否首日访问
• 国家
• 城市
• 省份
• 县区
• 会员等级

设备信息：

• 操作系统
• 操作系统版本
• 手机型号
• 设备制造商
• 设备型号
• 屏幕高度
• 屏幕宽度
• 经度
• 纬度
• 深色模式
• 是否 WiFi
• 网络类型
• 运营商名称
• IP
• UA信息

应用信息：

• 是否是灰度版本
• 当前渠道
• 应用内部版本号
• AB测试标识
• 实验ID
• 包名
• 是否青少年模式
• 夜间模式
• 位置是否授权
• 提醒是否开启
• 安装渠道

界面信息：

• 当前页面
• 当前URL
• URL参数
• 当前URI
• 上一页
• 页面标题
• 形式(原生/H5)

界面层级：

• 一级
• 二级
• 三级
• 四级

模块信息：

• 模块名称
• 父模块名称
• 模块位置顺序

内容：

• 内容类型
• 内容名称
• 内容 ID
• 父内容 ID

事件的触发时机

        说明每一个事件应在何时触发，如一个事件在多个时机均有可能会被触发，则需要整理出所有的触发时机。例如：“点击开始注册事件”的触发时机应为点击注册时，但注册通常有多个不同的入口，因此，业务人员需要明确地枚举出哪些注册入口是需要研发人员进行埋点的，如果有属性值的区分也要标注，避免遗漏。

事件	属性	属性值	触发时机
点击开始注册	注册入口	首页右上 登录页去注册 首页下方	首页右上角点击注册时触发，注册入口属性值传【首页右上】 登录页点击去注册时触发，注册入口属性值传【登录页去注册】 首页下方点击去看看时触发，注册入口属性值传【首页下方】

用户表设计要素

        ​​​​用户表，顾名思义是记录用户信息、用户属性的表，通过用户的唯一标识（user_id）能够将事件表和用户表两张表进行关联。事件与用户实现关联，事件表里一条条的数据记录，就不会再是孤立的统计数字，而是能够与具体的用户产生关联进行分析，或者用行为来圈定用户，给用户设定分群和标签。 

        某日商品详情页的总浏览数据是上升的，但是总GMV没有明显提高，从事件侧分析，发现某类合作主推的单商品详页浏览数据上升，其他品类商详页没有明确上升；从用户侧分析，该类单品新增流量主要来自于渠道A。

        从此得出的初步判断是：

1. 对渠道A的用户拉新效果明显；
2. 但是该类用户被吸引来了，但是目标群体却没有下单，很奇怪，需要确认投放落地页与站内商品信息是否一致，尤其是价格、库存等信息；
3. 该类用户对平台其他商品的兴趣不高。     

1. 确立观察指标

2. 抽象过程行为

3. 补充事件属性

4. 设计事件要素

5. 补充用户属性  

确认是否需要导入后台业务数据库、标签等数据

数据指标地图

        数据能力推广的第一个难点，是让平台上有哪些数据让大家知道。一个是在各平台埋设的指标，比如采用excel的方式进行管理，问题是指标一多起来，找起来不太方便，对于定义者来说自然很容易找到，但是对于使用者来说则不太友好。即使搜中文名称，也会存在同一个地方，大家用不同的关键词去搜索，比如：模块、版块、板块。

        因此在数据指标表的第一个sheet，设计了一个数据指标地图，将不同功能模块的数据指标进行了拆解和说明，运营同学找数据指标之前，先打开指标地图大概定位，然后再去对应的sheet表中寻找对应指标的细节定义和可下钻的维度信息。

        另一块就是数据仓库的各种表的定义。从数仓里自助取数时，会有以下的问题：有哪些表、表格对应的是哪块业务的数据、有哪些字段，字段的含义是什么？这个需要和数据同学一起来明确具体内容了，这个工作并不复杂，就是需要开个小会进行确认，并且约定好，新增表格时，及时更新对表格的解释。

版本迭代功能埋点管理

随着版本迭代有新功能的埋点，或者针对之前功能的优化，所以需要对之前埋点进行调整。从埋点管理的角度，新增/修改的埋点，需要整合到之前的埋点系统里，这样能够方便使用者查阅整体的埋点明细。

背景：产品迭代周期为两周一个版本，有3位功能产品经理，他们负责具体功能的设计和产品跟进，在设计产品功能时，也会提交与功能相关的埋点需求，在经过功能评审后，会和数据产品就功能埋点进行一次沟通，然后将确定的埋点需求梳理出来。

处理流程：功能在经过需求评审（=技术评审）后，基本确定了这一次要做的功能点，因此也可以梳理出要做的埋点有哪些。所以从这个节点的处理流程是：

1. 功能产品经理（后称功能PM）梳理相应的埋点清单（按照符合总表设计逻辑的字段进行梳理）；
2. 功能PM与数据产品经理（后称数据PM）做内部评审，评审目标是针对功能点梳理出与总埋点文档保持兼容、同时又可以拎出来后给到开发看的埋点清单；
3. 功能PM与开发进行埋点需求评审，数据PM可旁听。

埋点应用

可视化数据大屏

        数据大屏的视觉冲击力强，对于关注整体指标的领导层来说，大屏解决了他们快速掌握全局数据的需求，另外，如果常要接待其他单位或者到外面汇报、参展，动态数据大屏绝对是曝光度最高的产品。

开源数据展示工具 

        数据大屏满足了展示类需求，但是定制化一点的、操作类需求，数据大屏满足不了。这时可以考虑使用别的工具，其核心就是通过该工具平台，连接数据库，读取数据后进行展现，并且可以按照一定的维度，如日期、周期、item名称等维度聚合数据，形成一个个看板。看板里的单图支持源数据下载、和简单的SQL取数。能够解决略进一层的数据展示和分析诉求。

数据应用平台

        数据终究要产生业务价值的，上面提到的数据展示工具，又无法以可视化形态做业务分析。因为数据需要结合具体的业务场景，然后选择成熟的分析场景，例如：事件分析、漏斗分析、留存分析、归因分析等，以及更深度的用户画像、精准营销，才能真正赋能业务。这类数据应用工具，目前已经有成熟厂商提供了标准化产品，如果公司规模没有达到自研数据平台时，建议采购。

数据仓库

数据采集、录入，最终会落入到数据仓库中进行存储和后续使用，成为数据仓库中的“弹药”。在2019年热门兴起的“数据中台”，去掉面子，里子其实就是一个数据仓库。数据仓库汇聚各业务端的原始数据，和主题数据，其建设过程是一个随着业务发展不断更新的过程。只是做数据的ETL本身并不是数据仓库的价值，其核心是能够收录好业务侧需要使用的数据，或者在业务侧提出新的数据需求时，能够快速响应。

按照数据仓库设计的经典三层结构：ODS层、DWD层、DM层，数据产品经理在数据仓库建设中的工作职责，是：

1. 约定进入ODS层的原始数据的维度、周期；
2. 定义DWD层主题宽表的字段、周期；
3. 设计DM层应用表的字段、周期（需要结合具体业务，设计尽可能通用的主题表、应用表）；
4. 设计监控方案，ETL过程中异常需告警，并及时告知数据应用侧有污染数据。

建立标准化流程

一般无特殊情况开发可参考下图：

某些特殊情况

相似场景是合并一个事件还是分不同的事件

示例如下：

事件设计	场景示例	说明
设计为同一事件	例如相似场景下的按钮点击可合并，不必一个点击一个事件，需合并为一个事件。	对于全局性的事件，我们建议设计为同一事件，通过特定的属性值对特定操作进行区分，而不是针对每一个操作设计一个事件。
设计为同一事件	例如：点击banner、点击热门活动位，都是点击首页的推荐位，可通过增加属性区分。	各事件所需属性相差不大，平时分析场景多整体分析。
设计为不同事件	例如一个内容平台，有视频，有文章，因视频和文章所记录属性差异较大，浏览内容详情应区分为浏览视频详情和浏览文章详情	各事件所需属性相差很大，分析场景多分别分析。
设计为不同事件	例如：收藏、浏览详情，虽属性差异不大，但是收藏和浏览业务关系不大，且通常为单独分析。	各事件所需属性相差不大，但平时分析场景单一分析，并且业务含义区别较大。

多重身份用户的设计

例如，在在线教育用户中，有多重用户身份，例如老师、学生、家长等，要做好用户属性的区分，对不同身份用户的属性进行不同的设置。

主被动事件的处理

        在线上行为中，很多需要记录的埋点事件非用户主动触发，为被动触发，例如平台审核、发放优惠券、被其他人关注等，所以这种场景下不存在主动事件，主动触发行为的不是用户，用户是行为的接受者，被动受到影响。但是在分析需求比如审核通过率，需要提交审核-审核通过的主体ID为一人，此时被动事件的上报主体会影响到分析结果。

曝光事件的处理

和其他事件一样，只是曝光事件的触发时机需要注意，例如某平台内容曝光事件触发时机为：

1. 内容露出全部，且feed流静止状态超过2s算曝光。
2. 限制单一内容一次请求只会出现一次曝光（比如上下滑动屏幕，只要不刷新发生新请求，算一次曝光）。

注意 以上仅为示例，具体的规则可根据需求和研发的实现成本灵活变动。另外，需要注意的是，曝光触发事件量巨大，一般分析CTR，或者有推荐算法数据需求时需要曝光事件，其他场景请根据需求谨慎埋点。

虚拟事件

        虚拟事件是对元事件的合并和拆分，是一个特殊功能。所以在事件埋点设计时，如果虚拟事件可满足，不必增加新埋点

社交数据采集方案示例

示例来源于火山引擎-增长平台

用户表

属性显示名	属性英文变量名	数据类型	属性值说明或示例
国家	user_country	string	中国，美国
省份	user_province	string	江苏省，New York
用户注册时间	register_time	int	用户注册时间
用户最近一次登陆时间	last_login_in_time	int	用户最近一次登陆时间
性别	gender	string	男性/女性
年龄	user_age	int	-
年龄段	user_age_interval	string	年龄段：18岁以下、18-25岁、25-30岁、30-40岁、40-50岁、50-60岁、60-70岁、70岁以上
会员类型	vip_type	string	VIP、SVIP、黑钻用户
财富等级	wealth_level	string	LV1、LV2、LV3等
星座	star_name	string	12星座名称：白羊座、水瓶座、摩羯座等
学校	school	string	***大学
职业	job_type	string	职业名称：销售、教师、律师、编辑、创始人、分析师等
行业	job_industry	string	职业领域：零售、教育、金融、影视、文化、互联网等
是否被认证真实头像	if_real	string	认证/未认证

公共属性

预置属性	属性类型	展示名
app_version	string	软件版本
device_model	string	设备型号
brand	string	手机品牌
os_version	string	系统版本
network_type	string	网络类型
network_carrier	string	运营商
app_channel	string	渠道
user_is_new	int	新老用户
resolution	string	分辨率
language	string	系统语言
app_id	int	app_ID
region	string	系统国家
app_region	string	软件国家
loc_city_id	string	城市
loc_province_id	string	省份
loc_country_id	string	国家
app_version_minor	string	四位版本号

部分自定义事件

序号	事件名称	事件标识符	埋点触发时机	前端 / 后端	属性名称	属性标识符	属性类型	属性含义
1	页面浏览	page_view	用户浏览页面时触发	前端	页面类型	page_type	string	注册/登陆页面、配对页面、用户详细信息页面、聊天列表页面、社区页面、会员套餐详细页、直播页面、充值页面
					来源页面	page_source	string	页面的上一级页面
2	导航栏点击	navigation_view	用户点击下方导航栏任一按钮时触发	前端	导航栏名称	nav_name	string	首页、直播、消息、发现、我的页面
3	点击注册按钮	register_success_click	用户点击注册按钮时触发	前端	注册方式	register_type	string	手机号注册,微信注册,QQ注册,其他注册
4	注册成功	register_success	用户注册成功时触发	前端	注册方式	register_type	string	手机号注册,微信注册,QQ注册,其他注册
5	注册失败	register_fail	用户注册失败时触发	前端	失败原因	fail_reason	string	网络原因,用户名已存在,密码格式不正确,其他原因
					注册方式	register_type	string	手机号注册,微信注册,QQ注册,其他注册
6	点击喜欢	like_click	用户点击喜欢时触发	前端	是否是会员	if_vip	string	会员/非会员
					是否有共同兴趣	if_interests	string	有/没有
					是否被认证真实头像	if_real	string	认证/未认证
					星座	star_name	string	12星座名称：白羊座、水瓶座、摩羯座等
					性别	like_sex	string	性别
					年龄	like_age	int	年龄
					年龄段	like_age_interval	string	年龄段：18岁以下、18-25岁、25-30岁、30-40岁、40-50岁、50-60岁、60-70岁、70岁以上
					职业	job_type	string	职业名称

预置事件

预置事件	事件标识符	属性名称	属性标识符	属性类型
应用启动	app_launch	$预置属性
		session时长	session_duration	int
应用退出	app_terminate	$预置属性
		session时长	session_duration	int
全埋点页面访问	bav2b_page	$预置属性
全埋点元素点击	bav2b_click	$预置属性

---

数据分析

数据分析种类繁多、样式复杂，下文介绍仅为冰山一角。

        数据分析是指对收集的业务数据进行整理、处理和分析，以获得有关用户行为、业务指标和趋势的洞察和理解。数据分析可以帮助回答各种问题，如用户使用模式、转化率、流失率、用户细分、产品功能效果等。

        用户数据收集是指通过各种方式和渠道收集和记录关于用户的信息。这些信息可以包括个人身份信息、行为数据、偏好、兴趣、交易记录等。用户数据收集对于许多组织和企业来说是重要的，因为它可以提供有关用户行为和需求的洞察，用于改进产品和服务、优化营销策略、个性化用户体验等。

        数据分析可以帮助发现隐藏在数据中的趋势、模式和洞察，为业务提供有力的支持和指导。它可以用于预测未来趋势、优化业务流程、改进产品和服务、优化市场策略等。有效的数据分析可以提供有价值的见解，促使创新和业务增长。

数据分析的作用

描述性分析

        故名思义，主要是对已经发生的事实用数据做出准确的描述。比如某企业订单履约率从上月的98%下降到了95%，属于偏基础类的工作；

诊断性分析

        在知道了发生什么之后，更重要的是，我们要明白为什么发生。比如经过分析，发现订单履约率下降的原因是成品生产不出来，无法完成交付；

预测性分析

        基于上述两个层次的分析，我们发现了其中的规律，即原材料供应商的送货及时率会影响成品订单的履约率。假如上月某原材料供应商A送货及时率只有70%，通过建模，我们可以预测本月该供应商会使我们的订单履约率下降2%；

处方性分析

        有了预测性分析的结果后，我们无需再做事后诸葛亮，而可以运筹帷幄，在事前就采取措施。上例中，供应商A会导致本月我们的订单履约率下降，我们可能采取的措施就是把A换掉，但是现在有B和C两个供应商供我们选择，该选择哪个呢？通过分析和计算得出：选用供应商B会比选C的订单履约率高1%，因此建议选择供应商B。

数据分析方法

事件分析

事件分析是对用户触发的行为事件进行多角度分析。

按照小学时代的日记写作方法理解，叙述一件事情重要的元素是时间、地点、人物、做了什么、怎么做的、为什么做、做了多少，也就等同于5W2H模型。

一个用户行为事件=时间when+地点where+人物who（单个用户、用户群）+行为what（动作+动作对象）+工具how（设备、操作系统、语言等）+指标how much（统计事件的计量方式）。

        由于用户的行为是动态的，所以在前端事件分析的结果会展示过去、实时现在、趋势未来。例如实时在线人数、实时交易额等；用曲线图展示事件的发展的趋势，以预测未来的变化方向；也能够统计事件总体情况。经过细化的分层，又能够对用户进行精细化的分组，以便于精准的用户运营。

        经过对事件分析的总结，事件分析是所有分析方法的前提，捋清楚了事件分析的思路和各维度参数的含义，才能进一步的去了解其他的分析方法，特别是对用户行为和用户属性的理解，如何能够全量地进行分类和局部关键行为的概括。

分布分析

分布分析主要分析两种情况：

1. 洞察用户行为分布规律；
2. 观察不同维度（渠道、地区等）用户分布情况。

说到底分布分析就是事件分析中分层和分组的过程，是一种非连续性变量的统计分析方法，其目的就是为了进行层间和组间对比分析，以找到产品优化方向、甄别核心用户群、实时调整运营策略。

留存分析

一种用来分析用户参与情况/活跃程度的分析模型，考察进行初始行为的用户中，有多少人会进行后续行为，衡量产品对用户价值高低的重要方法。

        留存分析较其他的分析方法，更侧重于分析产品对用户的意义，只有用户觉得产品帮助自己解决了某些问题、满足了自己的需求、或者功能用起来更便捷的时候才会延用下去，否则用户一定吝啬自己的时间和手机内存的。这也是验证用户需求分析是否到位，产品设计是否合理的关键指标。

漏斗分析

漏斗分析是对多个行为进行分析，并且这些行为不仅有先后次序的，而且是一个完整的复杂事件，对漏斗的每个行为我们都很关心

漏斗分析是需要先预设好漏斗步骤和窗口期，总的来说是设计好的转化漏斗和转化周期，一般情况是对核心事件的转化行为的一个衡量方法。

        漏斗分析没有强顺序，中间可以重复步骤内的行为，也可以穿插步骤外的行为，只要在窗口期内完成漏斗步骤内的行为即可。例如：窗口期为1天，漏斗步骤为“A->B->C->D->E”，在用户触发A->B ，又回到A，再回到B或F，那么只会记录A->B一次，而F行为不在漏斗步骤内，则不参与统计。

漏斗分析是衡量流量转化、页面转化的高频数据分析方法。

从产品的角度来说：

• 核心转化行为的触达在预设的步骤中是否科学合理，是否能够让用户有效触发产品的核心功能。
• 产品的核心功能在用户使用时，是否达到简单快捷，从而提高转化效率？如果不是，那么卡在哪个环节，对该环节进行深入分析。
• 获得转化周期等等

从用户角度来说：

• 在每个漏斗步骤上，既有进入下一个步骤的用户，也有在这个步骤上流失的用户，从而对用户进行更细致的分群，也获得了忠实用户群和潜在用户群，对于精细化的用户运营提供了数据支撑。

路径分析

路径分析顾名思义就是用户在产品上进行操作的过程，有些地方会用“用户旅程”、“用户动线”词汇来形容用户路径。这好比是一种数字化方式来跟踪和监控用户的所有行为，从而可以得到频繁访问路径。和漏斗分析一样，目标还是为了提升关键模块的转化率。因此，路径分析需要得出最短路径、优化最低转化环节、跟踪主流路径。

路径分析主要分为三类：转化漏斗、智能路径、用户路径。

小结

       每种分析是对立而又统一的，看似目的不同，但是又是相互补充，使得产品的成长获得全面的营养素。用户网络行为数据越来越庞大，充分挖掘数据的价值是数据分析的目的，不论使用的一般的统计方法，还是机器学习等模型算法，都是为了 理解数据

数据分析切入点

        产品数据分析从以下几方面入手：1、功能交互数据分析，2、竞品调研，3、UGC数据，4、KPI数据。其中“功能交互数据”是比较细节的数据分析，能直接反应功能的好坏以及交互流程是否如预期。好坏和预期的标准都是依据自己设计这个功能的目标。

功能交互数据分析

功能交互数据是比较细节的数据分析，能直接反应功能的好坏以及交互流程是否如预期。好坏和预期的标准都是依据自己设计这个功能的目标。

比如交互流程优化，目的是想通过交互流程的优化提升点击率。所以在此目标下，需要看现有的流程每一步的转化情况，那么每一步的统计参数都要加。

分析方法：转化漏斗

        功能交互类的分析效果好坏，主要用的就是转化漏斗。栗子依然是分享，可看哪步流失多，也可看是否减少步骤。比如很多网站或APP由原来的统一分享按钮变为分享渠道直接暴露，减少步骤一定是可以提升转化率的，因为每一个步骤都会有流失。

竞品调研

竞品的数据情况获取主要是以下几种方式：搜集资料、可通过技术手段获取、估算。

KPI数据

KPI数据很重要很重要很重要，因为这是你一季度、半年、一年的奋斗目标，所有的工作计划都围绕着KPI进行。有条件的话可以让技术同学将重点KPI数据做成日报，每天早上发你邮箱。

• 数据日报

        数据日报是将你想要看的各种数据汇集在一起，方便提升产品工作效率的一种方式。除了各类数据项的当天数据，还需要增加对比前一天、前一周、前一月等增加下降的比例，这样才能有效分析。

• 流量（PV、UV、留存率）

        大多数产品应该都是这两项，PV和日活跃用户数，APP应该还会有留存数据。这是最能直接反应网站或APP的情况，也是全年提升的目标。APP的UV就是日活跃设备数，网站的则是cookie。

• PV、UV

        外部来源渠道，通过拆解来源渠道分析哪种上升哪种下降、哪种还可以提升拓展；留存率更多的是与push推送相关，好的push可以大大提升留存率

• 广告收入

        时刻关注变现，有了钱钱才更有话语权。主要关注项：收入钱钱、各广告位CTR、RPM、广告物料返回率。CTR高能证明广告位置以及广告相关性较好；RPM，可用来估算广告的价值以及我们接入后的收益；广告物料返回率，只有返回了物料我们的接入才有效。

数据报告流程

挑几个点介绍一下

数据清洗

在工作中，90%以上的情况，你拿到的数据都需要先做清洗工作，排除异常值、空白值、无效值、重复值等等。这项工作经常会占到整个数据分析过程将近一半的时间。
如果在上一步中，你的数据是通过手工复制/下载获取的，那么通常会比较干净，不需要做太多清洗工作。但如果数据是通过爬虫等方式得来，那么你需要进行清洗，提取核心内容，去掉网页代码、标点符号等无用内容。
无论你采用哪一种方式获取数据，请记住，数据清洗永远是你必须要做的一项工作。

数据整理

清洗过后，需要进行数据整理，即将数据整理为能够进行下一步分析的格式，对于初学者，用Excel来完成这一工作就OK。
如果你的数据已经是表格形式，那么计算一些二级指标就好，比如用今年销量和去年销量算出同比增长率。鉴于你是第一次做数据报告，建议你不要计算太多复杂的二级指标，基本的同比、环比、占比分布这些就OK。
如果你收集的是一些非数字的数据，比如对商家的点评，那么你进行下一步统计之前，需要通过“关键词-标签”方式，将句子转化为标签，再对标签进行统计。

描述分析

描述分析是最基本的分析统计方法，在实际工作中也是应用最广的分析方法。描述统计分为两大部分：数据描述和指标统计。

数据描述：用来对数据进行基本情况的刻画，包括：数据总数、时间跨度、时间粒度、空间范围、空间粒度、数据来源等。如果是建模，那么还要看数据的极值、分布、离散度等内容。这次我们是零基础做数据报告，那么就不用考虑后一类数据了。
指标统计：用来作报告，分析实际情况的数据指标，可粗略分为四大类：变化、分布、对比、预测；
变化：指标随时间的变动，表现为增幅（同比、环比等）；
分布：指标在不同层次上的表现，包括地域分布（省、市、区县、店/网点）、用户群分布（年龄、性别、职业等）、产品分布（如动感地带和全球通）等；
对比：包括内部对比和外部对比，内部对比包括团队对比、产品线对比；外部对比主要是与市场环境和竞争者对比；这一部分和分布有重叠的地方，但分布更多用于找出好或坏的地方，而对比更偏重于找到好或坏的原因；
预测：根据现有情况，估计下个分析时段的指标值。

数据敏感性

        数据敏感度是业务理解力、客户理解力、数据理解力三者的综合结果。很多人误以为数据敏感度只是数据能力强。事实上，要对数据敏感，业务理解力、客户理解力、数据理解力，三者缺一不可。因为数据只是对商业行为的客观描述，只有真正懂数据背后的意义，才能解读数据，才能挖掘数据背后的含义，才能形成数据敏感。

1）看到数据后，能一眼判断数据靠不靠谱，因为很多数据本身不靠谱，有指标口径问题、有数据质量问题，也有可能搞数据的人真的不理解业务，放了个风马牛不相及的数据。

2）看到数据后，能马上思考数据本身的商业意义，有人能快速定位数据背后的原因，并找到机会，有人眼里只是一个数字。对数据的解读基于对数据的理解，对数据的理解则基于对业务、客户、数据的理解。

合法化

最后最后，切记！用户数据的收集和使用应该始终遵循以下几个原则

1. 合法性和透明度：用户数据的收集应遵循适用的法律法规，包括隐私保护法和数据保护法。组织应该明确告知用户哪些数据被收集，收集目的是什么，并在隐私政策或其他适当方式中提供相关信息。

2. 最小化原则：仅收集与所需目的相关的最少数据。不应该收集不必要或无关的用户数据。

3. 安全保护：采取适当的安全措施来保护用户数据的机密性和完整性，防止未经授权的访问、泄露或滥用。

4. 用户选择和控制：用户应该有权选择是否提供他们的数据，并可以随时访问、更正或删除他们的个人数据。组织应该提供简单和透明的方式让用户行使他们的权利。

5. 数据用途限制：用户数据只能用于事先明确指定的目的，并且不得超出合理的范围。数据不应该用于与原始收集目的不相关的用途，除非获得用户明确的同意。

6. 数据共享与转让：用户数据不应未经明确的同意而与第三方共享或转让，除非受法律要求或有合法依据。

---------------------------

2023.06.06