AY Traffic Shaping

Introduction

Basically what we do is we sit in between the SSP as well as the DSP, meaning the DSP is like the buy-side platform that is bidding on inventory, and SSP is kind of an exchange between the buyers and the suppliers.

Now the issue is that a lot of times requests and bids are being sent from the SSP to the DSP without even responding or being interested in that inventory.

And quite often there are cases where like a thousand requests are being sent and only once is the partner actually interested in that.

What the system is doing and aimed to do is that it is predicting and forecasting who is going to be interested in that specific supply request.

So who wants to buy this kind of ad impression and is predicting how likely it is that a certain

partner will be interested in it and at what kind of rate?

!!!IMAGE!!!

How it Works

So the way the system works is that it is an on-premise system. So, of course, we have constraints on how quickly we have to provide this prediction because if it takes too long, it has

a negative impact on revenue as well.

And the system is optimized to be able to return back these kinds of predictions and results within less than half a millisecond.

In many cases, if it's set up properly, it's sitting some out like 0.2 to 0.3 milliseconds, which means that the system also runs on-premise within the data center or data centers of those SSPs.

It is a single stateless application, but it's one up dynamically, depending on how many are being needed. Scaling them up and down is possible easily.

It does resynchronize every 20 seconds, so it only takes at most 20 seconds to become aware of any kind of upscaling and downscaling of different nodes and so on.

Benefits of Using Assertive Yield Traffic Shaping

1.Send only monetizable requests

When we know that it is very unlikely for a partner to be interested in a specific supply request,

the system cuts out the request. Basically make sure that the partner doesn't even receive this request, which would be purely wasteful.

In many cases, this may result in a reduction of 50, 60, or 70% of the outgoing requests and practically no revenue impact at all.

Usually, it's actually a positive revenue impact because many of these kinds of buy-side platforms are setting limitations on how many requests they may accept from each partner, from its supply partner.

So that means that supply partners need to decide, okay, “What 10,000 requests per second do I take within the 1 million I have available?”

And now, of course, the more efficient this SSP or supply-side platform is, in terms of taking what requests to send within that limit, the higher the amount of revenue they are going to generate from that partner.

Yeah, the better they are at picking, the more revenue they are going to generate from it which also means that they become a more valuable partner to that buyer platform.

Also, the possibility to negotiate better rates and other things because they perform better than the competition. So maybe get a bigger chunk of the cake in the end.

2. Revenue prediction on user-level data through profiling

We took a different approach than what most of these kinds of SSPs are doing with in-house solutions, and that is that we are including user-level data.

Usually when an SSP already with a sophisticated system is filtering out traffic, what they do is they use machine learning to predict if a partner will be interested in what kind of rate they might be generating revenue if they send the requests.

Now the thing is that those predictions are based on information available at that point in time,

for example, country, device, type, and bidder behavior from that specific partner and real-time as well as historically, among other things such as creative size, format, the context category, and so on.

Now the difference with the Assertive Yield Traffic Shaping setting - and which is also in most cases doubling the performance in terms of reductions or cutting the loss rate in half, is using user profiling.

So that means that if a user we are seeing or most users we are seeing, we are starting to create a user profile and therefore we know and understand each specific user on top of all the context-related information and the information of the bid request. 3. Maximize revenue with smart QPS optimization

So there are two options: On one option, we can just use the thresholds being reported with our own logic to decide when we are sending out a bid and then we don't send it out.

But most exchanges actually use the built-in configuration for it, then we can configure it on the

data center level globally and by bidder.

What our QPS with our partner is, for example, we can put in here 40k meaning we can send 40,000 requests per second to this partner globally.

And what the system will do now is it will maintain this limit and it will only send the highest value requests within the limits to the partner automatically. And then the second part is that we could say, okay, but on top of that, you still want to limit.

It also automatically manages things like QPS limitations. So it will automatically pick

and tell the SSP what kind of requests are the highest-value ones, by staying within the QPS limitation as well as other kinds of optimization targets.

Let's say, for example, we want to reduce as much traffic as possible, but for every single bidder, we want to maintain the first positive rate in regard to revenue below half a percent.

So then it will control traffic better in real-time, automatically picking the highest-value inventory

and cutting out as much as it can, but always keeping the loss or the potential loss at less than half a percent.

!!!IMAGE!!!

4. Smart Bid Rate Filters

Revenue Loss Rate and a Reduction Efficiency. Now, the reduction efficiency is a combination of revenue losses but not how many requests it is reducing.

So in certain cases, we might not just want to set a limit of, okay… just keep a loss rate below

a certain value.

In some cases, we might want to look at the combination of how many requests it is cutting down as well as the revenue loss of it.

Depending on what our goal is to optimize to, like for example, if our goal is to not purely optimize based on like revenue but also optimize towards like of all being efficient and so on.

