Auto Trader的CDP是一个专门构建的实时数据库，它从我们的行为数据平台Snowplow获取跟踪事件：每次客户与 Auto Trader 网站或我们的本机应用程序交互时，例如查看汽车广告、访问主页、搜索车辆以及向零售商发送请求，我们都可以通过向 Snowplow 触发事件来跟踪这些。
事件包含身份信息，例如客户同意跟踪时的唯一用户 ID 和客户登录时的 Auto Trader 帐户 ID。事件还包含有关所采取操作的信息。例如，如果您在网站上查看整页广告，事件将包含有关该广告的信息，例如车辆制造商、型号、车龄、里程、燃料类型等。
{ |
这些 Snowplow 事件流入GCP Pub/Sub主题。从那里，它们被中继到我们的 Kafka 集群中，以供CDP使用。
进入CDP的事件数量很大（约 1,000 / 秒），跟上所有这些数据需要大量工程。
事件消费者服务是使用 Java (Springboot) 编写的 Kafka 消费者。它反序列化来自用户行为主题的事件，然后进入一个包含三个阶段的处理管道：
- 识别用户阶段使用附加到事件的标识符，然后确定我们之前是否见过该客户；如果是，则返回他们的客户资料 ID，如果不是，则创建一个新的资料。
- 追加事件阶段将事件添加到客户最近事件的时间轴上。
- 更新配置文件阶段采用最近 10 天的事件并计算客户所属的属性和细分。
为了决定什么时候将客户添加到细分市场，我们会查看他们最近的浏览活动：
以ELECTRIC细分市场为例，我们希望该细分市场的客户比普通客户更有可能查看EV（电动汽车）。因此，我们根据我们认为客户查看EV的可能性将客户分配到细分市场。
我们可以使用客户浏览历史的任何方面来决定他们是否有可能查看EV，例如他们是否阅读过有关 EV 的内容，或者他们是否参加过我们的EV赠品竞赛。然而，最具预测性的特征仅仅是他们过去是否看过电动汽车。因此，我们使用一个简单的模型，该模型基于已查看的具有电动燃料类型的车辆的比例。
一旦我们知道某人查看EV的可能性有多大，我们就需要一个阈值来决定何时将他们添加到细分中。
这是一个经典的精度/召回权衡：
如果我们使用较低的阈值，更多的客户将最终进入该细分市场（导致更高的召回率），但与该细分市场匹配的车辆比例将会下降（导致较低的精度）。为了在缩小搜索结果时保持简单，我们选择 50% 的阈值，因为这意味着客户最多可以属于一种燃料类型细分：
2 Petrol views, 3 Electric views -> ELECTRIC segment applied |
我们将相同的方法应用于其他燃料类型细分市场，以及车身类型细分市场。
现在客户关于燃料类型的偏好被记录在CDP中，转换成细分，并根据他们的唯一用户 ID 存储在客户的个人资料中，我们需要在他们浏览网站时获取此信息，以操纵他们的搜索体验。
在客户登陆 Auto Trader 之前，他们的请求会通过 Consumer Gateway，这是一个用于管理客户流量的 Springboot Zuul应用程序。在这个应用程序中，我们可以创建一个自定义 Zuul 过滤器来管理获取客户资料的请求。这包括仅在客户访问网站的某些部分时获取它 - 更具体地说，每当他们导航到搜索列表页面时，因为这会减轻 CDP的负载. 从CDP获取配置文件后，使用 Snowplow cookie 中的唯一用户 ID，将段枚举连接起来并作为字符串插入到请求标头中。这个标头现在已经准备好转发给为汽车交易网站提供动力的应用程序系列，即Sauron。
Sauron查询了无数的域名网络服务，以填充客户在Auto Trader网站上看到的和互动的内容，包括点击取货地点、财务选项、部分交换估值等等。
我们对为客户提供车辆搜索结果的服务特别感兴趣，即车辆列表服务（VLS）：
VLS提供自然位置（不受任何Auto Trader产品影响的位置）和突出位置的列表 - 包括特色列表。
这些数据是通过查询Search One获取的，Search One是另一个负责提供广告信息的内部服务。
VLS的做法是根据客户使用的过滤器和列表类型建立一个查询：
例如，如果是精选列表的位置，查询会要求从PPC库中获取广告。我们可以使用请求头将细分市场再次传递给VLS，根据所存在的细分市场，VLS可以将其添加到Search One请求查询中。
举个例子，如果客户是在SUV细分市场，我们可以操纵查询，使其带回一个SUV车身类型的广告，因为我们可以推断出客户对SUV感兴趣。只有在没有使用车身类型过滤器的情况下才会应用细分市场（因为我们只想在没有明确知道客户偏好的情况下使用细分市场）。
更多点击标题