Tag Archives: AdSense

Updated RMF Schedule and Non-Compliance Fees on the AdWords API Rate Sheet

If you're a software developer that builds tools for agencies or other advertisers to manage AdWords campaigns, or if you use the AdWords API to provide reporting dashboards to clients, please take a minute to review these updates.

In May 2014, we extended the deadline for all Required Minimum Functionality (RMF) until December 31, 2014. Now that the extension period has expired, we’d like to explain how we’ll review RMF in 2015. If you’re subject to RMF, you’ll receive emails in the days and weeks ahead explaining the details, so please be sure to update your contact information in the AdWords API Center of your MCC account.

At a high level, the review will look like this: first you’ll confirm your contact information and help ensure the demo account for your tool is working properly. Then, if any requirements are missing from your tool, you’ll receive a detailed non-compliance email followed by a 30-day “fix-it” period to bring your tool into compliance. We hope this will provide sufficient time to address any shortcomings. After that, if you’re not in compliance after the 30-day fix-it period, you’ll be subject to non-compliance fees (which have been reduced) as specified on the updated API rate sheet. And if you’re still not in compliance within 120 days of receiving the initial non-compliance email, your token may be downgraded to Basic Access. Throughout the process, we’ll send you reminder emails of the important milestones and deadlines.

Please note again that we’ve reduced the fees associated with non-compliance. You can see a full list of changes to the API rate sheet.

If you have any questions please feel free to reach out directly to the API Review Team.

-- AdWords API Team

New features in AdWords scripts

We have added the following new features in AdWords scripts.

Bidding

You can now manage bids for your campaigns, ad groups and criteria in AdWords scripts. Support is also provided to retrieve and update shared bidding strategies in your account. The current release allows you to use MANUAL_CPC, MANUAL_CPM, BUDGET_OPTIMIZER or CONVERSION_OPTIMIZER as bidding strategies; and set CPC, CPM or CPA bids to your biddable entities. See our guide and code snippets to learn more about this feature.

Display criteria

You can now manage the following display criteria through AdWords scripts: keywords, placements, topics, audiences. Check out our code snippets for usage examples.

New ad extensions

You can now manage review and callout extensions for your campaigns and ad groups in AdWords scripts.

If you have questions or feedback about these features, let us know on our forum.

Anash P. Oommen, AdWords Scripts Team

Upcoming removal of AdWords legacy PLA objects

Now that all existing legacy Product Listing Ads campaigns have been upgraded to Shopping campaigns, some cleanup is in order. On March 23, 2015, we'll be removing criteria and ad objects related to AdWords legacy PLA campaigns, specifically:
  • All AdGroupCriterion objects for Product criteria (Product Targets):
    • Criteria that accrued impressions will be marked REMOVED. These objects will continue to appear in API reports in v201406 and v201409.
    • Criteria that did not accrue impressions will be permanently deleted. These objects will no longer appear in API reports.
  • All ProductAd objects for legacy Product Listing Ads campaigns will be marked DISABLED. These objects will continue to appear in API reports in v201406 and v201409, regardless of whether or not they accrued impressions.

Actions required

If you are interested in capturing the components of legacy Product Listing Ads campaigns that did not accrue impressions, retrieve that information before March 2015 using the appropriate services (e.g., AdGroupCriterionService, AdGroupAdService).

Learn more

If you haven't started using Shopping campaigns, check out the following resources. Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.

- Josh Radcliff, AdWords API Team

Announcing the launch of account-level tax and shipping and improved product dates in Content API for Shopping

We are pleased to announce the launch of API support for account-level tax & shipping for the Google Content API for Shopping v2. Previously, this was only available on the Merchant Center UI. This API feature will match the configuration options available in the UI.

This launch enables you to programmatically specify default tax and shipping rules that apply to all products within an account through the Accountshipping and Accounttax services. Specifically, the account-level tax and shipping rules apply to all products, but can be overridden by item-level tax and shipping settings, which are in the Products service. Note that products' taxes and the Accounttax service are only applicable to products targeting the US.

The shipping settings allow you to set-up different shipping services using calculation methods ranging from flat rate to carrier-based rates, and you can use rate tables or decision trees to specify conditions on price, weight, and delivery location. Please see our guide and reference documentation: Accountshipping service, Accounttax service, which will help you get up and running with these new services.

