Skip to main content

AWS Solutions Library

Guidance for Capturing Advertising OpenRTB (Real-Time Bidding) Events for Analytics on AWS

Overview

This Guidance helps ad-tech companies capture Open Real-Time Bidding (OpenRTB) events and establish a foundation for near real-time and batch analytics. During a programmatic advertising transaction, a demand-side platform (DSP) service generates a series of events. Capturing these events helps ad-tech companies keep their budgets updated and understand signals for optimizing the bid response. By tracking events, such as a successful win bid, advertisers can better measure the effectiveness of their campaigns. They can also analyze these events to make informed decisions for future bids. 


For an overview of RTB and a description of the events that advertisers generate to win a bid request, visit Guidance for Building a Real Time Bidder for Advertising on AWS.

How it works

This architecture enables you to capture OpenRTB bid events for both near real-time and batch analytics.

Download the architecture diagram

Well-Architected Pillars

The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.

The bidder application uses a microservices approach, meaning that the bid request-response event capture and post bid events capture services are decoupled from the bidder service. This enables independent release cycles and scaling mechanisms based on the transactions-per-second (TPS) requirements. For example, the post bid event capture TPS is multiple orders of magnitude less than other components and can be configured independently.

Read the Operational Excellence whitepaper

Data at rest in the Amazon S3 bucket is encrypted with AWS KMS keys. Data in transit is encrypted and transferred over HTTPS. The Amazon EKS clusters run in a VPC, and the connectivity between Amazon EKS and Kinesis is routed through a secure VPC endpoint. 

Read the Security whitepaper

The bid request-response and post bid event capture services are decoupled from the code bidder application. The bidder application needs to implement throttling, retry, and backpressure accordingly. Additionally, the architecture promotes a stateless implementation using containers. The KPL implements throttling, retry, and asynchronous publish of events.

Read the Reliability whitepaper

All components of this Guidance are co-located in a single Region and Availability Zone, and you can use automated deployments to deploy the architecture into any Region that meets your data residency and latency requirements.

Read the Performance Efficiency whitepaper

With serverless services, you pay only for the resources you consume. The Amazon EKS cluster is the only component in this architecture that does not use serverless services. To meet the high TPS workload, we recommend a hybrid consumption model for the Amazon EKS cluster. Amazon Elastic Compute Cloud (Amazon EC2) Spot instances provide up to a 90% discount compared to on-demand instances and can support additional bursts in workloads. Additionally, the services in the bidder application run within an Amazon VPC and are deployed in a single Availability Zone to minimize data transfer costs. 

Read the Cost Optimization whitepaper

With Amazon EKS, you can implement scalability and elasticity. By decoupling components through microservices, you can allocate the right instance type and the right number of instances to dynamic workloads, helping you to not overprovision resources.  

Read the Sustainability whitepaper

Related Content

Guidance for Building a Real Time Bidder for Advertising on AWS

This Guidance helps you assess ad opportunities at scale using real time bidding (RTB). It shows how demand side platforms (DSPs) bid on ad space available from supply side platforms (SSPs).
Learn more

Disclaimer

The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.