Native Ads

Quick Look - Example Integrations. For a better understanding please start with the information below.

Native ads are different from standard ad units in that rather than being a single, self contained entity from the perspective of a publisher, they are a collection of individual components that can be laid out and interacted with individually.

Due to their flexible nature and the various components that might be involved, the MM Ad SDK uses a concept of native ad type to provide a contract of sorts that a publisher is able to rely on. Each native type represents a collection of individual components and guarantees the existence of specific components within the native ad response. This guarantee is important because some native types can have optional components that may or may not be present.

Components within a native ad each have a “type” that can almost be thought of as a data type like you would find in most programming languages. The type that is associated with a component indicates certain properties about the component such as:

  • role (icon image, main image, title text, etc)
  • content type (text, image, button, etc)
  • content restraints (max size of text string, etc)

Native type definitions are then just a collection of various components and rules about which are required to display and which are not. In order to record impressions, native ads are required to display certain elements tagged as “publisher required.” These are the components of the ad which are guaranteed display for advertisers. Other components may be present, but their display is considered optional. Where possible, you should choose to display optional elements to help drive user engagement. A list of all available native types and their associated components can be found here

The type for a native ad response can be retrieved by calling accessing the type property on a native ad object.

The native type string can be used for determining which components to access or which layouts to pass to the SDK when trying to display native ad content.

Interaction with native ads within the MM Ad SDK can be broken up into two basic approaches - accessor model and layout model.

Accessor Model

With the accessor model, native ad content is used by accessing each component individually. For example, if a native ad response has title, icon and disclaimer components then the publisher would call a getter method for each of those components and layout those individual views themselves.

UILabel* title = nativeAd.title;
UIView* icon = nativeAd.iconImageView;
UILabel* disclaimer = nativeAd.disclaimer;

The views that are returned already have click listeners associated with them so no wiring is needed beyond taking the view and inserting it into a layout for display.

IMPORTANT: With the accessor model, the impression must be fired manually by the publisher by calling:

[nativeAd fireImpression];

Failing to fire an impression will result in not properly tracking revenue from ad displays, so make sure that once all required components are displayed and visible to the user, an impression is fired. The SDK tracks accessed elements and will not fire the impression if all the required components for the native type have not been displayed.

 

Layout Model

With the layout model, the layout of the individual native ad components is handled by the SDK. In the layout model, once a native ad response is received the publisher can ask the SDK to populate a specified layout with native ad content contained within the native ad response. In this approach, the click handling and impression firing is handled automatically by the SDK.

When the SDK is trying to populate a layout with native ad content, validation will occur that ensures the provided layout has placeholder views for the required components of the native type in question. A detailed breakdown of what required components, native types and component identifiers are provided here.

1. Create a new Bundle target in your project.

Native Layouts - Create New Bundle

2. Ensure the Base SDK is set to “Latest iOS”.

Native Layouts - Set Base SDK

3. Create a new xib file in your Bundle Target.

Use Interface Builder to lay out UIViews to display the native ad components. Each component should enable Accessibility and be given an Accessibility Label as seen in the example below.

Native Layouts - Create xib for Layout

4. Associate your layout components with the ad components.

Create a layouts.plist file in your Bundle target, associating the Accessibility Labels from the xib file with the getter names in MMNativeAd. Follow the example below or copy the example in the packaged Sample App.

Native Layouts - layouts.plist

5. Create and load the native ad object.

Make an ad request. After the request succeeded, create the native ad view by loading the native ad object into your layout. See the example below or in the packaged Sample App.

#import <UIKit/UIKit.
#import <MMAdSDK/MMAdSDK.h>

@interface ViewController : UIViewController <MMNativeAdDelegate>

@property (nonatomic, strong) MMNativeAd *nativeAd;
@property (nonatomic, weak) UIView *nativeView;

@end
- (void)viewDidLoad {
    [super viewDidLoad];
    
    self.nativeAd = [[MMNativeAd alloc] initWithPlacementId:@"<YOUR_PLACEMENT_ID>"
                                             supportedTypes:@[MMNativeAdTypeInline]];
    self.nativeInlineAd.delegate = self;
    [self.nativeInlineAd load:nil];
}

- (void)nativeAdRequestDidSucceed:(MMNativeAd *)nativeAd {
    NSURL *layoutBundleURL = [[NSBundle mainBundle] URLForResource:@"<BUNDLE_NAME>"
                                                     withExtension:@"bundle"];
    NSBundle *layoutBundle = [NSBundle bundleWithURL:layoutBundleURL];
    self.nativeView = [self.nativeAd loadIntoLayoutFromBundle:layoutBundle];
    [self.view addSubview:self.nativeView];
}

- (void)dealloc {
    [_nativeView removeFromSuperview];
    _nativeView = nil;
    _nativeAd.delegate = nil;
    _nativeAd = nil;
}

Additional Topics