比用户更懂用户|新一代用户行为追踪和数据洞见
作者|王可,孔一民,邵锋,李翔,徐冰泉
编辑|林颖
供稿|Tracking Team
本文共7310字，预计阅读时间15分钟
更多干货请关注“eBay技术荟”公众号
背景
Background
为了打造新一代用户行为追踪系统，Tracking（中国）团队着力于开发一个新的项目——Surface Tracking。该项目旨在打造一个无用户感知且覆盖全站的用户交互行为追踪和数据体系。时至今日，Surface Tracking已经发展成为集用户行为捕捉、数据收集、数据处理与数据服务的一体化平台。
目前，Surface Tracking的每日流量为5TB左右，每日捕捉的用户行为数据为150亿条，其范围已覆盖全站所有页面，覆盖的页面共有1,200余个。与此同时，在此基础上的数据查询仅需秒级就能完成。
1 介绍
1.1 什么是用户行为追踪
用户行为追踪（User Behavior Tracking），是指通过代码注入监听的技术方式，对用户与设备之间发生的交互行为进行捕捉、收集、处理，并实现最终数据落地。通过对于eBay页面上用户交互行为的记录，数据科学家和分析师们可以对追踪的数据进行分析、建模以及可视化，并且能基于该数据层面的发现进一步对eBay产品的用户体验和内容表现进行提升。
eBay作为电商平台，会将关注点集中于用户在eBay网站与App上的浏览、点击、交易等行为，如下电商常见用户旅程解析图[1]所示。这些用户行为数据的分析广泛应用于广告推荐、搜索算法、用户画像等一系列场景，并对于eBay整体用户体验的提升提供了极大的帮助。
图：电商常见用户旅程解析图
(点击可查看大图)
在Surface Tracking出现之前，eBay已经拥有一套“历史悠久”的站内追踪系统。除了单纯的用户页面展示以外，该系统还记录了各个大大小小站内界面交互的调试信息，几乎包含了所有系统行为。该系统记录量已经达到了日均500亿条以上。虽然该系统追踪的数据看似已经很全面了，但按照原有的架构设计和数据模型并不能高效率地解答目前所有数据需求的问题。
我们以一个简单且常见的问题为例：通过一个用户的标识，如何准确地获得该用户所有页面的访问、点击和模块展示时间？
针对以上例子，使用原有系统需要掌握大量不同页面的领域知识，配合极其复杂难懂的SQL，才可以得到接近准确的答案。这就需要新一代用户行为追踪系统来解决原有系统的问题，以提供更高效的用户行为数据。
1.2 用户行为追踪的方式
1.2.1 细分领域追踪v.s.平台驱动追踪
在eBay站内，大到各业务部，小到各功能模块，都是基于原有的追踪平台，来自定义各自的用户追踪方案。这就属于细分领域（Domain-specific Tracking）的解决方案。每个系统都是针对各自业务独立设计的，因所关注的用户行为不尽相同，往往是在垂直方向进行深入，从而得到与各领域自有业务相关性较强的数据。与此同时，为了对捕捉到的数据进行分析，数据工程师、分析师和数据科学家们往往需要大量的数据清洗与处理工作，其中的处理逻辑也会与业务逻辑紧密关联。
而与之相对的，还有一种方式属于平台驱动（Platform-driven Tracking）解决方案。这种方案的特征是：使用统一的追踪模块覆盖所有页面，并对所有数据进行统一的处理，所以行为捕捉的逻辑、所关注的行为、得到的数据结构与内容都具有强一致性。因此，平台驱动型的用户追踪旨在解决各业务领域所共有的或跨领域的问题。
综上所述，细分领域追踪和平台驱动追踪两者的适用范围和价值（如下图所示）各不相同，应根据需要选择对应适合的解决方案。
图：两者的适用范围和价值
(点击可查看大图)
1.2.2 客户端行为v.s.服务器端行为
对于用户行为进行追踪，从技术上可以分为客户端行为（Client Side Behavior）与服务器端行为（Server Side Behavior）两种方式。
客户端的行为追踪会将代码加载在客户端，包括浏览器网页和手机app等等；而服务器端的行为追踪则会在服务器端使用中间件或添加代码等方式，记录用户与服务器的交互。
所以，客户端与服务器端所能得到的结果会有许多不同。如下图所示，服务器端推荐N个商品，而用户在客户端实际上只看到了前3个。由于客户端追踪更贴近于用户，因而原生能支持许多特定行为的捕捉，如模块是否在屏幕上展示以及用户的键盘动作等等。
图：客户端与服务器端得到的结果对比
(点击可查看大图)
Surface Tracking是纯客户端的解决方案，在数据上对原有服务端追踪进行了很好的补充。不管是对个性化推荐算法的完善，用户体验的完整监控，还是对卖家、买家、公司决策的报告纬度的完整性提升都有很大的意义。
2 电商平台常见用户数据问题
通过对用户旅程与用户交互数据的记录，Surface Tracking可以回答电商平台上常见的数据洞见问题，如用户转化率、模块转化率、页面指标、页面流转等，这对提升用户体验与改进方案建议提供了不少帮助。
比如，通过分析用户转化以及用户在站内的页面流转数据，可以提升网站设计，提高用户在eBay购物时的体验。另一方面，通过广告展示、搜索结果等模块的转化率与业绩归因分析，可以优化相关推荐算法，在提升用户体验的同时，也能增加eBay平台的成交额度。
接下来，本文将具体介绍Surface Tracking可回答的用户追踪数据问题——用户旅程问题（User Journey）和用户交互问题（User Engagement）。
2.1 用户旅程问题
2.1.1 会话v.s.路径
根据分析维度的不同，用户旅程可以细分为访问会话（Session）和访问路径（Path）两种。
会话指在时间维度上具有连续性的一系列用户事件的集合，描述了用户对于eBay网站持续性访问的行为。目前在Surface Tracking解决方案中，与Sojourner Tracking（细分领域追踪内部产品名）类似，我们采用30分钟静默期作为会话时间窗的分割标准。
路径指具有因果关系的一系列用户事件的集合，描述了用户在eBay站内网页跳转的访问链。在App端，由于App内容的单屏特性，用户的访问路径往往是时间序列的事件链路。而在Web浏览器上，由于用户可以打开不同标签页，基于各个标签页进行后续的页面访问，因此访问路径（如下图所示）往往是分叉的。
图：带分叉的用户行为路径
(点击可查看大图)
2.1.2 页面流 & 页面漏斗
基于Surface Tracking的路径维度分析，我们给出了描述用户行为的两种不同形式。
页面流（Page Flow）描述了用户在同一路径内对于不同页面的连续访问模式。Surface Tracking可以提供任意顺序组合页面流的统计数据，以及其下一步访问事件的概率分布。
与页面流不同，页面漏斗（Page Funnel）的功能并非针对于连续的访问事件，而是关心用户从一个或一系列页面最终转化到另一个或一系列页面的情况，如下图展示了从主页到搜索再到商品页面的数据情况。
图：页面漏斗
(点击可查看大图)
2.2 用户交互问题
在同一个网页中，展示的内容、曝光的时间会根据用户不同而有所不同，而不同地方所展示内容的交互方式也会不同。例如，在一个长网页中，用户需要上下翻滚才能浏览其全部内容；又如在eBay站内常见的推荐广告组件中，用户需要进行左右滑动以查看更多内容。
与页面级别的追踪不同，在用户浏览一个页面时，除当前页面本身之外，每一个可见模块都会作为一个可追踪对象。对此，我们采用热度图的方式来对模块级别的数据进行追踪。
当模块展示在用户屏幕上时，我们会以模块为维度对用户的浏览行为进行记录。不同模块开始展示的时间与结束展示的时间都有所不同，也会在用户视野内停留不同的时长。另外，除了模块的展示之外，用户是否执行动作与当前模块进行互动，也属于热度图的范畴。
通过上述指标，数据用户可以直观地得出页面上各模块的曝光率、点击率、收益归因等热度信息。Surface Tracking目前已经支持网络页面上各模块的曝光率与点击率数据。通过结合Nous PA 2.0（分析产品内部名称）浏览器插件，我们可以直观地将热度图数据展示在网络页面上，如下图所示，显示不同模块的展示率。
图：页面热力图
(点击可查看大图)
3 方案与架构
3.1 产品形态
Surface Tracking是集数据抓取、处理与分析于一体的端到端解决方案。以下将分别从两端介绍产品的对外形态——追踪内容（Tracking Targets）与数据服务（Tracking Data Access）。
3.1.1 追踪内容：多维度&多粒度
目前Surface Tracking所追踪的用户数据包括页面浏览、访问路径、模块展示、模块点击数据。根据用户行为，我们追踪的内容与追踪粒度如下所示：
3.1.2 数据服务：接口&数据集
对于下游数据用户，Surface Tracking提供两种不同的数据访问形式。
一种是用户可以直接使用Surface Tracking的数据集。目前Surface Tracking将数据以Hive表的形式记录在公司的Hadoop大数据平台，而对于较为原始的数据需求可以通过对数据集的查询来获取。
另外，Surface Tracking也提供数据访问服务，通过自有网络应用将数据查询功能以RESTful接口形式暴露给下游用户。而对于较为复杂的热度图、页面漏斗等数据，可以直接通过访问接口进行查询。
Surface Tracking出现之前，追踪的数据集（如下表所示）囊括了所有与追踪相关的数据记录，较为庞大且杂乱。而不同部门在进行数据记录时，所记录的内容、格式均不相同。当需要进行跨业务领域的分析时，会很难理解其他部门所记录的数据。
表：细分领域追踪数据集样本示例
(点击可查看大图)
当各业务部门需要使用用户行为数据时，所需要付出的努力也是巨大的。以搜索业务团队为例，由于原始数据结构复杂且数据量极大，因此不能直接使用查询语句或视图。数据工程师需要专门编写Spark Job进行数据提取、清洗以及落盘操作，其中需要开发近3,000行SQL语句进行数据处理，如下图所示为查询某个用户在某一天的所有页面访问。而且，即便在项目完成后，每天也需要花费数小时来运行数据处理任务。
图：查询语句
(点击可查看大图)
针对上述问题，Surface Tracking提供了简洁优雅、格式统一、可读性高的数据集，如下表所示。
表：Surface Tracking数据集样本示例
(点击可查看大图)
在使用Surface Tracking数据时，对于任何领域或部门的数据工程师来说，不需要进行任何数据清洗工作，并且只需要极少量的学习成本就可以立刻上手，如下图所示，仅需要几行SQL语句就能完成某个用户在某一天的页面访问查询。同时，Surface Tracking以统一的数据处理方案维持了数据集的简洁性，大大提高了查询效率。
图：查询语句
(点击可查看大图)
3.2 产品技术框架
我们一般将追踪系统按照数据流向分为捕捉（Tracking Agent）、收集（Collection）、处理（Processing）和服务（Access）四个组件。接下来，我们将分别介绍各组件的内部架构。
(点击可查看大图)
3.2.1 捕捉
用户行为捕捉组件也被称为追踪代理（Tracking Agent）。在Web上，Surface Tracking的追踪代理是一份Javascript文件，并通过eBay Global Header注入在eBay站内的网页上。因此，Surface Tracking无需任何额外操作就可以直接注入eBay网页并运行。同时，追踪代理的版本更新与发布，和各业务页面相互独立，不会互相影响。追踪代理主要包括以下几个方面的技术内容。
1、全自动模块捕捉
全自动模块捕捉是指通过读取并解析当前页面，追踪代理会遍历当前页面的可视组件。脚本通过对所有的Web组件进行扫描，并过滤掉一些过小或展示时间过短的“类不可见”模块。如下图所示，虚线框出来的模块就是脚本可以自动追踪的内容。
图：自动追踪模块
(点击可查看大图)
脚本也会观测各可视化模块与用户设备视窗的相交事件，它可捕捉各模块在用户视窗中所显示的比率（Intersection Ratio），并确定各模块在视窗中的驻留时长（Dwell）。通过事件监听，追踪代理还可以捕捉到相应模块的用户点击行为。
2、数据发送
在用户切换标签页以及退出当前页面时，用户代理选择向服务器发送数据，以收集更全面的数据。如果用户关闭标签或跳转页面，会在卸载文档前发送数据。为了不延迟文档卸载，我们优先使用Navigator.sendBeacon()，将数据以异步形式传输到服务器。
3、插件拦截监测
目前有许多常见的浏览器插件可以对用户追踪系统进行拦截，例如uBlock Origin、Ad-Blocker、Adblock Plus等。为了及时得知拦截情况，Surface Tracking专门搭建了拦截监测系统。该系统在一个独立Docker容器中运行一个装有拦截插件的浏览器，并使用Selenium框架对其进行持续测试，以便得知追踪代理的行为是否被插件拦截。一旦被拦截就会收到警报，Surface Tracking Team将会采取相应的方案以避免数据丢失。
值得一提的是，该插件监测系统目前还同时服务于eBay广告，以便监控站内广告是否被去广告插件拦截或折叠。
3.2.2 收集
用户行为收集组件也被称为收集服务（Collection Service）。Surface Tracking的收集服务是由Java编写的网络应用集群。收集服务是基于eBay Raptor.IO框架实现的，并部署在Altus上，通过向外提供RESTful API的方式与前端捕捉组件进行集成。
收集服务在收到网络请求后，会对所得到的数据进行校验和初步处理，即将不合法的数据过滤，从而得到的合法数据信息，并进行重新组装。
收集服务同时集成了eBay提供的基础架构——ES集群服务（Pronto）和流处理服务（Rheos），作为数据下游。经校验处理后的数据会双写进入ES集群中，供下游数据用户订阅，同时进入Kafka管道与Surface Tracking下游处理模块进行集成。
3.2.3 处理
Surface Tracking的数据处理组件可分为流处理与批处理两部分。
1、流处理：会话化&欺诈监测
流式处理组件整体是基于流处理服务平台Rheos的，并使用其中的Kafka与Flink组件组合来实现的。流处理Flink任务（如下图所示）基于事件时间，对事件流进行静默期为30分钟的会话窗口处理。在窗口处理时，将窗口内最早事件的时间戳作为会话的标识，并标记在会话窗口内的所有事件上。
图：流处理Flink任务
(点击可查看大图)
同时，流处理组件会基于预定义规则对事件流进行欺诈检测。例如，在一个会话窗口内，若超过10,000个事件，该用户会被认为是欺诈用户，即使用脚本对eBay进行访问。被标记为欺诈的用户标识将会通过广播传递给下游算子进行过滤。
最终流处理程序将数据落盘并写入Hive表中。由于整体流处理程序的事件时间是从客户端所捕捉到的，因此会对迟到事件进行旁路输出，并记录在单独的表中。
2、批处理：时间矫正 & 路径构建
由于行为追踪代码运行在客户端，因此所采集数据的事件时间会收到用户设备时间设置的影响。如果用户电脑时间较慢，那么所采集到的用户行为时间也同样较慢。因此在收集服务接收到数据时，会将数据中的事件时间与服务器时间进行比较，并记录差值。
在批处理过程中，会根据上游记录下的差值进行事件时间的矫正，即处理模块会统计每个用户所有事件时间差值的中位数，并以此为依据，矫正其全部事件的时间戳。
由于用户访问路径数据结构的特殊性，批处理组件会针对路径数据的树状结构来重写数据，并落盘在另一张用户访问路径表中。与事件记录表有所不同，用户路径表会以访问路径树的每一组路径（由根节点到叶子节点）为维度进行记录。
3.2.4 服务
服务组件也被称为数据访问层（Data Access Layer），由Java网络应用与NuColumnar数据存储服务两部分组成。网络应用组件部署在Tess平台，并通过RESTful API向外提供数据查询服务。接下来将具体介绍数据服务的一些技术细节。
图：数据服务架构图
(点击可查看大图)
1、Clickhouse
Surface Tracking当前以URI为主要数据特征，它的数据基数极高。其中，每日页面访问数据约为4亿，基数为1.5亿左右。为了解决数据高基数（Cardinality）问题，我们采用了与以往预聚合[2]不同的解决方案，即Clickhouse将原生数据存储后，通过实时聚合计算进行查询。
基于Clickhouse的实时聚合功能，Surface Tracking提供用户即时查询（Adhoc Query）服务，即用户可以高自由度地根据自己需求来自定义查询条件。基于MergeTree引擎，Clickhouse实现了性能极高的分布式查询，如下图所示。总而言之，Surface Tracking依托于NuColumnar服务（NuColumnar是eBay基于Clickhouse[3]的存储查询服务），实现了高性能即时查询。
图：Clickhouse分布式存储示意图
(点击可查看大图)
与此同时，页面流与页面漏斗查询拥有n2~n3的算法复杂度。因此，Surface Tracking利用Clickhouse的采样特性，可以在牺牲少量准确性的情况下极大提升了其查询性能。上述用例的性能如下：
除此之外，Clickhouse还提供了丰富的数据类型与处理函数。首先，Clickhouse支持数组（Array）类型，并提供了非常全面的数组函数。Surface Tracking利用数组的特性实现了页面流的高性能查询。同时，Clickhouse也提供许多URL处理函数，为各项功能的实现提供了许多便利。
2、缓存层 & 缓存预热
数据服务组件通过Spring Cache框架与Redis集群进行集成，以实现访问缓存。针对每一个请求，服务会将请求与查询结果序列化后，作为键值对，存储于Redis中。在完全命中缓存的情况下，服务可提供至少12,000QPS的查询性能。当Redis空间不足时，缓存记录采用LRU（Least Recently Used）的淘汰策略，以保留热点查询结果。由于查询数据集不会动态更新，因此从时间维度上缓存采用“永不过期”策略。
对于相同的缓存条目，我们利用Redis的分布式锁来保证其一致性，同时也能减少对Clickhouse的访问。当请求到达时，数据服务组件会获取以缓存键命名的Redis分布式锁，之后执行查询及缓存写入操作。如此一来，即使多个相同的请求同时到达，也只会有一次对于Clickhouse的访问。
简单来说，缓存就是在用户请求访问系统时，把计算结果保存在某个地方。当在遇到同样的请求时，就可以跳过计算直接返回保存的结果。但这对于第一个访问系统的用户并不友好，可能会有耗时长的体验问题。为了提升用户体验，我们会针对耗时较长的热点查询进行缓存预热，即在某种请求第一次到来前，系统对自己访问并缓存结果。这样第一个用户触发的请求访问时，实际上已经是读取保存好的结果。因此，我们在Surface Tracking批处理流程中，会定期地触发预热任务。
3、并发控制
Clickhouse数据库服务虽然具有优秀的分布式查询性能，但对于复杂SQL查询的并发性能较差。在实践中，我们发现：在高并发请求发生时，Clickhouse数据库有极小概率会出现内存不足的异常。尽管系统拥有缓存层，但当缓存未命中时仍会有数据库并发访问的发生。
因此，利用Redis，服务采用分布式的可过期信号量进行并发控制。查询请求到达服务后会进入内存队列中，只有当消费线程获得信号量后才能执行Clickhouse查询。目前，信号量的总数为4，即服务同一时间点最多并行执行4个Clickhouse查询。这里是利用了Clickhouse原生的特点（即拥有1份主分片与3份复制分片），将查询并发量最大化。
4 总结与展望
从成立至今，Surface Tracking在一年的时间内实现了完整的端到端解决方案，并成功于2021年6月上线，开始服务下游用户。
然而，作为客户端追踪的数据源，Surface Tracking不能覆盖全部的用户场景。
作为一种纯粹的客户端解决方案，Surface Tracking对于服务器系统行为、系统逻辑方面是无法感知的。因此，Surface Tracking目前正致力于实现一种客户端与服务器端数据连接方案，以方便用户进行更全面的用户行为分析。此外，目前对于Native应用上的追踪数据并不全。
与此同时，作为典型站内解决方案，Surface Tracking缺少eBay的站外用户活动数据，如用户对于Google付费搜索的广告点击等。Surface Tracking目前也正在实现站内与站外数据互联的完整用户旅程。
虽然Surface Tracking目前仍处于发展阶段，但我们相信：随着解决方案的日益完善，它将会为eBay提供更多价值。千里之行，始于足下，它的无限潜力仍需我们不断探寻、突破！
★
今天是2021年最后一天
2021年即将结束
2022年马上就要到来
在这里，eBay愿您
新的一年
拥有“亿”倍快乐！
万事
如意
心想
事成
虎虎
生威
★
参考链接：
[1]https://www.rocketsource.co/blog/customer-journey-visualization/
[2]https://kylin.apache.org/cn/
[3]https://clickhouse.com/docs/zh/
往期推荐
eBay支付核心账务系统之直冲云霄
干货|Spark优化之高性能Range Join
ClickHouse|Operator跨k8s集群管理
点击阅读原文，一键投递
eBay大量优质职位虚席以待
我们的身边，还缺一个你