Subscribe: AdWords API Blog
http://adwordsapi.blogspot.com/atom.xml
Added By: Feedage Forager Feedage Grade A rated
Language: English
Tags:
account  ads  adwords api  adwords  api  extensions  google  location extensions  location  mobile ads  new  questions  video 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: AdWords API Blog

Google Ads Developer Blog



The official blog for information about the AdWords, AdSense, DoubleClick and AdMob APIs and SDKs.



Updated: 2017-03-26T08:22:55.071-07:00

 



Google Mobile Ads Unity Plugin v3.3.0

2017-03-20T10:22:11.107-07:00

We recently launched v3.3.0 of the Google Mobile Ads Unity Plugin with support for ad position offsets and Unity 5.6 compatibility. The updated v3.3.0 Unity package is available for download from the Google Mobile Ads Unity Plugin GitHub repository.

Ad positions offsets

Version 3.3.0 of Google Mobile Ads Unity Plugin adds the ability to specify an x and y position for both BannerView and NativeExpressAdView objects. To position ad views outside of the existing AdPosition values, provide x and y offsets instead of an AdPosition when instantiating an ad view, as shown below.

BannerView bannerView = new BannerView(adUnitId, AdSize.SmartBanner, 50, 50);

The code snippet above creates a BannerView offset from the top-left corner of the screen by 50 density independent pixels in the x and y axis. NativeExpressAdView positions can be offset in the same manner, as shown below.

NativeExpressAdView nativeExpressAdView = new NativeExpressAdView(
adUnitId, new AdSize(320, 150), 50, 50);

Support for Unity 5.6

Although Unity 5.6 is still in beta, the latest version of the Google Mobile Ads Unity plugin includes changes to be fully compatible with the upcoming release.

In addition to the new features outlined above, it is recommended to update to the latest version of the Google Mobile Ads plugin to take advantage of stability and bug fixes. The source code and a sample app for the plugin are available in our GitHub repo,asisthefullchangelogfor this release. If you have any questions about Unity integration, you can reach us on our developer forum.

(image)



Productstatuses now includes issues older than 21 days in the Content API for Shopping

2017-03-14T11:35:55.365-07:00

Starting today, Productstatuses will return all the issues present in the Diagnostics tab of Merchant Center. Historically, only data quality issues from the last 21 days were available from Productstatuses. This means that you may see more issues returned by Productstatuses than before, but the number of issues should now match those available in the Diagnostics tab of Merchant Center.

If you have any questions or feedback about the changes to issue reporting or other questions about the Content API for Shopping, please let us know on the forum.
(image)



Native Express Video

2017-03-10T11:13:11.691-08:00

If you've created a Native Express ad unit recently, you may have noticed a new template format alongside App Install and Content: Video App Install. In the past few weeks, AdMob has rolled out support for video assets in Native Ads Express, giving publishers a new way to create more engaging presentations for their users. How to get started Enabling video demand for a Native Express ad unit is easy. Just open the ad unit's settings in the AdMob console, and look for the Ad type checkboxes at the top of the editor: Check the checkbox marked "Video app install," and save the change. In a short while, your ad unit will start serving video creatives alongside the other two formats, with no code changes to your app required. That means you can update your existing apps to display this new format without redeploying to the Play Store or App Store. An important thing to note is that video creatives are only available for ad units using the Large template size. The video player needs a certain amount of space, and the Large template ensures that it's available. Customizing the experience While there's no mobile code required to take advantage of Native Express Video, AdMob has introduced some new features to the API that allow publishers to customize the user experience. In particular, a new video options class (VideoOptions on Android, and GADVideoOptions on iOS) gives publishers a way to influence how the ads behave. For example, the following code will cause video ads appearing in an Android NativeExpressAdView to begin playing with their audio on: mAdView = (NativeExpressAdView) findViewById(R.id.adView);mAdView.setVideoOptions(new VideoOptions.Builder() .setStartMuted(false) .build()); Staying in the know App publishers can retrieve information about the video assets in their ads through the use of a video controller object (VideoController on Android, GADVideoController on iOS). The ad view classes for native express have been updated to include video controller properties that apps can grab and query for info like whether a video is present in the ad, and what its aspect ratio is. Even if the ad doesn't contain an video asset (or no ad has been loaded at all), you'll always get a valid reference to the ad view's video controller. For example, here's a Swift snippet that shows how to check if an ad that just loaded contains a video asset: func nativeExpressAdViewDidReceiveAd(_ nativeExpressAdView: GADNativeExpressAdView){ if nativeExpressAdView.videoController.hasVideoContent() { print("Received an ad with a video asset.") } else { print("Received an ad without a video asset.") }} More Info Native Express is designed to make implementing native ads easy, but if you have questions about how to get up and running or how you can best put it to use in your apps, stop by our support forum. The Mobile Ads Garage recently released an episode covering Native Express Video as well, with feature details and screencasts for iOS and Android: width="560" height="315" src="https://www.youtube.com/embed/5jHWbwkdeko?list=PLOU2XLYxmsIKX0pUJV3uqp6N3NeHwHh0c?ecver=1" frameborder="0" allowfullscreen>  - Andrew Brogdon, Mobile Ads Developer Relations[...]



