Google Data » Eric Koleda https://googledata.org Everything Google: News, Products, Services, Content, Culture Wed, 26 Oct 2011 02:57:25 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Tablet Targeting in v201101 https://googledata.org/google-adwords-api/tablet-targeting-in-v201101/?utm_source=rss&utm_medium=rss&utm_campaign=tablet-targeting-in-v201101 https://googledata.org/google-adwords-api/tablet-targeting-in-v201101/#comments Mon, 29 Aug 2011 20:56:00 +0000 Eric Koleda https://googledata.org/?guid=b0521b8f74e25ef785b180871f095cf0 Last month the device targeting options in AdWords were expanded to include new settings for tablets.  Previously tablets had counted as mobile devices, with the iPad listed as one such device.  The AdWords API worked the same way, using the PlatformTarget HIGH_END_MOBILE for both mobile devices and tablets and the MobilePlatformTarget "iPad" for the iPad specifically.  Representing these new tablet settings in the current v201101 version of the API is tricky, and in this blog post we’ll cover the behavior you can expect.

The first thing to note is that there is no PlatformTarget that represents tablets, since enum values can’t be added to an existing version.  You can look at the MobilePlatformTargets returned to get a better idea of what’s being targeted, but be aware that the meaning of some of the values have changed.  Specifically, the value "iPad" now represents any tablet, and the value "iPhone" represents any iOS device.

The tables below show the PlatformTargets and MobilePlatformTargets returned for every combination of device and operating system that can be set in the UI.

Computers Mobile Tablets
Android DESKTOP
(None) 		HIGH_END_MOBILE
Android 		HIGH_END_MOBILE
Android, iPad
iOS DESKTOP
(None) 		HIGH_END_MOBILE
iPhone 		HIGH_END_MOBILE
iPhone, iPad
webOS DESKTOP
(None) 		HIGH_END_MOBILE
Palm 		HIGH_END_MOBILE
Palm, iPad
All DESKTOP
(None) 		HIGH_END_MOBILE
(None) 		HIGH_END_MOBILE
iPad

Computers & Mobile Computers & Tablets Mobile & Tablets All
Android (None)
Android 		DESKTOP
Android, iPad 		HIGH_END_MOBILE
Android, iPad 		(None)
Android, iPad
iOS (None)
iPhone 		DESKTOP
iPhone, iPad 		HIGH_END_MOBILE
iPhone, iPad 		(None)
iPhone, iPad
webOS (None)
Palm 		DESKTOP
Palm, iPad 		HIGH_END_MOBILE
Palm, iPad 		(None)
Palm, iPad
All (None)
(None) 		DESKTOP
(None) 		HIGH_END_MOBILE
(None) 		(None)
(None)

As you can see there are certain states in the UI that appear identical in the API. This is unfortunate behavior that is due to the limited values available in the current version of the API.  Specifically, it’s not possible to distinguish:

  1. Tablets vs. Mobile & Tablets
  2. Mobile with all operating systems vs. Mobile & Tablets with all operating systems
  3. Computers vs. Computers & Tablets with all operating systems
  4. Computer & Mobile with all operating systems vs. All devices with all operating systems

Likewise, using these values in a mutate request may inadvertently change the targeting options of the campaign since the system will always apply the broadest targeting that matches the input.  For example, let’s say you have a campaign that was configured in the AdWords web interface to target just Android tablets.  If you called CampaignTargetService.get() you would get back the PlatformTarget "HIGH_END_MOBILE" and the MobilePlatformTargets "Android" and "iPad".  If you then call CampaignTargetService.mutate()using those same values, the campaign will be updated to target both tablets and mobile devices that run Android.

What this means is that there are certain targeting combinations that can’t be determined or applied accurately in the v201101 version of the API.  In the next version of the API we plan to update these target types to support the new tablet settings, which will make reading and writing these combinations much simpler.  As always, if you have any questions about this topic you can reach us on the AdWords API forum.

- , AdWords API Team

]]> https://googledata.org/google-adwords-api/tablet-targeting-in-v201101/feed/ 0 Fine grained partial failure in the BulkMutateJobService https://googledata.org/uncategorized/fine-grained-partial-failure-in-the-bulkmutatejobservice/?utm_source=rss&utm_medium=rss&utm_campaign=fine-grained-partial-failure-in-the-bulkmutatejobservice https://googledata.org/uncategorized/fine-grained-partial-failure-in-the-bulkmutatejobservice/#comments Fri, 22 Jul 2011 18:20:00 +0000 Eric Koleda https://googledata.org/?guid=fb833f63ee4d4ac7830fc9d5d54d008e BulkMutateJobService has provided support for partial failures, allowing some operations to succeed even though others have failed. Over the next few weeks we'll be rolling out improvements to this functionality, allowing for more granular failures when possible.