Quite often something like a Reduction Efficiency makes a bit more sense because it takes into account both sides of the reduction rate as well as the revenue loss rate.

!!!IMAGE!!! 5. Handles Bid Request Limitations with Intelligent QPS Management

This is an SSP solution, not a Publisher solution. And the SSPs only think in terms of data centers. So for them, there is not really much in regard to countries at all.

Of course, there are some DSPs that don’t bid for certain countries and otherwise, but these are limitations, they are already enforcing on their end because they know black and white. “Okay, in this country we gonna send, this country we don't send”.

And top of that, the entire system -under the hood has information of course, the country, and other things, so long as if like a certain partner is not bidding at all in a certain country or is bidding very low, and will then automatically exclude most fields depending on what kind of likely the value is for each bidder, partner.

And this is really purely about like the DSP of the buyer-side platform saying “Hey, and this data center, like our European data center, we can allow you to send 5000 requests per second and then the US data centers, we’ll allow up to 20,000.

It is more about purely this kind of partner saying, okay, we're gonna have different limits depending where but most of them just have a global limit. So it's okay, like worldwide, you can send us 50,000.

!!!IMAGE!!!

6. Smooth and stress-free integration

The entire integration is optimized to be as simple as possible as well as to have an integration that is very reliable and doesn't require many changes within the existing infrastructure.

And on top of that, we’ve been able to design a method where we can run alongside without blocking or being directly integrated into the existing tech.

That means for whatever reason, there is a delay in the response time or otherwise, be requiring more resources than anticipated. It doesn't cause any damage to the existing setup because it will just be used as an internal timer.

Say, okay, it took too long to get a response, I'm going to continue on my own without a prediction.

But overall, it is built to be very scalable and before every kind of new deployment.

Otherwise, we are running a bunch of benchmarks and tests to verify that performance and reliability are all guaranteed.

Now, in terms of the setup itself, we are basically spawning up multiple containers, most single executables, most that are being deployed as side cards. That means they are running on the same node right next to the existing RTV application while they are running on their own dedicated node within the same data center.

The tradeoff between the two is that if they are running on the same node, the healthy lowest latency possible, but it also means that we have more fragmentation in terms of users

hitting different nodes and otherwise.

Now if you run an instance in central with a few per data center, it means that we can build like a pickup profile of different users and so on, so we can get more granular in that regard and also collect more information on most users. As well as data that would’ve been otherwise, but it comes at a slightly higher latency cost in the network content.

What Reports Are Available Within the Tool?

Basically, we have a quick overview of the integration and the different kinds of KPIs there that are important and should be basically monitored.

We have a Threshold report providing information as to how well the system is doing across different thresholds.

So for example, the threshold of 40 is doing a reduction of requests at like 49% and on most revenue rates of 12%. Now both of these metrics are absolutely terrible and they are just dummy data, so it's not actually something properly running here.

Normal data here would be something like a reduction of 50, 60, or sometimes 70% at a loss

rate of half a percent or less.

Yeah, then we have Latency reporting as well as integration of reporting how many regards of any kind of errors being detected, how quickly the container is responding to a report on if it would need more compute resources available to perform properly.

There's an Uplift report which is a report on basically increment uplift generated between no optimization running and this optimization running.

In regards to QPS limitations, that means what is the amount of value we are getting incrementally out of the QPS limitations we have by running the system.

Then we have Sample reporting, which is purely looking at training data. That means here no reduction is happening at all, and this is like pure data, without any kind of optimization on it which is being used for training purposes and we also use it for reporting on how to look into the details.

Feedback from SSPs using Assertive Traffic Shaping

Even more, if it would mean that the revenue lost would stay less than half a percent and then we set up an optimization target like this and set it like a revenue loss of half a percent.

What it really means is just that the system is going to have false positives, the more it's going to reduce because it becomes more and more difficult to predict if a certain partner will bid or not the more we are to reduce the floor.

Usually, this best tool will like the highest efficiency to reduce as much as we can, but using something like a lost function, meaning this is the absolute highest amount of loss we are willing to take.

That's like the limit, but so it will automatically adapt to how much it can reduce. And our limit is justifying finding based on a lost function. But this half-a-percent loss here, (in terms of revenue), it's not an actual loss.

It is just like the optimization target it's using internally. Now when you are starting to filter traffic, our partner will see that the amount of requests and information that they are getting is of higher quality and they are reacting positively to that.

At least the majority of them are reacting positively to that, so then what we will actually see is that also we are sending fewer requests, and in most cases, we are receiving more requests in total.

So not purely based on the reduction, we are seeing a higher bid rate, but also looking at the absolute numbers similar thing in regards to the total revenue that is being transacted, usually it goes up for most of them.

!!!IMAGE!!!