Category Archives: Google Ads Developer Blog

The blog for information about the AdWords, AdSense, DoubleClick and AdMob APIs and SDKs.

Update: Creating SNDS Campaigns in AdWords

This post will help you configure the attributes of your campaigns in the AdWords API and ensure they're ready for the Search Network with Display Select (SNDS) migration.

In v201402, we introduced the displaySelect attribute to indicate the campaign state during the migration period. Consider displaySelect as a transitional flag: it only has meaning when advertisingChannelType is set to SEARCH and both search and content networks set to true in networkSettings. Elsewhere, it can be safely ignored.

Starting September 16th 2014, we will begin automatically upgrading legacy Search & Display campaigns. Once the migration is complete, we will remove the displaySelect flag from the Campaign entity and service in a subsequent API release. Therefore, we recommend not setting any value for displaySelect in your campaign creation code, so you don’t need to maintain it later. It is only useful for migrating Search & Display campaigns to SNDS.

If you take a Search Only campaign that had contentNetwork = false in its networkSettings, and set that to true in v201402, thereby opting into the Display network, the API will also then set displaySelect to true, so that you don’t mistakenly create a legacy Search & Display campaign instead of an SNDS campaign.

If you still have legacy Search & Display campaigns, we recommend you either split or migrate them before we automatically migrate them for you. There are multiple options for migrating, from switching over entirely to SNDS, to splitting your campaign into parts each targeting Display, Search, and/or SNDS separately.

We have taken these steps in order to reduce the number of changes required to your code. If you have any further questions about this, or any other, topic, please contact us on the forum or via our Google+ page.


Legacy AdMob Sunset and Legacy SDK Deprecation Reminder

Summary: Legacy AdMob will sunset August 31st, 2014. The Google Play store will not accept apps using the legacy SDK after August 1st, 2014. Please update.

Greetings AdMob Developers!

We're pleased to announce we've completed the rollout of the new AdMob to over 200 countries. AdMob is now a complete platform for developers to monetize, promote and analyze their apps, with Google Analytics directly available in the AdMob interface. We hope you enjoy the new features it provides, including ad network optimization and simplified mediation. You can read more about the new features and changes in this help center doc.

Since the new AdMob is now available to everyone, we’re beginning our deprecation of the legacy AdMob, and will be sunsetting the old platform on August 31st, 2014. After August 31st:

  • Ads will stop serving to legacy ad units
  • Legacy house ad campaigns will stop serving
  • The legacy AdMob UI will be inaccessible

Please upgrade to the new AdMob as soon as possible - and definitely before the end of August. If you encounter difficulties, please see the help docs and support forms in our Help Center.

We also want to remind you that after August 1st, 2014, the Google Play Store will no longer accept apps using the legacy AdMob SDK. If you're an Android publisher, you should migrate to Google Play Services as soon as possible. We have plenty of resources for you including our migration guide and intro video - and if you still need help, please ask your technical questions on our forum.

We hope that you're as excited about the evolution of AdMob as we are!

Google Mobile Ads SDK – A Note on Ad Click Events

When you make an ad request using the Google Mobile Ads SDK, you’re probably setting an AdListener or GADBannerViewDelegate to listen for ad events. The click events for these listeners are slightly different on Android and iOS, so today we’ll take a deeper look at what events get invoked when an ad click:

  • opens an overlay, for example an in-app browser
  • launches an external application, for example an external browser or app store

Ad Opens an Overlay

Here are the ad events that get called when an ad opens an overlay:

Event Android Callback(s) iOS Callback(s)
Ad Opens Overlay
onAdOpened
adViewWillPresentScreen
Ad Overlay is Closed
onAdClosed
adViewWillDismissScreen
adViewDidDismissScreen

These events are pretty straightforward. When the ad overlay opens, you get a single callback. When the ad overlay closes, Android notifies you the moment the event happens, while iOS notifies you right before and after the event happens.

Ad Launches an External Application

When an ad launches an external application, the ad events are slightly different:

Event Android Callback(s) iOS Callback(s)
Ad Launches External App
onAdOpened
onAdLeftApplication
adViewWillLeaveApplication
User relaunches App
onAdClosed
-----

Notice how on Android you still get the onAdOpened and onAdClosed events even if an ad leaves an application. But on iOS, the adViewWillPresentScreen and adViewWillDismissScreen/adViewDidDismissScreen events are only invoked when presenting and dismissing modal views.

