Google Ads Developer Blog: Şubat 2013

Updates to the AdWords API Terms and Conditions

22 Şubat 2013 Cuma

We’ve always enabled advertisers to export their ad campaigns from AdWords to accomplish their online advertising goals. We recently committed to updating our AdWords API Terms and Conditions to give advertisers using third party ad management tools even more flexibility.

Today, we’re making the following changes to the Adwords API Terms and Conditions:

We’ve removed former Section III(2)(c)(i) (“Co-Mingling of AdWords Data: Input Fields for Creation Functionality and Management Functionality”), which covered Adwords API clients showing input fields that collected or transmitted campaign management data in the same tab or screen with the content of third parties.
We’ve removed former Section III(2)(c)(ii) (“Co-Mingling of AdWords Data: Copying Data”), which covered AdWords API clients offering functionality that copied campaign management data between Google and a third party.
We’ve updated Section (III)(2)(f) ("Required Minimum Functionality"), in part by adding subsection (ii) (“Data Transmission”), which requires disclosure to users of the names of networks the data is transmitted to, explanation of any incompatibilities, and opportunities for users to resolve any issues.

For more information about these changes, please review our updated Terms and Conditions.

- The AdWords API Team

IMA HTML5 SDK v3 released

21 Şubat 2013 Perşembe

IMA HTML5 SDK

Ad rules as described in the Help Center

Optimized Pods* - TV-style ad breaks consisting of multiple video ads which algorithmically chosen to optimize for line item priority, pacing goals, and revenue

Video Fallback* - Option to maximize your overall fill-rate across multiple third-party ad networks and redirects

Skippable Video Ads* - Video ads which may be skipped by the user after a minimum duration as configured in DFP

IMA Flash SDKAPI documentationv3 Release HistoryNote:integration instructionsforumGoogle+ page

- Joe Roepcke, IMA SDK Team

New Hangouts Coming Your Way

19 Şubat 2013 Salı

You spoke and we listened; we like to do that in Developer Relations! We've heard your comments regarding Google Developer Live (GDL) events and we understand that they are often key to solving complex questions you have. In order to keep up with your demand we've scheduled another round of Hangouts for all of our products over the next few months.

In the upcoming Hangouts you'll notice that we are experimenting with some new formats. On some products you'll see engineer interviews, third party product discussions, or the typical Office Hours. You can view the newly scheduled hangouts on the Google Developers events page. Please RSVP by clicking the “I’ll be there” button if you plan on attending.

In case you haven’t joined us before, you'll need four things to join the hangout:

A Google+ account (sign up here)
The Google voice and video plugin installed on your computer
A quiet place to hangout so we can hear you.
A microphone is required and a video camera is preferred.

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 GDLs, reach out to us on the forums.

- Paul Rashidi, DFP API Team

New AdMob SDK v6.3.0 and Deprecation of Old SDKs

14 Şubat 2013 Perşembe

We are happy to announce the latest SDK release, v6.3.0, for both Android and iOS. v6.3.0 is a bug-fix release that includes:

Improved logging messages on Android

Fix for crash in Eclipse when defining an AdView in the graphical XML layout editor

New logging statement that provides the ID to pass to request.testDevices on iOS to enable test ads on a specific device

Support for test ads on iOS6

Fix for crash in GADMraidInterceptor on iOS

