Tag Archives: mobile_ads_sdk

Announcing open sign-ups for the Ads API Workshops on Display

We're pleased to announce open sign-ups for the first Ads API Workshops on Display event of 2014. The workshop will cover the following display ads products:
  • DoubleClick for Publishers API
  • DoubleClick Sales Manager API
  • Interactive Media Ads (IMA) SDK
  • Mobile Ads SDK

These workshops are a great way for you to meet with the display ads API team and ask questions in person. This is also a key occasion for members of the community to bring their feedback directly to us. Most of all, it's a great opportunity for you to exchange ideas and best practices with fellow developers.

We are inviting you to join us in the following cities:

  • New York, Tuesday, June 17
  • San Francisco, Monday, June 23

Please fill out this registration form if you're interested in attending one of these workshops. Due to limited space, we cannot guarantee admittance, but we’ll send a confirmation email in the coming weeks to let you know if you have a spot.

To receive announcements of upcoming Ads API Workshops on Display, please join this mailing list.

Hope to see you there!

 - , DFP API Team

Google Mobile Ads Unity Plugin 2.1 Adds Interstitial Support

Today, we’re delighted to announce the launch of the Google Mobile Ads Unity Plugin v2.1, now with interstitial ads. You can start playing around with the latest code by grabbing the v2.1 Unity package on GitHub.

Interstitial Ads

There are four steps required to integrate interstitial ads:

  1. Create a new InterstitialAd, specifying your interstitial ad unit ID
  2. Register for the ad events you care about
  3. Load the InterstitialAd with an AdRequest
  4. Show the InterstitialAd at an appropriate place in your app

The first three steps can be performed at the same time, and can even live in its own helper function:


public InterstitialAd CreateAndLoadInterstitial() {
  // Initialize an InterstitialAd.
  InterstitialAd interstitial = new InterstitialAd("MY_AD_UNIT_ID");
  // Register for ad events.
  interstitial.AdLoaded += delegate(object sender, EventArgs args) {};
  interstitial.AdFailedToLoad += delegate(object sender, AdFailToLoadEventArgs args) {};
  interstitial.AdOpened += delegate(object sender, EventArgs args) {};
  interstitial.AdClosing += delegate(object sender, EventArgs args) {};
  interstitial.AdClosed += delegate(object sender, EventArgs args) {};
  interstitial.AdLeftApplication += delegate(object sender, EventArgs args) {};
  // Load the InterstitialAd with an AdRequest.
  interstitial.LoadAd(new AdRequest.Builder().Build());
}

You should wait to show the interstitial until a good stopping point in your app, for example when the user finishes a level in your game. Remember to check that the interstitial has finished loading before you show it:


// Call this when a level finishes.
public void LevelFinished() {
  if (interstitial.isLoaded()) {
    interstitial.Show();
  }
}

Keep in mind that an interstitial is a one-time use object. Once the interstitial is closed, you can dispose of the object and prepare another one. This can be implemented directly in the AdClosed event.


interstitial.AdClosed += delegate(object sender, EventArgs args)
{
  interstitial.Destroy();
  interstitial = CreateAndLoadInterstitial();
};

Ad Events now use EventHandlers

In this release, we also changed our ad events to be of type EventHandler instead of Action for both BannerView and InterstitialAd. This means your callback methods now take an object representing the event sender, and an EventArgs:


interstitial.AdLoaded = delegate(object sender, EventArgs args)
{
  print(“Interstitial Loaded”);
};

The only event with special event args is AdFailedToLoad. It passes an instance of AdFailedToLoadEventArgs with a Message describing the error.


interstitial.AdFailedToLoad = delegate(object sender, AdFailedToLoadEventArgs args)
{
  print("Interstitial Failed to load: " + args.Message);
};

The source code as well as a sample app for the plugin is available on our googleads-mobile-plugins GitHub repo. If you have any questions about Unity integration, you can reach us on our forum. Remember that you can also find us on Google+, where we have updates on all of our Google Ads developer products.

