Programmatic advertising might be confusing at times. With the continuous industry updates, both publishers and advertisers might struggle to keep up with the requirements and various technical implementations.
Table of Contents
Monetisation through integration via SDK with the SSP remains one of the most efficient ways to take control of your programmatic inventory. Whether you’re part of a large game studio or a small team launching your first app, this guide provides a step-by-step explanation of how to connect directly to BidsCube SSP using the SDK and its advantages.
Why Choose SDK Integration?
- Full control over ad behaviourds: manage formats, frequency, placement logic, and fallback strategies directly within the app and dashboard.
- Higher fill-rate and demand: access real-time auctions with quality demand sources, improving revenue performance across geos and formats.
- Convenience and low latency: SDK provides a direct connection to our SSP, avoiding third-party intermediaries and unnecessary hustle.
How does SDK Operate with Bidscube SSP?
The whole process can be split into several simple steps:
- The SDK triggers an ad request for every eligible impression in the app.
- The response is received directly from BidsCube SSP, with no third-party intermediaries involved.
- All auction logic is handled on the server side; the app only initiates the request and processes the response.
- Creatives are rendered directly within the app, ensuring minimal latency and a smooth user experience.
- There is no need to integrate separate ad networks – the entire monetization process is managed through our SSP.
Supported Formats
Our Bidscube SSP supports a range of formats to fit different app categories and user experiences:
-
Banner Ads
Static or refreshable display ads in common sizes such as 320×50 (smartphone banner) and 300×250 (medium rectangle).
-
Video Ads
Interstitial – ads appearing at natural breaks or transitions within the app, such as between game levels or after completing a task, either static or video-based.
Rewarded – opt-in video ads that offer users a reward such as in-game currency, bonuses, etc.
Auto-play video ads – ads that start automatically when triggered by a viewable impression.
*Note that all formats are configurable via the SDK and controlled through the publisher dashboard, allowing full control over ad frequency and format targeting.
Supported Platforms
Besides a variety of formats, SDK integration allows connection of the most widely recognized platforms, making it accessible for both native and cross-platform teams:
-
Android (Java & Kotlin)
Full support for native Android apps, with integration guides and sample code available for both Java and Kotlin.
-
IOS (Swift & Objective-C)
Compatibility with modern and legacy iOS codebases. Includes detailed documentation for Swift and Objective-C.
-
Cross-Platform (Coming Soon)
SDK versions for Unity and Flutter are currently being developed to support cross-platform frameworks that are commonly used in both gaming and utility applications. These upcoming versions are designed to offer the same level of control, flexibility, and auction performance as the native Android and iOS integrations.
Technical Requirements
To ensure a smooth and successful SDK integration with BidsCube SSP, developers should be aware of the following technical specifications and setup parameters:
Minimum supported versions
IOS: IOS 11 or higher.
Android: API Level 21 or higher
Compatibility with Major Mobile Ad Systems:
The SDK is designed to operate within OpenRTB-compliant systems and follows industry-standard protocols. It is also compatible with other ad SDKs, provided they don’t interfere with real-time bidding logic.
Initialization Parameters:
During setup, the app must initialize the SDK with required values, such as:
- Ad Formats (banners, rewarded, interstitial)
- Ad Placements
- Ad ID.
SDK Size:
The SDK is lightweight, ranging from 800 KB for Android to 3.2 MB for IOS, according to Prebid’s documentation.
Auction Request & Response Handling:
The SDK handles auctions by initiating an ad request at the designated impression trigger point. Responses are returned in real-time via callback functions, and creatives are rendered natively inside the app. No external rendering engines are required.
Publisher-Side Settings (App-ads.txt):
Publishers are required to maintain an up-to-date App-ads.txt file on their app store-verified domain. This file must authorize our SSP as a valid seller to ensure proper demand access and transparency for buyers.
Example User Cases
- A hyper-casual mobile game studio based in the U.S. integrated the BidsCube SDK across a portfolio of lightweight games. The studio’s primary goal was to simplify its monetization stack by removing reliance on mediated SDK chains and legacy ad networks. By connecting directly to the SSP, the studio gained access to high-quality demand partners via a single integration point. The team reported minimal latency and smooth ad rendering during gameplay, which helped maintain a positive user experience across sessions.
- A small but growing European studio with an app averaging 100,000+ DAU used the SDK in a controlled rollout on one of their productivity tools. The purpose was to test direct monetization performance in comparison to their existing waterfall setup. Within two days, the SDK was implemented and configured in a sandbox environment. During the testing phase, the team monitored key performance metrics such as fill rate, QPS, and eCPM using built-in analytics.
- A South Asian developer collective managing a set of utility and lifestyle apps adopted the SDK to build a self-managed monetization infrastructure. Previously, they relied on multiple third-party networks and faced challenges around transparency, bid control, and inconsistent CPMs. Through SDK integration, they moved to a direct-sold model that allowed them to set bid floors, segment traffic by region, and control how demand sources were prioritized. The entire migration was completed in under a week, allowing them to bypass network-level restrictions and operate with full visibility into auction behavior and revenue flows.
Integration Procedure
Our SDK integration process is designed to be straightforward and efficient. The full process can typically be completed within three business days, assuming the app is production-ready and development resources are available.
- Step 1: Submit an Integration Request
The publisher submits a request to begin integration, providing basic app details and traffic expectations.
- Step 2: Receive SDK and Documentation
The team responsible for integration shares the SDK package, platform-specific setup instructions, and a full technical implementation guide.
- Step 3: Technical Support for Initial Integration
Our support team members are available to assist with SDK integration, configuration, and initial setup within the app codebase.
- Step 4: Real-Traffic Testing (1–3 Days)
Once integrated, the app is moved into a sandbox or test environment. During this period, key metrics such as QPS, fill rate, and error handling are monitored under live traffic conditions.
- Step 5: Monetisation Launch
Finally, after successful testing, the app is approved for full access to live demand. At this stage, traffic moves into the production environment, and real monetization begins.
Want to connect your app directly to BidsCube SSP?
Submit your integration request to receive the SDK, full technical documentation, and support from our engineering team. Whether you’re working on a new app or improving an existing one, we’ll help you launch a reliable, direct monetization flow.
Our tech staff and AdOps are formed by the best AdTech and MarTech industry specialists with 10+ years of proven track record!
This Article's Ad Tech terms
