To continue, the book continues once more. Last time we looked at how we got the ads, how we polished them, and how we went through a series of procedures to determine which ads were eligible to bid on. In this article, we’ll continue to look at steps 4 through 8, looking at how to get different AD offers, how to control the pace of delivery, and how to identify which ads ultimately get shown.

Step 4: Drop control

Controlling the pace of delivery is one of the most important steps for any advertising service. Advertisers want to spread their campaigns evenly throughout the day and want to reach as large and diverse an audience as possible.

We use Akka Actor to maintain spending and budget information for each campaign. Considering that the cost is a monotonically increasing operation and that the ultimate consistency is acceptable for this kind of information in our business, the conflict-free replicable Data structure (CRDT) in Akka Distributed Data, Conflict-free Replicated Data Type) becomes a good choice for storing overhead information, even for scenarios across data centers. After verifying that the campaign did not exceed its budget, we also loaded the cost forecast data that Spark had calculated offline based on its past history. In the Graph implementation of Pacing, we used a very simple control theory derivative technique to decide whether an AD should participate in the auction.

The main purpose of the forecast data mentioned above is to control how traffic is distributed during the day. The forecast data is generated based on all the major targets we know, based on relevant advertising domain knowledge, combined with traffic patterns and the number of AD spots we can deliver. For example, the traffic pattern of our App running on a game console is completely different from that running on a phone.

Step 5: Collect bids

Some of Tubi’s advertising space is sold directly by our own sales team (they are also hiring!). , some through programmatic purchase and third-party demand side platform (DSP) integration, sales. These integration with the third party advertising platform, naturally involves the call to the third party. These calls certainly involve sending network requests and parsing the various forms of response they return.

Encapsulating these requests into their own Akka-stream allows us to once again write common graphs to smooth out complex logic such as asynchronous network calls, concurrency control, error handling, flow limiting, fuses, and so on. We can then focus on the specific business logic, making sure the code integrates with the quirks of third-party interfaces, and testing the implementation differences that result from different people’s understanding of the IAB standard. Similarly, because this part of the network request Flow has a strict concurrency limit, the unexpected performance of one third party does not affect the normal functioning of the rest of our advertising system.

Step 6: transcoding advertising video

When we’ve collected all the bids, we check to see if we’ve transcoded the ads for those bids. If there is no transcoding, we will perform a transcoding operation. The reason for transcoding is mainly the following considerations:

  1. As a video company, we fine-tune video playback, so we want ads to play smoothly in all places where Tubi App runs;

  2. Some ads may be too loud, so we adjust them accordingly so that they are not deafening to users.

  3. We also want the advertising rating to match the content rating. For example, tobacco advertising should not appear in PG-13 content.

  4. For programmatic purchases, such as from a demand-side platform (DSP), we want to be able to identify their brand. On the one hand for reporting use, on the other hand for better control of the same advertising frequency.

Each of these steps has its own separate services and associated machine learning models, which we will share in separate articles. Our advertising platform, like all other Tubi services, communicates with them via gRPC, and 99% of requests have slAs below 10ms.

Step 7: Bid

This brings us to one of the most important steps (or none) of our advertising requests: bidding. We had several bids waiting to be processed, possibly from multiple partners and internal campaigns, and what we were trying to do was quickly determine which bids should fill our one to five spots. In contrast to the onerous network I/O, caching, concurrency and the like of the rest of the AD request, bidding is a 100% CPU operation to solve a complex conditional optimization problem. Here is a simple example: here is an N * K matrix, representing n bids (rows) for k AD Spaces (columns) in a single AD request.

The value of each grid in the matrix can be 1 or 0, indicating whether a bid is selected for a particular advertising space. This allows the bidding limit to be represented by some simple addition. For example, if we need to limit an advertiser’s multiple bids to one win, we can limit the sum of all the rows that he bids to no more than 1. Similarly, to ensure that there is only one winning bid per AD space, we limit the sum of the columns to less than or equal to 1. More things like independent bidding segregation, user experience guarantees for certain AD competitions, and so on can be set in this way. A parser diligently optimizes our target function according to the limits we set. The objective function, however, is a linear programming problem for maximizing revenue, with certain guaranteed constraints.

Step 8: Render the result

In the final step, we render the winning bids into ads that are appropriate for each platform. For example, some of our platforms like to use the VAST format, and some of our platforms like to use JSON format. By using akka-HTTP’s rendering mechanism, we can customize any template we need.

Step 9: Join Tubi

In contrast to comprador solutions, Tubi’s own AD tech stack is one of many examples of how we use our own technology to make great products. If you are interested in distributed systems and Scala responsive programming, please join us! In addition to advertising technology, we also use the same technology to build our machine learning, big data and other platforms.

Marios Assiotis, Tubi CTO, click “Read The original article” for English version

Translator: Yingyu Cheng, Tubi Senior Scala Engineer

Tubi pats you and invites you **** to join our family!

Positions currently open:

  • Senior Data Development Engineer

  • Senior Machine learning Engineer

  • Senior Back-end Engineer – Elixir direction

  • Senior Backend Engineer – Scala direction

  • Senior Android Engineer

  • Senior iOS Engineer

  • Senior Front End Engineer

  • Senior Front End Engineer – Multimedia direction

  • Senior QA Engineer

For more details, please click on our official website: chinateam.tubi. TV /, or search “Bitu Technology” on Boss Zhipin to visit our recruitment homepage.