Introduction
Introduction to ad formats and placements
Last updated
Introduction to ad formats and placements
Last updated
This guide contains the implementation of the various advertising formats organized as placements in the app. The app shall create a separate “Placement” through AATKit for every position of an advertisement inside the app that either:
Has a different ad format.
Shall be controlled separately from others.
Placements are the entry point for loading and receiving ads. AATKit provides a separate protocol for each ad format. Creating the placement should be done by calling AATKit
public APIs. Once you have created the placement, the later communication callbacks like loading and displaying ads will happen via the created placement instance.
Rules for Placement Names
In order to work with the Gravite backend, placement names must be constant at runtime, i.e. they shouldn’t change on each app start. Note that any placement instance is supposed to be reused. Do not create a placement instance for each ad you want to display. Keep the number of placements low.
The placement name cannot start nor end with a space, and can only contain the following characters:
Character | Unicode | Name |
---|---|---|
In order to keep track of the performance of your placement over time, your placement name should not change as long as you use Gravite with your app unless you plan a substantial rework of your ad integration.
All the communication with placements is being done via placement instances. The app will also receive different kinds of callbacks for ad loads, displays and other events via the placement-specific listeners. So, each placement type has its own listener that will notify the publisher about the different events.
All callback methods have Placement as a parameter to let you verify which placement fired a specific callback. This will be needed if you have one class implementing two types of placements listeners (e.g. StickyBannerPlacementListener and FullscreenPlacementListener), in this case, you can check the placement name to verify which placement fired this callback.
Placement Type | Explanation |
---|---|
Placement | Corresponding Listener |
---|---|
U+0020
Space
()
U+0028 + U+0029
Parentheses
-
U+002D
Hyphen-Minus
.
U+002E
Full Stop
/
U+002F
Solidus
0-9
U+0030 – U+0039
Digits
:
U+003A
Colon
A-Z
U+0041 – U+005A
(ASCII) Uppercase Letters
_
U+005F
Low Line
a-z
U+0061 – U+007A
(ASCII) Lowercase Letters
Classic banner integration. The Banner is positioned either above or below the fold at a sticky position and usually keeps being shown all the time. Typically, sticky banners refresh automatically every 30 seconds. The Banner also sticks to its initial size all the time. Mostly used in gaming apps.
Like the sticky banner, but can change its size with every loaded ad.
Convenient interface for banner ads that are displayed in moving (scrollable) feeds. It automatically takes care of loading and caching ads, so that the app can consume a banner any time a dedicated ad slot gets scrolled into the visible area - without latency. One banner cache is dedicated to populate all the ad slots of a feed. Also, it reports ad spaces automatically when the app consumes ads. Supports different and multiple banner sizes. A good choice for content based apps like e.g. news, weather, or classifieds apps.
Barebone interface for banner ads. We recommend using this placement type only, if you need complete control over loading and caching strategies, selling strategy at every single ad slot. Needs more integration efforts than BannerCache (e.g. manual caching, and manual reporting of ad spaces). Supports different and multiple banner sizes. Please contact our support, if you plan to integrate this placement type.
A fullscreen interstitial. Typically pre-loaded and presented on user interaction. Can be used in any kind of app.
A special fullscreen interstitial that can be presented during the app’s start instead of a typical splash screen. The ad will contain the app’s logo to give it an app-specific look. Can be used in any kind of app.
A special fullscreen interstitial that (typically only) plays videos. Once the videos have been watched to the end, the user can be rewarded by the app. Typically used in gaming apps to provide users with in-app currency as an alternative to real currency payment.
Native ads in general behave like (in-feed) banners. But they don’t consist of just one image. Instead, they provide a couple of assets that the app developer can (and must) arrange to their liking. Most relevant for news or classified apps.