PUBLISHER

ONBOARDING
AND
INTEGRATION 101

FOR INTERNAL REFERENCE ONLY

What to Expect
 This document is meant to help BD and PMs understand and visualize the nuances of
our monetization solutions and onboarding processes with flowcharts and tables.

 The goals is to become self-reliant and cut short dependencies on Sales Engineering

during publisher onboarding.

 We also have performance stats to compare MCO vs AB and SDK vs API, that will be
updated on a monthly/quarterly basis.

 Don't forget to go through the notes mentioned in textboxes and in the in-built PPT notes
section.
Table of Contents
 Introduction to SDK 9xx

 Monetization Solutions

 SDK vs API

 Plug-ins & Adapters

 SDK 900 Integrations & Workflows

 Callbacks: Banner, Interstitials, Native

 Set up issues overlooked

What is an
SDK?
A Software Development Kit (SDK) is a set of tools
and programs used by developers to create apps. 

In the world of mobile advertising, it a piece of code

that requests and renders ads on behalf of a publisher.

It facilitates app monetization by connecting

the app with third-party sources (ad networks).
InMobi 
SDK 9xx SDK 9xx Components

Released in Sept 2019

Module A Module B
Initialization logic Third-party provider
logic
Rendering logic
Mediation specific
Lightweight & Robust Config logic logic

InMobi Media SDK InMobi Mediation SDK

Media SDK and Mediation SDK
separated

NOTE: Module B has its own Initialization Logic. But overall,

Module B isn't standalone and is dependent on Module A.
Monetization
Solutions

InMobi Media Monetization InMobi Mediation InMobi Audience Bidding

InMobi Media Monetization
InMobi Media (Direct)
Publisher InMobi
The publisher sends the ad request only to InMobi
and receives a response only from us. We don't
mediate between other ad networks for bids.

InMobi behind Mediation
Third-Party
Publisher Mediation InMobi
If publishers already have a primary mediation
in place, they will add InMobi to their existing
mediation stack.
 InMobi 
Mediation
If InMobi is the primary mediation platform for
publishers, we get to mediate between multiple
InMobi ad networks and push ad requests to them. 

InMobi
Publisher
Mediation
The way in which the ad request flows out to
Third-Party Ad other ad networks depends on their rank in
Networks
the waterfall. Networks are sequentially
arranged mostly based on the historic eCPM
each network brings on board.
 InMobi 
Audience Bidding

In-app Header Bidding allows publishers to invite all demand Most platforms today offer a hybrid model with in-app
sources to bid on their mobile ad impressions simultaneously header bidding and waterfalls coexisting.  Real-time
and helps them identify who the highest bidder is.  With In- bid values collected via header bidding gets added to
App Header Bidding, an ad request is democratized since all the publisher's existing waterfall on the mediation
parties receive equal opportunities. platform and it competes in another final auction for
deciding the winning bid. 
WATERFALL vs HEADER BIDDING ?
Ad Network Configuration on a Mediation Platform

AD REQUEST
Exchange / DSP
Exchange / DSP
WATERFALL
SET UP

$3
$3
Ad Network A Ad Network A
AD REQUEST

IN-APP HEADER
$5
BIDDING

Ad Network B Ad Network B $5

$8

Ad Network C Ad Network C $8

HISTORIC DATA REAL TIME DATA

AB Integration
Publishers can access this by either adopting the InMobi Audience Bidding Platform 
or by accessing InMobi via their existing Third-Party Header Bidder Platform.

InMobi Third-Party
AB Platform HB Platform
 LIVE
AB Integrations 
Integration  SDK API SDK
Line items to be created No No Yes (hybrid-model
with HB and waterfall)
Ad request sent by InMobi UMP InMobi UMP InMobi SDK
third-party bidding server to
SDK Version supporting AB  iOS (907) & N/A iOS (907) &
Android (906) Android (907)
Ad Rendering by  InMobi SDK Publisher InMobi SDK
Integration Handled by MAX Handled by A9 Handled by InMobi
and Adapter Documentation 
 Workflow with
