一.基础
软件的数据采集
历史，业务数据：数据库DB，日志LOG
用户行为数据：数据埋点
1.定义
埋点是数据采集的重要方式，通过在页面上植入代码，监控用户行为（如页面加载，按钮点击等）用户一旦触发了该事件，就会根据埋点信息将相关数据上传到数据服务器
是数据采集领域（尤其是用户行为数据采集领域）的术语，指的是针对特定用户行为或事件进行捕获，处理和发送的相关技术及其实施过程。比如用户某个icon点击次数，观看某个视频的时长等
埋点的技术实质是先监听软件应用运行过程中的事件，当需要关注的事件发生时进行判断和捕获
特别注意需要明确事件发生时间点，判别条件，这里如果遇到不清楚时，需要和开发沟通清楚，避免采集数据与理想存在差异。比如进入某个页面，点击某个按钮等，会自动触发记录和存储，然后这些数据会被收集并被传输到终端提供商，或者是通过后端采集用户使用服务过程中的请求数据
比如：APP可以简单分为四个层级，表层是UI层，底层是数据表和日志
数据埋点的发生场景便是在表层UI层里，其作用是监控用户在UI层产生的行为，也就是用户对界面的操作
数据埋点无法统计有多少用户发布了朋友圈，但可以统计有多少用户点击了朋友圈的发布按钮，以及有多少用户在朋友圈发布页点击了确认发布的按钮
埋点方式总结
埋点需求设计的整体框架
2.什么是点？
点具有以下特征：
点规定了程序在特定触发条件下进行记录的一种策略
以excel为例，第一行的标题栏就是点，标题栏规定这个excel中记录哪些数据
用户在APP，网页中产生各种行为，程序会根据点的规定，将用户的行为进行记录
事件模型 = 点
3.如何描述一个点？
一个点的描述可以和常用的5W2H模型进行匹配
5W2H是对一个点描述的思考，根据情况和实际需求，可以适当增加和减少描述的维度
比如：不需要知道是具体哪个用户发出的事件，则可以不要who这个维度后面的数据，或者用户都是在产品内部闭环，不需要知道用户来源，则why也可以不用
注意：
一般情况下对每个事件的描述应尽量丰富，如果数据不提前记录，日后回溯则无法补全
5W2H模型并不需要和后面的描述进行生搬硬套，只是一种思考维度，熟悉后完全可以按照自己的思路来
how这一条中，用户具体的动作则进行了着重标记，意味着基本这是整个事件的核心骨干，一般不可缺少
点：事件模型，用中文描述清楚需要记录一个什么样类型的事件
即：需要对从抖音广告中跳转到京东商城里商品的用户进行数据统计
目的：可以是看抖音这条渠道的带新用户能力，也可以是这个商品曝光后的转化能力等
4.目的与位置
页面统计
统计哪些页面访问热度高，停留时间长
可通过对页面URL（原生则需要指定页面）进行埋点，记录用户访问次数及时间
行为分析
统计用户对页面上不同功能的操作行为
根据对应功能位置进行埋点，记录用户点击，选择行为，往往需要记录行为要素
5.分类
可以分成两类：页面统计和行为统计
页面统计可以让产品经理知道某个页面被多少人访问了多少次
其本质是监控页面加载的行为，尽管此时用户并没有对UI产生行为，但却是由上一个点击行为触发的一个结果
除了访问的人数和次数，也可以监控到用户在某个页面停留的时长，部分产品希望用户在某个页面停留的时间越长越好
比如：信息流产品，这表示用户正在持续的进行阅读，停留的时间越长，表示内容对用户的吸引力越高这样才能产生持续的阅读行为
比如：微博，朋友圈等以短信息为主要内容的信息流，长信息会更加侧重跳转详情页的数值
行为统计是指用户在界面上的操作行为，应用最广泛的便是按钮的点击次数
多个入口：一些基础的功能，往往被多个页面应用，也能通过两个以上的页面进入
此时可以借助指定入口页的访问人数，入口按钮的点击人数，来判断该页面的转化率
6.为什么需要埋点？
数据生产 → 数据采集 → 数据处理 → 数据分析挖掘 → 数据驱动/用户反馈 → 产品优化/迭代
上述是整个数据从产生到最终作用于产品优化上的过程
埋点是整个流程的开始点，终端提供商在收集到埋点数据之后，通过大数据处理，数据统计，数据分析，数据挖掘等加工处理，可以得到衡量产品状态的一些基本指标，比如活跃，留存，新增等大盘数据，从而洞察产品的状态，随着数据挖掘等技术的兴起，埋点采集到的数据在以下方面的作用也越来越凸显
7.作用
用户
用户的来源有哪些
不同用户的访问操作习惯有什么不同
页面
哪些页面用户点击率高
什么样的页面排版能提高点击率
动作
哪些功能的留存高
用户使用功能时的操作习惯是什么
一句话概括：通过植入代码的形式监测用户在页面的具体行为，将统计到的数据作为产品优化的依据
8.流程
9.第三方埋点模式
常见的第三方埋点平台：百度统计，友盟，GrowingIO，神策数据，诸葛，TalkingData
代码埋点
由开发人员在触发事件的具体方法里，植入多行代码把需要上传的参数上报至服务端；优点是精准定义功能事件；缺点是工作量大，必须进行项目迭代开发，更新影响大
可视化埋点（也称为半自动埋点）
是指开发人员除集成采集SDK外，不需要额外去写埋点代码，而是由业务人员通过访问分析平台的圈选功能来圈出需要对用户行为进行捕捉的控件，并给出事件命名；优点是业务接入，无需开发支持；缺点是仅支持前端界面行为分析（如点击次数）
无埋点（全埋点）也称为全自动埋点
是指开发人员集成采集SDK后，SDK便直接开始捕捉和监测用户在应用里的所有行为，并全部上报，不需要开发人员添加额外代码；或者是说用户展现界面元素时，通过控件绑定触发事件，事件被触发的时候系统会有相应的接口让开发者处理这些行为。优点是不会出现漏埋，误埋等现象，开发工作量少，先上报数据，后进行埋点；缺点是缺乏数据获取的灵活性，数据传输压力大
通常埋点文档会采用代码埋点，客户端埋点。即：程序员根据产品经理的埋点文档，对用户在网站或APP中的目标行为进行数据上报
因为服务器并不会直接捕捉到用户在端上的行为
服务器上一般已经有研发开发时所留下的日志系统，再额外的加埋点处理，可能会降低服务器性能
10.数据
通过数据埋点捕捉到的数据有三层
第一层是基础层，比较通用的数据，像日活，新增
第二层是页面访问
第三层是行为统计，名词上来讲通常被称为时间统计
通过对捕捉界面响应事件，能够得知某个按钮点击数及对应点击率
11.APP数据埋点的相关注意事项
注册一家统计网站
建议用公司邮箱或者公用邮箱注册，不要用自己的私人邮箱和手机号码，后续一旦有交接和工作变动会比较麻烦
新建应用
登录后一般都有“新建应用”，可以选标准统计大部分APP都选该统计
名称写自己APP的名称，分类自己选一个，选错了也不影响
平台根据情况自己选，后期看数据和埋点都是iOS和安卓分开，所以如果两个端都做，就一起都选上
描述可以选填，可以不用填
点击按钮“创建应用”，完成
获取KEY和SDK代码包
完成后可以得到2个APP key，分别是iOS和安卓
APP key很重要，可以下载了给研发，也可以稍后让研发自己登录进来自己下载
iOS和安卓是分开独立的，后续埋点和看数据都是分开的
重点：如果只想看APP和活跃用户，留存用户，下载量，用户地域分布，渠道分布，此步骤已经可以
将埋点需求和SDK包发给研发
这时候就把刚才获得的APP key和SDK包的下载地址，发给研发。或者直接把账号和密码发给研发，然后告诉研发，集成下百度移动统计的SDK包。这样发版后，就可以看到大部分数据
初步数据埋点的前期工作可以就此完成
自定义埋点需求完善
背景：实际工作中往往对数据的需求远远不局限以上基础数据，还需要看每个页面的转化率，页面里面的行为按钮的点击次数，弹层的展示次数等更细节的数据。这样才能更好地知道用户行为和操作流程，以便后期改进优化，这就需要进行自定义事件完善。不做这步，这些数据看不到
案例：比如后台想看页面里面注册搜索按钮，顶部banner，底部首页和我的两个导航条的点击量
一个埋点事件对应一个按钮或者一个页面或者一个弹层，产品经理来定义
如果埋点比较多，也可以批量添加，批量添加时需要下载excel模板，按照要求填写好，上传进来即可
添加完成后就可以把这个列表导出或者人工复制出来一个表格，发给研发，并附上产品原型图，做好对应关系标注
研发开发并完成APP上线
完成上面几步后，研发就可以看懂并进入研发阶段
在后台查看数据
产品上线后就可以在后台网站看到统计数据，大部分数据一般隔天更新
12.埋点后能看到什么数据？
按照步骤完成数据分析SDK集成和自定义事件后，就可以在第三方网站看到相关统计数据
注意：不添加自定义事件，可以看到基础数据；添加后，可以看到更细节的按钮，页面等点击数据
比如：查看自定义事件埋点数据，还是进入刚才的“事件分析”页面，点击对应埋点即可看到数据，支持筛选时间段查看
其它功能：如果还想查看几个页面之间的转化路径和数据漏斗，那还需要添加转化分析
添加转化分析后，可以看到例如：进入首页 - 点击注册按钮 - 进入注册成功页 这几步的转化率和流失率。会自动生成一个转化分析图，也可以分别看这几个页面的数据，自己去分析汇总
进阶的方法还有把事件埋点配合转化分析，访问路径，转化漏斗等工具使用，从点到面地了解用户的使用行为，APP存在的问题
产品核心指标一般包含
产品规模
用户数据：如新增用户，用户类型分布，活跃用户，沉默用户，启动次数，版本分析等
业务数据：这个与具体业务有关，如问答社区的问题数，回答数，全网热度，浏览量；如对含交易平台的交易量，交易额，客单价，转化率，利润等
产品运营
流量数据：pv，uv，dau，mau，留存分析（次日留存，7日留存，用户新鲜度），流失分析（日周月，自然流失，回归流失）
渠道数据：渠道流量，渠道转化率，渠道评价，渠道时段详情，渠道质量（渠道活跃用户渠道流量）
二.场景
在整体业务流程基础上，建立一个完整的转化漏斗
首页 → 商品详情页 → 加入购物车 → 提交订单 → 支付 → 支付成功
基于转化漏斗的情况，找到最亟待优化的点
在转化漏斗的每个环节，查看事件的不同属性分布
商品详情页有不同的入口，用户都从哪些地方进入
基于事件的不同属性分布，占比低的地方，如无符合预期就需要优化，占比高的地方，就需要持续关注确保功能运行稳定
通过用户行为的埋点数据，了解前端功能的使用情况
商品详情页，查看讲解视频，滑动查看头图，查看评论，咨询客服
找到对用户转化影响最突出的地方，强化给到更多的用户
三.方法论
基于需求分析做出收益预估
定义论证收益需要关注什么指标
通过埋点获得生成这些指标的能力
通过数据系统结合埋点获得数据
基于数据结果，找到产品优化方向，迭代产品
一般情况下，主要有3类埋点：展现埋点 + 曝光埋点 + 交互埋点
展现埋点：定义展现其实是一个服务端的触发。服务端被触发后，用户侧将会展现什么内容，展现埋点需要记录的是页面展现的内容信息，即服务端下发的内容是什么（这些东西一定是当前页面主要内容，不包含一些交互信息）
曝光埋点：哪些下发的内容被用户实际看到了，和展现埋点类似，由于屏幕有限，但内容可以无限。哪些内容被用户侧实际看到（曝光），需要记录的是单个“内容”被看到。一系列被下发的内容，可以触发多次曝光埋点
交互埋点：交互埋点表明的是功能/内容被用户点击了。从埋点时机来说，这个是展现&曝光的下游。记录对于我们提供的服务的消费情况。比如，一个页面，用户可以点击，那么我们需要记录相应的交互动作埋点；比如一个视频可以点赞，我们也可以记录交互埋点；比如一个视频可以播放暂停，我们也可以记录消费埋点。总体来说，就是我们要记录被看到的可交互功能/信息的消费数据
四.案例
收益预估
选餐速度提升
下单率提升
单次购买金额提升
指标定义
选餐速度：从打开APP到订单支付成功
下单率：打开APP的用户中订单支付的人数
单次购买金额：订单均价
埋点获得
选餐速度：历史数据，打开APP会有接口请求，或者有APP启动的事件，原来有订单的数据或者有订单支付成功的事件；在订单支付成功的事件中，增加一个"距离打开APP时长"，"订单类型是否为盲盒"
下单率：历史数据，每日活跃用户，每日下单用户；APP启动的事件，订单支付成功，订单类型是否为盲盒，用户分群是否使用了盲盒功能
单次购买金额：历史数据订单表，原有的订单支付成功事件；在订单支付成功的事件中，增加"订单类型是否为盲盒"
如何获得数据
选餐速度：通过事件分析，查看订单支付成功这个事件中，按照平均时长查看，获得一段时间类的均值和历史进行对比，结合订单类型是否为盲盒订单对用户决策的影响
下单率：用户分群，找到那些使用过盲盒的用户；漏斗转化，区分用户分群
单次购买金额：事件分析，基于订单类型是否为盲盒查看不同订单类型的均价
本文参考链接：https://blog.csdn.net/happylls666/article/details/128697145
