Google Ads Developer Blog |
| Announcing v201311 of the DFP API Posted: 25 Nov 2013 01:11 PM PST Today, we are launching v201311 of the DFP API. This release includes improvements to location targeting and expanded PQL functionality. It is the final version to allow ClientLogin and OAuth1.0 authentication, and provide support for the old Java client library. A detailed list of these features and what's changed can be found on our release notes page. It's all about location, location, location Starting in v201311, we are making an important change to how you interpret targeted locations; Location objects will no longer come back as subtypes. Instead, they now contain a type field that indicates what kind it is. Since this field is a string, you can now handle new types as they are introduced, rather than having to update to a newer version of the API. This means faster turnaround times to get features into the hands of your customers. A displayName has also been added to easily show your users what is being targeted, just like our UI does. Note, there is no change to how you target locations, and all fields except for id remain read-only. We believe this is a positive step forward as we continue to streamline the API; the switch to a single Location object aligns with the recently released Geo_Target table and reduces the number of code paths of your application. Stay tuned for a follow-up blog post about best practices and how to migrate your application. More through PQL As mentioned in our previous release post, the new LINE_ITEM table provides a quick and easy way to fetch information about your line items. Today, we are releasing the AD_UNIT table to do the same for your inventory. We'll be releasing more tables soon, so be sure to let us know in the forum what tables you'd like to see next. One of our popular feature requests is the ability to filter reports by parent ad units, i.e. by sections of your inventory. Now, with the AD_UNIT_ANCESTOR_AD_UNIT_ID dimension, you can filter by any ad unit within the inventory hierarchy. See the RunInventoryReport example in each client library for more. We've also updated the ActivityService to no longer require an activityGroupId in PQL filter statements. We've updated our GetAllActivities example to reflect this as well. Deprecation announcements As we stated in our previous blog post, v201311 will be the last version to support the ClientLogin and OAuth1.0 authentication mechanisms. Starting in 2014, new versions will only support OAuth2. As you plan your application updates for the new year, please take this into consideration. Finally, if you are a Java developer, v201311 will be the last version supported by the old Java client library. If you haven't migrated to the new Java client library yet, now would be a great time to do so. As always, if you have any suggestions or questions about the new version, feel free to drop us a line on our Ads Developer Google+ page.  - Adam Rogal, DFP API Team | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Please set User Agent or Application Name for the AdWords, DFP, and DFA APIs Posted: 25 Nov 2013 12:30 PM PST The AdWords, DFP, and DFA APIs can take a user agent string in the SOAP headers, and the client libraries all allow you to set this string in their configuration files. This post explains why it's in your own best interests to set this value to something unique and useful for each of your applications. We will be enforcing this soon in the Client Libraries - you won't be able to leave it as the default setting, or set an empty string. So, come up with a fitting string for your application and start using it in your headers now, if you're not doing so already! Here at Google we have the means to check our logs to see the SOAP requests you make, the responses we send you, and any internal error messages that might have been generated if something went wrong. If something appears wrong from your side, you can contact us, and tell us what happened and when, and we can search these logs for your developer token, network code, or specific features of the request that went wrong. In many cases that can be enough for us to be able to help you diagnose and solve that problem. But many of you are developing more than one product. And sometimes the problem you're trying to diagnose doesn't come down to a particular single event. Sometimes there's a behavior over time we're trying to pin down. And there are a lot of requests and responses in our logs. If you can tell us the UserAgent or ApplicationName string you set for a particular version of a particular product that appears to be misbehaving, we can much more quickly and easily tell you how many of each request type it made, and when, and what the success rate for those requests were. Likewise, if you're trying to migrate from one version of the API to another, we can tell you if you are still making requests using the old API release, and also exactly which version of which application. Supplying a useful UserAgent or ApplicationName string also enables us to proactively reach out to you when we see something going wrong or notify you of upcoming API changes that may affect you. We could then tell you exactly which behavior of what product and release will be impacted. We suggest you use the format <CompanyURL>:<AppName>:<Version> so for example: example.com:ReportDownloader:V3.2 Here's where to look and what to set for each Client Library:
And if you're generating your own SOAP and not using a Client Library, please set the string directly in the headers yourself. So why not make this simple change, if you aren't making use of it already, and set the UserAgent or ApplicationName string for each of your application releases? You never know when it will mean the difference between hours of digging or a quick fix. Feel free to ask questions or give us feedback via the G+ page.  |
| You are subscribed to email updates from Google Ads Developer Blog To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google Inc., 20 West Kinzie, Chicago IL USA 60610 | |
No comments:
Post a Comment