Labels: mobile_ads_sdk, unity

 - , Mobile Ads Developer Relations

Announcing New Google Mobile Ads SDKs: 4.4 for Google Play Services and 6.9.2 for iOS

Today, we’re excited to announce a new release to both our Android and iOS Google Mobile Ads SDKs. The key new features added in these releases are in-app purchase ads for both platforms and new mediation APIs for Android.

In-App Purchase Ads

In this release we’ve added SDK-level support (front-end support coming soon!) for running house ads that can initiate an in-app purchase. In-app purchase ads require that you set an in-app purchase listener on your interstitial ad. If an in-app purchase ad is shown, it will present the user with an option to buy one or more items that you have configured:

When the user clicks Buy now, the SDK will invoke your in-app purchase listener with the purchase information necessary to start a transaction for that product. You are responsible for implementing the in-app purchase flow from this point. Full implementation details can be found in our Android and iOS documentation.

Note: Front-end support for this feature is not available yet, but is coming soon.

New Mediation APIs

As part of our Google Play services API revamp, we’ve added new mediation APIs (which we’re calling mediation v2) to make it easier for ad networks to create mediation adapters.

Don’t worry! We’re still supporting mediation adapters written against mediation v1 APIs. This change won’t require any immediate updates to your apps.

If you previously passed extra parameters to third party networks, note that this process has changed for mediation v2. You’ll now pass a bundle to the ad network, keyed by its mediation v2 adapter class. Here is an example of passing extra parameters to AdMob:


Bundle adMobBundle = new Bundle();
adMobBundle.putString("color_bg", "AAAAFF");
AdRequest request = new AdRequest.Builder()
    .addNetworkExtrasBundle(AdMobAdapter.class, adMobBundle)
    .build();

You can also use this snippet to check for the existence of mediation v2 support. If this snippet compiles, then the adapter supports mediation v2. If there is a compilation error saying that the arguments don’t match the arguments for addNetworkExtrasBundle(Class, Bundle), then that adapter class does not support mediation v2.

See the documentation for more information on passing parameters to mediation v2.

Dropped Support for iOS 4.3

The 6.9.2 iOS SDK release has dropped support for iOS 4.3. By dropping iOS 4.3, the SDK can take advantage of automatic reference counting (ARC) weak references to provide a more stable release. The SDK still supports iOS 5.0 and above.

Check out the downloads page to grab the latest iOS release. A new Google Play services revision will soon be available in Android’s SDK Manager.

For a full list of SDK changes, see the release notes. If you have any technical questions about these changes, we’re available on the forum. Finally, stay tuned for an update on front-end support for in-app purchase ads on our Google+ page.

 - , Mobile Ads Developer Relations

How to Create a Google Mobile Ads Splash Screen Interstitial on Android

Previously, we showed you how to create a splash screen interstitial on iOS. Today we’ll discuss how to trigger an interstitial on an Android app launch.

The cleanest solution is to have an app launch Activity for showing the splash screen image and loading/showing the interstitial. This special splash screen activity should be the activity that launches when the user starts the app. In the splash screen activity’s onCreate method, the first task is to make an ImageView and set it as the content view.


@Override
protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  ImageView image = new ImageView(this);
  // Assumes you have a resource with the name kitten.
  image.setImageResource(R.drawable.kitten);
  setContentView(image);

Next, create and load the interstitial ad. Setting an AdListener is needed in order to know when the ad succeeds or fails to load. If the interstitial loads within a reasonable time limit, we’ll show it. If it fails, we’ll move on to the main activity.


  interstitial = new InterstitialAd(this);
  interstitial.setAdUnitId(AD_UNIT_ID);
  interstitial.setAdListener(new AdListener() {
    @Override
    public void onAdLoaded() {
      if (!interstitialCanceled) {
        waitTimer.cancel();
        interstitial.show();
      }
    }

    @Override
    public void onAdFailedToLoad(int errorCode) {
      startMainActivity();
    }
  });

