Our customer wanted us to make the Ad Exchange with a smart query routing, which will be able to provide a good buyout rate. It’s obvious, that the reduction of ‘losing’ requests leads to a decrease in operating costs. This makes your offer more attractive for SSPs (supply-side platforms) and DSPs (demand-side platforms) against the competing Ad Exchange solutions. Thus, we have created an advanced solution that solves this problem. The essence of this approach is — selective SSP requests to the DSP.
Introduction
Inside the programmatic advertising paradigm, Ad Exchange is a specific add-on for Real-Time Bidding (RTB) mechanism. RTB provides the sale of ads on websites in real-time and shows ads to the target audience. Ad Exchange links a large number of supply-side platforms and demand-side platforms, which do not have direct integration between themselves, plus – resale advertising traffic between them.
Nowadays Ad Exchange solutions work according to different principles: some offer a higher margin, some less, some trade unique inventory, others focus on the mass market. This market is quite young and develops actively, so there are no proven business models: everything is built on hypotheses and experiments.
Motivation
Most of the competitors work in a simple way: they receive a request from one of several SSPs with which they have an agreement and forward the request to all integrated DSPs in anticipation of a better bet. Ad Exchange revenue is the difference between the purchase price and the sale of advertising inventory from SSP and DSP minus operating costs. We’ve proposed the solution that radically optimizes them.
For the successful Ad Exchange solution, It’s crucial not to send “losing” requests. Reduction of such requests leads to a decrease in operating costs. Due to this, you can reduce the commission of the stock exchange, without losing income. This makes your offer more attractive for supply-side platforms and demand-side platforms against the competing Ad Exchange solutions. Moreover, a large pool of partners will give income and stability in the market.
Solution structure
In accordance with the task specification basic Ad Exchange solution must:
- accept requests from the SSP;
- conduct an auction (sends requests to several DSPs, compares the prices offered, identifies the winner);
- coordinate the victory with SSP (informs the winner’s price minus his commission, waits for a response with the total ad price);
- complete the transaction (informs the desired DSP about his victory, conducts user traffic);
- all process must fit the given timeout limits.
The above functionality was constructed in three main component parts:
- Ad Exchange itself — is used for connection between traffic providers and consumers
- The database — is used to save aggregated data that will help to make smart traffic routing decisions.
- Smart traffic routing subsystem — allows to reduce the load, meet the customer-defined timeouts and perform smart routing.
Ad Exchange subsystem
The solution is based on the “Chain of responsibility” template, which allows flexible request routing, easy handlers utilization and other services.
Ad Exchange solution architecture
Software components were deployed on four physical servers and were built on Postgres and Hadoop. All these choices were made to make the whole solution horizontally scalable. In this context, that would mean better at the breadth of load bearing ( traffic breadth from additional SSP/DSP integrations).
Ad Exchange itself was written in Java – at the same time, we did not use any frameworks be able to maintain the system load (low-level programming). In order to meet the SSP timeout, we adjusted the garbage collector (G1) parameters and worked out the synchronous scheme of requests processing in the context of high load. To implement that, we used an HTTP client that does not block the stream and keep-alive HTTP protocol extension that allows you to send several requests within single TCP-connection.
The open source Apache Kafka was used as a message-broker. It can be integrated into the “one subscriber – many publishers” model. The subsystem also has the protection from messages doubling.
The designed monitoring system, which is part of the Ad Exchange, controls the growing load. Nginx is used as hardware balancer.
The database subsystem
The database is the crucial part of our Ad Exchange which provides the data support for analytical decisions. The system stores information about bids, bidders and deals made.
Data is stored only for the amount of time in which it can be useful. Thus, the storage has a multi-layered architecture:
- all auction data is stored for a week, then it is erased;
- on the basis of auction data, higher-level intermediate aggregates are built. They are stored for several months;
- on the basis of intermediate aggregates, the final assemblies are made. They are used in long-term analytics and for reconciliations with supply-side platforms and demand-side platforms. These aggregates also contain data about how many bets were made and how much money the exchange will pay SSP or expects to receive from the DSP. Final aggregates are stored for the duration of the Ad Exchange.
Smart traffic routing subsystem
The key element of the system, which allowed to reduce the load and meet the customer-defined timeouts, is traffic routing and filtering. Smart query routing in our Ad Exchange is enabled at the beginning of the auction.
When we receive a request from an SSP with certain information (IP, user agent), we detail it using information accumulated in the system — known user data, a list of DSPs to which similar requests were sent, their responses, etc. This is necessary to select the most advantageous DSP combination for each request. Due to the smart selection of this combination, the system allows not to send requests to those DSPs that do not bet or do, but bets are too low. To obtain this, a separate service assesses the DSPs in the real-time (these DSP maps are stored in Redis).
In parallel, we check the status of the DSPs. If the proportion of responses within the timeout drops (from the particular DSP) the system automatically reduces the number of requests to this DSP. As soon as the load on the DSP decreases (and the proportion of correct answers increases), the number of requests gradually returns to the previous level.
Among the “proper” DSPs we conduct an internal auction. We highlight the best offer and send it to SSP. In accordance with the industry requirements, the time between SSP request and our response doesn’t exceed 300 ms.
Since we give the data to the SSP where our auction is held, we need to consider the winning bids. Their logging takes place in the auction server at the next stage (user traffic processing). Due to this information, the DSP response maps enrich with new data (along with the information collected about the end user).
Solution risks and risk management
| Risk name | Risk description | Risk severity | Risk management |
| Integration problems | Problem with only one integrated service can lead to problems with the whole system. | High | A comprehensive testing service was created to monitor the programmatic system integrity state in the real-time. |
| Traffic overload | The traffic can increase suddenly for a short period of time. This can lead to system hardware overload. | High | To ensure the stability of the programmatic system, a traffic limiting subsystem was introduced. When the system realizes that the current Ad Exchange is overloaded it “cuts” the requests for auctions that cannot be physically processed. Thus, the system is protected from an uncontrolled load increase. |
| Ad bots | There are a lot of bots that automatically click ads and create useless traffic. | High | The comparison between the data obtained at the auction stage and parameters known from user traffic allows bots filtering (clickers for advertising, search bots, etc.)
Even inclusion of a simple filter gives a huge profit gain. In our projects, the increase was – 50%. |
| Fast traffic growth | The number of system users will increase radically so that the system hardware won’t be able to process all incoming requests. | Low | Most of the Ad Exchange is “stateless”, which provides easy horizontal scaling in the future. It does not store any data on requests – the maximum, the information about which demand-side platform to choose. So we can add new servers to process requests any time we want.
An extra hardware balancer can be bought to distribute requests among several nginx of the same type. |
| Cloud solutions are too slow | Cloud solutions can slow down unexpectedly for no reason and we can’t control this process. | Low | Own servers were bought, instead of using Cloud solutions. |
| Fault-tolerance | What if Ad Exchange server fail unexpectedly? | Low | One additional server is used for seamless updates and fault tolerance. |
Results
Today, our Ad Exchange works and is profitable. We support and integrate new partners (DSP / SSP) as needed. In total, several dozen systems have already been integrated. The created solution could easily cope with customers requirements.
Here are the main features of the subsystems:
Ad Exchange provider:
- servers provide the processing of more than 10K requests per second in the normal mode;
- peak the request flow reached 40K per second within a few hours, and the Ad Exchange coped with it perfectly.
Hardware balancer:
- Nginx can hold up to 60–70K requests per second without allocating a separate hardware balancer.
Database:
- provides 90K queries per second to Postgres (inserting of data).
Smart traffic routing subsystem:
- in accordance with the industry requirements, the time between the supply-side platform request and our response doesn’t exceed 300 ms.
The Ad Exchange is a liquidity provider. By now, the Ads Exchange model is gaining popularity. We are looking forward to massive integration which will raise the opportunity to update and scale our own solution.
Authors: Nikolay Eremin, Alexander Bespalov
#maxilect #maxilect_expertise #ad #Advertising #Adtech #ad_tech #AdExchange #Programmatic #RTB #digital_advertising #smartrouting #supplysideplatform #demandsideplatform #demandside