Using SendBeacon for AdWords click tracking

2017-03-09T14:58:59.225-08:00

Accurate click accounting is a critical aspect of any campaign. However, traditionally it often came with a high cost to the user experience: the user has to follow one or more HTTP redirects, or is forced to wait for a synchronous logging request to complete before they can navigate to their destination. The Beacon API addresses these shortcomings:
  • Beacon requests are prioritized by the browser to minimize conflict with other time-critical operations, like reacting to user input.
  • Beacon requests are guaranteed to be initiated before a page is unloaded and are allowed to run to completion without requiring blocking requests or other techniques that block processing of user input.
In short, Beacon provides a fire-and-forget API that ensures logging requests are queued and completed by the browser, without the need for blocking requests or additional redirects. This allows users to be taken directly to landing pages without waiting on the click account requests to complete, greatly reducing latency.

AdWords recently switched from redirects to the Beacon API to account for some of the ad clicks on Google.com. This resulted in significant latency improvements. For example, for ad clicks pointing to Google Maps pages, the median latency dropped by 250ms and the 90th percentile latency dropped by more than 1,000ms.

You do not need to take any action at this time to benefit from SendBeacon. Chrome, Firefox and Edge all support SendBeacon, accounting for over 72% of worldwide traffic. We are planning to leverage Beacon API in more of our products in the future, and we encourage everyone else to take it out for a spin.

(image)



Launch of AwReporting 2.0

2017-03-07T07:55:49.016-08:00

AwReporting is an open-source Java framework optimized for large-scale retrieval of AdWords API reports.

We’ve just released a new major version of the tool that encompasses the full suite of AdWords API Reports and their fields. As mentioned in our pre-announcement, "aw-reporting-server” and “aw-reporting-server-appengine” modules were removed.

You can find the latest release on GitHub. Please find the full list of changes in the ChangeLog, and follow the migration guide to upgrade from the current version of the tool.

Feel free to ask questions or give us feedback via the forum or the project’s issue tracker.
(image)



AdWords API v201605 sunset reminder

2017-03-01T11:41:50.413-08:00

AdWords API v201605 will be sunset on March 28, 2017, after which all v201605 API requests will begin to fail. This version was deprecated on July 28, 2016. If you are still on v201605, we recommend that you skip v201607 and v201609 and migrate directly to v201702. Please be sure to migrate prior to the sunset to ensure your API access is unaffected.

We've prepared the following resources to help you with the migration: As always, if you have any questions about this migration, please contact us via the forum.
(image)



Announcing v201702 of the AdWords API

2017-02-28T12:41:51.168-08:00

