Server-to-Server (S2S)
Explained

How Nimbus Cuts Latency and Increases Your Fill Rate

What is a server-to-server connection?

Server-to-server (S2S) means that two or more servers are communicating directly with each other.

Why is having an S2S connection a big deal?

The Problem with SDK-based Solutions

Most mobile apps are working with multiple demand sources: marketplaces that place ad units on behalf of brands. Each of these networks operates from a server. In a traditional monetization setup, this means that the mobile device has to call each of these servers one at a time, from each individual network’s SDK inside your app’s code base. That means a lot of processing on the device itself and, with each demand partner added, more opportunity for slow-downs and errors — not to mention the additional size added to the app with each SDK.

sdk-based
The Nimbus S2S Solution

Nimbus operates like your own personal server — a super-fast middleman between your app and all of the demand partners you work with. The device sends one simple call to Nimbus and everything else is handled in the cloud.

discrepancy-table

What are the benefits?

Using the Nimbus exchange offers serious benefits to your app.
  1. Speed: Nimbus is lightning-fast. It talks to every demand server at once and returns creative at the highest available CPM within milliseconds. Serving ads will never compromise your app’s speed.
  2. oRTB: Nimbus uses the industry-standard oRTB language to talk to demand servers. This means you can onboard new demand sources instantly. No engineering resources. No wasted time.
  3. Transparency: Because oRTB has been standardized, you know exactly what information is being passed from server to server on your behalf. No extra bloat. No risky data. No funny business. Nimbus exposes this call so you can see for yourself, at any time, exactly what is being included in each request.
  4. Direct DSP Connection: DSPs use oRTB exclusively. One of the benefits of using an SSP has been the ability to communicate in that language. In exchange, the SSP takes a buyer-side fee in addition to the publisher revenue share split, significantly diluting the CPM. With Nimbus, you can communicate to DSPs directly and keep more of your CPM as revenue. This direct relationship increases buyer confidence, and DSPs will win more regularly with the same campaign spend.
  5. Demand-agnostic: Nimbus’s job is to talk to demand servers on your behalf. No one gets preferential treatment. Nimbus is not a marketplace and has no demand affiliation. It acts as a neutral party to get you the highest CPMs possible.

    Other SDK-based Solutions

  • Phones are slow for many reasons: internet speed, available memory, other apps open, out-of-date software, etc.
  • Auctions that are handled “client-side” inherit this latency
  • Your fill rates go down and your bottom line suffers
  • You typically need multiple SDKs to integrate demand partners, bloating your app and costing you time and engineering resources

vs.

    Nimbus S2S Unified Auctions

  • Servers are huge, fast, dependable, and consistent
  • Nimbus auctions are handled “server-side” and you benefit from this speed
  • Your fill rates go up and your revenue increases
  • Nimbus demand partners are accessed server-side and automatically activated without any development time

The Nimbus SDK

Doesn’t Nimbus have an SDK?

Yes. Think of the Nimbus SDK as a translator to demand servers. Each ad request requires a standardized set of information to ensure you are served the proper ad. Rather than writing this call by yourself, the Nimbus SDK does it for you. It also includes everything needed to render different creative types.

Do I have to use the Nimbus SDK?

No. While the Nimbus SDK is the easiest way to integrate with the Nimbus server, it is totally optional to use. As a publisher, you can choose to use the entire SDK, or use the server call and render portions independently.