MAX
1. Once the integration is live, the publisher sends an ad request to
MAX.
InMobi UMP
2. MAX SDK identifies the corresponding InMobi Placement ID and
requests for signals from InMobi SDK. 
5 6
3. InMobi SDK sends signals back to MAX SDK.
MAX oRTB
Server 4. The signals shared by the InMobi SDK are then relayed by MAX
SDK to MAX oRTB sever. 
4
5. The MAX server then sends the ad request to InMobi UMP, creating
2
1 InMobi a server-to-server connection, unlike in a mediation set up where the
Publisher MAX SDK
SDK SDK is responsible for all the steps. 
3/7

6. The signals relayed help UMP identify the corresponding InMobi

placement ID. An ad response is sent back to the MAX bidder.
MAX conducts the auction. 

7. If we win the auction, InMobi SDK renders the ad.

 Workflow
with A9
1. Once the integration is live, the publisher sends an ad
InMobi request to A9 bidder through the ad server of the primary
1 Third-Party 2 3 Header mediation being used.
Publisher A9 bidder Bidding
Ad Server
Server
4 2. A9 bidder sends ad request to InMobi Header Bidding
Sever with A9 App ID and A9 Tag ID as identifiers.

3. InMobi Header Bidding Sever identifies corresponding

InMobi placement ID with these details. An ad response is
sent back to the A9 bidder. A9 conducts the auction. 

4. Then there will be another auction on the primary

mediation platform. If we win the auction, publisher
renders the ad since A9 bidder doesn't have rendering
capabilities.

NOTE: Publishers using A9 Header Bidder use other primary ad networks

such as Mopub in most cases. There will be two auctions, one on A9 and
then on the primary ad network used. That's why there is an ad server
between the publisher and A9 bidder.
MoPub &
InMobi AB

InMobi Audience Bidding with MoPub operates in a AB also helps us increase our chances of being
hybrid-model with header bidding and waterfalls selected in the publisher's waterfall. For example,
coexisting. Real-time bids shared via header bidding publishers create multiple line items for InMobi on
gets added to the publisher's existing waterfall on the MoPub, say $10, $5 and $2. If we know we can
MoPub mediation platform and it competes in pay $5 while real-time bids are being collected, we
another final auction for deciding the winning bid. That can activate the $5 line item on the waterfall
is why we need to create multiple line items on MoPub before the final auction starts and deactivate
even with the AB integration  $10/$2 line items.  
 Workflow with
Mopub
InMobi 1. Publisher initiates Mopub SDK.
SDK
2. Mopub SDK talks to InMobi Adapter to send a bid.
7
3. InMobi adapter pings InMobi oRTB end point for a bid.
8
Mopub 4. InMobi server responds with a bid.
Waterfall
5. InMobi bid is passed to Mopub SDK.
6
2 3 6. Mopub SDK inserts the bid in to the waterfall. 
1 InMobi InMobi 
Publisher Mopub SDK
Adpater oRTB Point
5 4 7. InMobi SDK is called to render the ad, if the bid wins the
auction.

8. InMobi SDK renders ad. 

SDK vs API
Note: SDK is always the preferred channel of integration as it puts us in control of the rendering experience, data collection and
viewability needs.

Set of tools used to create applications, consisting of docs, tutorials, libraries and 
APIs. It contains all the tools needed to communicate between apps.

SDK is like a cake mix that makes baking a cake faster & easier. The pre-built
functionality of SDK enables plug-n-play integration.

Facilitates communication between applications even if they have different

languages and instructions. It acts as a bridge between the two but can't be
used to build applications.