Today we’re announcing the release of AdWords API v201702. Here are the highlights: Batch job support for shopping BatchJobService in all versions of the AdWords API now supports AdGroupCriterionOperations that modify shopping ProductPartitions. Check out the updated Batch Processing guide for details. Current attribution model reporting Several fields were added to reports to allow you to view historical stats using your current choice of attribution model. Message extensions You can now create message extensions via extension setting services to let customers send you a text message from your mobile ads. Affiliate location extensions You can now create affiliate location extensions to include the locations of stores where your product is sold in your ads. The updated Location Extensions guide has step-by-step instructions to help you get started. More policy details The new policySummary field of AdGroupAd provides additional details behind the approval status of your ads. For example, you can now differentiate between Approved (limited) and Approved ads. Showcase Shopping ads The AdWords API now supports Showcase Shopping ads which help customers discover what to buy and where to buy it. More details are in the updated Shopping Campaigns guide. Enhanced CPC for maximize clicks bidding strategies You can now opt in or out of enhanced CPC on standard TARGET_SPEND bidding strategies. If you’re using v201605 or v201607 of the AdWords API, please note that they are now deprecated and will be sunset on March 28, 2017 and June 27, 2017, respectively. We encourage you to skip v201609 and migrate straight to v201702. As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201702 migration guide. The updated client libraries and code examples will be published within the next 48 hours. If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page. - Josh Radcliff on behalf of the AdWords API Team[...]



Sunsetting manual location extensions from feeds

2017-02-23T06:51:16.305-08:00

At the moment, location extensions in AdWords can be sourced from two different places: a Google My Business account that is linked to your AdWords account or - for legacy users - manual location extensions created as feed items in AdWords. What’s changing?We’ll sunset manual location extensions on May 20, 2017 for all legacy users. You’ll no longer be able to manually create and manage Feed and FeedItem with a corresponding FeedMapping of placeholderType 7 (location extensions) and placeholderType 77 (location targeting) after this date. Instead, create your locations in Google My Business and link them to your AdWords account as outlined in our Location Extensions guide. You can use the Google My Business API to manage your business locations at scale. What you should doPlease migrate your code before May 20, 2017 to avoid being impacted by this transition. See our guide for managing location extensions for further details, including an end-to-end code example. We recommend migrating your existing legacy locations alongside your code in order to have full control over your Google My Business account structure, test your setup, and avoid any downtime in location extension management. If you're not concerned about downtime, let us migrate your existing manual location extensions for you (you still have to migrate your code). Auto-migrationAll unmigrated manual location extensions stored in AdWords will be gradually auto-migrated starting from May 22, 2017. For each Customer Account with unmigrated manual location extensions, we'll pick all Manager Accounts at the lowest level of the manager hierarchy. For each such Manager Account, we'll create a single Business Account in Google My Business managed by the administrative users of the original Manager Account and its managers. The name of this Business Account will be ‘AdWords ()’, where is the AdWords Customer ID of the original Manager Account. We’ll also create Business Accounts in Google My Business for Customer Accounts not linked to any Manager Account. Those will be managed by the administrative users of the Customer Account. For each unmigrated location in the Customer Account, we'll create a new unverified business location in that Business Account and label it with its AdWords Customer ID. The original manually created feed items representing that location in AdWords will be removed. We'll replace all unmigrated location extension and location targeting feeds with new feeds linked to the shared Business Account created in Google My Business. In each feed, we'll set up a labelFilter based on the Customer ID to map each location to its original account. Any existing CampaignFeed and AdGroupFeed will be recreated to match the original setup, including their matching functions. If you have questions while you’re upgrading, please reach out to us on the AdWords API forum. - Timo Bozsolik, AdWords API Team[...]



Upcoming DCM/DFA Reporting and Trafficking API system maintenance

2017-02-21T09:48:37.399-08:00

Starting in March, DoubleClick Campaign Manager (DCM) will be undergoing scheduled maintenance to make important updates to our systems. Every DCM account will be assigned a single maintenance window. However, these windows may be on different days for different accounts. More information about how this will affect the DCM product can be found in our help center.

How will this affect API users?

Maintenance is expected to last up to 8 hours per account. During that time DCM Trafficking will be read-only. While in read-only mode, all API delete, insert, patch, and update methods requiring the DCM Trafficking scope will be disabled. See the Scheduled Maintenance page on our developer site to learn more about the methods that will be impacted and the errors you may encounter.

What can API users do to prepare?

If your application accesses a single DCM account, we recommend simply planning ahead to avoid running workflows that use affected API methods during your account's maintenance window. Details of when this window will occur will be communicated in advance via in-product notification.