The second addition is new date fields that many have asked for. The Productstatuses service in v2 of the API has 3 new fields:
  • creationDate: the date that a product was first inserted into the Merchant Center.
  • lastUpdateDate: the date that the product was last updated. This may be the same as the creationDate. It also reflects updates from Inventory service.
  • googleExpirationDate: the date that your product will expire in Google Shopping. By default, products usually expire after 30 days of no updates.
Also, the Products service contains an expirationDate field. This field represents the date as submitted by the merchant. The field is optional, and can be useful for setting an expiration date that is closer than 30 days away.

Another use case of expirationDate is for products you wish to expire later than 30 days away; for example, 40 days away. As you continue to resubmit the product, this date will remain unchanged, and the product will not expire until the expirationDate is reached. Remember that if you don’t resubmit a product within a 30-day window, it will automatically expire, regardless of what date you set in expirationDate. There is no equivalent v1 field to expirationDate.

On that note, please be aware that these new features are not available in v1, which is deprecated and will be sunset at the end of February 2015.

We hope these new features will simplify your process for configuring tax and shipping settings, and clarify your product expiration dates. As always, feel free to reach out on the developer forums if you have any questions.   —Yufeng Guo, Shopping Developer Relations

Mobile Ads SDK Interstitial Best Practices

As you know, interstitials are a great way to monetize your app while still providing a great user experience, with natural "commercial breaks" in your user flow. However, interstitials can take a while to load, and we know that this can make it tricky to implement since you must explicitly call loadAd() before calling show().

A common mistake is to call interstitial.show() in the onAdLoaded() callback. This makes the show() call not dependent on the app state, but on the asynchronous loading. Since the developer doesn't control when the onAdLoaded() callback happens, this provides a terrible user experience; the ad will show as soon as it's finished loading, which could be in the middle of another user interaction. This can result in policy violations due to accidental clicks.

Instead, we recommend loading the ad earlier in the lifecycle of the application, then polling interstitial.isLoaded() to see if the ad is ready to be shown. If it isn't ready, we recommend moving to the next state in the application.

We provide an example of proper interstitial loading in our sample "Impossible" game. When the game begins, we call loadAd() on the interstitial. When the user loses and clicks the button to try the game again, we check to see if the ad is loaded with isLoaded(). If it is, then we show an ad before starting the new round. Otherwise, we show a toast message that the ad isn't loaded and begin a new round.

This example focuses on the Android experience, but the same ideas apply to iOS. We hope our new interstitial example can help you create the best user experience as you integrate the Mobile Ads SDK into your apps. Check out this video for more on interstitial best practices. And as you're adding interstitials to your app, hit us up with technical questions on our developer forum!

 - , Mobile Ads Developer Relations

Reducing Google Play services’ impact on APK size

Like any Android library, the Google Play services SDK impacts the final size of applications that include it. Good developers care about the size of their apps, so today we’d like to show you two ways that you can leverage the Android plugin for gradle to reduce the APK size of applications that include Google Play services.

  1. Split JAR Architecture

    Beginning with Google Play services 6.5, additional maven artifacts have been added to the Google Repository that contain single domains of functionality. This means that you can include just those portions of Google Play services that your app uses. For example, here’s how to configure gradle to incorporate the JAR that contains functionality relating to ads:


    dependencies {
        compile 'com.google.android.gms:play-services-ads:6.5.+'
    }

    That line instructs gradle to include everything Mobile Ads developers need, with the exception of the IMA SDK JAR needed for IMA applications.

    Please note that if you currently initialize Mobile Ads SDK banner ads via XML layout files, you should continue including the full Google Play services artifact. See this blog post for more information.

  2. Shrink Resources

    The Android gradle plugin supports the ability to automatically exclude unused resources during the build process via the shrinkResources gradle property. To take advantage of this in your release builds, just add “shrinkResources true” to your build.gradle file’s release configuration:


    android {
        buildTypes {
            release {
                minifyEnabled true
                shrinkResources true
            }
        }
    }

    Note that the shrinkResources property requires that minifyEnabled be set to true as well, though that’s already a good practice for release builds.

Both of these techniques are quick to implement, so consider giving them a try. In testing, the use of shrinkResources and the new, split JAR maven artifacts reduced the APK size of our Interstitial Example by 1.2MB -- almost 50%!

If you have questions about these techniques and how to put them to work in your applications, visit us on the Mobile Ads SDK forum or the IMA SDK forum.

 - , Mobile Ads Developer Relations

Bulk Upload in AdWords Scripts

