We used to rely on a batch-based algorithm that assigned one campaign to each user or website every two hours. No longer! To make our display advertising more efficient, we used machine learning to enable real-time display advertising. Our team developed a system that could determine the content and bid price for a single request in milliseconds: We called it RaBid.
Until recently we relied on a batch-based algorithm named Compass that assigned exactly one campaign to a user or a website every two hours. This assignment was then used to reply to real-time bid requests. You can read about how Compass did this in detail in a previous blogpost.
However, we encountered limitations to Compass's capabilities. While display advertising is most efficient with fast decisions in real time, Compass wasn’t flexible enough to deal with market changes. For example, if we assigned one campaign to a certain user pool (or website pool) as a batch, those users would have not been able to see any other ads within the next two hours. Or, if the assigned campaign didn't have an ad for the currently requested format, the user would simply not receive an ad. On top of this, specific campaigns could struggle with spending their budgets efficiently if less traffic than expected was generated in assigned auctions.
So we needed a system that provides rapid decisions for bid requests.
Figure 1: RaBid – bidding process overview
Looks super easy, doesn’t it? To explain it in a little more detail, let’s take a closer look at a bid request containing user and website information. As previously mentioned, the goal is now to decide which campaign is the best choice (e.g., in terms of click probability) and how much we are willing to pay for that auction.
We start by scoring all suitable campaigns for this incoming bid request. We then assign advertising budget to the best campaign based on the remaining budget for each campaign and the calculated campaign score. After that, we can calculate the bid depending on campaign score and market context (e.g., expected competition). With this bid we can now participate in an auction. Our ad is displayed if we have placed the highest bid; otherwise our bid is discarded – but that still gives us a valuable market insight.
Let us offer an example and go even further into detail. OTTO is a leading e-commerce platform, where you can basically buy anything you want. As an online shop, different marketing methods are used to attract customers – for instance, display advertising. With this method we have different campaigns with different contents. Let’s say we have three campaigns: one carrot campaign, one apple campaign, and one t-shirt campaign. One of our customers is Berta Bunny, a frequent visitor to otto.de. She is highly interested in carrots, sometimes also in apples. Berta is a proud user of her recently purchased smartphone and spends her evenings reading about the newest vegan cooking trends.
Figure 2: RaBid – Berta Bunny’s journey
As mentioned, the bid request we receive contains user information (if available), and context information such as page URL and ad size. Furthermore, Orbidder(our SSP/DSP solution) enriches the bid request with information on all currently relevant campaigns before forwarding it to RaBid.
Remember Berta Bunny on the couch browsing for new recipes? As she opens her favourite food blog, a bid request is triggered. It contains her cookie ID and the page URL. The request is enriched with the information about our three currently active campaigns and their expenditure so far.
But how do we now decide which campaign should be displayed?
We start by scoring all active campaigns suitable for that bid request. To do this, we will look up available user features, for instance affinity and activity profiles for Berta Bunny. Additionally, we will consider context information such as website click-rate and category (maybe it's a fruit shop... or a fashion blog?). We also want to include our knowledge about the products advertised by the active campaigns and so we include campaign-specific features.
All these features are used in a neutral network to predict different KPIs such as click probability. In each bid request a score is calculated for every valid campaign. To be able to compare the scores across these different campaigns we normalize them. Above-average scores are rewarded and more likely to be chosen.
In our example, this means that Berta Bunny’s affinity and activity profile indicate a high interest in carrots and apples. She is currently browsing a food blog on her smartphone – and we know this food blog is highly frequented by other OTTO users who sometimes click on our ads, preferably on food content. This means that the food blog is an attractive website to place OTTO advertisements. Based on all this information we score each of our three suitable campaigns. Because we have two campaigns in the food segment, the carrot and the apple campaigns will most likely receive a higher normalised score than the t-shirt campaign.
The normalized score is then used for the campaign assignment.
Besides the normalised scores, the remaining budget is the main factor for assigning campaigns and is updated in real time. All suitable campaigns are compared based on their relative expenditure. Campaigns with a low percentage of budget expenditure are pushed in the assignment process to achieve similar budget ratios.
Let’s get back to Berta Bunny. Although Berta has a strong affinity for carrots, she also likes apples a lot! Now, the apple campaign has had trouble spending its budget during the day, whereas the carrot campaign budget is well on track. The apple campaign is therefore pushed in the assignment and selected for the bid calculation.
To calculate the final bid, we need the normalised score of the assigned campaign, information on the bid function, and a controller factor. The bid function is a function that assigns a bid value to a given KPI score, depending on the website context. It reflects the competition in the auction process; the stronger the competition, the more we need to bid to have a higher probability of winning.
Now, we could insert the normalised KPI into the bid function and get our final bid. However, we need to make sure that all campaigns spend their whole budget during the day. Since all our calculations are based on predictions, we are constantly at risk of over or underspending. Therefore, we have a controlling component to scale the score and so adjust the bid value.
In our example, we consider a popular vegan food blog with strong competition among advertisers. Additionally, Berta’s score for our apple campaign is high and the controller needs to compensate for the underspend. In conclusion, all three factors lead to a high bid and hence to a high winning probability.
The process for all components – scoring, assignment and bid calculation – happens within approximately 20 milliseconds. With the resulting campaign and bid, we participate in an auction with other competitors. The highest bid submitted wins and the winning advertiser can display the campaign.
Given our high bid for Berta, we outbid our competitors and won the auction to display our apple campaign on the food blog.
RaBid is a product developed and owned by team Nautik, an agile and interdisciplinary team of Data Scientists and Data Engineers. Our whole team is involved in creating concepts, planning and defining tasks to find simple solutions to bigger problems, for example calculating the optimal bidding strategy for each campaign in display advertising. Our agile working approach is characterised by pair programming to spread knowledge. This means that ideally a minimum of two developers is required to code tasks.
But in fact, managing bid requests in real time relies on very close collaboration between two OTTO teams, Nautik and Siggi (responsible for the Orbidder). During the development process both teams synced and discussed ideas, concepts and technologies.
RaBid is an ensemble of different model components (click scoring model, etc.), each with a different task to do. Although RaBid processing takes place in real time, a lot of its data and components are prepared beforehand in batches. The input data is stored and processed in Google Cloud storage and accessed via virtual machines to train various model components. However, the RaBid core works in real time, in just a few milliseconds. Implementation was via TensorFlow, a licence-free AI system for Machine Learning and this allows us to code mostly in Python. Besides the model’s algorithm, all relevant input data is integrated in the TensorFlow model. Want to know more? Take a look at the Techblog of Team Siggi.
We have plenty of ideas for further improvement and are currently implementing a test-and-learn approach for further developments. We see RaBid as a product which can and will constantly be challenged in AB tests to continuously improve our business.
To sum up, RaBid is an ensemble of models to predict the optimal bid level and to assign the best content of a campaign to a user and context in real time. A former batch-based system hit too many limitations, so the idea of RaBid was born.
The biggest advantage of RaBid is its flexibility, as well as its efficiency and fast decision-making process. Display advertising requires a system which can adapt to quick market changes. In less than 20 milliseconds RaBid delivers the best available content based on users' interests and budget expenditure so far. Furthermore, considering market observations, time, and website contexts, RaBid is also able to calculate the best bid to maximise the probability of wining. As a plus, we've also managed to cut operational costs significantly!
After RaBid's promising start, we and our stakeholders have plenty of ideas for further improvement, including more detailed content affinity, optimisation based on additional KPIs and ideal budget distribution over multiple days. But first we will finish implementing the AB testing system to ensure the right decisions are made. According to our experience the behaviours of our users and the display market are surprisingly different from expert assumptions, so these tests will enable us to find the solution with the biggest positive impact for OTTO.
Currently, RaBid is already live for www.otto.de and other Group websites as well as apps. Although we launched offsite, more and more campaigns are using our system on www.otto.de. Additionally, RaBid can optimise the very same campaign over both environments, offsite and onsite. Furthermore, RaBid can potentially also be implemented in other marketing channels such as e-mail.
We hope we've offered you an interesting insight into the world of display advertising! In closing, we admit this blogpost probably was an ad for RaBid – but we genuinely appreciate that you clicked on it :)
We have received your feedback.