[go: up one dir, main page]

We are making some changes to the way qualityInfo and firstPageCpc fields are returned by AdGroupCriterionService in AdWords API. Currently, the qualityInfo and firstPageCpc fields are populated for BiddableAdGroupCriterion objects returned in response to AdGroupCriterionService.mutate API calls. Starting the week of June 15th, these fields will no longer be populated in mutate call responses. If you wish to retrieve QualityInfo or firstPageCpc for criteria, you need to retrieve them by making a get() call instead, using the appropriate selector fields. This change will affect all the active versions of the AdWords API.

If your code depends on the current behaviour of AdGroupCriterionService.mutate, please make sure you migrate your code by the week of June 15th. If you have any questions about these changes please reach out to us in the forum or during one of our office hours hangouts.

Update: We have extended the date for this migration till the week of 16th July.

As previously mentioned, AdWords now supports new matching behavior for exact and phrase match keywords. Support was added in v201109_1 that allows toggling of this setting. In order to better support reporting on the performance of this new feature, the Search Query Performance Report will gain a new field, MatchTypeWithVariant, which will now return two additional enum values in addition to the existing values of the MatchType field (enum values / display values):
  • NEAR_EXACT / exact (close variant)
  • NEAR_PHRASE / phrase (close variant)
The existing MatchType field will continue to return only the values it does today. This means that a value that would return “exact (close variant)” from MatchTypeWithVariant will return as “exact” for field MatchType.

This new field will be available starting the week of Monday June 4th.

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


The Java Client libraries for Ads APIs are some of the most popular, used by thousands of developers each day to manage their AdWords, DFA and DFP accounts. Since they were initially written years ago, we’ve gotten a lot of feedback from developers using the libraries. We’ve tried to incorporate as many suggestions as possible, but due to the legacy architecture, certain changes were not feasible.

Today we’re pleased to announce that we are officially supporting a new from-scratch rewrite of the Java Library! It is now production-ready and is no longer experimental. Read on for some reasons why you’ll want to take the new library for a spin right away.
New Features
New features in the rewritten library include:
  • Product level support for AdWords, DFA and DFP with shared common layer code.
  • Library is now hosted on Maven.
  • OAuth1.0a and OAuth2.0 support.
  • Uses the SLF4J logging facade.
  • More control over building your session, providing authentication and more.
  • Experimental AppEngine support via JAX-WS.
Migrating
The two biggest changes involve how to configure your session and how to obtain Service objects.

Here’s how you configure an AdWordsSession:
AdWordsSession session = new AdWordsSession.Builder()
    .fromFile()
    .withClientLoginToken(clientLoginToken)
    .build();
Here’s how you obtain a reference to a service:
AdWordsServices adWordsServices = new AdWordsServices();
CampaignServiceInterface campaignService =
    adWordsServices.get(session, CampaignServiceInterface.class);
Check out the migration guide we have recently published on the new project page wiki. You’ll find these procedures described in depth, along with best practices for using these classes.

The new library will be the primary focus of development moving forward. The existing AdWords and DFP java libraries are now in maintenance mode and we will continue to add support for new AdWords and DFP API releases for the near future.

If you find any bugs, have a patch to contribute or just a feature request, please feel free to file an issue on our issue tracker.

Previously, we discussed extending the set of operations in version v1.18 of the DFA API which will receive a limit of 1000 objects per page on June 2nd, 2012. Additional operations have been added to this set since the announcement. The new list is as follows:

The getPlacementsByCriteria operation has been capped at 1000 results per page since version v1.18’s release. The original post has also been updated with this new list. You can reach us with any questions you may have on our forum.

The newest version of the DFA API is now available: v1.18. This release adds support for In-Stream Video creatives and makes some assorted improvements, including better error messages and trimming out some unused fields. This post reflects just some of the changes in the release. Our updated release notes page gives you a more in-depth breakdown of what has changed since the previous version.

In-Stream Video Creatives

New to v1.18, you can create and manage your In-Stream video creatives through the API. Several new classes have been added to the creative service to represent these objects. You can expect to see examples of their use in our updated client libraries.

Capping on Page Sizes

Most get operations in the DFA API return pageable result sets. We are now beginning to enforce reasonable limits on the number of objects within an individual pages (also known as pageSize). With the release of v1.18, the placement service’s getPlacementsByCriteria operation is limited to a maximum of 1000 objects in a single page.

[Update 5/17/2012: The following list of operations has been extended as explained in this blog post.]

Beginning June 2nd, 2012, the same limit also applies for the following operations:

All affected operations will have a default page size of 1000 if a page size is not provided.

Deprecation and Sunset of Older Versions

With the the release of v1.18, version v1.16 is now deprecated. Version v1.16 will continue to be supported until June 2nd, 2012, when it will be entirely removed from service, as previously announced.

