🌞 Analyst.Best

Search

SearchSearch

埋点与日志数据

Jul 16, 202428 min read

需采集的数据的类型

一个正常运行的网站或软件，会在用户与其发生交互的时候产生多种类型的数据。

首先，软件为响应用户的操作，需要接受用户的输入，并给出相应的输出，这些输入输出的信息，就是软件系统正常运转时产生的数据流。它们直接体现和软件的功能相关，每一条数据都体现了软件本身所承载的业务。这些数据可以被认为是业务数据。业务数据会存储在支持软件运转的业务数据库中。例如，新闻网站最核心的业务就是让用户可以阅读新闻，它就会有一份新闻数据库，存储着每天刊发的新闻文章。用户在浏览这个新闻网站时，会根据个人的兴趣点击某条新闻的标题，形成一次输入，新闻网站则查询新闻数据库中对应的记录，将用户点击的这条新闻的全文显示在网页上。为了记录新闻的阅读情况，新闻网站的系统可能会同时在这条新闻的数据库记录中的阅读量字段上加 1，记录了真实的新闻阅读量。

在使用电脑的时候，我们可能都遇到过所谓的“软件崩溃”的情况，不少软件会在崩溃后主动记录崩溃时的运行日志，征求用户的授权后，再将日志回传给开发者。网站的主要系统运行在服务器端，相应的日志数据可以直接存入到服务器的文件系统中。最初的时候，开发日志只是开发人员为了排查问题，记录历史状态而记录的，并不是为了分析业务问题而记录的。但开发日志中的确蕴含了大量的业务信息，数据分析人员可以从中分析挖掘出有价值的业务知识。最简单的例子，前面提到过新闻阅读量的记录，只能记录到阅读量的总数。用户在请求网页数据时，网站服务器是能够获知用户的 IP 地址的，只需将包含 IP 地址的请求信息以日志的形式保存下来，就可以按 IP 统计到该网站的访问用户数。同样的，我们可以将各类用户请求数据以日志形式保存下来，获得完整的网站访问日志，分析人员就可以借此进行各类网站数据分析了。不单单是页面的请求，只要是服务器端能够识别的用户行为，我们都有机会编写程序记录下来。因为日志的记录位置在网站的服务器端，所以也会被称为服务端埋点、后端埋点。

当然，用户的行为其实是发生在交互界面上的，也就是所谓的前端页面上，大量的交互动作和细节不会传送给服务器端，服务端无法完整捕捉这些信息。所以，为了获取这些数据，开发者同样可以在交互界面上编写程序，将用户的行为记录记录下来，并回传给服务器。这就是前端埋点。因交互设备种类的多种多样，PC设备的网页端、程序端，移动设备的 App 端、网页端、小程序端，甚至包括可穿戴设备的程序端，前端埋点面临着复杂的技术环境。埋点的实现和质量的把控，需要开发人员发挥自己的聪明才智，而埋点数据结构的规范则依赖于开发初期制定的统一的埋点数据模型。

初步小结，通过编写程序捕捉、存储的各类数据可以分为：

  • 业务数据库
  • 服务端埋点
  • 前端埋点
    • Web
    • App
    • 小程序
    • 其他类型的设备

业务数据库

无需复言，业务数据库一般由数据仓库工程师直接按规范建模并导入数据仓库，并不需要额外的采集开发成本。

服务端埋点

服务端日志一般以纯文本格式记录所有需要记录的服务端信息，再通过文本解析程序载入到数据库或数据仓库中。载入时可以载入全部字段，也可以仅仅载入和数据统计和分析相关的字段。

Web 日志

如前所述，用户在 Web 页面上发生交互时我们可以采集到 Web 前端埋点数据，Web 程序和后端服务器发生交互时我们可以采集到服务器日志数据。同样地，本篇不讨论为了开发运维而采集的 Web 日志。

