在现实世界中实施家居广告技术解决方案的方法和挑战

[ashammi238]

在本系列的前几篇文章（此处和此处）中，我们讨论了家庭管理，它如何在向无 Cookie 环境的持续过渡期间充当有效的临时解决方案，以及实施过程中面临的挑战。在本文中，我们将深入探讨在特定现实场景中实施家庭管理解决方案的技术复杂性，以及我们在获得良好实施过程中遇到的挑战。

首先，让我们定义家庭流量。家庭流量是指被识别为属于真实家庭并在技术上丰富了额外数据的无 Cookie 请求。在本例中，我们在用户个人资料中定义了一个 BuyerUID 字段，其中填充了用户 Cookie 映射列表。

由于我们计划将无 Cookie 流量转换为带 Cookie 流量，因此我 赌博数据库 们必须使用之前收集的 Cookie 映射。这些映射适用于来自同一 IP 地址且启用了 Cookie 的设备上的流量。

从原则上来说，使用这些现有映射相对简单。在处理带有家庭 IP 地址的广告请求时，我们只需加载与该 IP 地址关联的相应 cookie 映射。此操作将流量从无 cookie 转换为有 cookie。当然，实际情况要复杂一些。例如，我们需要确保 IP 地址是家庭的有效代理。总的来说，我们发现涉及数据准备的初始步骤至关重要且不简单，值得仔细检查。

为了准备家庭数据以集成到 OpenRTB 管道中，我们遵循以下步骤：

步骤 1 - 识别家庭流量
第一步是确定流量是否应归类为家庭流量。我们使用了第三方服务Tapad，它可以通过返回布尔标志来识别当前广告请求中的 IP 地址是否属于家庭。为了确保系统效率，我们基于 Hadoop 分布式文件系统 (HDFS) 实现了一个缓存层，该层存储了有关之前看到的 IP 地址是否为家庭的信息。为了使这些信息保持最新，我们通过计划作业实现了日期刷新。

第 2 步 - 为家庭 IP 地址选择合适的 Cookie 映射
鉴于我们的系统已经为所有需求合作伙伴维护了 cookie 映射，因此我们提供的服务可以同时访问 IP 地址和 cookie。对于家庭 IP 地址，我们将一个 cookie 与相应的 IP 地址相关联。由于多个 cookie 可能与一个 IP 地址相关联，因此我们应用特殊逻辑根据启发式标准选择最合适的 cookie：我们避免选择非常旧的 cookie（因为可能过期）或最新的 cookie（因为用户个人资料可能不完全提供信息，或者映射可能尚未与需求合作伙伴同步）。

步骤 3 - 优化家庭地图访问，提高绩效
接下来，我们将 IP 地址映射到 Cookie。广告请求通常包含有效负载，其中包含 IP 地址和 Cookie 对的列表。在 OpenRTB 中，快速响应至关重要，通常要在 350 毫秒的极短时间内做出响应。为了满足这一要求，我们缓存了此管道期间使用的所有数据。但是，用户映射会生成数 TB 的数据，因此将所有内容都存储在内存中是不切实际的。因此，我们应用程序中之前收集的所有 Cookie 映射都存储在 Aerospike 数据库的一个命名空间下，该数据库因其快速的数据访问能力而被选中。当调用家庭 API 进行 Cookie 流量时，应用程序使用该请求在 Cookie 命名空间中查找适当的 Cookie 映射，然后将它们复制到单独的家庭命名空间，并使用请求中的 IP 地址作为键。因此，对于所有未来的无 Cookie 流量，我们将能够通过 IP 地址高效地访问 Cookie 映射并满足性能要求。

步骤 4 - 实现旧家庭地图绘制
在步骤 1 中，我们确定了特定 IP 地址是否属于某个家庭。但是，这些信息总体上不如人们所希望的那样静态，并且可能会带来未来的问题。例如，ISP 可能会频繁地将之前识别和缓存的家庭 IP 地址重新分配给办公室或其他公共场所。幸运的是，Tapad 服务可能会返回之前标记为家庭但不再属于家庭的 IP 地址。我们使用此功能来处理可能过时的信息。例如，在识别过程中，如果特定 IP 地址与某个家庭相关联，我们可能会遇到表明该 IP 地址以前与某个家庭有关联但目前已断开连接的数据。在这种情况下，我们会立即从 Aerospike 数据库中删除与此 IP 地址关联的 cookie 映射。