Meanwhile, version v1.17 will be deprecated in August and sunset in early September, 2012.

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

We're very pleased to announce the availability of the AdWhirl to AdMob Ad Network Mediation Import Pipeline. This functionality--accessible from mediation.admob.com--will enable you to import all of your relevant configuration data from AdWhirl in just a few clicks!

Getting started is simple! Here are the steps you'll want to follow to import a configuration:

  1. Navigate to mediation.admob.com and click the Import Placement from AdWhirl link. Read through the notes.
  2. Click Log in to AdWhirl. You'll be redirected to an AdWhirl authorization page where you should enter your AdWhirl account's email address and password.
  3. Click Submit. Assuming your info is correct, you'll be redirected back to AdMob's Import Placement from AdWhirl workflow, where you can choose a particular placement to pull over.
  4. Mouse over a placement and click the Select to Import button. After confirming things are correct on the Review & Import screen, go ahead and click the final Import button.
  5. Put your feet up, grab a brew; you're done! Take a moment to bask in the warm glow of your accomplishment. The placement will now appear in your AdMob Ad Network Mediation Placements interface.

The AdMob Ad Network Mediation product offers many improvements over AdWhirl, including enhanced stability, support for tablet sizes, revenue optimizations by country, and improved reporting. We hope you give it a look! As always, if you have questions or concerns, you can get a hold of us on our forum.

New to v201204 of DFP API are custom fields, which can be applied to orders, line items, and creatives. This new feature gives you the ability to include additional information on DFP entities without having to implement data persistence in your own system. They are saved when the entities are saved on the DFP servers which ensures data consistency and removes the need for syncing.

Data Types
The following are the supported data types of a custom field:
  • String
  • Number
  • Toggle (true/ false)
  • Drop-down (selection from user-defined values)
These data types should cover some of the most common use cases for custom fields such as comments (string), metrics (number), and internal system status (toggle/drop-down).

How-To
You can create and manage your custom fields and custom field options (for drop-down custom fields) with the new CustomFieldService. Please make sure you have the feature enabled for your network before you try to set up custom fields. We are also working on bringing custom fields to the user interface, so be on the lookout for them!

Walk-Through
The following Java sample shows how you can add a string and drop-down custom field value to your line item. This assumes that you have already created the custom fields and custom field options. You can check out how to create them using the CreateCustomFields and CreateCustomFieldOptions examples in the client libraries.
Long customFieldId = Long.parseLong("INSERT_STRING_CUSTOM_FIELD_ID_HERE");
Long dropDownCustomFieldId = 
    Long.parseLong("INSERT_DROP_DOWN_CUSTOM_FIELD_ID_HERE");
Long customFieldOptionId = 
    Long.parseLong("INSERT_CUSTOM_FIELD_OPTION_ID_HERE");
Long lineItemId = Long.parseLong("INSERT_LINE_ITEM_ID_HERE");

// Get the line item.
LineItem lineItem = lineItemService.getLineItem(lineItemId);

// Create custom field values.
List customFieldValues = new ArrayList();

// Create the String custom field value.
TextValue textValue = new TextValue();
textValue.setValue("Custom field value");
CustomFieldValue customFieldValue = new CustomFieldValue();
customFieldValue.setCustomFieldId(customFieldId);
customFieldValue.setValue(textValue);
customFieldValues.add(customFieldValue);

// Create the drop-down custom field value.
DropDownCustomFieldValue dropDownCustomFieldValue =
    new DropDownCustomFieldValue();
dropDownCustomFieldValue.setCustomFieldId(dropDownCustomFieldId);
dropDownCustomFieldValue.setCustomFieldOptionId(customFieldOptionId);
customFieldValues.add(dropDownCustomFieldValue);

// The line item can contain custom field values for the field you are
// trying to set or an unrelated one.  The following checks that you only 
// add existing custom field values for custom fields different from the 
// ones you are setting.
if (lineItem.getCustomFieldValues() != null) {
  for (BaseCustomFieldValue oldCustomFieldValue : 
      lineItem.getCustomFieldValues()) {
    if (!oldCustomFieldValue.getCustomFieldId().equals(customFieldId)
        && !oldCustomFieldValue.getCustomFieldId().equals(
        dropDownCustomFieldId)) {
      customFieldValues.add(oldCustomFieldValue);
    }
  }
}

// Set the custom field values on the line item.
lineItem.setCustomFieldValues(customFieldValues.toArray(
    new BaseCustomFieldValue[]{}));

// Update the line item on the server.
LineItem[] lineItems = lineItemService.updateLineItems(
    new LineItem[] {lineItem});
And that’s it! For the full Java code example, you can refer to the SetLineItemCustomFieldValue in the client library.

