[go: nahoru, domu]

Editor's note: re post from Geo Developers Blog.

Our developers often ask about opportunities for monetizing sites that use the Google Maps API. For years we've provided a way to add AdSense to their maps via the Maps Ad Unit, and today we're adding two new extensions to that feature. This means more choices for ads with your maps and an improved experience for your users.

The first extension adds six new ad formats that request a link unit rather than direct ads. Link units display a list of topics that are relevant to the content of your page. When a user clicks a topic, Google will show a page of related ads. Since link units can take up less screen space than direct ads they’re a great option to consider when you have limited space.

The second new extension allows you to customize the design of the Maps Ad Unit. We now support custom colors for the ad unit's background, border, link, text and URL. This enables you to set a color scheme that complements the design of your site.



You can now test-drive these new features with the demo. While the demo illustrates only a subset of the supported formats with a limited number of predefined styles and on-map positioning, you have much more creative freedom over your own ad unit.


When you are ready to try this on your own site please see the developer documentation and Maps API reference for instructions on how to use these features with your ad unit.

Posted by Jorrit Herder, Software Engineer, Google Maps API
Labels: ,

In response to your feedback, we are pleased to announce that starting at the end of September 2012, new major versions of the AdWords API will be released according to a published schedule. These major releases will occur 3 times per year: at the end of February, in the middle of June and at the end of September. Exact release dates may vary.

A major release is one that starts the sunset clock on previous releases. An example of this is the recent v201206 release which started the sunset clock on the v201109 and v201109_1 releases. We will also continue to release minor versions to deliver new features as required. Minor versions are optional and are source code compatible. Minor versions are delivered as dot releases and an example of this is the v201109_1 dot release.

We believe that delivering new API releases to a published schedule will allow you, the API users, to better plan and allocate resources, not just for performing required API updates but also for innovating and implementing new features and continuously developing your tools and platforms. It also provides us with a more stable and more frequent vehicle for delivering new features.

Each new major release will trigger the deprecation of the previous major release. Exact deprecation timelines will be announced with each major release.

If you have any questions about this announcement please post on the forum or attend one of the AdWords API Office Hours Hangouts.

- , AdWords API Team
Labels:

If you've recently visited any of the Google Ads Developer documentation, you may have noticed a "Feedback on this document" link at the top right corner of a page. That's right—you can now use that link to report errors, comment on existing content, or request further clarification for any of the Google Ads Developer docs:

In addition to this new channel, you can continue to reach out to us through the developer forums or Google Developers Live events.

Quang Nguyen, Ads Developer Relations Team

Labels: , , , , , ,

We are pleased to announce the release of Ad Catalog v2 for iOS. Ad Catalog is a sample application which showcases a number of best practices when it comes to integrating AdMob ads into your iOS application.

This updated version shows how to integrate AdMob ads into four different types of iOS layouts - TabbedView, TableView, ScrollView and OpenGLView. Highlights include:

  • The TabbedView example shows how to correctly implement a GADBannerView singleton that gets reused across many different views
  • The TableView example shows how to correctly reuse a single ad inside multiple cells in a TableView
  • The OpenGL and ScrollView examples show how to correctly dock an ad to the top or bottom of your screen, outside of your content

You can download a zip file from the google-mobile-dev download page, or you can get the source by taking a look at our online repository.

If you have any comments, questions, or feature requests for Ad Catalog, please let us know about them on the forum or during our office hours.



 - , AdMob Team
Labels: , ,

At Google, we enjoy hearing from you, the developer community, and working with you to ensure that progress is being made. We think the latest DFP API release reflects positively on how we work better together and we're excited to announce version v201208. This release adds new types of creatives, support for optimization, rich media, and video interaction report columns, along with new options for downloading reports. A full list of improvements from this release can be found on our release notes page. We also want to remind you that we host virtual office hours via Google+ hangouts in order to make sure your voice is heard. Stay tuned to our Google Developers Live calendar to catch the next one on September 18th.

Reporting improvements

