1.1. 在构建洞察的过程中，一项越来越重要的工作是收集、分析和聚合行为数据，即点击流数据

1.2. 点击流是代表用户在应用程序或网站中操作的事件序列，包括点击、浏览和相关的上下文，比如页面加载时间、访问者使用的浏览器或设备等

1.3. 点击流数据对于客户流量分析、营销活动管理、市场细分、销售漏斗分析等业务流程洞察至关重要

1.4. 在分析产品体验、了解用户意图以及针对不同客户群体提供个性化产品体验方面也发挥着关键作用

1.5. A/B测试利用点击流数据流来计算业务提升或获取用户对产品或网站新变化的反馈

1.6. 关键痛点

1.6.1. 数据用户需要根据自己的分析需求不断在产品和网页中添加新的跟踪信标

1.6.1.1. 添加这些信标不是自助式的，需要专业知识来确定在哪里添加监测信标（instrumentation beacon）信息、使用什么监测插件库，以及使用什么事件分类法

1.6.2. 点击流数据需要经过聚合、过滤和丰富，然后才能被用于产生洞察

1.6.3. 点击流分析需要访问交易历史以及实时点击流数据

1.7. 理想的情况是，自助式点击流服务能够简化SaaS应用程序以及营销Web页面中编辑监测信标的工作

1.7.1. 该服务可以自动完成事件的聚合、过滤、ID拼接和上下文丰富

1.7.2. 根据用例的需要，数据用户可以以批处理和流处理的方式使用数据事件

1.7.3. 通过服务自动化，可以改进数据事件的收集、丰富和使用，从整体上减少洞察耗时

1.8. 点击流数据代表在线实验、营销等多项与客户行为相关的洞察的关键数据集

1.8.1. 对于大多数SaaS企业，由于它们拥有数以百万计的客户和细粒度的监测信标，所以自动获取和分析点击流数据是一项关键能力

2.1. 不同的优化目标：增加销售额、提高客户留存率和扩大品牌影响力

2.2. 从洞察中，我们可以获知在线广告的运行及其对目标函数的影响—点击量、浏览量、浏览时间、广告成本/转化率等之间的相关性

2.3. 网络流量分析提供了关于带来流量的来源、热门关键词、不同流量来源访客的转化率、与活动相关联的群组分析等方面的洞察

2.4. 各种岗位的用户使用

2.4.1. 市场营销人员旨在通过不同类型的营销活动来提高品牌影响力、盈利和用户留存率

2.4.2. 数据分析师旨在利用点击流洞察来发现客户细分、需要改进的产品流程等

2.4.3. 应用开发人员使用点击流分析为产品建立个性化推荐，以更好地满足不同客户群体的需求

2.4.4. 实验人员使用点击流指标来评估A/B方案的影响

2.4.5. 数据科学家使用标准化的点击流事件进行预测建模，并采用生产环境的特征

2.4.6. 产品经理对有关产品功能性能的实时数据感兴趣

2.5. 关键的功能模块

2.5.1. 在产品和Web页面中添加跟踪代码，以捕获客户的点击和浏览

2.5.2. 从信标收集信息数据，然后对这些信息进行聚合、关联、清洗和丰富

2.5.3. 结合数据湖中的实时点击流事件和历史数据来生成洞察

3.1. 包括管理监测信息、丰富收集的事件数据和分析数据消耗的时间

3.2. 监测管理

3.2.1. 生成点击流事件需要在产品或Web页面中使用监测信标

3.2.2. 挑战

3.2.2.1. 有多个库的克隆和收集框架，并且框架可能不可靠

3.2.2.2. 信标必须不断更新以适应第三方集成，包括电子邮件营销工具、实验工具、活动工具等

3.2.2.3. 由于跟踪模式的事件和属性标准不一致，导致出现脏数据

3.3. 丰富事件

3.3.1. 监测信标收集到的事件数据需要进行清洗和丰富

3.3.2. 关键步骤

3.3.2.1. 机器人过滤

3.3.2.1.1. 互联网上有很多机器人正在抓取网页

3.3.2.1.1.1. 它们扭曲了与客户互动和每个访问者转换相关的关键指标

3.3.2.1.2. 三分之一或更多的网站流量是由机器人引起的

3.3.2.1.3. 挑战是准确识别与机器人相关的流量

3.3.2.1.4. 当前的方法主要是基于规则来分析访问模式细节

3.3.2.2. 会话处理

