前端埋点的缺点_数据埋点小白入门

本文主要介绍了数据埋点是什么、为什么要数据埋点、数据埋点的几种方式、触发埋点的几种事件，最后通过一个简单的埋点案例介绍了埋点数据的格式。

一、基础知识

1、数据埋点

1.1、概念

解读 1： 数据埋点是针对特定用户行为或事件进行捕获、处理和发送的相关技术，是一种常用的数据采集方法；采集的数据可以帮助业务人员分析网站或者 APP 的使用情况、用户行为习惯等，是后续建立用户画像、用户行为路径等数据产品的基础。

解读 2： 数据埋点是数据产品经理、数据运营以及数据分析师，基于业务需求、产品需求对用户行为的每一个事件对应的位置进行开发埋点，并通过 SDK 上报埋点的数据结果，记录数据汇总后进行分析，推动产品优化或指导运营。

解读 3：

• 初级数据埋点：在产品流程关键部位植相关统计代码，用来追踪每次用户的行为，统计关键流程的使用程度；
• 中级数据埋点：在产品中植入多段代码追踪用户连续行为，建立用户模型来具体化用户在使用产品中的操作行为；
• 高级数据埋点：与研发及数据分析师团队合作，通过数据埋点还原出用户画像及用户行为，建立数据分析后台，通过数据分析优化产品。

解读 4： 数据埋点是数据采集的一种重要方式，主要用来记录和收集终端用户的操作行为，其基本原理是在App/H5/PC等终端部署采集的SDK代码，当用户的行为满足某种条件的时候，比如进入某个页面、点击某个按钮等，会自动触发记录和存储，然后这些数据会被收集并被传输到终端提供商，或者是通过后端采集用户使用服务过程中的请求数据。

一个典型的埋点采集处理流程如下图所示：

数据埋点的表现是采集用户行为数据，目标是通过分析采集的数据来推动产品优化或指导运营。

1.2、价值

埋点主要目的是为了弥补应用系统（主要是网站或者app）在设计时的不足。任何一个系统在设计初始阶段只关心核心业务的功能，等到系统上线以后，数据分析师对用户行为分析时会发现缺少很多数据，此时需要采用埋点的方法进行采集需要的数据。

具体来说就是在系统代码里面添加一些额外的代码来采集需要的数据进行精细化数据分析。比如在电商行业，当用户点击“购物车“时，这是一次交互行为，也是系统的核心功能，但是忽略了用户信息、商品品类等其他维度的信息。我们需要采用埋点的方法嵌入额外的代码来辅助采集数据，进而实现深度的数据分析。

从本质上讲，埋点是为了对产品的持续追踪，通过深度数据分析不断优化产品。

比如用户点击率怎么样？用户在核心使用路径上是否顺畅？有没有得到用户的认可？有没有因为设计按钮过多导致用户行为无效？用户希望有什么样的功能更新？

这些问题都可以通过数据埋点的方法实现，因此埋点贯穿了产品的整个生命周期，为产品优化指明了方向。

2、埋点方式

埋点方式主要分为代码埋点、可视化埋点、无埋点（全埋点）、服务端埋点四种。

2.1、代码埋点

代码埋点主要由工程师手工在程序中写代码实现，通过触发某个动作后程序主动发送数据。

• 优点：具有很强的灵活性，可以控制发送的时机和发送方式等，有较高数据的准确性；
• 缺点：人力成本较高，需要工程师开发程序，有时候还要依赖发版来生效。

2.2、可视化埋点

界面化埋点管理配置无需开发人员介入，更便捷的埋点更新，生效快。

• 优点：技术门槛低，简单、方便，能够快速地埋点；
• 缺点：比较受限，上报的行为信息有限；重构或者页面变化时需要重新配置。

2.3、无埋点（全埋点）

它要求必须在页面上嵌入数据采集基础SDK，无需人工埋点，一切操作皆自动埋点，统计数据按需处理，这等于做了一个统一的埋点，因此又被称为全埋点。

• 优点：不需要开发，方便、快捷、省事；
• 缺点：传输数据量比较大；无法采集自定义属性，只适用通用的场景。

2.4、服务端埋点

数据埋点不仅有前端埋点，还有服务器后端埋点，它能够收集不在前端发生的行为，只要有网络请求就可以记录下来，它能够实时收集，不存在延时上报的问题，但是没有网络就很难收集到数据，这也是服务器后端埋点的一个弊端。

因此，很多公司都会结合客户端前端埋点和服务器后端埋点两种方式一起埋点，服务器后端数据实时性强、很准确，用户需要请求服务器的关键业务量最好均使用服务器后端埋点。

