Millennial Media SDK to Ads SDK Migration
The migration from the Millennial Media (Millennial Media SDK) to Ads SDK is relatively straightforward with many of the method calls and processes remaining the same. This section outlines areas of consideration and how to move an existing application from Millennial Media SDK to Ads SDK. There is no need to make any changes in the Yahoo SSP Portal in order to migrate from Millennial Media SDK to the Ads SDK, as it is intended to work seamlessly with existing placement(s) and application settings.
The key areas of consideration when migrating from Millennial Media SDK 6.x to Ads SDK fall into the areas of integrating the SDK, setting required permissions, application initialization, publisher settings (appInfo), user settings (userData), GDPR, and COPPA.
Obtaining the SDK
The Ads SDK is available via BinTray on Android and CocoaPods on iOS, so the SDK doesn’t need a separate download. These services will make it easy to keep app code up to date with the latest Ads SDK version.
The Ads SDK will be available in several configurations, or editions, where each providing a particular set of features which can be mapped to an app’s needs. The Ads SDK Standard Edition is the first available edition; it includes support for inline, interstitial, and native ads.
Updating Permissions on Android
The list of required permissions for Android has changed. Providing access to “android.permission.ACCESS_WIFI_STATE” or “android.permission.VIBRATE” are no longer required.
Initializing the SDK
Call the initialization method for the particular edition that that’s being integrated into an app. On iOS, app and users settings objects are no longer required to be present for initialization, as they were with the Millennial Media SDK; instead, set the corresponding values after initialization. Examples are found here:
Millennial Media SDK - Android | Ads SDK - Android |
---|---|
Initialize the SDK | Initialize the edition |
MMSDK.initialize(myAppInstance); | VerizonAdsStandardEdition.initialize(myApp, mySiteID); |
Millennial Media SDK - iOS | Ads SDK - iOS |
---|---|
Initialize the SDK | Initialize the edition |
[[MMSDK sharedInstance] initializeWithSettings:appSettings withUserSettings:userSettings]; | [VerizonAdsStandardEdition initializeWithSiteId: mySiteID]; |
Migrating of Setting Publisher Settings and COPPA
In the Millennial Media SDK on both the Android and iOS platforms, the App object is where the Site ID and COPPA flag are set, and also establishes if the Advertiser ID or Application ID can be shared with creatives. With the Ads SDK, the Site ID is now required for SDK initialization. Treatment of the Advertising ID, Application ID, and COPPA are set later through static SDK methods. Examples are found here:
Millennial Media SDK - Android | Ads SDK - Android |
---|---|
AppInfo appInfo = new AppInfo(); appInfo.setSiteId(SITE_ID); appInfo.setShareAdvertiserIdEnabled(true); appInfo.setShareApplicationIdEnabled(true); |
VASAds.setShareAdvertiserIdEnable(true); VASAds.setShareApplicationIdEnabled(true); |
Millennial Media SDK - iOS | Ads SDK - iOS |
---|---|
MMAppSettings* appSettings = [[MMAppSettings alloc] init]; appSettings.siteId = kSiteID; appSettings.mraidIncludeBundleID = YES; appSettings.mraidIncludeIDFA = YES; |
VASAds.shareAdvertiserID = YES; VASAds.shareApplicationID = YES; |
Migrating the Setting User Targeting Information
In migrating from Millennial Media SDK to Ads SDK there have been changes to how user information (e.g. age, sex,income, education, etc…) is set for ad targeting. In Millennial Media SDK a UserData object was created with attributes set there. In the Ads SDK user data is set on the RequestMetadata object using the RequestMetaData Builder object.
Millennial Media SDK - Android | Ads SDK - Android |
---|---|
UserData userData = new UserData() .setAge(myAge) .setChildren(myChildren) //etc…. |
RequestMetadata.Builder builder = new RequestMetadata.Builder(); builder.setUserAge(myUserAge); builder.setUserChildren(myUserChildren); //etc…. // Create the Request MetaData object RequestMetadata requestMetadata = builder.build(); |
Millennial Media SDK - iOS | Ads SDK - iOS |
---|---|
MMUserSettings* userSettings = [[MMUserSettings alloc] init]; userSettings.age = @(myUserAge); userSettings.children = @(myUserChildren); //etc… |
VASAdsRequestMetadataBuilder *builder = [[VASAdsRequestMetadataBuilder alloc] initWithRequestMetadata:self.metadata]; builder.userAge = @(myUserAge); builder.userChildren = @(myUserChildren); //etc… VASAdsRequestMetadata *metadata = [builder build]; |
Migrating GDPR
In MMSDK 6.8 there were two method calls that provided the SDK with information required to comply with GDPR: 1) setConsentRequired and 2) setConsentData. In Millennial Media SDK 6.8 setConsentRequired was used to indicate whether a user was in GDPR scope. The Ads SDK combines these two methods into a single setConsentData method that takes a parameter indicating the user’s GDPR status. Examples are found here.
Millennial Media SDK - Android | Ads SDK - Android |
---|---|
// Set to true if the user falls under GDPR jurisdiction. MMSDK.setConsentRequired(true); // Sets the IAB Consent String. MMSDK.setConsentData(IAB_CONSENT_KEY,myConstentString); |
Map<String, String> consentMap = new HashMap<>(); consentMap.put(VASAds.IAB_CONSENT_KEY), myConstentString); // Sets both consent string and consent required. VASAds.setConsentData(consentMap, false); |
Millennial Media SDK - iOS | Ads SDK - iOS |
---|---|
// Set to true if the user falls under GDPR jurisdiction. [[MMSDK sharedInstance] setConsentRequired:YES]; // Sets the IAB Consent String. [[MMSDK sharedInstance] setConsentDataValue:@myConstentString forKey:MMIABConsentKey]; |
// Sets both the Consent String and Consent Required, [[VASAds sharedInstance]setConsentData:@{kVASConfigIABConsentKey : myConstentString} fromRestrictedOrigin: YES]; |
Migrating Inline, Interstitial, and Native Ads
In Ads SDK there have been changes to the interface for retrieving and displaying ads. The Ads SDK introduced an AdFactory class which is responsible for the retrieval of Ads. Each ad placement type (inline, interstitial, and native) have a corresponding AdFactory class (InlineAdFactory, InterstitialAdFactory, NativeAdFactory). The AdFactory classes are responsible for retrieving an ad object for their respective type and allow the setting of callback to monitor the status of ads being loaded. When an ad is loaded, an InlineAd, InterstitialAd, or NativeAd is returned. A listener or delegate object can be applied to ad to receive callbacks for ad-related events.
Please review the implementation guide for each placement type for specifics.