API is like a set of instructions in a recipe used to bake a cake. The publisher will source all
the ingredients / components and build it from scratch.
SDK vs API
SDK API
Time Required 4-6 hours 1 week
User Experience InMobi SDK handles the entire Publisher must solely
user experience with an handle the integration, 
inbuilt caching mechanism. stitch the ad experiences,
It helps in rendering creatives. and implement caching.

Data Collection & Accuracy SDK acts as a data collector The publisher must handle
providing accurate signals the data collection on their own.
needed for displaying
personalized ads to users.

Tracking and Viewability Accurately tracks and  Publisher must track and 

attribute user events. Helps attribute user events and handle 
with viewability measurement.  viewability compliance.
Troubleshooting No impression loss or time out. All ad requests aren't received,
and lot of bugs can be found.
Supply Performance
Metrics Benchmarks
MCO AB MCO AB MCO AB MCO AB
Fill rate (highest & avg) Render rate (highest & avg) Completion rate (highest & avg) eCPM (highest & avg)
Banner 29.65%, 4.58% 70.93%, 20.2% 98.16%, 86.24% 76.25%, 15.41% - - $2.42, $0.85 $4.78, $1.34
Interstitial 10.35%, 4.56% 95.61%, 51.82% 74.8%, 56.43% 31.80%, 7.85% 77.08%, 48.85% 97.33%, 40.4% $15.5, $5.84 $15.75, $6.5
Video 3.5%, 1.54% 12.88%, 4.01% 84.89%, 63.13% 2.68%, 0.86% 99.22%, 85.79% 91.31%, 27.74% $13.46, $9 $17.47, $5.07
Native (Instream) 79.9%, 18.98% - 92.04%, 61.97% - 87.97%, 10.26% - $4.88, $0.43 -

SDK API SDK API SDK API SDK API

Fill rate (highest & avg) Render rate (highest & avg) Completion rate (highest & avg) eCPM (highest & avg)
Banner 55.45%, 5.3% 33.81%, 10.78% 98.16%, 85.96% 92.94%, 31.07% - - $2.42, $0.79 $4.10, $1.31
Interstitial 75.63%, 13.39% 45.75%, 14.21% 74.8%, 51.5% 92.58%, 27.05% 77.08%, 51.81% 35.46%, 2.72% $15.5, $5.79 $15.75, $4.87
Video - 36.08%, 2.49% - 100%, 37.10% - 100%, 61.39% - $15.37, $6.6
Native (Instream) 79.92%, 19.33% 12.40%, 2.44% 91.95%, 31.63% 74.56%, 11.20% 87.79%, 10.66% 0%, 0% $4.87, $0.44 $0.42, $0.08

Please refer to PPT Notes by clicking the button below.

Plug-ins & Adapters

Plug-ins Adapters

Third - InMobi Third -

Publisher Plug-in InMobi Publisher Adapter
Party SDKs Mediation Party SDKs

When InMobi sits behind other mediations, plug-ins are used. When other networks sit behind InMobi, adapters are used. 

NOTE: This is the internal terminology used by engineering. The term adapter is the standard word that is used across all documentation. No changes need to be made.  
SDK 9xx
Integration​
APP
Adding SDK to Project

SDK
 Initializing the InMobi SDK​
Step #1

Adding the 
SDK
The first step is to add the InMobi SDK Framework to
the app's code base. 

The MOAT framework is shipped with Android SDK while

it is a separate optional framework for iOS (for now*). 

NOTE

 MOAT is a viewability partner that helps publishers measure and verify

ad performance metrics such as ad renders, views etc. ​

 The two partners available with SDK 900 are MOAT and OMSDK (Part
of InMobi SDK for both iOS and Android).

 *iOS 13 doesn't allow new publishers to update app with MOAT.

Step #2

Initializing 
the SDK
In initialization, steps that are not dependent on the load, are
completed. Here are someone of the
important components that help in initialization:

Signal Config
Publisher needs to inform us if the user has given Once SDK is inside the app’s cod
consent to use their data, as per GDPR and e base, we can't access it during
COPPA guidelines. Location, sessions and config run time because an if-else logic
signals are also pulled. For COPPA, Wi-Fi and is used. Changes need to be made
cell information is also collected. through the config server.

Telemetry Cache
Stores data and helps in loading
Tracks and measures all the events from calling ads faster during subsequent
load, show, beacons fired, crashing, etc. requests.
 SDK Initialized

Create Ad
Request

SDK 9xx  Request sent to

MUTT
To get an ad response  
for the request
MUTT > UMP > CAS > Exchange

Workflow​
Ad response sent to MUTT

Processing the
response

Downloading  Creating a
the asset web view

Show

NOTE:  Publisher doesn't call show for banner ads because of the nature of the ad format.
InMobi Ad
Request Lifecycle
VA L I D A D S E RV E D LOADED RENDERED V I E WA B L E
CLICK
REQUEST IMPRESSION IMPRESSION IMPRESSION IMPRESSION

1 2 3 4 5 6

Ad request Ad is dispatched Ad has been Ad is shown on 50% of pixels  User clicks

received by the screen visible, ad is on the ad
the device viewed for 2
continuous secs
Public APIs
Before understanding the SDK callbacks for the ad formats, it is
important to know about the Public APIs in the InMobi SDK. Below are Account ID
the components that need to be implemented into the project:  Unique for every publisher.

Context ​ Demogdata
It is unique for android and pulls information regarding the windows  Allows publishers to set age, income, educational
within the apps, for example whether it is the first window, second window, etc.  qualifications etc.  

gdprConsent SetgdprConsent
As per GDPR guidelines, we need to collect consent from users in In some cases, users may not have given us consent
order to show them personalized ads. This API tells us whether we to show them personalized ads at the start. If the user
have received the required consent from users or not.  gives consent later on during game play, then this API
informs us about the updated consent from users.
 Ad Formats & Callbacks
Major ad format classification, as supported by the InMobi SDK:

Banner Interstitial Native

NOTE:  Rewarded video ads callbacks are same as interstitial, covered in the following slides.
Banner Load

Static or animated ads that appear and stay within the app's

layout at the top or bottom of the screen. 

When a publisher calls load,  if the load is successful, the onAdLoadSucceeded onAdLoadFailed
onAdLoadSucceeded callback is sent but if it fails the onAdLoadFailed
(end-state) callback will be sent.

If the load is successful and the user clicks on the ad onAdCIicked

(onAdCIicked is sent), the user either gets redirected to another
landing page (onUserLeftApplication) or a full screen ad appears.  

The OnAdDisplayed callback is sent at a different stage for banners when

compared to other formats. The ad being referred to here is the full screen
ad that loads
onUserLeftApplication onAdDisplayed
after clicking on the banner ad. 

OnAdDismissed callback can also be sent when the user 

clicks the close ad button. ​
​ onAdDismissed

There is no show called for banner ads since it's a 

part of the UI component and the ads are much 
smaller in size and simpler in design. 
 Load

Interstitial  onAdReceived

onAdLoadFailed
Full screen ads that appear during natural
transition points in the app flow. onAdLoadSucceeded

When a publisher calls load, there is an additonal step

Show
before the onAdLoadSucceeded callback can be sent.
The onAdReceived callback is sent when an ad is
received because the creatives make the file heavier. If the
ad isn't received or the load fails, onAdLoadFailed is
sent. onAdDisplayed onAdDisplayFailed

Once show is called, if

the ad is rendered, onAdDisplayed callback is sent, post
which a user can ignore the ad and onAdDismissed is onUserCIicked onAdDismissed
sent. If they interact with
the ad, these callbacks are sent: onUserCIicked, 
onUserWillLeave
onUserWillLeaveApplication, onUserLeftApplication. 
Application

Rewarded video ads callbacks are same as interstitial, but

