[go: nahoru, domu]

The IMA SDK for iOS version beta7 will introduce some changes in the way you tell the SDK about your display area and companion slots, which lays the groundwork for more versatility in displaying ads. While these new, more versatile features aren’t quite ready yet, we recommend building with beta7 so you'll be prepared to take advantage of upcoming greater versatility and extending support to future iOS platforms.

Introducing the IMAAdDisplayContainer

In the beta6 version of the SDK, the IMAAdsManager contains an adView which you add to your UI to display ads (IMAAdsManager.adView). In the beta7 version of the SDK, you will provide the SDK with a UIView in which it will display ads when they are ready. This is done via the new IMAAdDisplayContainer. This new object will also contain information about your companion ad slots (but more on that later):

  self.adDisplayContainer = [[IMAAdDisplayContainer alloc]
      initWithAdContainer:self.videoView
           companionSlots:nil];

In the example, we use the videoView as the UIView for the ad container. The SDK simply adds views to the provided UIView to display ads, so you won’t lose the required components for the content player already in the videoView. This IMAAdDisplayContainer will be passed to the IMAAdRequest, in place of the current companionSlots parameter:

  IMAAdsRequest *request =
      [[IMAAdsRequest alloc] initWithAdTagUrl:self.adTagUrlTextField.text
                           adDisplayContainer:self.adDisplayContainer
                                  userContext:nil];

Changes to the IMACompanionAdSlot

In the beta6 version of the SDK, you provide the IMAAdsRequest with an NSArray of IMACompanionSlot objects, each of which is initialized with a width and height. When ads are loaded, you add these to your UI:

  // Create your companion slots.
  NSMutableDictionary *companions = [NSMutableDictionary dictionary];
  companions[@"300x50"] =
      [[IMACompanionAdSlot alloc] initWithWidth:300 height:50];
  self.companionSlots = companions;

  ...

  // Give the companion slots to the IMAAdsRequest.
  IMAAdsRequest *request =
      [[IMAAdsRequest alloc] initWithAdTagUrl:self.adTagUrlTextField.text
                               companionSlots:[self.companionSlots allValues]
                                  userContext:nil];

  ...

  // Once ads have been loaded, display the companion ads.
  [self.smallCompanionSlot addSubview:
      ((IMACompanionAdSlot *)self.companionSlots[@"300x50"]).view];
In the beta7 version of the SDK, you will initialize the IMAAdDisplayContainer with an array of companion ad slots. You will then initialize the IMAAdsRequest with the IMAAdDisplayContainer. When ads are loaded, the SDK will fill in the companions for you:
  // Create your companion slots.
  NSMutableDictionary *companions = [NSMutableDictionary dictionary];
  companions[@"300x50"] =
      [[IMACompanionAdSlot alloc] initWithView:self.smallCompanionSlot 
                                         width:300 
                                        height:50];
  self.companionSlots = companions;

  // Give the companion slots to the IMAAdDisplayContainer.
  self.adDisplayContainer = [[IMAAdDisplayContainer alloc]
      initWithAdContainer:self.videoView
           companionSlots:[self.companionSlots allValues]];

  // Request ads with the IMAAdDisplayContainer.
  IMAAdsRequest *request =
      [[IMAAdsRequest alloc] initWithAdTagUrl:self.adTagUrlTextField.text
                           adDisplayContainer:self.adDisplayContainer
                                  userContext:nil];

These changes will allow for continued support of YouTube-hosted ads (including TrueView), as well as allow you to provide a custom player for ads further down the road, similar to the HTML5 custom playback option. A custom ad player is not intended to be used by everyone - in fact most of you will not need it - but it will offer support for some additional features in the future.

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

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.


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!

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+.

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!

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!



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!

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.

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

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.

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.

MCC scripts is a powerful new way to manage your AdWords accounts at scale through simple JavaScript code. You can make cross-account changes, create customized reports to save time, and even pull data from Google Spreadsheets. In March, we announced that MCC scripts are available for Beta signup. Today, we are excited to make this feature available for all users.

To get started with MCC scripts, log in to your My Client Center account, and navigate to My Client Center->Scripts.
Here are some of the ways you can save time with MCC scripts:
  • High quality cross-account reports: Generate well-formatted custom reports in HTML, PDF or Google Spreadsheets for all your client accounts. You can save these reports to Google Drive, to an external server, or include them as an email attachment.
  • Cross-account optimization: Analyze performance and adjust bids in all your client accounts at scale.
  • Troubleshooting and maintenance tools: Scan your client accounts for potential issues like paused campaigns, broken URLs, capped budgets, conflicting negative keywords, etc.
We have put together several resources to get you started:
  • Getting started guide: Our getting started guide provides a technical overview of MCC scripts and how to use it.
  • Reference docs: Refer to the technical reference for MccApp at https://developers.google.com/adwords/scripts/docs/reference/mccapp/index
  • Code snippets: Not sure how to use a particular feature? You can click the “Show examples” button on the Scripts editor or refer to our code snippets page to view a list of code snippets for the most common use cases in AdWords scripts. We have expanded this section to include snippets that shows various features of MCC Scripts.
  • Solutions: Looking for some ready-to-use scripts? Check out our solutions section, which we've just expanded to include solutions specifically tailored to MCC.
Don't be shy with questions if you're just getting started with AdWords scripts--our forum is here to help! You can also provide feedback via the Google Ads Developers Google+ page.

We have added new code snippets to cover the new services released over the last year. You can view these code snippets by either clicking the Code examples button on the Scripts Editor window in the AdWords UI, or through the examples page on AdWords scripts documentation.



We hope you find these new code snippets useful. If you wish to see more code snippets or have feedback about the new ones, let us know on our developer forum. You can also follow our Google+ page for updates about AdWords scripts.