If your application accesses multiple DCM accounts, you may be subject to multiple maintenance windows. If it's not possible to plan around these windows, you should prepare your application to catch and handle maintenance related errors. Recommended error handling strategies include:

  • For user initiated requests, return an error to the user along with instructions to wait up to 8 hours before retrying the request.
  • For server initiated requests, retry automatically using an exponential backoff strategy. For example: pause 30 seconds before the first retry, 1 minute before the second, 2 minutes before the third, and so on up to a maximum of 8 hours. This strategy helps ensure you're not calling the API too aggressively and that your request quota is not being wasted.

Questions about this or anything else DCM API related? Contact us via our support forum.

(image)




Announcing v201702 of the DFP API

2017-02-14T10:35:21.814-08:00

Today we're pleased to announce the v201702 release of the DFP API. This release adds a new PublisherQueryLanguageService table: Change_History. This table contains entries for changes to entities in your network. This allows for the long-awaited ability of querying for DFP entity changes programmatically.

Additionally, v201702 adds the NativeStyleService, which allows you to read, create, and update native styles.

For a full list of API changes in v201702, see the release notes.

With each new release comes a new deprecation. If you're using v201605 or earlier, it's time to look into upgrading. Also remember that v201602 will be sunset at the end of February 2017.

As always, if you have any questions, feel free to drop us a line on the DFP API forums or the Ads Developer Google+ page.

(image)




Latency best practices in the IMA SDKs

2017-02-09T10:35:36.784-08:00

One of the most important factors in keeping users on your page or in your app is latency - the lower your latency, the more likely your users are to stick around. With this in mind, we'd like to remind you about our best practices for reducing latency with the IMA SDKs. In general, you can reduce latency by doing as much IMA set-up work as possible on page or app load, before your user tries to play a video. The following can be done in all of the SDKs before the user attempts to play a video:

  • Creating your ads loader.
  • Creating your ads request.
  • Requesting ads.
  • Obtaining the ads manager.
  • Registering ads manager event handlers.

You can find more information on optimizing latency in each of our SDKs at the links below:

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

(image)



Budget Optimizer and Conversion Optimizer Sunset in AdWords

2017-02-08T12:38:07.121-08:00

What’s happening?In March 2017, we will stop supporting the Budget Optimizer and Conversion Optimizer bidding strategies in AdWords. These strategies have long been unavailable for user opt in. We will migrate existing campaigns that use these legacy strategies to use their replacement counterparts which offer identical features: Budget Optimizer -> Target Spend Conversion Optimizer -> Target Cpa or Manual CPC There will be no change in performance after the migration. What do I need to do?If you are satisfied with your current Budget Optimizer or Conversion Optimizer setup, then you don't need to do anything to your existing campaigns -- Google will automatically migrate them for you. If you prefer manually migrating your campaigns before the automatic migration begins, you may refer to the automatic migration steps below. Refer to our bidding guide and help center articles on target CPA and target spend strategies to learn more about the new bidding strategies. What will the automatic migration do for Conversion Optimizer campaigns? Convert the campaign's bidding strategy to standard target CPA. Identify all ad groups of the campaign and their CPA bids, calculate the most common CPA bid value, and set the campaign's target CPA value to this value. If no CPA bids exist, Google sets the campaign's target CPA to the minimum billable unit. Pause any ad groups that do not have a CPA bid. This prevents previously inactive ad groups from inheriting the campaign's new target CPA value and inadvertently serving. What will the automatic migration do for Budget Optimizer campaigns? If no ad group level bidding strategy overrides exist, update the campaign’s bidding strategy to a standard target spend strategy. If the enhancedCpcEnabled field is set to true for the budget optimizer strategy, set it for the target spend strategy also. If some--but not all--ad groups have overrides, update the the campaign’s bidding strategy to a new portfolio target spend strategy. This preserves the ad group level bidding strategy overrides. In the rare case that all ad groups have overrides, update the campaign’s bidding strategy to standard manual CPC. The campaign level bidding strategy doesn’t matter in this case since all the ad groups have overrides. However, changing the campaign’s bidding strategy to manual CPC helps us avoid creating portfolio target spend strategies for each ad group in the campaign. As always, if you have any questions about this change or other API features, please post on the forum. - Mike Cloonan, AdWords API Team[...]



DCM/DFA Reporting and Trafficking API sunset reminder