AdWords scripts now support bulk changes to your account through uploading data in CSV format. You can upload data from a CSV file on Google Drive, a Google spreadsheet, a Microsoft Excel spreadsheet, or construct a bulk upload request in your script at runtime.

AdWords scripts currently support the following operations for bulk upload:
  • Campaign management: You can create, edit or delete campaigns, ad groups, keywords and text ads using bulk upload. You can also edit existing ad group criteria, ads and product groups.
  • Offline conversions: You can upload offline conversions to your account using bulk upload.
Learn more about this feature on our guide, and check out our code snippets for usage examples. If you have questions or feedback about this feature, let us know on our forum.

Anash P. Oommen, AdWords Scripts Team

Tips for a Smooth Transition to Content API for Shopping v2

The deadline for the migration to v2 of the Content API for Shopping is less than 2 months away! As such, we would like to take this opportunity to highlight some useful features in the developer documentation for the Content API for Shopping, which will make it easier to find the information you need:

  • The Migration Guide shows you how to smoothly transition from v1 to v2.
  • The Guides section features in-depth coverage of implementing many aspects of the API.
  • The search bar now allows for auto-complete responses as you type your query.
  • Running into errors? Consult the Common Errors page, located in the Reference section.
  • The Reference section also contains our detailed descriptions of each API call, as well as an in-browser.
  • For troubleshooting your requests, check out the API dashboard.
  • If you have additional questions about the API, please head over to our support forum.
We hope these features will make it easy for you to navigate the documentation and find the help you are looking for.

  —Yufeng Guo, Shopping Developer Relations

Deprecation of active view NOT_* report columns in the DFP API

In the coming weeks, we will be deprecating all ACTIVE_VIEW_NOT* report columns in v201405, v201403, v201311 and v201306 of the DFP API. These columns are no longer supported in the DFP query tool, and the DFP API is following suit. The following columns will be affected:

Column.TOTAL_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.TOTAL_ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Column.AD_SERVER_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.AD_SERVER_ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Column.ADSENSE_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.ADSENSE_ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Column.AD_EXCHANGE_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.AD_EXCHANGE_ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Column.ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Migration
Normally all features are supported until the API version is sunset. This deprecation is a rare case where these report metrics are being disabled for existing versions due to product changes related to viewability. If you are using v201408 or later, you will not be affected by this deprecation. If you are currently using these columns in v201405 or earlier, you can replace them with their logical opposites. Alternatively, to retain the same metrics, you can calculate them from the logical opposite and the rate. For example, Column.TOTAL_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS is equivalent to

Deprecation errors
If you do not migrate, your reports will return the following error:

ReportError.COLUMNS_NOT_SUPPORTED_FOR_REQUESTED_DIMENSIONS

If you have any questions or migration troubles, please reach out to us on our developer forum.

 - , DFP API Team

Introducing the DCM/DFA Reporting and Trafficking API

If you programmatically manage and report on DoubleClick Campaign Manager (DCM) campaigns, you know that trafficking and reporting tasks have traditionally been handled by separate APIs. We realize that this can be inconvenient so today we're introducing a unified solution: the DCM/DFA Reporting and Trafficking API!

This release constitutes a new major version (v2.0) of what was previously known as the DFA Reporting API, adding functionality previously only available in our dedicated trafficking API. While older versions of our dedicated reporting and trafficking APIs will continue to remain available until September 30th, 2015, we recommend that you adopt this updated version as early as possible to take advantage of all of its new and enhanced features.

Unified trafficking and reporting experience

This release combines the trafficking functionality of the DFA API with the reporting functionality of the DFA Reporting API to create a simplified end-to-end experience. It's now possible to manage your DCM campaigns and report on their performance without switching APIs or reauthenticating. In addition, a unified object model allows you to pass data seamlessly between these two systems.

New trafficking functionality

This API expands the feature set of the DFA API to add new and improved trafficking functionality. A few highlights of this expanded functionality include:
Updated project quota limits

In addition to increasing the functionality of the API, we've also increased the default project quota limit. All projects can now make 50,000 requests/day (up from 10,000), to support a combined trafficking and reporting workflow. As always, requests for additional quota can be made via the Google Developers Console, should the need arise.

Learn more

This API is built on the same RESTful, standards-based technology stack previously employed by the DFA Reporting API. This means that you have access to all sorts of useful tools for trying it out, such as the APIs explorer (which is also built into the documentation for each method) and our generic, cross-API client libraries. The getting started guide is also a great reference for users who are just starting out.

Give it a try and let us know if you have any questions!

 - , DFA API Team