Bid Floor Optimisation Basics

What ad formats can Nefta optimise bid floors for?

Nefta can only optimise interstitial and rewarded ad formats. It is not possible to optimise floors for banners.

How many ad units does Nefta use to optimise bid floors, and how does it work?

Nefta only needs two ad units in order to optimise bid floors: a primary that serves to optimise the bid floors, and a secondary that operates as a backfill fall through. On MAX, a direct price parameter allows us to send specific price points at user level for every ad opportunity. On LevelPlay, this is done automatically as LevelPlay allows for dynamic feedback on its ad units.

Is it really necessary to have two ad units (one with bid floor and one without for fallback)? Could we use a single ad unit, try bid floors 2-3 times, and if it fails, simply remove the bid floor from that ad unit?

It is indeed really necessary because you have to comply with a backoff timer every time there is a no fill event. Otherwise you are at risk of being flagged with MAX or have demand impacted. The backfill ad unit allows all ad opportunities to get filled and ensure we drive consistent revenue uplift over time. If it’s not there, CPM will go up but total ad revenue will decline due to lower fill rate.

Should I configure ad units on Nefta and on the MAX custom network configuration?

No. There is no need to configure any ad units on Nefta, and on the MAX custom network configuration. In order to use bid floor optimization, all you need to do is to set up an app, and use the AppId with the developer carrying out the integration. For more information, please visit this page.

When the bid floor fails on the first ad unit, do you retry with a lower CPM or the same one?

The system learns and adjusts the CPM for every request. There is no rule such as “retry with a lower eCPM” as the algorithm executes an inference request in Nefta before every mediation request. This uses a vast feature set and happens in “true” real-time (latency measured in tens of milliseconds). It can be that the subsequent request eCPM goes up (for example if the user just purchased something in-game), this is for the algorithm to optimise towards.

How do you handle multiple call constraints on certain ad networks, such as AdMob?

We always show all ads that we request and also monitor closely to ensure we don’t fall below a certain threshold which would impact the demand side. The algorithm can optimise towards ensuring a minimum fill rate.

Our two ad requests tracks (track 1: Nefta-optimised and track 2: backfill) will not be called at the same time, with one ad being discarded (this is what ad networks are monitoring and enforcing).

The backfill track is preloaded and the ad is eventually shown when there is a no_fill event on track 1 to make sure publishers don’t lose out on revenue.

Could you describe the user journey from the first impression to the 50th for example? Specifically, how do you track user information and ensure that the bid floors adapt dynamically to each impression?

User logs on to the app.
Both tracks are being loaded (Nefta-optimised flow and backfill flow)
When an ad opportunity arises, the user gets an ad from the Nefta-optimised flow first or from the backfill flow if the optimised track is still loading. These two tracks operate in conjunction to achieve both increased fill rates and CPM uplift.
The model will ensure fill will happen from the Nefta flow after 1, 2 or 3 retries depending on the fill rate status at the ad unit level.
Once a user gets fill from the Nefta flow, the system resets for another cycle.
The backfill ad unit is always loaded and ready to fill in the eventuality of a no fill scenario.

Data

Could you explain exactly which data you use to adjust the bid floors to the impression level?

Standard ‘AdTech’ data collected from device (country, device type, pixel, battery level, network, etc).
Session data (everything related to frequency, time, intervals of user sessions).
In-game behavioural data (per user progression, spending etc).
Ad revenue data:
- Mediation requests
- Mediation responses
- Impression revenue

Should I integrate game events first-party data for my initial test, or can we add it over time?

In addition to the data above, it is possible to share with Nefta game events in the form of tags. These are pieces of code which are added when different events take place in the game or app, such as when the user purchases something, spends a resource, or simply progresses with usage. This data is then also used to make better predictions.

It is possible to start the bid floor optimisation process without game event tags, however, in the future this system will have greater prominence in determining user value. Your account manager will be able to advise you as to the best course of action for you.

The backfill track is preloaded and the ad is eventually shown when there is a no_fill event on track 1 to make sure publishers don’t lose out on revenue.

Testing

How can I test my integration before switching on the bid floor optimisation?

We have a step-by-step guide on how to verify your integration here. It consists of:

Enable event logging
Requesting an insight (bid floor recommendation)
Requesting an ad
Logging the response of that ad request
Verifying whether or not the ad loaded or failed to load
Closing the ad

Our technical team will support and work with your team on verifying the integration.

What happens after the technical integration has been verified?

Once the integration has been verified by our team, Nefta will start receiving mediation events and building the models. Once enough data has been gathered to generate insights, the Nefta team will create an A/B or A/B/C test in order to prove lift. The configuration of the test will depend on a number of factors, such as the size of the traffic, the data collected, and the algorithms that are better suited for the test, but they usually follow this pattern: 34% no optimisation, 33% our default algorithm, 33% our most aggressive algorithm.

What is the optimal size for choosing an app/game?

The minimum number is around 5000 impressions per session. This will allow for more accurate predictions from the outset.

Why does your model need several days before it starts optimising bid floors?

It is the necessary time to have a good market price overview and model calibration. The more users the app has, the shorter the process. The model can serve on the first day but the results won’t be as good.

Why do I need to disable back-to-back ad loading on MAX?

Back-to-back ad loading is enabled by default and causes MAX to automatically preload a second ad on the same ad unit. This is done as an optimisation under the assumption that future ad load calls will also be on the same ad unit, and therefore immediately available. Publishers working with multiple ad units should disable this behaviour. Details are outlined in our documentation here.