2017-02-03T09:49:51.506-08:00

In accordance with our deprecation schedule, we'll be sunsetting versions 2.5 and 2.5beta1 of the DCM/DFA Reporting and Trafficking API on February 28th, 2017. On this date, all requests made against these versions will begin returning HTTP 403 errors.

If you're still working with these versions, we strongly encourage you to begin migrating to the most recent release to avoid an interruption in service. If you're not sure, or would like to know more about the migration process, refer to the migration guide.

As always, feel free to reach out to us with any questions that you have.

(image)




Automatic removal of invalid location extension filters

2017-01-24T09:03:01.359-08:00

AdWords offers several different strategies for configuring filters for your Google My Business locations. However, users sometimes choose filters that do not match any locations, which results in no location extensions appearing with ads. What's changing?Starting on February 14, 2017, AdWords will perform a daily check to determine if the following location extension feed item filters are not matching any Google My Business locations: PlacesLocationFeedData businessNameFilter categoryFilters labelFilters CampaignFeed and AdGroupFeed matchingFunction If any such invalid filters are found, they will be automatically cleared as outlined in the updated Location Extensions guide. Please keep the following details in mind: The periodic check will only clear matchingFunction filters on a CampaignFeed or AdGroupFeed for location extensions (placeholderType = 7). It will not clear filters on those objects for location targeting (criterionType = 77). The periodic check will not clear matching functions of the form IDENTITY(false), since these indicate that you want to disable location extensions for a campaign or ad group. What you should do To minimize the impact of the periodic check, regularly review your application's location feed setup and ensure that you are choosing filtering options on your PlacesLocationFeedData and matching functions that actually match locations in your Google My Business account. Make sure that your application will be able to handle the filter changes made by the periodic check. If you have any questions, please post on the AdWords API Forum. - Josh Radcliff, AdWords API Team[...]



Upgrade to AdWords API campaign drafts and experiments before February 1st

2017-01-23T11:01:48.228-08:00

Last year, we announced that you have until February 1st, 2017 to upgrade from ExperimentService to the new campaign drafts and experiments introduced in v201603. After this date, you’ll no longer be able to use ExperimentService.
  • API calls to ExperimentService across all API versions will result in an error
  • All experiments running via ExperimentService will be stopped
  • All ExperimentService experiments will be deleted and their stats will be unavailable
Check out our Campaign Drafts and Experiments guide for examples while upgrading your code. If you have questions while you’re upgrading, please reach out to us on the AdWords API forum.
(image)



Upgrade to expanded text ads and responsive ads before January 31st

2017-01-18T08:04:27.456-08:00

Last year, we announced that you have until January 31st, 2017 to upgrade your standard text ads to expanded text ads or responsive ads. After this date, you’ll no longer be able to create new standard text ads. Existing standard text ads will continue serving alongside expanded text ads and responsive ads.

To prevent any errors when creating ads, it’s important to immediately upgrade to expanded text ads or responsive ads before January 31st, 2017. To help you get started, we’ve put together a few resources: If you have questions while you’re upgrading, please reach out to us on the AdWords API forum.
(image)



Mobile search ads will feature a click-to-call option automatically after Feb 6th

2017-01-19T12:16:37.056-08:00

TL;DR: New feeds and feed items will automatically be added to eligible AdWords accounts.

This year, mobile search engines are predicted to drive nearly 33 billion clicks-to-call to businesses globally, almost 19% more calls than from mobile landing pages alone (BIA/Kelsey, July 2016). Using Google call extensions, you can get more calls by making it easy for people to contact you right from your mobile search ads.

If you manage accounts with ads that take users to landing pages prominently featuring a phone number, starting February 6, 2017 you will see call extensions automatically added for these mobile search ads via the extension setting services.

When added automatically, the new feed will have ORIGIN of "USER". You can update call extensions yourself directly with Feed services, Call Extensions or the AdWords user interface at any time.

You’ll be able to get detailed reporting insights (API report) about your calls performance (including call duration, call start and end time, caller area code) and whether the call was connected. You can also set up call conversion tracking to see which parts of your campaigns are driving the most valuable calls.