it is not skippable. For giving reward, there is an onUserLeftApplication
additional callback at the end - onRewardsUnlocked.
 Load

Native onAdReceived

onAdLoadFailed

Customizable ads that match the look, feel onAdLoadSucceeded

and function of the app.

Native ads are not internal to the app view, we getPrimaryView / Show
need to create a view. 

The callbacks for natives are almost the same as

callbacks made for interstitials. The additonal onAdImpressed onAdDisplayed onAdDisplayFailed
two have been explained below.

Unlike interstitials, the pubs render native ads

on their own. An extra API called onAdDismissed
onUserCIicked
getPrimaryView is used to render the ad,
which is equivalent to Show for interstitials. 
onUserWillLeave
Application
The onAdImpressed callback is given when the
viewability criteria of an ad is succeeded. It's
called to notify that the impression has been onUserLeftApplication
recorded for this ad.
Set Up Issues
Overlooked
Platforms Supported Native Placements

Android Dependencies Fallback Placements

Generating API Key Testing the Integration

Set Up Issues
Overlooked
Platforms Supported Platforms Not Supported
Set Up Issues
Overlooked
Android Dependencies

To monetize with InMobi SDK, certain external libraries need to be added to the Android Studio project. Dependencies
allow publishers to include these external libraries by downloading them and making it available in the project.

The following dependencies need to be added and verified:

Google Play Services Support Library Picasso Library

Enables better ad targeting (including location targeting) For supporting paged scroll of a deck of Required for loading ad assets.
via the Google Advertising ID. images or ads,

Chrome Custom Tab RecyclerView

Required to redirect the users to URLs outside InMobi For supporting free scroll of a deck of images
WebView or ads. Useful to display a large set of scrolling items.

NOTE:  If these libraries aren't added, we will not be able to see any ad
requests on the dashboard. This needs to be conveyed to the publishers. 
Android Dependencies
Once the dependencies have been added, dependencies element of the project will look like this:

The dependencies can be found on the support portal page here. Please refer to step 2.
Set Up Issues
Overlooked
Generating API Key

Every publisher is given an API key to monetize with

InMobi and to access the reports.

It is automatically generated for publishers but most

of them have trouble with finding their API key. 

A common mistake is that they might be a secondary user

who doesn't have permissions to access the API key.

Publishers can also generate additional keys on the

account level by going to Admin panel > Account Settings
> 5th drop-down is API key > Generate API key.
Set Up Issues
Overlooked
Native Placements

While creating native placements, many publishers

don't select the right ad layout and then face issues.

If they don't choose the right ad layout, ads won't be

served. This is applicable for both iOS and Android.

They can opt for in-feed or splash while selecting ad

layouts.

For more details, click here for Android and

here for iOS.
Set Up Issues
Overlooked
Fallback Placements (for AB only)

To ensure impressions don't remain unfilled, fallbacks

are enabled.

Instead of losing an impression,  fallbacks help make

another ad call without sending a new ad request.

This issue is more commonly seen for publishers on A9

who have multiple placements and creating these
placements on CI is tedious because of the complicated
tag system used by publishers.

PMs can now create fallback placements at

an app > ad-format level, in the regular set
up process. To enable this, select 
Is Fallback Placement as shown in the image
on the right.
Set Up Issues
Overlooked
Testing the Integration
A set up issue often overlooked is that
publishers forget to test their integration
before going live.

They need to configure the test mode on the

support portal under the Diagnostics tab. 

There are two options:

1. Global ON – If the publisher is integrating an

ad unit for the first time.

2. Selective ON - Selectively turn on test

traffic for a set of devices if SDK has
been integrated before for the ad unit.

NOTE:  The test mode needs to be turned off before

going live otherwise the publisher will fail to monetize.
POCs
If you have any questions, please reach out to:

1. Supply Product Marketing – Anish Aravindakshan, Nishita Kini

2. Product – Ankit Mittal, Manu Mathew