In v201208, we’ve added 64 new columns which enable you to pull metrics for optimization, rich media, and video. Using these new columns, you’ll now be able to better track performance of your network including determining the interaction time of your rich media (e.g. RICH_MEDIA_INTERACTION_TIME), locating videos which complete the most (e.g. VIDEO_INTERACTION_COMPLETE), or analyzing the revenue resulting from optimized impressions (e.g. OPTIMIZATION_OPTIMIZED_REVENUE). In addition to these columns, we’ve added the CREATIVE_TYPE dimension and the ability to include custom fields to help you better break down your reports.

For applications which cannot process gzip files, you can now download reports already deflated using the new ReportService.getReportDownloadUrlWithOptions method. If you choose to not use gzip compression, we still highly recommend that you set the HTTP header Accept-Encoding: gzip to speed up downloads. We’ve also added the ability to include report properties (e.g. network, user, generation date, etc...) and remove the totals row. If there are any other types of report download options you’d like to see, we’d love to hear about them on the forum.

Creative additions

For publishers who are using the cutting edge features of DFP, we’ve added support for four new creative types: AdSenseCreative, AdExchangeCreative, RichMediaStudioCreative, and AspectRatioImageCreative. AdSense and Ad Exchange creatives allow you to traffic line item level dynamic allocation ads by serving ad slot code snippets as the creative asset. Rich media studio creatives allow you to fetch creatives created using the DoubleClick rich media studio. Although these creatives are mostly used in a read-only manner (since they are created in the rich media studio and not DFP), some fields are mutable, such as the duration, any CSS overrides, and URLs. Finally, aspect ratio image creatives let you upload multiple image assets of the same aspect ratio to give you control of how images should be scaled; these creatives are mostly used in a mobile environment given the variety of screen sizes and resolution of today’s devices.

Last but not least

In our ongoing effort to bring the API up to parity with the UI, we’ve also added a number of smaller features. These include additional company partner types, the ability to set the mobile platform type on ad units, a friendly display string for inventory sizes, the option to associate line items with creative sets , and support for the recently released device category targeting criteria.

Our API and outreach efforts are constantly growing, but we can't do it without you. If there is anything you'd like to see us do better, please let us know or introduce yourself in the next Google+ hangout on September 18th.

 - , DFP API Team
Labels: , , , ,

Authorization is an important concern when writing software that interacts with Google’s Ads APIs. We’ve recently improved our documentation and published resources documenting how to use OAuth2 with many of our Ads APIs.

OAuth2 is an authorization flow that allows you to direct a user to a specially crafted Google URL where they grant permissions to your software to make changes to their account. With an authorized access token, you can make requests to Ads APIs on the user’s behalf. Benefits include:
  • Users don’t need to provide a username and password - they just log into Google.
  • No CAPTCHA challenges.
  • Limited scope - the user will only be prompted to grant access to a specific part of their account. For example, they could grant access to AdWords without the application being able to see their email or calendar.
OAuth2 is supported by:
The Ads API client libraries supported by Google have built-in support for OAuth2. We’ve included examples demonstrating how to use this feature in all client libraries. See your respective product and language product sites for more information on OAuth2.

We’re also hosting a Google Developers Live event covering how to use OAuth2 on August 23rd. This will be recorded if you can’t make it. If you have any questions about OAuth2, please post on the respective product API forums.

 - , AdWords API Team
Labels: , , , , , ,

Today we are excited to introduce a new channel for communication - Ads Developers Google+ Page. It's a place to stay informed, engaged and connected on Ads products and developer tools.

Add our Google+ page to your circles for the latest product and feature announcements, best practices, case studies, as well as opportunities to interact with and learn from Google's Ads Developer Relations team and other members of the developer community.

We look forward to having one place to bring timely updates, concise announcements, and to share information in multimedia formats across all Ads products, as well as to listen and respond to your comments.


 - , Ads Developer Relations Team.
Labels: , , , , , , , , ,

We have some exciting changes and important announcements for the DoubleClick for Advertisers community as we begin to improve our overall approach to APIs for the product. This is just the first of many improvements that will come over the next several quarters.

DFA API v1.19 - Security at the Forefront

