介绍Uber 的使命是重塑世界出行方式，让其变得更好，并通过其市场在全球范围内提供赚钱机会。让 Uber 品牌和市场更贴近人们的有效方法之一是投资付费营销策略。
要在市场中实现最佳平衡，就必须持续保持供需平衡。这需要创造一个消费者负担得起的环境，同时为赚钱者提供绝佳的赚钱机会。实现这一目标的一种方法是不断向市场引入新用户，这是一个持续的过程，包括在 Google、Meta、Apple 等各种营销平台上推广 Uber 的市场产品。
鉴于这些都是付费广告，我们的营销团队不断制定策略，以快速吸引更多用户加入平台。因此，及时从这些供应商那里收到信号对于我们有效改进方法至关重要。
这篇博文旨在探讨我们传统的采集系统 MaRS（营销报告服务）所遇到的限制和困难，该系统负责以固定间隔从外部广告合作伙伴收集广告信号。此外，我们将讨论如何通过技术进步增强我们的营销运营，并通过实施我们的新系统 Jupiter 实现可扩展性。
在本博客中，我们将付费营销描述为一个领域，而广告技术则代表同一领域内的系统。这些术语在本上下文中可以互换使用。
什么是绩效营销用户流？总体而言，后续顺序提供了完整的用户旅程的完整概述：从与广告互动开始，导航到 Uber 平台，最后完成转化。在我们的情境中，此操作对我们的业务很有价值，可能涉及在 Uber 上注册、通过 Uber Eats 下单或搭乘一趟车。
上述操作之后，将触发后续事件：
转化事件：当用户点击广告下载 Uber 应用时，标记特定于该广告的转化。这是与下载相关的一种转化事件。
消费事件：当用户查看广告时，表示向用户显示该广告的费用。
这些来自广告合作伙伴的支出事件需要被提取、处理并传输到下游。这样做是为了衡量和优化广告的效果。
图 1：Adtech 中的用户流。
用户流程示例步骤 1：用户点击合作伙伴页面上的 Uber 广告第 2 步：用户进入 Uber 应用 [转化事件]步骤 3：Adtech 系统从合作伙伴 [采集平台] 检索数据步骤 4：计算绩效指标（ROAS）步骤 5：优化引擎根据计算指标调整出价算法，从而增强出价算法。为什么及时摄入至关重要？及时准确地接收这些广告信号对于 Uber 的整体效果营销至关重要。即使是最轻微的延迟或对来自外部合作伙伴的及时广告信号的不准确处理，也会影响 Uber 在这些平台上投放广告的能力。因此，这可能会影响用户加入该平台的人数。
例如，在一次持续两天的宕机期间，我们无法从单个合作伙伴处提取数据，下游关键绩效指标 ( KPI )（特别是ROAS ）的创建被延迟。这种延迟导致竞价和优化系统中的机器学习算法错误地认为我们的广告表现不佳，从而导致广告支出停止。
结果，我们吸引新用户的能力受到影响，导致供需失衡。所有这些都是由于一次集成中断而发生的。
问题陈述由于 Uber 的业务遍及全球多个国家，我们与各种本地和全球广告合作伙伴或广告商合作开展付费营销活动。这导致我们整合了多个技术成熟度不同的不同技术系统，这些系统具有异构数据模式和格式、不同的传输协议以及数据新鲜度、谱系和完整性方面的差异。
广告技术行业正在经历一场重大变革，合作伙伴、移动测量平台 (MMP) 和外部广告技术平台正在从基于用户的广告跟踪过渡到一系列以隐私为中心的替代方案。这种转变催生了一个多元化的生态系统，合作伙伴之间的标准各不相同，带来了一些复杂性，例如数据模式频繁且不可预测的变化，这对营销和广告领域的传统假设提出了挑战。
由于其快速发展、规模以及所涉及数据集的多样性，这种复杂性给摄取系统带来了复合挑战。
以下是问题类别的细分以及提取团队之前投入的时间：
图 2：问题类别的划分。
可靠性从数据中可以明显看出，大部分时间都用于确保摄取系统的可靠性。造成这种情况的主要因素可归类为以下几类：
高延迟确保仓库中的数据及时可用对于减少平均检测时间 (MTTD) 异常和提高广告技术系统的整体性能至关重要。
由于数据不完整或数据延迟问题，营销人员很难区分季节性和实际广告效果。
没有部分数据可用随着营销数据随时间变化（例如超过 24 小时的支出数据和超过 28 天的转化数据），向下游系统提供部分数据变得非常重要。当合作伙伴在特定广告帐户级别出现问题时，这一点尤其重要。考虑到此类问题发生的频率，拥有此功能可以防止大量数据中断。
技术堆栈的增强旧系统 MaRS 的设计与旧广告格式/域紧密相关。对 MaRS 进行细微改进会导致工程周期延长或导致多项技术倒退。因此，在系统中容纳新用例会导致其变得笨重且难以管理。
此外，我们过时的基于 Python® 的技术堆栈导致速度变慢。利用这种情况，我们启动了升级。
第三方依赖项标准化在我们的全球和本地广告合作伙伴中，有些合作伙伴拥有先进的数据共享 API。然而，有些规模较小的合作伙伴由于成熟度有限，会通过电子邮件和 SFTP 等更手动的方式共享数据。因此，必须有一个系统能够处理来自这些不同来源的数据提取。
此外，所有合作伙伴之间的数据格式和服务水平协议 (SLA) 并不一致。这种缺乏标准化的状况给维护带来了挑战。因此，有必要在所有合作伙伴之间建立统一的数据标准，以便下游系统无缝使用。
速率限制引入新的合作伙伴数据、为现有合作伙伴引入新数据或遇到数据处理层中的错误，都需要采集系统导入多年的历史数据（回填）。此过程会产生很大的延迟，通常需要几天甚至几周的时间，而且由于合作伙伴速率限制，它还会阻碍日常管道的正常流动。
高维护维护特定于合作伙伴的 SDK/API 需要大量的维护费用，包括专门的人员分配，用于频繁的更新和错误修复，这最终降低了开发人员的工作效率。
规模上市时间极长由于积压了大量订单，我们只能处理 P0 级营销请求。积压主要源于新合作伙伴的入职通常需要数周时间，这阻碍了我们快速进行实验的能力。
例如，对于新兴合作伙伴，如果我们想在他们的平台上投放广告，我们必须等待几个月才能有资源完成入职流程。
高度依赖英语目前，任何合作伙伴的入职都严重依赖工程资源来编写用于 API 集成、数据转换、验证和测试的样板代码。这占用了入职流程的很大一部分。
解决方案策略最初，MaRS 的构建受到广告支出限制。随着 Uber 的全球扩张，本地和全球市场对个性化营销的需求日益增长。这就需要一个能够快速适应并融入特定细微差别的系统。
营销人员需要为测量渠道中的新合作伙伴提供更快捷的入职流程，以促进实验。他们还寻求更高频率的数据以加速结果，使他们能够相应地微调营销策略。
因此，我们开发了一个系统，通过采用高度松散耦合的架构来解决技术堆栈中的差距并满足未来的业务需求。
构建还是购买我们对外部第三方广告信号采集供应商进行了评估，而不是仅仅依赖内部解决方案。这主要是为了精简维护成本。
此外，营销团队还发出了强有力的业务指令，以获得更大的灵活性和对主要渠道（支出较高的顶级渠道）的控制力，例如 Google、Apple 和 Meta。
因此，我们选择了一种混合架构，允许结合外部供应商数据和来自合作伙伴的直接内部检索。在入职期间采用哪种方法的决定将取决于集成的业务关键性。
即插即用架构我们需要采集除广告技术内部现有数据类别之外的数据，以满足各种内部用例的需求，并且许多短期解决方案都是在孤岛中构建的。我们需要设想一个专门用于数据集的单一采集系统，并且我们需要轻松且尽量少用力地做到这一点。
我们为所有组件采用了即插即用架构，因此任何摄取都可以以最小的努力将其内部组件更改为其他东西。
领域无关的数据提取在我们致力于为各种数据创建一个包容性的摄取系统的过程中，我们需要分离特定领域的复杂性，并通过完全自助式、基于配置的架构实现可配置性。
可靠性由于我们的合作伙伴类型各异，因此我们的系统必须处理大量不成熟的数据格式、不一致的 SLA 和意外情况。这些广告信号的大小也存在很大差异，在特定情况下从几 GB 到几 TB 不等。Jupiter 经过专门设计，能够灵活地管理这些不同的情况。
建筑学
图 3：Jupiter 架构。
多供应商集成我们有各种业务场景需要将来自不同供应商的不同数据集集成到我们的平台中。这些集成需要考虑特定因素，例如数据格式、提取频率和数据成熟度级别。
因此，该平台的架构可以适应任何供应商的任何数据提取流程，从而以最少的配置实现无缝更改。
集成新的供应商涉及配置其特定的集成细节，之后平台的其余部分将与其无缝连接。
多源集成由于我们与众多供应商有互动，因此我们自然会遇到需要提取的各种数据源。为了解决这个问题，我们实现了可配置的数据源，并通过配置定义其特定属性。与供应商一样，这些数据源可以随时切换，且配置工作量极小。
目前，我们已与 Amazon Web Services、Google Drive、电子邮件、API 等来源集成。添加新来源涉及配置其集成详细信息，之后平台的其余部分将无缝适应它。
未转换的数据集为了满足我们的业务需求，我们发现有必要在不受合作伙伴能力限制的情况下，以更长的时间间隔采集数据。此外，我们迫切需要快速检测任何异常趋势 (MTTD)，这促使我们实施了数据复制流程，而无需应用任何转换。
这种方法使我们能够加快任何问题的调试并在必要时有效地补充数据。
配置驱动转换层由于我们管理的数据模式多种多样，因此定制转换对于标准化至关重要。
大部分样板代码都专用于此特定组件。为了实现完全自助式摄取系统，我们的目标是针对每个不同的用例配置此组件。
因此，我们为该转换层开发了一个内部库。该库整合了用户定义的转换，从行到行、列到列，到聚合转换。我们在内部系统和类似用例中利用了这个库，以实现可重用性。附件是示例配置。
自助摄取入门我们优化了平台的整个导入流程，将其转变为具有必要保障的自助服务模式。这一转变涉及实施基于触发器的机制，这些机制可在所有组件之间无缝运行，从获取源数据开始，启动转换，进行测试，在所有检查后进行验证和推广，以及触发验证后程序。以下是随附的高级流程，供参考。
图 4：流程图。
由于这些改进，该流程的责任已转移到运营团队，从而无需持续进行工程参与。
影响目前，旧系统已完全淘汰并过渡到 Jupiter。下面，我们概述了这两个系统的指标：
公制
改进 ％
入职时间 – 新摄入量
> 90%
入职时间 – 新供应商
> 75％
入职时间 – 新资源
> 75％
数据采集频率
> 75％
数据采集延迟
> 70％
结论我们概述了与广告技术领域网络相关的困难和潜在优势，以及从中获取可靠数据并实施复杂转换以满足各种业务需求的过程。目前，我们已经淘汰了以前的系统，并将所有用例过渡到新平台，并在可行的情况下纳入新的数据增强功能。
我们已成功实现主要目标，即通过为利益相关者提供自助服务的方式加速新合作伙伴的入职流程并确保数据可靠性。但是，仍有更复杂的用例需要解决。例如，到目前为止，我们专注于下载单个报告结构并应用转换。我们的下一个挑战是下载多个结构，合并它们，并通过统一的工作流程提供一个或多个数据集。下一个重要步骤是扩展此平台，使其超越其当前特定用例支持，并将其转换为多租户系统。
致谢我们特别感谢核心工程和产品团队，其中包括 Prathamesh Gabale（工程经理）、Akshit Jain（软件工程师）、Sarthak Chhillar（软件工程师）、Saurav Pradhan（软件工程师）和 Piyush Choudhary（产品经理），他们在确保这次旅程的成功方面发挥了关键作用。
我们还要向 Devesh Kumar、Diwakar Bhatia 和 Vijayasaradhi Uppaluri 表示感谢，感谢他们的宝贵反馈和坚定支持。
Amazon Web Services、AWS、Powered by AWS 徽标和 S3 是 Amazon.com, Inc. 或其附属公司的商标。
作者:
Barani Subramanian
Barani serves as the Technical Lead for the ad tech ingestion platform. She established the groundwork for the existing ingestion platform and devised a comprehensive long-term plan. Her main role involves comprehending business requirements and addressing stakeholder challenges, translating them into a tangible roadmap for the team to implement.
Manaswini Lakshmikanth Sugatoor
Manaswini served as the former Engineering Lead for the ad tech systems. She oversaw various sub-teams within the ad tech domain, including Ingestion, Sharing, Mobile, and Reliability Platforms. She spearheaded a transformative shift in the ad tech function, transitioning from a build-per-request model to a self-serve platform paradigm.
出处:https://www.uber.com/en-JP/blog/jupiter-batch-ingestion-platform/