So how do you know when the user returns to your iOS app? You can listen for the applicationWillEnterForeground delegate method that iOS provides.

Testing The Different Click Behaviors

Hopefully you’re already requesting test ads during application development. If you’re making test requests, you should already see these ads showing up in your development environment:



On iOS, you can use these ads to test both ad click behaviors. If you click the banner, the Google Mobile Ads SDK will launch an external web browser and call adViewWillLeaveApplication. If you click the icon in the bottom-left corner of the ad, the SDK will launch an overlay and adViewWillPresentScreen will get called.

Hopefully this clears up any confusion regarding any ad click events. If you have any additional questions, we’ll field them on our forum. You can also find us on Google+.

New features in AdWords scripts

We have added a couple of new features in AdWords scripts. We hope you like these new features. Try them out and let us know on the forum!

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!

Announcing the DFP API Playground GitHub project



As many of you are well aware, the DFP API Playground is a great tool to explore the DFP API. With it, you can easily test PQL statements and examine the JSON equivalent of the objects you fetch. Best of all, it acts as a full reference implementation of how you should integrate the API with App Engine, touching on features such as OAuth2 authentication, task queues, and channels.

Now, we are announcing the new GitHub project for the DFP API Playground, featuring all the benefits of being hosted on GitHub, improved getting started instructions, and revamped project downloads.

Taking it for a spin

The first thing you’ll notice when visiting the project is that we’ve made it incredibly easy to get up and running.

With Maven

If you are a Maven user, it’s as simple as modifying the appengine-web.xml file and running
 mvn appengine:devserver

We’ve also included an m2e project so developing with Eclipse is easier than ever. Just import the extracted dfp-playground-maven-project download into Eclipse, modify the appengine-web.xml file (in the src/main/webapp/WEB-INF directory), and run the DevAppServer.launch profile in the eclipse-launch-profiles folder.

With Google Plugin for Eclipse

We also heard you loud and clear that not everyone uses Maven, so we’ve added a Google Plugin for Eclipse project download which includes all jar dependencies. As with the Maven project, just extract the dfp-playground-jars-and-google-eclipse-plugin-project download, import it into Eclipse, add Google App Engine functionality to the project, modify the appengine-web.xml file (in the war/WEB-INF directory), and run the project like any other App Engine project.

If you’d like to learn more, take a look at the README. As always, we are open to any feedback, so please don’t hesitate to leave us any feature requests in the issues section. Also, if you’d like to contribute to the project, we welcome any patches (just make sure you become an official contributor first).

In the coming months, we’ll be adding even more functionality to the application, so stay tuned and happy hacking!

AdWords and DoubleClick Ad Exchange SOAP API users – Only two months left to migrate from ClientLogin to OAuth 2.0!

ClientLogin authentication support for the AdWords API and the DoubleClick Ad Exchange SOAP API will sunset along with v201309 on July 21st, 2014. You only have two months left to migrate - don’t wait until the last minute!

We have plenty of resources to help you migrate. It might take longer than expected to migrate to OAuth2, especially if you don't already use a single top-level MCC to manage your AdWords accounts or if you are a DoubleClick Ad Exchange customer.

Start your migration as soon as possible and reach out to us early on the AdWords API Forum or the DoubleClick Ad Exchange API Forum with any questions.

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

IMA SDK Moving Off of s0.2mdn.net

What is happening?

If you pay close attention to your network traffic, you’ve probably noticed that the IMA SDK is hosted on s0.2mdn.net. Last week we started migrating traffic from this domain to imasdk.googleapis.com. This will be a gradual migration - we will not move all traffic at once. Instead, we’ve started putting all HTML5 traffic on the new domain. Flash and native SDKs will follow shortly. For updates on our progress, check out the "Domain Migration Status” forum thread. The old domain will continue to work for the remainder of the year, but we encourage you to move early.

What this means for you

Flash publishers

Re-download the implementation swc from our downloads page, recompile your app, and re-deploy. This only needs to be done after the Flash migration starts - we’ll let you know when that will happen on the aforementioned forum thread.

HTML5 publishers

Start loading the ima3.js file from the new domain (http://imasdk.googleapis.com/js/sdkloader/ima3.js).

Native publishers (Android and iOS users)

You should not be affected by this change.

As always, if you have any questions feel free to contact us via the support forum.

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.