The newest release of the DFA API, v1.19, is now available. This release brings two major security enhancements. SSL encryption, a feature we originally slated for v1.18, is now mandatory on all API requests. This is in line with a Google-wide effort to leverage HTTPS connections for greater security.

Secondly, this release of the DFA API supports OAuth2 authentication in addition to the API passwords tied to your DFA user profiles. We recommend using this new approach. In time, we plan to phase out the profile-specific passwords in favor of making OAuth2 the single, standard way to authenticate against our API. Please see our documentation for more information on how OAuth2 is integrated with the DFA API and reference our client libraries, all of which will soon be updated with examples of using OAuth2 instead of an API password.

Our release notes page has been updated with complete notes on v1.19.

DFA Reporting Gets an API

Less than a year ago, we announced the availability of the new DFA Reporting system. This new system offers the power, flexibility and data access required to keep up with today’s always-connected, multi-device consumer. Compared to Report Central, data in the new DFA Reporting system is fresher, can be segmented by the hour, and includes a host of new features including geographic reporting for all ads. Today, we are pleased to launch an API for the new DFA Reporting system.

The DFA Reporting API is a language-neutral REST API that offers programmatic access to the same reports as can be generated through the DFA Reporting user interface. Along with improved speed and performance, the new API will allow you to create, edit, and schedule Standard reports. We will continue to launch additional features to the new DFA Reporting API over the next few months. Support for this API has been added to the Google APIs Client Libraries. The Java library currently has the most complete example set.

Version Enforcement on the Java DART API

The Java DART API, long the bread and butter of integrating with our ReportCentral service, has a large range of versions currently in use. We are going to begin enforcing a minimum version requirement on this API on November 3rd, 2012. At this time, clients will be must be using one of the newest versions of the Java DART API -- version 13.4, version 13.6, or version 13.8. We recommend you take the opportunity to consider the new DFA Reporting API. Come enjoy the benefits of its newer technology.

Changes to Our Deprecation Policy

This past April, Google announced changes to the deprecation policies surrounding our APIs to help keep our products moving and innovating quickly. DFA is joining this overall Google effort. As such, as of November 3rd, 2012, DFA will remove the depreciation policy for all of our APIs.

The removal of the deprecation policy doesn't mean we have changed the way we think about our APIs. As signaled by the launch of the new DFA Reporting API, we are more committed than ever to offering stable and relevant APIs to our developer community. We will continue to work very hard to communicate any changes to our APIs well in advance, regardless of the APIs' deprecation policy. Our commitment to our clients and to the API remains unchanged.

Until November 3,2012 we will continue the deprecation policy we currently have in place. With the the release of v1.19, version v1.17 is now deprecated. Version v1.17 will continue to be supported until September 8th, 2012, when it will be entirely removed from service, as previously announced. Meanwhile, version v1.18 will be deprecated in November and sunset in early December, 2012.

As always, we highly value your feedback and questions. Please join us on our forumwhenever you’d like to reach us.

- Joseph DiLallo, the DFA API Team
Labels: , ,

Interested in more Google Ads Developers Live (Office Hours) events? We know you are because attendance has been great!

We've scheduled another round of events for AdWords, AdMob, DFP and AdSense APIs. You can view the newly scheduled live events on the Google Ads Developers Live page. Please add the events you are interested in to your calendar. You can follow our schedule by subscribing to the Google Ads Developers Office Hours calendar, which is also linked on this blog’s sidebar.

Just like in previous live events, you can join these hangouts to ask us questions or provide feedback about our products. In response to your request we will be adding AdWords API sessions for the Asia Pacific region and Japan. If you are from Asia Pacific countries or Australia and couldn’t join the hangouts before due to timezone inconvenience, we hope you will find these additional sessions more convenient. The live events in Japan will be in Japanese.

Events will rotate throughout the week to accommodate more people. We are also planning to make some of these events topic-based, where we will introduce you to a new feature of our product and then answer your questions on that topic. The dates and topics for these sessions will be announced in advance in separate blog posts.


In case you haven’t joined us before, you will need 3 things to join the hangout:
These hangouts are informal and conversational, which make them a great place to ask questions or give us feedback. If you have questions about our office hours, reach out to us on the forums.

 - , Ads Developer Relations Team