3.3.2.2.1. 会话是两个或多个设备或用户之间短暂的交互

3.3.2.2.2. 会话的开始和结束很难确定，通常是由一个没有相关事件的时间段定义的

3.3.2.2.3. 当一个新的事件在指定的延迟时间段（通过迭代分析确定）过去后没有事件到达时，一个会话开始

3.3.2.2.4. 当一个新的事件在指定的延迟时间内未到达时，会话结束

3.3.2.3. 丰富上下文

3.3.2.3.1. 为了有效地提取洞察，点击流事件被丰富了额外的上下文信息

3.3.3. 大规模丰富数据极具挑战性，特别是事件排序、聚合、过滤和丰富

3.3.3.1. 为了洞察分析，可能需要实时处理数百万个事件

3.4. 构建洞察

3.4.1. 基于实时仪表盘，我们可以实现E2E客户旅程、客户360画像、个性化等场景的可视化

3.4.2. 实时跟踪用户行为可以实现更新推荐、执行高级A/B测试以及向客户推送通知

3.4.3. 构建洞察需要关联实时事件流和批处理数据，并以亚秒级效率处理和传递事件，实现每秒处理数百万个事件

3.4.4. 对于全球化的企业来说，处理能力需要在全球部署

4.1. 监测需求清单

4.1.1. 事件中捕获的属性

4.1.1.1. 定义事件的属性（即谁、什么、在哪里和域详细信息），以及事件的类型（即页面浏览、点击等）

4.1.2. 收集客户端事件

4.1.2.1. 整理移动客户端、桌面应用程序和Web应用程序的清单

4.1.3. 收集第三方源数据

4.1.3.1. 确定是否需要汇总来自第三方合作商的日志数据和统计数据

4.1.4. 收集服务器端事件

4.1.4.1. 确定是否需要从后端应用程序服务器捕获事件

4.1.5. 速度和容量

4.1.5.1. 获得信标数量、事件生成速率和事件保存时间范围的大致估计量

4.2. 数据丰富需求清单

4.2.1. 根据用例的要求，通常会对原始点击流数据进行丰富

4.2.2. 丰富包括清洗不需要的事件、加入额外的信息源、在不同的时间粒度上进行汇总以及确保数据隐私

4.2.3. 机器人过滤

4.2.3.1. 从真实的用户活动中过滤机器人流量，特别是针对用例预测用户对产品变化的参与度

4.2.4. 用户代理解析

4.2.4.1. 额外信息

4.2.4.2. 如浏览器类型，点击流事件来自移动端程序还是桌面客户端程序

4.2.5. IP地理信息转换（IP2Geo）

4.2.5.1. 跟踪地理位置，以便更好地了解不同地域的产品使用差异

4.2.6. 会话处理

4.2.6.1. 用于分析指定会话期间、跨会话期间的用户活动用例

4.2.7. 不同时间范围内事件数据的汇总

4.2.7.1. 适用于在较长时间段内，对单个事件细节和一般用户活动趋势的需求不同的用例

4.2.8. 隐私信息过滤

4.2.8.1. 适用于为了用户隐私合规而删除IP地址这样的用例

4.3. 重要的是要了解用于识别用户的不同选项，包括账户登录（一小部分用户）、cookie标识（不适用于跨设备行为，并且会被删除、终结和阻塞）、设备指纹（识别用户的一种概率方法）和IP匹配（不适用动态IP和共享IP场景）

5.1. 监测模式

5.1.1. 简化了在产品和营销网页中管理跟踪信标

5.1.2. 监测模式简化了整个产品和Web页面的监测信标的管理，它使得数据用户可以自助更新、添加和查询可用的信标

5.1.3. 传统上，信标被实现为与页面一起加载的JavaScript跟踪器

5.1.4. 该信标向电子邮件活动管理系统、实验平台、Web分析服务等提供商发送JSON POST请求

5.1.5. 收集事件

5.1.5.1. 事件由Web页面、移动应用程序、桌面应用程序和后端服务器生成

5.1.5.2. 来自第三方服务器的事件会使用webhook收集

5.1.6. 验证事件

5.1.6.1. 事件在终端对模式属性和数据进行验证，不符合要求的事件会触发规则，无法通过验证的事件会被阻止访问

5.1.6.2. 验证事件的质量有助于创建主动检测和反馈循环

5.1.7. 转发事件

