Optimizing the Request Flow

Introduction

The key to a successful Fyber integration is determining the optimal place to make requests for offers. When designing your request flow, it's good to consider the timing of the requests and synergy along with your app interface while taking into consideration our known Best Practices.

Timing Video Requests

Best Practice Check

We recommend you make the request for videos as close to the point in which the user will be presented with the option to see the ad as possible.

Fyber does not use automated offer requests, and we generally don't recommend the use of strict timers when making requests. Automatically requesting an ad after a certain period of time has elapsed will lead to making more requests than you need.

The best approach is to request offers based on the time when the user will navigate to the location where they will see the actual ads. We recommend giving less time between the ad request and show rather than making the request too early.

If you make a request too close to when the user has the option to see the ad, you may need to implement short user interface mechanisms to let the user know they may have to wait for it to load. If you make a request too far away from when the user has the option to see the ad, you might run into problems showing the ad, or cause performance degradations in your integration.

Pre-caching and Starting the SDK

Best Practice Check

To make sure that you only request ads after all networks are up and running and ready to provide their ads, allow at least 5-10 seconds for the SDK to start up.

The start method for the Fyber SDK returns immediately, but it also starts performing tasks asynchronously in the background to start up completely. Among these tasks is ad pre-caching.

Although it is possible to pause caching for the Fyber inventory, mediated demand partners do not provide similar options. So many networks will only be prepared to deliver ads after they have finished caching ads.

Allowing for Possible Request Timeout

Best Practice Check

If your integration allows for viewing an ad in less than 10 seconds, implement user interface elements that indicate that the request is in progress and may still take some time.

Although a request for ads will normally take less than one second to complete and provide your app with a valid response, it can sometimes take longer. Network connection issues, poor quality cellular data plans, and so forth can cause requests to draw out.

Fyber implements an automatic timeout for any request that takes over 10 seconds to complete. When designing your user interface and request timing, take into consideration that a request could take up to 10 seconds to complete.

Making Too Many General Requests

Best Practice Check

If you make too many requests, you're wasting the resources of your own users - including network, memory, battery and worst: their data plan.

Making a large number of requests for ads that are never consumed by users causes overall performance degradation. You could reduce everything from the number of ads available to the revenue generated, not only for Fyber inventory but also for mediated demand partners.

With the level of flexibility the Fyber SDK offers, you can accidentally generate too many requests which cause a negative impact on our servers.

In such cases, our policy is to disable the traffic coming from the malfunctioning integration to prevent an impact on the other developers using the Fyber system.

Keeping Track of Your Request Responses

Note

If the ad was returned less than five minutes ago (the Fyber reservation window), don’t make a new request and keep the ad you have. If the ad is older than five minutes, make a new request.

It's always possible to generate more requests than you might need. To handle these scenarios, we recommend keeping track of the ads that you successfully receive from requests, and not make a new request for ads until it's needed.

Networks normally guarantee delivery of an ad that is returned to a request for at least some period of time, so it doesn't make sense to make another request for ads until after that guaranteed time window elapses. The only time you need to make a new request before the reservation window has elapsed is if you make a change to other parameters, such as user segmentation, that might affect the request response.

We recommend you keep track of the time of each successful ad response that you receive. Any time that you might want to make a request for new ads, first check to see if you already have an ad, and if so, when you got it.

Handling a No-fill Scenario

Best Practice Check

Avoid a constant loop: Do not make a consecutive request when your ad request returns a no-fill.

It is not possible to guarantee a 100% fill rate to all users, everywhere in the world, no matter how many demand partners you integrate. Inventory can be limited in some countries, particular users can be blocked for fraud against the different demand partners, or network connection issues can cause timeouts.

So your integration must be able to handle a response from our SDK in which we report that there is no ad available for the user.

It may be tempting to immediately make another request, and keep making requests until you get an ad. There is no benefit to your integration in making additional requests every time the Fyber SDK fails to return a fill.

Performing requests in this way will lead to an infinite loop in many cases. This would risk our Fyber platform stability and possibly result in your integration being disabled from our side.

We recommend handling the no-fill scenario by disabling the integration’s interface elements, or by notifying the user that there are no offers currently available. If your request flow is configured correctly, another request for videos should occur naturally as the user moves through your app’s interface.

Viewing the Ad

Best Practice Check

Show the ad to the user as close to 10 seconds after making the request as possible so that you can handle a possible request timeout, and use your inventory efficiently.

Most demand partners are likely to have some kind of mechanisms in their system to prevent over-delivery of advertisements. To ensure proper inventory performance, we must ensure that advertisers pay for every delivered impression.

Fyber employs a reservation window, during which time we guarantee that the video returned to your request will be available to the user for whom you made the request. That reservation window lasts for five (5) minutes.

If you are following our recommendations to make requests for offers near to the point in time when the user will have a view option, this should not be an issue for you. 

Tailoring your Interface

Here are a few tricks and tips to help your user interface and integration work together well:

  1. Use natural delays in your app to cover the time it takes for a request to complete.

  2. Harness your knowledge of how your users will move through your app to find the best places to make requests.

  3. Use the response events coming from the Fyber SDK to update your interface and help direct users to the ads.

Special Concerns with Rewarded Video

Best Practice Check

If you allow the user to interact with the UI element that will show the video ad before the ad is available, make sure that it is clear to your users that the video is not available yet but will be soon.

When using Rewarded Video, you will often provide the user with a specific option to choose to watch a video ad. The options that you provide need to be reflected in your interface in some way. This is normally some type of UI element that the user taps to start the ad.

If a user taps on your UI element while a request is in progress, and you tell them that there is no video available, they will leave the integration and not come back for some time. If the video becomes available only a second after they have left, then you have lost out on potential revenue from the impression that the user abandoned.