Labels: , , , ,

In the first part of this series, we talked about integrating AdMob ads in a cocos2d application without diminishing performance. However, we conveniently overlooked how you’d go about handling device reorientation. This blog post will outline the two steps necessary for getting autorotation to work using v0.99.5b3 or higher of the cocos2d framework.


Step One: Setting UIKit Autorotation

cocos2d allows you to handle autorotation in two different ways (UIKit and cocos2d). Since we’re working with both UIKit views as well as Open GL views, we want to rely on UIKit autorotation. If not, we’d have to transform our GADBannerView manually. To make sure you’re using UIKit autorotation, set the GAME_AUTOROTATION directive on your platform of choice to kGameAutorotationUIViewController.

Once you’ve done this, check RootViewController.m to make sure shouldAutorotateToInterfaceOrientation: returns YES for all of the orientations that you support. cocos2d produces skeleton code that handles this method differently depending on the autorotation method you’re using, so make sure that you modify the code block where GAME_AUTOROTATION == kGameAutorotationUIViewController.


Step Two: Modifying View Layout

The final step is to modify our resizeViews: method so that it takes the orientation of the device into account when laying out the views. Rewrite resizeViews: as resizeViewForOrientation:, using the orientation parameter to lay out your GADBannerView. The code below, similar to the first blog post, assumes you’re laying out your banner at the top of the screen.

- (void)resizeViewsForOrientation:(UIInterfaceOrientation)toInt {
  // If the banner hasn't been created yet, no need for resizing views.
  if (!bannerView_) {
    return;
  }

  BOOL adIsShowing = [self.view.subviews containsObject:bannerView_];
  if (!adIsShowing) {
    return;
  }

  // Frame of the main RootViewController which we call the root view.
  CGRect rootViewFrame = self.view.frame;
  // Frame of the main RootViewController view that holds the cocos2d view.
  CGRect glViewFrame = [[CCDirector sharedDirector] openGLView].frame;
  CGRect bannerViewFrame = bannerView_.frame;
  CGRect frame = bannerViewFrame;
  // The updated x and y coordinates for the origin of the banner.
  CGFloat yLocation = 0.0;
  CGFloat xLocation = 0.0;

  // Move the root view underneath the ad banner.
  glViewFrame.origin.y = bannerViewFrame.size.height;
  // Center the banner using the value of the origin.
  if (UIInterfaceOrientationIsLandscape(toInt)) {
    // The superView has not had its width and height updated yet so
    // use those values for the x and y of the new origin respectively.
    xLocation = (rootViewFrame.size.height -
                      bannerViewFrame.size.width) / 2.0;
  } else {
    xLocation = (rootViewFrame.size.width -
                      bannerViewFrame.size.width) / 2.0;
  }

  frame.origin = CGPointMake(xLocation, yLocation);
  bannerView_.frame = frame;

  if (UIInterfaceOrientationIsLandscape(toInt)) {
    // The super view's frame hasn't been updated so use its width
    // as the height.
    glViewFrame.size.height = rootViewFrame.size.width -
                                    bannerViewFrame.size.height;
    glViewFrame.size.width = rootViewFrame.size.height;
  } else {
    glViewFrame.size.height = rootViewFrame.size.height -
                                    bannerViewFrame.size.height;
  }
  [[CCDirector sharedDirector] openGLView].frame = glViewFrame;

}

Now that you’re handling rotation, you’re going to have to resize your views in two different places. We’ve already covered this in initGADBanner: in the first post (simply use the interfaceOrientation property of UIViewController to call resizeViewsForOrientation: instead of resizeViews:). Here, we also have to call resizeviewsForOrientation: in willRotateToInterfaceOrientation:duration: as well. You can add this call after the skeleton code that cocos2d provides.

Ads inside your cocos2d application should now stay docked in place whenever device rotations occur. You can check out a full example from this blog post here. As always, feel free to direct any questions you have to our forum or join us for our upcoming hangout.


 - , AdMob Team
Labels: , ,