CONVERSION DURATION THRESHOLD
FeedMappingService
FeedMappingError.INVALID_PLACEHOLDER_FIELD
CONVERSION TYPE ID
As part of our ongoing efforts to improve DFP's performance and stability, we will be introducing limits on select DFP items, beginning June 30, 2014. As an API user, here’s how this change will affect you.
If you create more children than the allowed maximum for an entity, or modify an existing entity so that its number of children exceeds those limits, the API will throw an EntityChildrenLimitReachedError. Refer to the error’s reason field for an explanation for each type of entity that exceeds a child limit. The best way to handle this situation is to catch ApiException errors in your code, check the error type, and perform whatever is appropriate for your application based on the reason.
For a more detailed example of best practices with ApiException errors, please see this blog post on troubleshooting and error handling.
ApiException
As always, if you have any suggestions or questions, feel free to drop us a line on our API forums or Ads Developer Google+ page.
- Vincent Tsao, DFP API Team
If you synchronize your line items regularly to a local database using the LineItem.getLineItemsByStatement method, you are hopefully already filtering by LineItem.lastModifiedDateTime and using our other best practices. We want to mention one other best practice that will help you synchronize your line items as quickly as possible.
Recently, DFP has begun to auto-archive old orders. This affects the lastModifiedDateTime field of the line items in the orders. This means that you may suddenly get significantly more line items in one day’s synchronization than in the previous day’s depending on how many orders were auto-archived since your last synchronization. To prevent this, we recommend always filtering by isArchived. For example:
lastModifiedDateTime
WHERE lastModifiedDateTime >= '2014-06-01T00:00:00' AND isArchived = false
Today, we launch v201405 of the DFP API. This release brings better OAuth2 standards, consolidates line item goal information, and adds a lot more report fields. A detailed list of these features and what’s changed can be found on our release notes page.
To align better with OAuth2 standards, starting in v201405 we have removed the OAuth2 SOAP object. This means that you can no longer pass OAuth2 authentication information through the SOAP header. Instead, you pass it in the HTTP header. All of our client libraries have already been updated to follow this process. If your integration is not using one of our client libraries, please be aware of this change when you upgrade to v201405.
We’ve heard your feedback that the line item goal fields such as unitsBought can be confusing. In this version, we have moved line item goal-related fields into their own object, called Goal. This makes it easier to understand and find line item goal information. For example, previously line item goal information would be set as follows (using the PHP client library):
$lineItem->unitsBought = 500000; $lineItem->unitType = 'IMPRESSIONS';
Now this goal information is stored in its own object:
$goal = new Goal(); $goal->units = 500000; $goal->unitType = 'IMPRESSIONS'; $lineItem->primaryGoal = $goal;
We’ve also heard your feedback regarding parity between the ReportService and the UI in terms of what dimensions, attributes, and columns are available when running a report. In v201405, we make available a whole slew of new report fields, including Gross Rating Points (GRP), business intelligence, shared selling, and SDK mediation dimensions and columns.
Although not specific to v201405, the quota for premium networks has been raised. This means that if you want to limit your requests locally, we now recommend at most 8 requests per second for premium networks. For small business networks, we continue to recommend making at most 2 requests per second. As always, limiting your requests does not guarantee that all your requests will succeed, but will help mitigate quota errors. You should still be writing code to handle EXCEEDED_QUOTA errors. For more information about exception handling and recovery, please refer to this blog post.
We want to remind you that with each new version release, we’ll also be deprecating a number of older versions. Versions v201206 and earlier have now been turned off. All requests made against those versions will fail. Our next wave of versions to be turned off are v201302, v201211, and v201208. This will occur on August 1, 2014. For more information on this deprecation and what resources are available for migrating to the latest version, please see this blog post.
As always, if you have any suggestions or questions about the new version, feel free to drop us a line on our API forums or Ads Developer Google+ page.
Since its launch in 2010, the Google Content API for Shopping has played a critical role in enabling merchants to manage product items, users, and subaccounts programmatically at scale. We’ve received a lot of feedback from you over the years, and today, we’re happy to announce a new version of this API.
The Content API version 2:
Version 2 of the API constitutes a big overhaul and we’re eager for you to try it! Version 1 of the API will continue to be available until the end of February 2015, but we recommend that you adopt the new version as early as possible to take advantage of its new and improved features.
In version 2 of the API, you can request full data quality reporting for the whole account as well as item-level information like disapprovals due to incorrect prices or unavailable landing pages.
The inventory service lets you update price and availability of any product without resubmitting other product details.
All existing account management features, such as linking AdWords accounts, adding authorized users, and updating settings are now available for all account types.
If you don’t want to parse JSON or XML yourself, check out the client libraries for .NET, Dart, Go, Java, JavaScript, Objective-C, PHP, Python and Ruby. The libraries use OAuth 2.0 authorization and work with the Content API as well as many other Google APIs.
The standard Google API tools such as the API console support Content API version 2 out of the box. Additionally, in our API reference documentation, you can now scroll down to the bottom of any reference page to try the API. You can also visit the standalone API Explorer to browse a list of supported operations.
The new XML format is lighter than in version 1 of the API. JSON, which is both simpler to work with and uses fewer bytes to transfer the same data, is also supported in version 2.
If you would like to learn more about the Content API version 2 you can check out the API documentation. We’ve also prepared a few code examples in PHP and Java if you would like to dive in straight away.
If you have any other questions or comments, please head over to our support forum.
- Mat Scales, Shopping Developer Relations
Whether you’re just starting out with the DoubleClick Ad Exchange Buyer REST API or are working with an unfamiliar client library, our examples will help you get started! Our examples are now on GitHub and have been expanded to cover the following languages:
Each of these include documentation to help you get started with the corresponding client library and demonstrate how you can use the Service Account authorization flow with the DoubleClick Ad Exchange Buyer REST API.
If you have any feedback or feature requests for these examples, we’d definitely be interested in hearing about it! Feel free to contact us via the forum or our Google+ page.
- Mark Saniscalchi, Ad Exchange Team