The “reasonable time limit” mentioned earlier is enforced by creating a timer to stop waiting for the interstitial. If the interstitial doesn’t load fast enough (in this case 5 seconds), we skip it and proceed to the main activity.


  waitTimer = new Timer();
  waitTimer.schedule(new TimerTask() {
    @Override
    public void run() {
      interstitialCanceled = true;
      SplashScreenActivity.this.runOnUiThread(new Runnable() {
        @Override
        public void run() {
          startMainActivity();
        }
      });
    }
  }, 5000);
} // end of onCreate implementation.

private void startMainActivity() {
  Intent intent = new Intent(this, MainActivity.class);
  startActivity(intent);
  finish();
}

Handing Early Exits

The code so far assumes that the user will stay in the activity for the duration of the interstitial loading. But what if the user hits the back or home button before the interstitial loads or the timer goes off? The interstitial will actually continue loading and could be shown on top of the home screen! That would be a poor user experience.

We account for this edge case by implementing the onPause and onResume methods from the activity lifecycle. In onPause, we stop the timer and set the interstitialCanceled flag so the interstitial doesn’t get immediately shown. In onResume, we show the interstitial if it’s ready when the user returns to the app again, otherwise we start the main activity.


@Override
public void onPause() {
  waitTimer.cancel();
  interstitialCanceled = true;
  super.onPause();
}

@Override
public void onResume() {
  super.onResume();
  if (interstitial.isLoaded()) {
    interstitial.show();
  } else if (interstitialCanceled) {
    startMainActivity();
  }
}

If you’re wondering why interstitialCanceled is checked again before starting the main application, it’s because onResume gets called immediately after onCreate the first time the app is loaded. And on the first app launch, we do want to wait for the interstitial to load.

A complete implementation is available in our googleads-mobile-android-examples repo on GitHub. Give us a shout on the forum if you have any questions about implementing the Google Mobile Ads SDK in your mobile applications. You can also find us on Google+.

 - , Mobile Ads Developer Relations

Monetizing Unity Mobile Apps Just Got Easier

Calling all Unity app developers! We are excited to announce the launch of version 2.0 of the Google Mobile Ads Unity Plugin. The new version comes with a completely rewritten, but much more flexible, API. It includes the following new features:

  • A single package supporting both Android and iOS
  • Support for running apps in the Unity editor
  • Ability to create multiple banner instances
  • Ability to create banners of any size
  • Flexible ad request targeting
  • and much more!

Taking a closer look at how to integrate the plugin, a typical banner request in v2.0 looks like this:


BannerView bannerView = new BannerView(
    "YOUR_AD_UNIT_ID", AdSize.Banner, AdPosition.Top);
AdRequest request = new AdRequest.Builder().Build();
bannerView.LoadAd(request);

For custom banner sizes, simply pass in an AdSize object into the BannerView constructor:


AdSize adSize = new AdSize(250, 250);
BannerView bannerView = new BannerView(
    "YOUR_AD_UNIT_ID", adSize, AdPosition.Top);

Want to pass additional targeting parameters? No problem! Set your custom targeting when building the AdRequest:


AdRequest request = new AdRequest.Builder()
        .AddTestDevice(AdRequest.TestDeviceSimulator)
        .AddTestDevice("0123456789ABCDEF0123456789ABCDEF")
        .AddKeyword("unity")
        .SetGender(Gender.Male)
        .SetBirthday(new DateTime(1985, 1, 1))
        .TagForChildDirectedTreatment(true)
        .Build();

Listening for ad events is also extremely straightforward. Register for the callbacks you care about:


bannerView.AdLoaded += HandleAdLoaded;
bannerView.AdFailedToLoad += HandleAdFailedToLoad;
bannerView.AdOpened += HandleAdOpened;
bannerView.AdClosing += HandleAdClosing;
bannerView.AdClosed += HandleAdClosed;
bannerView.AdLeftApplication += HandleAdLeftApplication;

