Beeswax Architecture / Life of a Bid

The following is the high level Beeswax architecture, with those components that are customizable and those that Beeswax maintains clearly indicated. Also indicated are parts of the system that are available for custom deployment.

Life of a Bid

Reading the diagram from left to right we can construct the “life of a bid” to give a quick explanation of the role of each component.

1. Auctions come in to the Beeswax “front end” which are normalized into a common OpenRTB 2.3 format. Beeswax augments the auction with common third-party data sources and can also lookup the customer’s unique user ID (cookie or synthetic ID) at this stage.
2. The normalized auctions can then be further augmented using a customer owned "Data Augmentor". This is typically a simple key-value lookup with a very short latency window (10ms). Use cases for first party data augmentation include custom geo databases, mapping of users to rich profiles, and scoring of inventory data.
3. The augmented auction is then passed to the Stinger bidder. The Stinger bidder has all active “ad groups” in memory, where each ad group represents a unique Line Item and Creative combination from the Buzz campaign management system.
4. Stinger filters the available ad groups on five criteria:
   -Does line item targeting match the incoming request?
   -Is the user over the desired frequency cap?
   -Does the line item have budget available?
   -Does the creative associated with the ad group match any creative attributes (filtering criteria) in the incoming request (e.g. creative size, VPAID enabled etc.)?
   -Should the line item be paced? This step is optional since pacing can be turned on or off at the line item level.
5. After filtering, Stinger passes the list of candidate ad groups to the customer’s owned Bidding Agent, which determines the bid prices and can also further select creatives and inject custom data into the creative markup via Dynamic Macros (Real-Time Custom Values). The bidding agent can have any number of ways of determining the bids, including pacing considerations, optimization, etc.
6. The bids are then returned to the front end server, sorted and de-duplicated, and the top bids are sent back to the exchange.

Data Flow

“Life of a Bid”, above, describes how bids are handled. But that’s just the start of our amazing RTB adventure! The next steps are what happens when we win an impression.

1. The rendered creative code passed back to the exchange include impression urls, click urls, and “event” urls for tracking things like video plays and completes. When these URLs are called, they are recorded by the Beeswax Event Server, which also sets cookies. The data from the Event Server is then streamed into multiple systems.
2. Any user data collected on the request is written to the cookie store. For example, the user may be placed in a segment based on their activity.
3. The budget server which is part of Stinger is updated with the win price.
4. Finally, the data is streamed into several data systems:
   -Data is fed into the Beeswax reporting system and aggregated hourly. The aggregated reports are made available through Buzz's Report Queue endpoint.
   -Raw data logs (auctions, bids, wins and conversions) can be delivered to a customer’s data store as described in Data Feeds.
   -Data is streamed into a customer specific Metamarkets dashboard for advanced analytics. This includes customer’s auctions, bids, and win data.