These extensions will only be added automatically once to each campaign or ad group and will not be re-added if modified or removed in the user interface or via the API. You can also indicate if you don't want extensions to be created for a specific account in the AdWords user interface:
  1. On the Ad extensions tab select “View: Automated extensions report”
  2. Scroll down to “Automated extension options (advanced)” and click on “Edit”
  3. Uncheck the option for “Automatic call extensions” under “Do not use specific automated extensions in this account”. 
As always, if you have any questions about this announcement, or other questions about the AdWords API, contact us via the forum.
(image)



Accountstatuses to now include validation issues in Content API for Shopping

2017-01-11T08:14:16.271-08:00

Starting on January 17th, 2017, Accountstatuses will return all the errors and warnings present in the Diagnostics tab of Merchant Center. This updates Accountstatuses to match the changes to Productstatuses from last August, so Accountstatuses will now report validation issues as well as data quality issues. This means that developers may see more issues returned by Accountstatuses than before.

If you have any questions or feedback about the changes to issue reporting or other questions about the Content API for Shopping, please let us know on the forum.
(image)



Deprecating Flash in the IMA SDKs

2017-01-04T11:49:26.532-08:00

On June 1, 2017, Google will cease development of Flash in the IMA SDKs. This will end support for the IMA SDK for Flash, as well as support for Flash VPAID ads in the HTML5 SDK. We strongly encourage all publishers still using the Flash SDK to migrate to the HTML5 SDK. We also strongly encourage advertisers still trafficking Flash VPAID ads to migrate those ads to JavaScript VPAID.

What does this mean for the Flash SDK?

We will not actively prevent ad serving to the Flash SDK. However, new releases will stop after June 1st and we will no longer fix bugs or answer support questions. If ad serving or playback stops working after this date for the Flash SDK, it will not be fixed. We strongly encourage you to migrate to the HTML5 SDK.

What does this mean for the HTML5 SDK?

We will no longer support Flash VPAID ads in the HTML5 SDK. Flash VPAID ads served to the HTML5 SDK will not be rendered and the SDK will fire an error. We strongly encourage you to migrate your Flash VPAID ads to JavaScript VPAID.

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

(image)



Sunset of DFP API v201602

2017-01-03T12:54:42.938-08:00

On Tuesday, February 28, 2017, in accordance with the deprecation schedule, v201602 of the DFP API will be sunset. At that time, any requests made to this version will return errors. If you're still using this version, now's the time to upgrade to the latest release and take advantage of new features like HTML5 creatives, programmatic support, and retrieving saved report queries. To do so, check the release notes to identify any breaking changes, grab the latest version of your client library, and update your code. Significant changes include: The reporting format CSV_EXCELhas been renamed TSV_EXCELto more accurately describe its actual format. Team.companyIds, Team.adUnitIds, and Team.orderIdshave been removed. Use Company.appliedTeamIds, AdUnit.appliedTeamIds, and Order.appliedTeamIdsinstead. Order.programmaticSettingshas been replaced by Proposal.ProposalMarketplaceInfo. getCustomTargetingValuesByStatement()now enforces the requirement of a custom targeting key ID in the filter statement.This is not an exhaustive list, so as always, don't hesitate to reach out to us with any questions. To be notified of future deprecations and sunsets, join the DFP API Sunset Announcements group and adjust your notification settings.  - Chris Seeley, DFP API Team[...]



Upcoming changes to AwReporting

2017-01-03T08:40:51.409-08:00

AwReporting is an open-source Java framework that is optimized for large-scale retrieval of AdWords API reports.

We plan to release a new major version (v2.0) within the next few months that will
This release will have some backwards incompatible changes, such as
  • uses report type names with “AW_” prefix as database table names
  • uses field names as database column names
  • renames setting “mccAccountId” to “managerAccountId” in properties file
  • renames setting "aw.report.downloader.retries.count" to "aw.report.downloader.num.attempts"
  • renames processor type setting’s options from “ON_FILE” to “FILE”, and “ON_MEMORY” to “STREAM”
  • removes “-debug” and “-verbose” command line options, and depends on log configuration file (default one is log4j.properties) for setting logging granularity
  • removes server modules (aw-reporting-server and aw-reporting-server-appengine) in the new release since they have third-party dependencies that are not actively maintained