例如，要根据埋点数据统计中奖用户信息，显然服务器后端数据更合理，客户端前端数据可能会漏掉部分中奖用户，导致用户投诉；客户端前端数据很全，记录了用户绝大多数的操作行为，其他非关键业务量或者不需要请求服务器的行为可以使用客户端前端埋点。

2.5、几种埋点方案的对比

2.6、埋点方案的选择

正如同硬币有两面，任何单一的埋点方式都存在优点与缺点，企图通过简单粗暴的几行代码/一次部署、甚至牺牲用户体验的埋点方式，都不是企业所期望的。

要满足精细化、精准化的数据分析需求，可根据实际需要的分析场景，选择一种或多种组合的采集方式，毕竟采集全量数据不是目的，实现有效的数据分析，从数据中找到关键决策信息实现增长才是重中之重。

因此，数据采集只是数据分析的第一步，数据分析的目的是洞察用户行为，挖掘用户价值，进而促进业务增长，故最理想的埋点方案是根据根据不同的业务和场景以及行业特性和自身实际需求，将埋点通过优劣互补方式进行组合。

切记，采集只是手段而不是目的，不以提升业务价值的数据分析，采集“大而全、快而简”的埋点方式，都是耍流氓！

3、埋点事件

在记录埋点信息时，主要的埋点事件分为点击事件、曝光事件和页面停留三类。

3.1、点击事件

用户每点击页面上的一个按钮一下都会记录一次数据；如下图红框标注所示，点击一次记一次。

3.2、曝光事件

成功打开一次页面记一次，刷新页面一次记一次，加载下一页新页，加载一次记一次；home 键切换到后台再进入页面，曝光事件不记；如下图页面所示，打开一次记一次。

3.3、页面停留

页面停留主要用来记录用户在一个页面的停留时间，它可以通过记录用户进入页面的时间 t1 和离开页面的时间 t2 计算，计算公式可以简单地表示为:用户停留时间 = 离开页面时间t1 - 进入页面时间t2。

除了上述的埋点事件，还有其他的埋点事件，例如：页面加截完成事件、服务器响应返回成功事件、屏幕滚动事件等。

二、学习笔记

1、数据埋点的基本概念

我们习惯将数据归纳为两大类：

• 流量数据，以用户访问产品，记录用户浏览行为核心的埋点数据日志；
• 业务数据，以生产系统内存储的业务表单数据为核心的业务库数据记录。

简单来说，用户访问产品时候的交互动作触发的是埋点流量数据，用户访问产品看到的内容是业务数据。

用户“点击广告”是“动作”事件，能够生产一条埋点数据，用户看的广告内容是“商品”信息，商品信息是被存储的业务数据。

我们学习数据埋点知识，就是为了设计“记录”用户“动作”的方案，记录用户“动作”发生的场景，探索用户“动作”背后的意图。

2、数据埋点参数说明

埋点数据一般分以下三个部分：

• 配置信息：记录为了对数据进一步个性化分类整理的配置信息；
• 环境信息：记录用户的属性，用户的设备、环境、APP 数据；
• 事件信息：记录用户当前操作触发条件和用户访问或操作的具体内容。

2.1、商品曝光案例

如上图所示为一条具体的商品信息，下面是商品曝光触发的埋点日志：

{
    //Part1：配置信息
    "user_id":"123", //埋点负责人的账号id
    "business":"xx业务", //埋点数据的业务分类
    "label":"标签属性"，//对埋点数据进行分类，对每个分类打标签

    //Part2：环境信息
    "uid":"123", //用户唯一ID，只要访问就生成一个新的身份标示
    "user_id":"123", //用户的账户ID，仅登录用户可获取得到
    "name":"joker",//用户的账户名称，仅登录用户可获取得到
    "city_id":"2",//如果用户访问的页面有城市属性，这里可以获取页面的城市属性id
    "city_name":"上海",//如果用户访问的页面有城市属性，这里可以获取页面的城市属性值
    "locate_city_id":"1",//用户访问时候所定位的城市id
    "locate_city_name":"北京"，//用户访问时候所定位的城市属性值
    "wifi":"on",//用户访问时候wifi的开关状态
    "app_version":"10.9.2",//用户当前使用的app版本
    "os_version":"11.8.2", //用户当前手机系统的版本
    "os_souce":"android" //用户当前的手机系统（Android，iPhone，小程序、web…）

    //Part3：事件信息
    "evs":[{
        "id":"a1234"//坑位模块的全app唯一标示id
        "val_val":{   //以下所有数据为同时携带的想要获取的数据内容
            "user_id":"123", //访问用户的账号id；
            "content_id":"123234", //商品唯一id标示
            "title":"conklab连帽潮牌oversize情侣装",//商品标题；
            "price":"298",//商品价格；
            "business_id":"4",//商品分类属性id
            "business":"女装",//商品分类属性
            "strategy":"abc123",//不同策略的策略id，用于区分不同策略的数据效果
            "shop_id":"123",//商品所属的店铺id
            "mark":"双十一",//个性化的数据标签，比如双十一代表此商品正在参加双十一活动
            "position":"2",//商品在列表中展示排序的第几个位置
        }
    }]
}