Check out the release notes for a full list of updates. Let us know on the forum if you have any questions about the new release. You can also follow us on our Google+ page for ads-related updates.Deprecation of Old AdMob SDKsWith the release of v6.3.0, we are deprecating old versions of the AdMob SDK to help us better support newer versions. Starting March 18, 2013, we will no longer support ad requests made through AdMob SDKs released before 2011. Requests that come from apps using deprecated versions of the SDK will no longer receive ads.Which versions of the SDK are you deprecating?We are deprecating all SDKs which were released before 2011. On Android, this includes any SDK released on November 9, 2010 or before. On iOS, this includes any SDK released on September 8, 2010 or before. See below for information on how to determine if your SDK version is being deprecated.How do I determine if my SDK version is being deprecated?For Android, if your code references com.admob.android.ads.* then you are using one of the SDKs that needs to be updated.For iOS, if you have headers such as AdMobView.h or AdMobDelegateProtocol.h in your application, then you are using one of the SDKs that needs to be updated.I’ve upgraded my app to use a recent version of the SDK. What will happen to traffic coming from older versions of the SDK starting on March 18?We recommend you encourage your users to upgrade to the latest version of your app. Traffic from older versions of the app still using the legacy SDKs will no longer receive ads.Are there any additional benefits to upgrading?The more recent SDK versions provide performance enhancements, access to our latest ad units, and fixes for common issues.

- Eric Leichtenschlag, AdMob Team

Optimization Series: Disapproved Ads

8 Şubat 2013 Cuma

In December, we introduced the Ad Exchange Real-Time Bidding Optimization Series on the developer's blog with our first post on post-filtered bids.

Today, we’ll address one of the common causes: Disapproved ads.

We’ll revisit the definition of disapproved ads, review the main reasons for disapproval, and the steps you can take to ensure your ads will not be disapproved.

What is a disapproved ad?
A disapproved ad is an ad in which the bid response is filtered out due to one or more reasons. To determine the reason for which your ad was disapproved, review your snippet status report. The snippet-status-report-proto.txt file lists all the issues described in the <DisapprovalReason> section of the report.

Note: As a proactive measure, the creative REST API provides methods for submitting a creative for verification, checking the status of a creative that you have submitted, seeing disapproval reasons for your submitted creatives, and retrieving a list of all your approved creatives before bidding on the creative ad.

What are the main reasons for an ad being disapproved?
Most disapprovals occur when ads fail to comply with the DoubleClick Ad Exchange policies for content and creative, or data and third-party ad serving.

Content & Creative: DoubleClick Ad Exchange reserves the right to disapprove ads in breach of the content and creative policies outlined in the Google AdWords Advertising Policies and to suspend entire accounts for certain violations. Here are the most common content and creative policy violations that may cause your ad to be disapproved:

Incorrect Destination URL Declaration means the actual destination URL does not match the declared destination URL.

Length of Image Animation means the length of the image animation is longer than allowed.

Adult Image/Video Content means the ad contains adult images or video content.

Landing Page Disabled means the landing page does not conform to Ad Exchange policy.

Pop-Up means the ad causes a pop-up window to appear.

Media Not Functional means that something is wrong with the creative itself. Please preview your third-party ad tag in a browser to make sure it is working properly.

Broken URL means the click through URL does not work properly. Please test your third-party ad tag in a browser to make sure it is working properly.

Data and Third-Party Ad Serving: In order to run ads on the Google Display Network through the DoubleClick Ad Exchange, buyers must follow the requirements for third-party ad serving. Here are the most common data and third-party ad serving violations that may cause your ad to be disapproved:

Problem with Click Macro means there is a problem with the way the click macro is used.

Invalid Fourth-Party Call means the ad makes a fourth-party call to a vendor that is not approved. See this list of vendors who are allowed to be on the DoubleClick Ad Exchange platform.

Usage of Locally Shared Objects (LSO) means the creative sets an LSO object.

No Border means the ad had a white or black background and no border.

Blank Creative means the ad serves a blank creative. Please preview your third-party ad tag in a browser to make sure the creative is loading properly.

Incorrect Ad Technology Declaration means the ad technology declaration is not accurate.
Google has an approved list of vendors who are allowed to be on the DoubleClick Ad Exchange platform.

Use of Raw IP means the ad contains a URL that uses a numeric IP address for the domain.
Please make sure to use the domain, and not the IP address.

Remember, each disapproved ad that is filtered out is a valuable impression you’ve missed out on. Therefore, always:

Leverage the creative REST API to submit creatives for verification, check the status of a creative that you have submitted, see disapproval reasons for your submitted creatives, and retrieve a list of all your approved creatives before bidding on the creative ad.
Review any disapproved ads in the snippet status report.

