YuriyVelichkoOpenX
commented
3 years ago @ppuviarasu, regarding to your question about motivation for the rendering module.
Here is my similar question in the prebid-mobile channel and @bszekely1 answer.
In addition to items listed in the above links:
- native support of SKAdNetwork and similar frameworks
- better support of click and impression handling
- support of any demand partner's feature, f.e Deep Link+ which will allow them to deliver special creatives with better quality
Motivation
OpenX intends to contribute to prebid by making the internal code base of Apollo SDK open source and gives it code to prebid. OpenX won't integrate publishers using Apollo SDK only with Prebid SDK. OpenX is interested in strong community products.
Background
During the last year, OpenX has developed a prebid compatible SDK that is able to render a winning bid. The product has been called the Apollo SDK according to the name of the OpenX prebid solution. The Apollo SDK has been built around the former OpenX exchange SDK, which was deprecated. Here is a brief description of migration steps:
This is an extremely short list of changes but it should give a general understanding of how Apollo SDK was created and what is inside.
Now the Apollo SDK is able to make bid requests to the prebid server, pass targeting keywords to the Primary Ad Server, handle the ad response, and render a winning bid depending on the winner of the waterfall. Here is the list of supported ad formats:
The Apollo SDK bundle consist of three components:
Pure In-App Bidding Integration
Integration with Primary Ad Server
Integration with GAM
Apollo SDK uses GAM Event Handlers to collaborate with GAM objects. Apollo SDK manages the rendering views. If prebid wins on Primary Ad Server Apollo SDK will render the winning bid with internal ad views. If the GAM ad wins Apollo SDK will insert the GAM's ad view registered in the Event Handler into UI and the ad will be rendered with GAM View.
Steps 1-2 Apollo SDK makes a bid request. Apollo server runs an auction and returns the winning bid to the SDK.
Step 3 Apollo SDK via GAM Event Handler or MoPub sets up targeting keywords into the GAM's ad unit.
Step 4 GAM SDK makes an ad request. GAM returns the winner of the waterfall.
Step 5 Based on the ad response Apollo GAM Event Handler decided who won on the GAM - the Apollo bid or another ad source on GAM.
Step 6 The winner is displayed in the App with the respective rendering engine.
Integration with MoPUB
The integration of header bidding into MoPub monetization is based on MoPub's Mediation feature. The MoPub Adapters framework contains the set of adapters for all supported ad formats. If the bid wins in the waterfall the creative with info for a custom adapter will instantiate Apollo's adapter which will render the bid. If MoPub's ad wins it will be shown in the MoPub's ad view.
Steps 1-2 Apollo SDK makes a bid request. Apollo server runs an auction and returns the winning bid to the SDK.
Step 3 Apollo SDK via MoPub Adapters Framework sets up targeting keywords into MoPub's ad unit.
Step 4 MoPub SDK makes an ad request. MoPub returns the winner of the waterfall.
Step 5 If Apollo's creative won then the MoPub SDK will instantiate the respective Apollo Adapter which will render the winning bid.
Step 6 The winner is displayed in the App with the respective rendering engine.
Demo
On the link below you can find the demo of the iOS Internal Test Application for Apollo SDK:
https://drive.google.com/file/d/1nbDOZ-HpoUxgHwC6khA4UKfY7rxg_RMO/view?usp=sharing
The native ads are not included demo yet, they will be ready in a week.
SDK Public docs and integration guides:
Features List
The chart below describes some differences between Prebid SDK and Apollo SDK:
As we see the Prebid SDK could be treated as a subset of Apollo SDK.
Consolidation Strategies
We propose to consider three approaches to adding rendering functionality:
The comparison matrix will be added after the description of the approaches.
Replacing
The current structure of the Prebid SDK allows dropping the entire Apollo SDK functionality into the PrebidSDKCore module. Before replacing the API of Apollo SDK will be tailored to the PrebidSDK API in an identical way so that publishers will be able to update it seamlessly.
Roadmap
MVP, ETA: 7-9 weeks
Gradual Additions
The introduction of new modules will be based on wrapping the existing Apollo codebase and migrating it into the Prebid SDK. We are going to reuse the codebase as much as possible. Adding features step by step could be done in the next order:
Of course, some steps could be done simultaneously if we have resources for it.
MVP (Banners): 7-8 weeks
Full ETA: 23 weeks (7-8 months)
Mutual Modularization
Looking at the current modularization of Preibid SDK we can see that it is in the initial state and requires a lot of additional work ahead. So far, there are two modules that are almost identical:
Therefore, the Apollo SDK could be added as an additional module as is, let's say:
In this case, we will get the rendering feature in prod as soon as possible alongside stability guarantees for clients and smooth adoption of the features by the community. Publishers who want rendering might integrate new dependency and use it as is.
Next, we will perform mutual modularization of both frameworks taking the best from both libraries. The roadmap would look like this:
MVP: 3-4 weeks
Full ETA: 18-20 weeks (6-7 months)
Comparison
Risks and Mitigations
Completeness of a proposition
Even though the proposal discloses the steps for migration it does not cover a lot of details that could appear during development. For instance, support of privacy frameworks, viewability tracking, MRC impression tracking. The merging, migration, or rework of such features could require additional reviews by the community and implementation could take more time than announced in this document.
However, we strongly believe that following the roadmap we will be on time with the provided ETA. Controversial decisions, if they are not critical, could be rescheduled to the next milestones. The critical components should be discussed and released in the most proper way from the very beginning.
Development Time
The provided ETA is based on an assumption of the continuous development work. Factors like employment on the main project and day-offs will increase the spent time. We do not see unsolvable technical obstacles in this project, however, we couldn't do anything with resource availability issues.
Quality Assurance
In the proposed roadmaps we did not consider the QA effort unless migration of existing cases, and of course. manual testing by developers before deploying changes. Apollo SDK has pretty good test coverage, so the number one requirement will be not to lose tests.
Later we will make an additional feature request for migration of the auto-tests project from Prebid to Apollo.
Internal Tests
Apollo SDK uses an internal Mock Server for testing. The Mock Server is a light python application that is able to recognize bid requests and responses with a particular mock. In addition, it is able to log all traffic for particular sessions and some additional features. Almost all test cases are based on the mocked examples.
Eventually, we have to consider if we need to migrate the Mock Server or rewrite cases. But this is out of the current scope.
For the Discussion
OpenX suggests following the Replacing or Mutual Modularization strategy since both of them give the better Time To Market and the fastest feedback loop. The Gradual Additions strategy looks like the most reliable but the most resource and time consuming.
The Mutual Modularization strategy looks like the golden ratio:
The only disadvantage that we see here is that solution won't be technically clean from the very beginning. But this point will be addressed by the end of merging, approximately at the same time as in the case of the Gradual Additions strategy. Event faster.
As a result, we are going to achieve clean modular architecture for all ad formats and integration kinds.
When some strategy is approved we will move further with a more detailed roadmap.