2.2、商品曝光上报策略

商品曝光上报策略简单来说就是：当事件本身实际曝光显示在屏幕当中所触发的数据上报策略（露出像素>0px），需要注意下面的事项：

• 滑动：在页面内上下滑动时，不重复记录；
• 刷新：刷新当前页面时，重复记录曝光；
• 翻页：下拉到新一页后再返回到前一页，上下滑动不重复记录；
• 返回：事件点击到落地页后，从落地页返回（包括返回按钮返回、滑动返回、支付等行为后自动跳转返回），不重复记录录曝光；
• 唤醒：手机锁屏被打开，直接展示事件所在的页面，不重复记录曝光；应用或者浏览器在后台被唤醒，展示广告所在的页面，不重复记录曝光。

没有特殊限制定义，埋点需要根据坑位颗粒端逐条上报，不做去重处理。

2.3、URL传参埋点

假设我们有网址：https://www.xxxabc.com/about/1.html（运营促销活动），我们针对这个活动在某网站投放广告引流，最有效的数据埋点方法是对 URL 添加埋点参数如下：https://www.xxxabc.com/about/1.html?source=sina_joker_ad_about_01。

参数说明：

• ?：问号后面是我们的埋点参数，以问号分割的作用是不影响正常的访问链接；
• source：埋点字段的命名，source 表示参数的名字，source 后面是参数的值；
• sina：表示来源的渠道，如果是 sohu，那么这里是搜狐即可；
• joker：表示来源渠道的负责人；
• ad：表示为广告类型，这里以 ad 表示一类广告；
• about：表示对应的是此次 about 这个活动；
• 01：如果我们对这个资源位做了很多不同的广告图片素材，我们可以对素材编号为 01，02 等。

三、神策数据模型

1、数据模型简介

神策使用事件模型来描述用户在产品上的各种行为。简单来说，事件模型包括事件（Event）和用户（User）两个核心实体。

1.1、Event Model

在这个年代，每个产品都有着独一无二的核心指标用来衡量产品是否成功，这个指标可能是发帖数量、视频播放数量、订单量或者其它的可以体现产品核心价值的指标，这些都是一个简单的 PV 无法衡量的。

神策分析采用事件模型作为基本的数据模型。事件模型可以给我们更多的信息，让我们知道用户用我们的产品具体做了什么事情。事件模型给予我们更全面且更具体的视野，指导我们做出更好的决策。

2、Event 实体

2.1、Event 的五要素

简单来说，一个 Event 就是描述了：一个用户（Who）在某个时间点（When）、某个地方（Where），以某种方式（How）完成了某个具体的事情（What）。

从这可以看出，一个完整的 Event，包含如下的几个关键因素：

• Who：即参与这个事件的用户是谁。在我们的数据接口中，使用 distinct_id 来设置用户的唯一 ID，对于未登录用户，这个 ID 可以是 cookie、设备 ID 等匿名 ID；对于登录用户，则建议使用后台分配的实际用户 ID；
• When：即这个事件发生的实际时间。在我们的数据接口中，使用 time 字段来记录精确到毫秒的事件发生时间；
• Where：即事件发生的地点。使用者可以设置 properties 中的 $ip 属性，这样系统会自动根据 ip 来解析相应的省份和城市，当然，使用者也可以根据应用的 GPS 定位结果，或者其它方式来获取地理位置信息，然后手动设置 $city 和 $province；
• How：即用户从事这个事件的方式。这个概念就比较广了，包括用户使用的设备、浏览器、APP 版本、操作系统版本、进入的渠道等，目前，神策分析预置了如下字段用来描述这类信息，使用者也可以根据需要来增加相应的自定义字段。
  • $app_version：应用版本
  • $city： 城市
  • $manufacturer： 设备制造商，字符串类型，如 "Apple"
  • $model： 设备型号，字符串类型，如 "iphone6"
  • $os： 操作系统，字符串类型，如 "iOS"
  • $os_version： 操作系统版本，字符串类型，如 "8.1.1"
  • $screen_height： 屏幕高度，数字类型，如 1920
  • $screen_width： 屏幕宽度，数字类型，如 1080
  • $wifi： 是否 WIFI，BOOL 类型，如 true