…

public void HandleAdLoaded()
{
    print("HandleAdLoaded event received.");
}

You can also manage the lifecycle of each BannerView by calling show(), hide(), or destroy().

To get access to these awesome features, check out the source code. Also stay tuned for upcoming support for interstitial ads.

If you have any feature requests or bug reports against the plugin, track it! If you have questions about how to use the plugin, speak up! And if you just want the latest news on what’s going on in the wonderful world of Google Ads, circle us!

 - , Mobile Ads Developer Relations

Readying AdMob for the Second App Economy with New Features: Livestream from GDC Today

According to Gartner, more than 130 billion apps will be downloaded onto phones and tablets in 2014, and most of them will be free. At the same time, revenue from apps is expected to grow by over 200% in the next 4 years. That may sound contradictory, but the reason has been clear to many developers for some time: while the first app economy was predominantly focused on paying for apps up front, we’re now seeing the rise of a second app economy, the era of free apps and incremental payments.

In this second app economy, the currency of success has altered significantly, centered on three critical areas:

  • Understanding audiences: Developers should be able to segment their audiences based on in-app behavior and turn data into useful insights for better monetization.

  • Growing in-app purchase revenue: According to Gartner, soon in-app purchases will account for almost half of all app store revenues, but this model requires a sophisticated approach from app developers and the right tools haven’t been available.

  • Maximizing ad revenue: Developers shouldn’t have to worry about managing ads; ads should optimize themselves, in real time, so developers can focus on other important parts of their business.

To help every developer succeed in this new economy, the AdMob team will be at the Game Developers Conference today to share four announcements.

1. Google Analytics now directly available in AdMob.
We introduced mobile app analytics in mid 2012 and there are hundreds of thousands of app developers using it already. We've now built Google Analytics directly into AdMob so developers can understand how people are using their app, segment them based on behavior in just a few clicks, then act on those insights. For example, the Google Analytics ecommerce report shows key insights into in-app purchases: top items sold, overall revenue and average order value. Now that Google Analytics is built directly into AdMob, developers can have a holistic view on their monetization based not only on revenue from ads but also on in-app purchase performance. All these functionalities have been incorporated into the updated Home tab in AdMob, making it a one-stop shop for all your performance reports.

2. In-App Purchase Ads.
To help developers promote in-app purchases to users in a more relevant way, we're also introducing in-app purchase ads. A developer can use these ads to promote in-app items at the right time to the users who are most likely to make a purchase, while still showing AdMob ads to those who aren't. Segmentation tools enable developers to quickly find these users, and then in-app purchase ads can be used to build relevant interstitial ads to reach them. For example, a developer can discover which of their users began playing their game in the last 48 hours, and promote a ‘welcome pack’ of extra lives at a 50% discount. This creates a more customized experience for users and can help prolong engagement. A developer can also choose where to place these interstitial ads in their app, and they can appear in either portrait or landscape mode.

In-App Purchase Ad

3. Ad network optimization and Live CPM.
If a developer is using more than one ad network to monetize their apps, a mediation tool helps to manage them. However, these tools may not optimize for the highest revenue. To solve this, ad network optimization obtains the most up-to-date CPMs from ad networks in the AdMob mediation stack, and requests ads from the highest paying one.

Live CPM goes one step further to ensure developers earn the most money from their ad impressions. When a developer uses AdMob to monetize, they get real-time access to all of Google’s demand sources, including programmatic demand, via our integration with DoubleClick Ad Exchange. For each ad request, Live CPM compares the highest CPM a developer can get from Google’s demand sources, with the CPM they could get from other networks in their mediation stack. If a higher-paying ad is available from Google’s demand sources, it will serve that ad over lower-paying CPMs offered by the other networks. App developer iHandy Inc. began using Live CPM in February this year. Many apps' revenues increased at different rates, and certain apps achieved a 200% increase.