With this new feature, we aim to help you create stronger integrations with DFP through the API. If there are any features you would like us to demonstrate, please don’t hesitate to let us know with a forum post or at a Office Hour Hangout.

The Ad Exchange Team is pleased to announce the launch of v201109_1 of the Ad Exchange Buyer SOAP API, a dot release which includes the following services that are relevant to Ad Exchange Developers:


Moving forward, we will use dot releases which will allow us to launch features more quickly; v201109_1 does not start the sunset on prior versions.

The full set of release notes is available here. If you have any questions please reach out to us in the DoubleClick Ad Exchange forum.

We're very happy to announce the release of AdWhirl v3.2! This version brings us support for the latest and greatest from several ad networks. In particular:

Android:

  • Support for AdMob v6.0.1
  • Support for Millennial v4.5.1
  • Support for InMobi v350

iOS:

  • Support for AdMob v6.0.4
  • Support for Millennial v4.5.5
  • Support for InMobi v350

As always, you can find the latest SDKs available on our download page. Or, feel free to snag the source: (Android | iOS). If you encounter any issues, don't hesitate to contact us on our forum or during Office Hours--times to be announced on our blog.


Editor’s note: We’d like to share this post from Chrix Finne which announces updates to the Google AdMob Ads SDK. -- Eric Leichtenschlag, Ads Developer Relations Team

Today we are posting an update to the AdMob SDKs for iOS and Android. This SDK update features several minor bug fixes and improvements.

We are also releasing an optional version of our SDK for iOS that includes the UDID parameter, which is used to improve ad performance and relevance. Apps utilizing this version must obtain appropriate user consent for sending device identifier information in compliance with relevant iOS policies.

Posted by Chrix Finne, Product Manager

In an effort to make more features available faster to AdWords API users, we’re launching AdWords API v201109_1, a dot release which includes services to help API users incorporate some recent AdWords web interface launches into their applications. New features include:
  • Keyword match properties NEAR_EXACT and NEAR_PHRASE, which allow API users to opt in/out of these match types.
  • LocationSyncExtension and the reports download service now have OAuth 1.0 support, bringing these services in line with others in the API.
As part of this dot release, we are also launching a few other features that will be available through an invitation-only beta. Similar to beta programs for the AdWords interface, the goal of this beta is to give developers earlier access to specific features, allowing us to incorporate feedback more quickly and innovate more effectively.

Moving forward, we will use dot releases to launch AdWords features more quickly. AdWords API v201109_1 does not start the sunset on prior versions, so you do not need to upgrade immediately. 

Complete release notes are available here. If you have any questions about these changes please reach out to us in the forum or during one of our office hours via Google+ Hangouts.

v201204 of the DFP API has launched and is ready for you to explore. In this version, we’ve added custom fields, expanded team and user functionality, and updated the conversion reports columns. A full list of features can be found on our release notes page.

Custom fields

Custom fields is a new feature to the API that lets you add attributes to entities, such as orders and line items. For example, you can add your own field to a line item that would let salespeople add comments as a string. Those comments would then be placed into custom field values that are added to each line item. Support for custom fields will be coming or the DFP UI soon, but if you have this feature enabled on your network now, you’ll be able to start working with them right away.

Teams changes

The way in which users are added to teams has changed starting in v201204. In previous versions, users were added to team objects directly. Now, you can associate users and teams, much like line items and creatives. The new associations will also let you define per user permissions, such as only letting some users have read-only access.

Version deprecation reminder

As a reminder, we are retiring support for v201103, v201104, and v201107 on May 11th. If you haven’t upgraded yet, now would be a great time.

Our next hangout is May 9th and we’d love to see you there. As always, let us know if you have any questions on our forum.

 - , DFP API Team

In this blog post, we will help you understand how you can monetize your mobile applications while following our ad placement guidelines to ensure a good experience for your users.

As you may know, Google takes issues regarding program policy compliance very seriously. We have our AdSense program policies and AdMob program policies to help ensure a positive experience for our publishers, our users, and our advertisers. As such, we ask that our publishers/developers comply with these policies.

One of the most common policy violations is placing ads in a way which can trigger accidental clicks. Your ads’ proximity to the other elements within your application can influence whether or not users click on ads by accident.

Here are some tips to decrease the chances of accidental clicks:

  1. Ads should not be right next to interactive buttons, such as a “next” button, or on a game play screen where users are interacting continuously with the application. We have seen that when a user is clicking or tapping repeatedly within an application and there is an ad near or within the interaction area, there is a much higher rate of invalid activity.
  2. If the space within your application is limited, it helps to then delineate the ad from the application content by creating a thick border between the ad and the application’s interactive portion.
An example of a placement to avoid:


A recommended ad placement in this scenario:



Please double check your ads’ implementation with the tips above. With the right implementation, you’ll be able to monetize your application properly without accidental clicks.