• What：描述用户所做的这个事件的具体内容。在我们的数据接口中，首先是使用“event”这个事件名称，来对用户所做的内容做初步的分类。除了“event”这个至关重要的字段以外，我们并没有设置太多预置字段，而是请使用者根据每个产品以及每个事件的实际情况和分析的需求，来进行具体的设置，下面给出一些典型的例子：
  • 对于一个“购买”类型的事件，则可能需要记录的字段有：商品名称、商品类型、购买数量、购买金额、 付款方式等；
  • 对于一个“搜索”类型的事件，则可能需要记录的字段有：搜索关键词、搜索类型等；
  • 对于一个“点击”类型的事件，则可能需要记录的字段有：点击 URL、点击 title、点击位置等；
  • 对于一个“用户注册”类型的事件，则可能需要记录的字段有：注册渠道、注册邀请码等；
  • 对于一个“用户投诉”类型的事件，则可能需要记录的字段有：投诉内容、投诉对象、投诉渠道、投诉方式等；
  • 对于一个“申请退货”类型的事件，则可能需要记录的字段有：退货金额、退货原因、退货方式等。

2.2、后端记录 Event

友盟、百度统计等传统分析工具，都是在客户端嵌入 SDK 进行埋点，但是，我们（神策）强烈推荐在后端记录 Event，这是出于以下一些考虑：

• 很多行为，如下单等，他们的很多字段在前端（App 和 Web 界面）是拿不到的；甚至有些行为，如用户线下消费等，前端根本就没有提供相应的功能，就更拿不到对应的数据；
• 后端修改程序更加方便便捷，如果是在 App 端记录数据，则每次修改都需要等待 App 的发版和用户更新；
• App 端收集数据会有丢失的风险，并且上传数据也不及时。App 端为了避免浪费用户的流量，一般情况下，都是将多条数据打包，并且等待网络状况良好以及应用处于前台时才压缩上传，因此，自然会造成上传数据不及时，很有可能某一天的数据会等待好几天才传到服务器端，这自然会导致每天的指标都计算有偏差。同时，由于 App 端可以缓存的内容有限，用户设备的网络连接等问题，App 端收集的数据目前也没有太好的手段保证100%不丢失。

基于以上几点考虑，除非某个行为只在前端发生，对后端没有任何请求，否则，我们（神策）建议永远只在后端收集数据。

2.3、Event 的划分原则

对产品划分 Event，我们有如下的一些建议：

• 为了节约使用成本，应该从需求出发，只记录那些会分析到的 Event，这一点是与传统的 PV 分析产品一个很大的不同。记录 Event 是为了详细地了解用户是如何使用产品的，对于暂时不会分析到的那些使用情况，可以暂时先不记录。
• Event 的数量不应过多，对于一个典型的用户产品，Event 的数量以不超过 20 个为宜。当然，这个只是我们对事件设计的一些原则性的建议，系统本身并没有这方面的限制。一些类似的用户操作，可以合并成一个 Event。例如，假设某个产品比较关心对一系列商品分类页的访问情况，那么，并不意味着每个商品分类页点击就应该划分成一个单独的 Event，而是可以划分出一个单独的“商品分类页访问” Event，然后再将不同的分类以字段的形式进行记录。
• Event 不仅局限于用户在 App、Web 界面等前端的操作和使用，一些其它类型的用户行为，例如用户的电话投诉、用户在线下接收服务、用户在线下商家进行消费等，如果能够获取到相应的数据，并且数据分析也会用到，则也可以作为相应的 Event。

2.4、字段设计原则

为每个 Event 进行字段设计，我们有如下的一些建议：

• 先根据需求梳理分析的指标和维度，然后再从指标和维度倒推需要在每个 Event 记录的字段；
• 神策分析是一个数据分析工具，并不是一个日志存储和备份系统，所以，一些用不到的字段就没有必要作为一个 Event 的字段来进行记录和收集了；
• 预置字段中已经有的字段，则建议尽量复用预置字段；
• 某个 Event 的某个字段的设计一旦确定，则不要再修改它的类型和取值含义。

四、相关参考

• http://www.woshipm.com/data-analysis/872543.html
• http://www.woshipm.com/operate/300099.html
• http://www.woshipm.com/pd/3049113.html
• https://mp.weixin.qq.com/s/E6ETEUikyjAYFdDr-2ipYQ
• https://mp.weixin.qq.com/s/giPfYrpv5bm0l1klXBiGUQ
• https://www.zhihu.com/question/36411025
• https://www.sensorsdata.cn/manual/data_model.html