4. The App Developer Business Kit.
The App Developer Business Kit is an in-depth website designed to help app developers understand ways to build a successful business. For example, there are detailed chapters about building an app, different ways to earn money, and options for marketing your app. You can also check out the interviews with developers, read case studies and view market insights from AdMob surveys which give developers a head start into building apps for global users. For example, did you know that a third of smartphone gamers in China have spent money in apps to personalize characters?

Tune into Google’s GDC livestream today at 10AM PST. We have sessions for game developers all day, and the AdMob talk is from 12-12.30PM PST.

Posted by Jonathan Alferness, Product Management Director, Google

Announcing Deprecation of the Standalone Android Google AdMob SDK

Since joining Google Play services back in October 2013, Google Mobile Ads has added support for the following products:

  • AdMob
  • DoubleClick for Publishers
  • DoubleClick Ad Exchange

The new Google Mobile Ads APIs also offer additional features that the standalone Android SDK doesn’t have:

  • The new library has full support for the Android Advertising ID, and is compliant with the latest Google Play Ad Policy.
  • Google Play services offers automatic service updates via the Google Play store, so you get the benefit of always being on our latest and greatest mobile ads library without the hassle of having to update your apps.
  • The DoubleClick Ad Exchange JavaScript adapter is now included in the Google Play services library. This means you have one less dependency in your application, and you can be sure that the adapter will always be compatible with future Google Play services updates.

As part of the Google Play services 4.2 update, we are deprecating the standalone Android SDK in favor of the Google Play services library. The deprecation allows us to focus our development efforts on Google Play services and offer additional exciting features going forward. Here is the deprecation timeline:

  • On August 1, 2014, the Play Store will stop accepting new or updated apps that use the standalone Google AdMob SDK. The standalone SDK does not use the Advertising ID, and will therefore be non-compliant with the Google Play Ad Policy on this date.
  • We will stop offering technical support for questions specifically related to the standalone Android SDK on August 1, 2014.
  • Ad serving through the standalone SDK will continue to work after August 1, 2014.

There are currently no plans to stop serving ads through the standalone SDK, but we strongly encourage you to update your apps sooner rather than later to avoid the August 1, 2014 deadline. Note that the Google Play services library still supports the same devices -- you can still serve ads through this library even on devices that don’t have the Google Play store installed.

Be sure to refer to our migration guide to help you upgrade. If you have any questions about the deprecation or how to upgrade, post them on our forum. You can also stay tuned to ads-related SDK updates on the Google Ads Developers +Page.

 - , Mobile Ads Developer Relations

AdMob Student Challenge: Best Practices

Hello students!
We're now a few months into the AdMob Student Challenge. By now many of you have probably made some headway on your app, but aren't completely sure about how you want to integrate AdMob. Today we'll give you some tips on best practices for integration.

Positioning

In general, ad placement should work with the flow of your app. Banners can be placed at the bottom of a screen containing another view, as elements placed in a ListView (as long as you don't show more than one banner on screen at once!) or other places that work with the current layout of the screen.
On the other hand, interstitials should be placed at a natural break in your flow from screen to screen - for example, in between game levels. You can see more examples of ad integration in our Ad Catalog app.

Event-based Action

If you want to track the different lifecycle events of an AdView object, you can use an AdListener. This allows you to not only track, but also take action in onAdOpened(), onAdClosed() and other methods. You can see an example of an AdListener in the Ad Catalog app, and the basic AdListener behavior in this sample app.

Flair

Another fun thing to do is create Custom Events, which allow you to serve your own ads in the ad space. For example, if you know your user's birthday, you could deliver a Happy Birthday message instead of an ad on that day. Custom Events give you a lot of flexibility with your ad space, and we're excited to see how you use them.

For additional controls, such as location and ad color, check out our docs. And if you have any SDK-related questions, you can ask other AdMob developers (including me!) for help on our forum.
Remember, using AdMob is a requirement to submit your app for the student challenge. We're looking forward to your submissions and hope to see some innovative uses of the AdMob SDK!
 - , Mobile Ads Developer Relations