If you are actively using the aw-reporting-server or aw-reporting-server-appengine module or have any questions about this upcoming release, please let us know on this forum thread.
(image)



Mobile Ads Garage #12: Native Express in a UITableView

2016-12-27T09:28:37.158-08:00

Episode twelve of The Mobile Ads Garage is live on YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and DoubleClick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.

With their customizable presentations and ability to be precached, Native Express ads fit right in with list-based user interfaces:

In this deep dive episode of the Mobile Ads Garage, you'll learn how to integrate Native Express ads into an iOS app that uses a UITableViewController for its primary UI. Along the way you'll get a detailed set of step and see screencasts of an implementation in Xcode. The episode also covers a handy technique for tapping into the ad lifecycle to load native express ads sequentially, from the top of the list to the bottom.

width="560" height="315" src="https://www.youtube.com/embed/chNb7-k6m4M?list=PLOU2XLYxmsIKX0pUJV3uqp6N3NeHwHh0c" frameborder="0" allowfullscreen>

If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We'd love to hear which AdMob features you'd like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

Until next time, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.

(image)



Announcing the new ads PHP client library

2016-12-21T17:11:47.670-08:00

Hello ads PHP developers! Today we're pleased to announce the stable release of the new ads PHP client library. This has been in beta for a while now, is a huge overhaul of the library, and offers the following improvements:

  • Uses namespaces and conforms to PSR-4 autoloading.
  • Conforms to PSR-3 for logging.
  • Supports installation via Composer.
  • Uses the Google PHP auth library for OAuth2, offering more features, flexibility, and service account support.
  • Uses Guzzle for non-SOAP HTTP calls, conforming to PSR-7.
  • Contains better object-oriented library design and stub interfaces, including builders to configure settings.
  • Contains upgraded and easier to use utilities for AdWords reporting, AdWords batch jobs, and DFP reporting.
  • Enables SSL by default for SOAP API calls and non-SOAP HTTP API calls.

This library has been pushed to the master branch on GitHub. The old library is now deprecated and moved to a deprecated branch with reduced support until it reaches end of life (EOL) on July 31, 2017. Reduced support details can be found in issue #193. To help you upgrade, we've written an upgrading guide.

As always, if you have any questions, feel free to drop us a line on the AdWords or DFP API forums, or the Ads Developer Google+ page.

(image)




AdMob Native Express ads in a content feed

2016-12-16T09:05:51.360-08:00

Today we're excited to announce iOS and Android sample projects that display AdMob Native Express ads in a feed. These samples address a common use case for monetizing apps with feeds or lists of content. The iOS (Swift and Objective-C) apps display Native Express ads in a UITableView and the Android app shows them in a RecyclerView.

Native Express ads work well in lists of content for two reasons. First, impressions are not counted until the ad is on screen, which enables you to preload the ads ahead of time. Preloading can help with optimizing scroll performance by making sure the ad is ready to be displayed when the user scrolls through the list. Second, you have more control over the styling of the ads, allowing you to create presentations that fit naturally with your content.

You can check out these sample apps by downloading them from our iOS and Android GitHub repos, and you can see them being coded in the Mobile Ads Garage YouTube series. Episode 11 walks you through the implementation for adding native ads into an Android RecyclerView. Episode 12, which will cover the implementation of native ads in an iOS UITableView, is due out next week.

If you have any questions or feedback regarding our SDK, feel free to contact us through our forum.

(image)



Announcing support for video campaigns in AdWords scripts

2016-12-13T13:46:48.680-08:00

Today we're announcing the release of video campaign management support in AdWords scripts. You can now create and manage in-stream, video discovery, and bumper ads in your existing video campaigns, set targeting for your video campaigns and ad groups, and report on performance including views and view rate.

To get started, visit our Video Campaigns guide for an overview of the new functionality. You can also view a variety of samples both in the docs and by using the Show examples button in the script editor. These are pre-built functions that may be useful to drop into your code or use as the basis for expansion into your own custom script.

When you're ready to dig in or when you're ready to learn more, check out the "Video" section of the left navigation bar under our AdWordsApp documentation.

If you have any questions about this new feature or AdWords scripts in general, you can post them on our developer forum.
(image)