1. Mediation Event Flow

2. Initialization

3. Initialization flow
When the user launches an app, the initialization process kicks off, starting the Fyber SDK and the integrated mediated demand partner SDKs. The pre- caching process can also begin at this time. The initialization allows Fyber to access app credentials from the mediated demand partner so the two SDKs can communicate. The two SDKs are connected through a mediation bundle. Within the mediation bundle, there is an adapter that facilitates communication between the SDKs.

4. Initialization of Partner SDK
Fyber server
Initialization Cycle
2. Get app configuration
3. Send app configuration
including mediation
partner credentials
Steps 4 through 7 occur for every demand partner that is integrated through a mediation bundle
Pre-caching
1. Start SDK
4. Start SDK
Passing of configuration
parameters and keys
Pre-caching may happen
anywhere during this process
APP
5. Initialization
Demand
partner
SDK
Adapter
6. Initialization
Mediation bundle 1
8. Adapter started
7. Adapter started
Fyber SDK

5. Ad request flow

6. Ad request flow
When the user reaches an ad placement in the app, the app triggers the Fyber SDK to begin the ad request flow. The Fyber SDK will then begin to make requests to demand partner SDKs to show an ad to the user. The Fyber SDK requests an ad from each demand partner in an order provided by the Fyber server. The order is determined by Fyber’s predictive optimization algorithm, which ranks networks based on performance, priority, and according to any ad control rules configured by the publisher. If the partner has an ad, it will respond with a “show” command and the ad will be delivered to the user. If an ad is not available, it will return a “no show” command and the Fyber SDK will make a request to the next demand partner.

7. Ad request flow Fyber server Fyber SDK
The Fyber server returns an ordered list of demand partner and Fyber exchange ad campaigns
Fyber’s predictive algorithm orders the list based on network performance and publisher defined priority
Fyber server
Network ad request cycle
2. Request ad list
3. Return ad list
The Fyber SDK requests ads from the
networks in order until the ad request is filled,
the request times out, or the list is completed.
Request counted
1. Request
4. Is ad available?
5. Is ad ready?
Fyber adapter
Demand partner SDK
8. Ad status
7. Ad status
6. Ad status
The demand partner responds with “show” or “no show”
Publisher fill counted
If no fills are available, “no fill” is returned
Fyber SDK

8. Ad view flow

9. Ad view flow
After the Fyber SDK has requested an ad and the ad is ready to show, the user will see an app call-to-action allowing him to view the ad. After the ad is viewed, an impression is counted. For rewarded video, if the ad is viewed completely, the user receives a reward. If the video is not completely viewed, a reward is not received.

10. Ad view flow z Fyber SDK Impression counted 1. Play video
3. Show ad
6. Video start
5. Video start
4. Video start
Fyber adapter
Demand partner SDK
9. Video not finished
8. Video not finished
7. Not finished
9. Video finished
8. Video finished
7. Finished
Completion not counted z
Rewarded video flow
Publisher does not reward the user because an interruption occurred
Either the video is viewed
entirely by the user, or
the video was not completed for reasons such as playback errors, the user exited the ad, etc.
Completion counted
Publisher rewards the user for a completed video view
Fyber SDK