一般情况下，网址可以准确描述用户当前所在的页面，常用的 http 或 https 开头的网址都属于 URL 的一种，完整的 URL 地址遵循这样的格式 [协议类型]://[访问资源需要的凭证信息]@[服务器地址]:[端口号]/[资源层级UNIX文件路径][文件名]?[查询]#[片段ID]

  • 协议类型：即 http、https、ftp 等协议，Web 日志中记录的基本都是 http 和 https。
  • 访问资源需要的凭证信息：在 Web 环境下往往无需填写，所以日志中基本不会捕捉到该信息。
  • 服务器地址：即日常语言中所谓的网站地址。
  • 端口号：不同服务都有自己的默认端口号，Web 服务常用的有 80、8080、443 等，日常上网时不需要用户填写，所以日志中基本也不会捕捉到该信息。
  • 资源层级文件路径与文件名：网址中含有 / 的部分，是当前访问资源（一般情况下即当前网页）的具体路径，采集到日志数据后经常需要通过该部分判断资源的详细内容。
  • 查询：以 ? 开头的部分，是用户使用网页程序时向服务器发起的查询内容，例如 [https://www.google.com/search?q=url](https://www.google.com/search?q=url) 中 q=url 代表着搜索关键词为 url 。
  • 片段ID：前面已经将网络资源定位到了页面，而片段ID则可以在页面上定位到具体的内容，也称做锚点。例如本篇文章当前段落的地址为 [https://www.yuque.com/javalover93/datapedia/dgahge#FtnQ7](#FtnQ7)，其锚点值 #FtnQ7 就指向 “Web 日志” 这个段落。

由此可见，url 信息足以确认用户当前所在页面，只要能够记录“每一位用户在何时访问了什么页面”的信息，就可以获得一份完整的 Web PV 日志。PV 即 pageview 页面浏览的缩写。这并不难实现，服务器端口一直等待着响应用户的请求，只需要在用户每次请求网页时将这些信息记录保存，再编写日志解析程序存入一个数据库中，我们就获得了“用户 Web PV 日志”。

下图是我在访问本页面时，Chrome 浏览器里能够查询到的请求头 Request Header 信息，我本地的 Chrome 浏览器以 Request Header 中的参数向 yuque 服务器通过 GET 方法请求了位于 [https://www.yuque.com/javalover93/datapedia/dgahge](https://www.yuque.com/javalover93/datapedia/dgahge) 上的资源内容，即本页面的内容。请求的结果是成功的（以 HTTP 状态码 Status Code = 200 表示），所以 Chrome 成功地展示了本网页。

值得注意的是，Request Headers 里除了 url 外，还有大量的用户无感知的参数。例如 accept-language 表示本浏览器可以接受的页面语言，sec-ch-ua 开头的参数标注了我的设备信息（macOS 系统，chrome 浏览器，还有暂时看不懂的版本号等其他参数）。最为重要的是 cookie 参数，里面有 yueque_session 和 yueque_ctoken 等参数。一般而言，token 可以让服务器鉴别用户的身份而无需每次请求时让用户手动登陆一次，session 则标记了用户的会话信息。一次会话帮助标识了用户在某一次使用该网站时接连访问的一串网址。关于会话的具体细节，可参考网页数据分析相关的资料。 image.png

典型的 Web PV 日志

一份典型的用户 Web PV 日志会包含以下这些字段：

  • 访问时间戳
  • 离开时间戳
  • 用户唯一标识字段，可以是这些字段：
    • IP 地址
    • cookie-id
    • cookie 中携带的用户id、或者能和服务器用户 ID 匹配的某种 id
    • MAC 地址
  • 访问的 url 地址
    • url 的查询和片段id等部分可能作为单独的字段列出。
  • session-id
  • 其他字段
    • 网络信息字段
    • 设备信息字段

典型的 Web 行为日志

Web PV 日志仅能记录用户在哪些页面上停留，不能记录用户在那些页面上的行为。简单的网页，用户在页面上只能滑动浏览和点击链接跳转到其他页面。复杂的页面上，用户可以产生各类交互：点击按钮，左右滑动画面，甚至游戏中的各种操作。为了记录这些细节的行为，对网页的具体功能进行分析，我们需要 Web 行为日志。

Web PV 日志中的字段，在 Web 行为日志中基本全部都有。因为行为只在某一时刻发生，所以没有离开时间戳，只有触发时间戳。Web 行为日志，还多出和用户具体行动有关的字段：

  • 行为名称
  • 行为参数

例如，用户点击查看轮播图中未展示的一个广告，则行为名称可能为 click_carousel，行为参数则有

  • loc = 3 代表点击了第三幅轮播图
  • material_id = 765 代表点击时第三幅轮播图展示的物料id是 765

UTM 参数

前面提到过 URL 中的查询关键字，这部分关键字是浏览器端向服务器端发起请求时的关键字。注意到多个关键字之间可以以查询名称区分，这意味着除了传递向服务器发起请求的查询关键字，还可以传递其他信息。即服务器端可以借此从浏览器端收集信息。以此为基础，UTM 参数可以实现对网页流量来源的追踪。

根据 wikipedia，常见的 UTM 参数有五种：

  • utm_source 标识广告客户、广告网站。
  • utm_medium 标识来源类型，如电子邮件、文章。
  • utm_campaign 标识具体广告标识。
  • utm_term 标识搜索关键字。
  • utm_content 区分同一广告内的不同链接，常用于A/B测试等。

UTM 本质上是一种数据采集的技术方式，参数名称并不一定得按照 utm 开头。与之类似的例子还有淘宝的 SPM 码。参考木东居士的博文，淘宝提供的SPM是淘宝社区电商业务为外部合作伙伴提供的一套跟踪引导成交效果数据的解决方案。SPM编码用来跟踪页面模块位置，标准spm编码由4段组成，采用a.b.c.d的格式，并建议全部使用数字。链接 [http://detail.tmall.com/item.htm?id=XXX&&spm=2014.123456789.1.2](http://detail.tmall.com/item.htm?id=XXX&&spm=2014.123456789.1.2)的 SPM 码含义如下：

  • a代表站点类型，对于xTao合作伙伴（外站），a为固定值，a=2014。
  • b代表外站ID（即外站所使用的TOP appkey），比如您的站点使用的TOP appkey=123456789，则b=123456789。
  • c代表b站点上的频道ID，比如是外站某个团购频道，某个逛街频道，某个试用频道等。
  • d代表c频道上的页面ID，比如是某个团购详情页，某个宝贝详情页，某个试用详情页等。

感兴趣的朋友可以仔细观察社交网络软件的分享链接，你很有可能可以找到分享网友的账号。如果你想分享一些东西但不被软件运营方或者网友追踪，建议试试删除这些查询参数。

附赠一些阅读材料：

App 日志

App 前端日志就是常说的“埋点日志”。埋点，在产品功能代码之上增加的专用于采集数据的代码。从软件开发的角度来说，也是软件功能的一部分，最好也纳入软件开发的项目周期中管理。历史上，因统计功能的开发较难体现工作成果，不少企业的开发团队对其不甚重视，甚至视为额外的负担，造成统计分析人员在此类工作的软件工程部分多费时间。现在的主流共识，埋点功能也当作产品功能的一部分，以软件项目管理的方式规范管理。因埋点工作的琐碎和细节，一般会内部研发一个埋点管理系统用于管理所有的埋点材料。

和 Web PV 日志一样，App 日志也可以分为页面和行为两类。因 App 页面空间有限，页面元素重叠，元素交互的丰富程度也远超 Web 页面，不少 App 应用上可能无法像 Web 那样清晰地定义“页面”，此时少量页面的进入和退出可以通过进入和退出的点击行为来定义。对于有很强的内容消费属性的 App，比如全屏的视频、图文内容、类似于贴吧的讨论区等等，内容往往还是得通过具体的“页面”承载，用户在页面上的时间就变得重要，此时将 App 日志分为页面和行为应该是有益的。对于交互更丰富导致元素更细碎的 App，比如游戏；或者对于功能单一到只有一个页面的 App，并且其辅助页面无统计价值的，例如短信、早期微信，单独划分出页面日志的价值有限，完整的行为日志中的蕴含信息的价值更大。

App 埋点的技术类型

  • 代码埋点
    • 按数据分析需要单个单个地提出采集需求，由开发人员逐个地编程实现并测试验收。因完全采取代码开发的方式，所以称为代码埋点。
    • 埋点需遵循一个既定的数据规范。因为是定制开发，功能实现的灵活性高。又因为所有的埋点都需要代码实现，而不少埋点可能重复性高，相对耗费开发资源。
  • 可视化埋点
    • 为了节约开发资源，且让数据分析人员也参与到埋点过程中，避免埋点实现不符合需求方预期，而开发出的一种埋点方式，一般会以某种叠加层的方式提供可视化的元素选择和埋点参数编辑功能。
    • 理想状态下，数据分析人员根据自己的需求，借助可视化埋点工具，选择触发的元件，设置好触发条件、触发方式，配置好需要收集的参数，即可实现埋点。
    • 对于一些需要细致逻辑判断触发，可视化埋点仍然无法实现。
  • 无埋点/全埋点
    • 前面两种方式都是需要时才收集，这种则是默认全收集。默认全部收集，意味着软件中内置了数据收集功能，对于所有的元素交互触发，都会自动收集数据，而无需人为指定（可视化埋点）或开发（代码埋点）。
    • 因不少行为需要收集的参数可能随着版本变化，一劳永逸的方式，意味着无法真的做到全面收集所有数据。采集到的埋点也不一定是分析需要的，意味着可能采集了太多无用数据。出于数据传输量和存储量的限制，无代码方式也有潜在的成本风险。

目前已有不少的可视化埋点和无代码埋点的 SaaS 产品，对于早期产品，这些产品省时省力，数据量不大的情况下，采集到冗余数据的支出成本也不高。对于成熟产品，细节层面的产品改进需求，意味着代码埋点的必然性。

对于埋点技术类型，这些文章有较为清晰的阐述： 《讲明白“埋点”的演变史》 《易观：可视化埋点》

日志数据模型

App 应用一般都有 iOS 和 Android 版本，如不预先制订一份较为通用的埋点字段规范，会为数据治理带来一些令人难受的问题。不难感受到，App 日志的规范同样适用于 Web 日志。埋点数据规范不但可以统一某一款 App 的各端日志，还可以统一企业层的日志，这对企业数据治理而言大有裨益。这份埋点字段规范落地实现时可以和数据仓库里的埋点数据模型对应。

日志数据模型并不复杂，按 4W1H 的框架即可整理出当前需要的主要字段。

  • WHO：包含用户信息和设备信息。
    • 一般自动生成，无需额外定义。
  • WHEN：埋点触发时间。
    • 具有多种变体。对于页面事件则为进入时间和退出时间。对于计时心跳，则包含心跳时间、心跳时长等。
    • 自动生成。
  • WHERE：埋点触发的位置。
    • 一般以页面名称标识，经常需要辅助字段来定位在页面上的具体位置。
  • WHAT：埋点的具体含义。
    • 一般就是埋点名称，辅以埋点解释字段。
    • 行为对象的信息，如内容的物料ID。
  • HOW：埋点触发的方式
    • 交互方式，一般默认是点击，如果是滑动、拖动等则需要记录。
    • 触发时其他需要记录的参数。为了便于扩展，可以按 json 格式记录这些信息，分析师在使用时再自行解析。
  • 还有一些如网络信息等和用户行为无直接关系，但也具有一些潜在价值的字段。

想要了解更贴近真实场景的埋点技术，可以参考神策等厂商的技术文档。

小程序日志

借鉴 Web 日志和 App 日志的方式即可。

埋点管理工作

埋点信息管理和开发流程管理的需要会很快显露出来，所以我建议一开始就要重视埋点的管理工作。埋点管理可以参考常规软件开发的需求发起、需求研讨、技术研发、测试验收、文档管理的流程，埋点量较大的企业以及未来规划制作高度自动化的数据系统的企业，则建议开发内部的埋点管理系统。

埋点管理的主要目的是减少甚至消灭这些数据源质量问题：

  • 埋点质量问题。如代码原因造成的漏报、错报等。
  • 重复埋点。
  • 遗漏埋点。
  • 埋点元信息丢失，收集到的数据无法被解读。
  • 埋点漂移。新版本加入新功能意外影响到线上埋点。
  • 信息垃圾。已经失效的埋点代码未删除，一直上报，浪费资源。
  • …

埋点管理中经常被忽视的部分，或者说真正导致埋点管理不易的部分，正是各方权责的划分和工作流程的管理。本文不对此展开。整体的埋点管理工作可以参考这些文章：

image.png

埋点管理系统

埋点管理系统本质上就是一张记录了各条埋点相关信息的大表格。所以，早期的埋点管理完全可以依仗电子表格，一个具备单元格级别权限管理和搜索查询功能的在线表格就可以制作初版的埋点管理系统了。除了 4W1H 中的信息外，埋点管理系统需要包含不少业务信息和工程管理信息。简单列举可能包含的信息类型

  • 埋点信息
    • 即前述的 4W1H 的部分。
  • 埋点需求管理
    • 需求方
    • 需求描述
      • 必要时给出含软件界面的描述、需求文档的下载链接等。
    • 优先级
    • …
  • 埋点开发管理
    • 埋点数据负责人（一般是需求方、相关模块产品经理、相关业务分析师）
    • 埋点开发责任人
    • 埋点测试责任人
    • 埋点测试验收情况
    • …
  • 埋点生命周期
    • 生效版本/生效时间
    • 失效版本/失效时间（建议写仍然生效的最后一个版本）
    • 数据采集开关
    • …
  • 埋点质量信息
    • 上线后发现的质量问题等，可以备注此处，便于数据使用者判断数据有效性。
  • EDW 信息
    • 所属业务域 等和数据仓库建模有关的字段，便于日志解析时直接分发到对应数据仓库和数据集市表中。
    • …

Graph View

Backlinks