Bulk mutate jobs process operations in batches, and a failed operation will cause the entire batch to fail, but not the rest of the job. The results for a failed batch start with a FailureResult that holds all the errors generated by the operations in that batch. It is followed by a series of BatchFailureResults which act as placeholders for the rest of the operations in the batch. More information about how these failures are reported can be found in a previous blog post we did on the topic.

In v201008 we enabled partial failure support for the synchronous AdGroupCriterionService. Unlike the behavior in the BulkMutateJobService, this version of partial failure allows individual operations to fail without affecting successful ones. This method of partial failure is preferred as it cuts down on the number of retries needed.

While we can't update the BulkMutateJobService to process all operations this way, we are able to enable it for operations that use an underlying service that does support granular partial failures. Starting August 1st, operations of type AdGroupCriterionOperation and AdGroupAdOperation processed by the BulkMutateJobService may start failing granularly instead of in batches.

Let's see how this will change the results returned.

Existing partial failure behavior

Operation Result
AdGroupCriterionOperation FailureResult
  • cause.errors[0].fieldPath = "operations[1]..."
  • cause.errors[1].fieldPath = "operations[2]..."
AdGroupCriterionOperation (Invalid) BatchFailureResult
  • operationIndexInBatch = 1
AdGroupCriterionOperation (Invalid) BatchFailureResult
  • operationIndexInBatch = 2
AdGroupCriterionOperation BatchFailureResult
  • operationIndexInBatch = 3

Before the change the invalid operations will cause other valid operations to fail. The FailureResult is the first result in the batch, even if the operation at the position was valid. The field path of the errors indicates the index of the invalid operations relative to the start of the batch.

New granular partial failure behavior

Operation Result
AdGroupCriterionOperation ReturnValueResult
AdGroupCriterionOperation (Invalid) FailureResult
  • cause.errors[0].fieldPath = "operations[0]..."
AdGroupCriterionOperation (Invalid) FailureResult
  • cause.errors[0].fieldPath = "operations[0]..."
AdGroupCriterionOperation ReturnValueResult

After the change invalid operations will not affect other valid operations in the same batch. Each invalid operation will have a corresponding FailureResult. There may still be cases where BatchFailureResults are returned for these operations, such as if there is a general error with the account that cannot be attributed to any specific operation.

So how does this affect code you've already written to process BulkMutateJob results? The good news is that if you've written your code to allow for a variable batch size (no hard coded batch size) then no changes are needed! Invalid operations are essentially processed as batches of one, and the same logic that you use to process the results today should work perfectly with these new granular failures. If your application is currently expecting a batch of a specific size then you should update it to detect the start and end of batches dynamically.

If you have any questions about how these new granular failures work, or feedback on how we can further improve the error handling in the API, add a post to the AdWords API forum.

Update 2011-08-25
This change has been fully deployed and all BulkMutateJobs will be processed with granular partial failures enabled.

- Eric Koleda, AdWords API Team
]]> https://googledata.org/uncategorized/fine-grained-partial-failure-in-the-bulkmutatejobservice/feed/ 0 Enhanced documentation for selectors and reports https://googledata.org/google-adwords-api/enhanced-documentation-for-selectors-and-reports/?utm_source=rss&utm_medium=rss&utm_campaign=enhanced-documentation-for-selectors-and-reports https://googledata.org/google-adwords-api/enhanced-documentation-for-selectors-and-reports/#comments Wed, 22 Jun 2011 21:31:00 +0000 Eric Koleda https://googledata.org/?guid=5b2c0010e0e72df8cd538b02ed0fdb0b
First off, we’ve published a new Selector Fields page that provides information about the fields that can be used in generic selectors. This information was always available on an object’s individual reference page, but now we’ve aggregated it together across entire services for quicker lookups.


Additional information on how to migrate from the service-specific selectors used in versions v200909 through v201008 is available in the Selector Migration Reference.

Next, we’ve added more notes to the Report Types page to indicate which fields will prevent zero-impression rows from being returned in the downloaded report. In general, any field that is a property of an impression or click (such as the date, network, etc) will prevent rows with no impressions from being returned, but we decided to explicitly mark these fields so that the behavior is clear.


Finally, we’ve added new tips to our Best Practices Guide on topics such as deleting entities and using gzip compression. The guide is a great resource for developers starting an AdWords API project, but is also useful for established developers trying to increase the efficiency of their applications.

We’re always looking to expand and improve our documentation, so if you have any feedback for us please post it to the forum.

- Eric Koleda, AdWords API Team
]]> https://googledata.org/google-adwords-api/enhanced-documentation-for-selectors-and-reports/feed/ 0