Have questions or want to enable the creative REST API or review your snippet status report for your disapproved ads issues? Reach out to your Ad Exchange account team.

Posted by the Ad Exchange Team

Geography data changes in DFP and how they affect the API

8 Şubat 2013 Cuma

We are constantly working to improve DFP to help our publishers serve ads in the best way possible. One recent improvement to DFP has been an update to the geography data used for targeting. This update also deprecates locations that may no longer exist, may be obsolete, or are no longer recognized. Any deprecated locations targeted by existing line items will be ignored, but still shown so you can update them appropriately.

Keeping our geography data up-to-date allows for more accurate ad targeting, which better helps publishers serve ads to their target audience. This update also lays the ground work for some further updates we have planned. These changes may affect how you use the API to integrate your product with DFP, so we wanted to give some tips to smooth out the transition.

All deprecated locations can be found by using PublisherQueryLanguage.select on the geo tables with the following query: "WHERE targetable = false"
When creating or updating line items with geo targeting, ensure that you are using the base Location object instead of one of the Location subtypes.
For developers who have cached any geo targeting tables, we recommend you update your local database of targetable locations. When doing so, ensure you examine the targetable field and mark it as deprecated or remove it from your local database so as not to use it in the future.

You may also notice some hierarchy changes in the new geo data. For example, some cities may no longer have a metro region. These changes are intentional as we work to better update and classify our geographic locations. If you have questions, please feel free to ask them on our forum.

To tie this all together, we have written an example that checks every line item in a network to see if it is targeting a deprecated location and needs to be updated. Doing this check will save you trouble later if you try to update a line item that is targeting a deprecated location as you will need to remove the deprecated location from targeting before DFP will allow you to make the update. A snippet of the example is as follows, and you can find the full example on the PHP client library google code site.

  // Find all untargetable locations.
  $untargetableLocationIds = getAllUntargetableLocations($user);
  printf("Found %d untargetable locations.\n",
      count($untargetableLocationIds));

  // Build a map of geo targets to the line items targeting them.
  $geoTargetToLineItemsMap = buildGeoTargetToLineItemsMap($user);

  // Find all the deprecated geo targets from that map.
  $lineItemsToUpdate = findLineItemsToUpdate($geoTargetToLineItemsMap,
      $untargetableLocationIds);

  $i = 0;
  // Print the line items that need to be updated.
  foreach ($lineItemsToUpdate as $geoTargetId => $lineItemIds) {
    printf("%d) The following line items are targeting deprecated location "
        . "%d and need to be updated: %s\n", $i, $geoTargetId, implode(', ',
        $lineItemIds));
    $i++;
  }

- Vincent Tsao, DFP API Team

New AdWords API features supporting enhanced campaigns

6 Şubat 2013 Çarşamba

We recently announced improvements to AdWords called enhanced campaigns. Today’s consumers are constantly connected and using many different devices, so we’ve developed enhanced campaigns to help advertisers reach them more effectively and more easily.

As part of the announcement of enhanced campaigns, we’ve enabled several new capabilities in the API including the ability to:

Upgrade campaigns to enhanced campaigns
Submit new ads marked as mobile preferred
Set a mobile bid adjustment
Retrieve Google suggested mobile bid adjustment for upgrading legacy campaigns to enhanced campaigns

These features are available for AdWords API developers through the forwardCompatibilityMap field, already available in Adwords API versions v201206 and v201209. For more information on how to use the Forward Compatibility Maps please consult this guide.

With the launch of enhanced campaigns, we have also updated the Required Minimum Functionality. Please review these materials carefully as you begin to develop your applications to create and upgrade to enhanced campaigns.

As always, we encourage you to review the resources in the AdWords API client libraries, as we have updated code examples. And if you have any questions, please post them on the AdWords API forum.

Posted by S Srikanth Belwadi - Product Manager, Adwords

Ads Developer Blog