5.1.7.1. 事件被转发到多个供应商，并且无须在站点上加载多个标识

5.1.7.2. 这种方法的优点是可以加载更少的信标，同时不会使跟踪代码复杂化

5.1.8. 开源实现有Segment和RudderStack

5.1.8.1. Segment使用发布者-订阅者模型实现点击流事件的代理

5.1.8.2. 事件被添加到消息总线（如Kafka）中

5.2. 数据丰富模式

5.2.1. 自动清理和丰富点击流事件

5.2.2. 专注于丰富点击流数据以提取洞察

5.2.3. 丰富模式会对原始事件进行分析、过滤和增强

5.2.4. 丰富模式的关键模块

5.2.4.1. 机器人过滤模式

5.2.4.1.1. 定义了区分正常用户和机器人的规则

5.2.4.1.2. 规则基于对多个模式的详细分析，并使用Spark或R包实现

5.2.4.1.3. 关闭图片功能

5.2.4.1.4. referrer为空

5.2.4.1.5. 页面点击速率过快

5.2.4.1.6. 深度优先或广度优先地搜索站点

5.2.4.1.7. 流量来自云服务提供商

5.2.4.1.8. 不接受cookie（使得每次请求都当作全新用户）

5.2.4.1.9. 经常从Linux或未知操作系统发起请求

5.2.4.1.10. 使用带有过时或未知浏览器版本的欺骗用户代理字符串

5.2.4.1.11. 灵活组合这些规则通常可以较好地预测机器人的流量

5.2.4.1.12. 机器人过滤分析通常是通过IP地址、用户代理和操作系统（而不是访问者ID）进行的

5.2.4.1.13. 没有cookie，所以每次点击，机器人都会产生一个全新的访客

5.2.4.1.13.1. 机器人在访问每个页面时提供了特定的访问时间戳

5.2.4.1.13.2. 对这些特定的访问时间戳进行线性回归分析时，它的R平方值非常接近于1，这是识别机器人流量的重要指标

5.2.4.2. 会话处理模式

5.2.4.2.1. 是基于规则的

5.2.4.2.2. 常见的方法是延迟一段时间（通常为30分钟），在此期间没有事件到达的话，会当作一次会话结束

5.2.4.2.3. AWS Kinesis提供了三种类型的窗口化查询函数：滑动窗口（sliding window）、滚动窗口（tumbling window）和交叉窗口（stagger window）

5.2.4.2.4. 对于会话模式来说，交叉窗口是一个很好的选择，因为它们会在符合分区键条件的第一个事件到达时打开

5.2.4.2.5. 交叉窗口不依赖于事件在流中到达的顺序，而是依赖于它们生成的时间

5.2.4.3. 用户上下文丰富模式

5.2.4.3.1. 为了有效地提取洞察，点击流事件要用额外的上下文信息来丰富

5.2.4.3.2. 该模式的一个开源实现是Divolte Collector，它收集信标信息并丰富事件信息

5.2.4.3.3. 所产生的点击事件被发布到Kafka队列中，可以直接用于生成洞察，而不需要任何ETL或日志文件解析

5.3. 消费模式

5.3.1. 自动处理事件，为多个用例生成实时洞察

5.3.2. 消费模式专注于点击流数据的使用，以支持与营销活动如何执行相关的机器学习模型和实时仪表盘

5.3.3. 实验如何影响用户留存、增长和提升销售

5.3.4. 该模式结合了批处理指标和流式数据，这样的处理称为复杂事件处理（CEP）

5.3.4.1. 使用消息处理框架

5.3.4.1.1. Apache NiFi和Pulsar，它们允许处理按时间戳标识的单个事件

5.3.4.1.2. Pulsar是一个建立在分层架构上的强大的发布-订阅模式，它开箱即用，具有地理复制、多租户、统一队列和流式处理的特点

5.3.4.2. 使用时间序列数据存储作为服务层

5.3.4.2.1. Apache Druid、Pinot和Uber的M3，它们能够处理记录更新和批量加载

5.3.4.2.2. Druid实现了面向列的存储，每个列单独存储，这样可以只读取特定查询所需的列，支持快速扫描、排序和分组操作

5.3.4.2.3. Druid为字符串值创建倒排索引，以实现快速搜索和过滤，并优雅地处理不断发展的模式和嵌套数据

5.3.5. CEP模式涉及使用窗口函数在时间范围内或跨批次的事件中对模式进行通用搜索和关联