Google Ads Developer Blog

Announcing a from-scratch rewrite of the Java Client Library

2012-05-21T14:01:00.000-07:00

The Java Client libraries for Ads APIs are some of the most popular, used by thousands of developers each day to manage their AdWords, DFA and DFP accounts. Since they were initially written years ago, we’ve gotten a lot of feedback from developers using the libraries. We’ve tried to incorporate as many suggestions as possible, but due to the legacy architecture, certain changes were not feasible.

Today we’re pleased to announce that we are officially supporting a new from-scratch rewrite of the Java Library! It is now production-ready and is no longer experimental. Read on for some reasons why you’ll want to take the new library for a spin right away.

New Features

New features in the rewritten library include:

Product level support for AdWords, DFA and DFP with shared common layer code.
Library is now hosted on Maven.
OAuth1.0a and OAuth2.0 support.
Uses the SLF4J logging facade.
More control over building your session, providing authentication and more.
Experimental AppEngine support via JAX-WS.

Migrating

The two biggest changes involve how to configure your session and how to obtain Service objects.

Here’s how you configure an AdWordsSession:

AdWordsSession session = new AdWordsSession.Builder()
    .fromFile()
    .withClientLoginToken(clientLoginToken)
    .build();

Here’s how you obtain a reference to a service:

AdWordsServices adWordsServices = new AdWordsServices();
CampaignServiceInterface campaignService =
    adWordsServices.get(session, CampaignServiceInterface.class);

Check out the migration guide we have recently published on the new project page wiki. You’ll find these procedures described in depth, along with best practices for using these classes.

The new library will be the primary focus of development moving forward. The existing AdWords and DFP java libraries are now in maintenance mode and we will continue to add support for new AdWords and DFP API releases for the near future.

If you find any bugs, have a patch to contribute or just a feature request, please feel free to file an issue on our issue tracker.

- Kevin Winter, AdWords API Team

Make it your own with Custom Fields in DFP API

2012-05-11T11:37:00.001-07:00

New to v201204 of DFP API are custom fields, which can be applied to orders, line items, and creatives. This new feature gives you the ability to include additional information on DFP entities without having to implement data persistence in your own system. They are saved when the entities are saved on the DFP servers which ensures data consistency and removes the need for syncing.

Data Types
The following are the supported data types of a custom field:

String
Number
Toggle (true/ false)
Drop-down (selection from user-defined values)

These data types should cover some of the most common use cases for custom fields such as comments (string), metrics (number), and internal system status (toggle/drop-down).

How-To
You can create and manage your custom fields and custom field options (for drop-down custom fields) with the new CustomFieldService. Please make sure you have the feature enabled for your network before you try to set up custom fields. We are also working on bringing custom fields to the user interface, so be on the lookout for them!

Walk-Through
The following Java sample shows how you can add a string and drop-down custom field value to your line item. This assumes that you have already created the custom fields and custom field options. You can check out how to create them using the CreateCustomFields and CreateCustomFieldOptions examples in the client libraries.

Long customFieldId = Long.parseLong("INSERT_STRING_CUSTOM_FIELD_ID_HERE");
Long dropDownCustomFieldId = 
    Long.parseLong("INSERT_DROP_DOWN_CUSTOM_FIELD_ID_HERE");
Long customFieldOptionId = 
    Long.parseLong("INSERT_CUSTOM_FIELD_OPTION_ID_HERE");
Long lineItemId = Long.parseLong("INSERT_LINE_ITEM_ID_HERE");

// Get the line item.
LineItem lineItem = lineItemService.getLineItem(lineItemId);

// Create custom field values.
List customFieldValues = new ArrayList();

// Create the String custom field value.
TextValue textValue = new TextValue();
textValue.setValue("Custom field value");
CustomFieldValue customFieldValue = new CustomFieldValue();
customFieldValue.setCustomFieldId(customFieldId);
customFieldValue.setValue(textValue);
customFieldValues.add(customFieldValue);

// Create the drop-down custom field value.
DropDownCustomFieldValue dropDownCustomFieldValue =
    new DropDownCustomFieldValue();
dropDownCustomFieldValue.setCustomFieldId(dropDownCustomFieldId);
dropDownCustomFieldValue.setCustomFieldOptionId(customFieldOptionId);
customFieldValues.add(dropDownCustomFieldValue);

// The line item can contain custom field values for the field you are
// trying to set or an unrelated one.  The following checks that you only 
// add existing custom field values for custom fields different from the 
// ones you are setting.
if (lineItem.getCustomFieldValues() != null) {
  for (BaseCustomFieldValue oldCustomFieldValue : 
      lineItem.getCustomFieldValues()) {
    if (!oldCustomFieldValue.getCustomFieldId().equals(customFieldId)
        && !oldCustomFieldValue.getCustomFieldId().equals(
        dropDownCustomFieldId)) {
      customFieldValues.add(oldCustomFieldValue);
    }
  }
}

// Set the custom field values on the line item.
lineItem.setCustomFieldValues(customFieldValues.toArray(
    new BaseCustomFieldValue[]{}));

// Update the line item on the server.
LineItem[] lineItems = lineItemService.updateLineItems(
    new LineItem[] {lineItem});

And that’s it! For the full Java code example, you can refer to the SetLineItemCustomFieldValue in the client library.

With this new feature, we aim to help you create stronger integrations with DFP through the API. If there are any features you would like us to demonstrate, please don’t hesitate to let us know with a forum post or at a Office Hour Hangout.

- Jeffrey Sham, DFP API Team

Announcing v201204 of the DFP API

2012-05-07T10:00:00.000-07:00

v201204 of the DFP API has launched and is ready for you to explore. In this version, we’ve added custom fields, expanded team and user functionality, and updated the conversion reports columns. A full list of features can be found on our release notes page.

Custom fields

Custom fields is a new feature to the API that lets you add attributes to entities, such as orders and line items. For example, you can add your own field to a line item that would let salespeople add comments as a string. Those comments would then be placed into custom field values that are added to each line item. Support for custom fields will be coming or the DFP UI soon, but if you have this feature enabled on your network now, you’ll be able to start working with them right away.

Teams changes

The way in which users are added to teams has changed starting in v201204. In previous versions, users were added to team objects directly. Now, you can associate users and teams, much like line items and creatives. The new associations will also let you define per user permissions, such as only letting some users have read-only access.

Version deprecation reminder

As a reminder, we are retiring support for v201103, v201104, and v201107 on May 11th. If you haven’t upgraded yet, now would be a great time.

Our next hangout is May 9th and we’d love to see you there. As always, let us know if you have any questions on our forum.

- Adam Rogal, DFP API Team

DFP API Test Network Update and Sandbox Shutdown

2012-04-24T15:00:00.000-07:00

We announced in a previous post an easier way to test with the DFP API. We've iterated quickly and improved on that solution and we are also setting a date for the shutdown of the sandbox.

Test Accounts
When we initially launched the new test networks, you had to create a new Google account if you had any type of DFP network associated with the account. We've lifted this restriction. Now each Google account is always allowed to create a single test network using NetworkService.makeTestNetwork(). This means you can use the same google account for production and test networks.

Sandbox Shutdown
Now that we've given you a bit of time to switch off of the sandbox environment, we're announcing that we are shutting it down on May 24th, 2012. This allows for another month of testing, but we hope you will migrate to the new test networks as soon as possible.

Happy testing and stay tuned for more DFP API blog posts. Don't forget to join us on our next Hangout and, as always, let us know if you want to see any new features or blog posts on our forum.

- Paul Rashidi, DFP API Team

The Docs are Dead. Long Live the Docs!

2012-04-19T04:36:00.003-07:00

Recent visitors to any of the Ads API documentation pages will have noticed their shiny new appearance and a message to let you know the docs have moved to a new platform:

This move is much more than a skin-deep makeover. As we’ve blogged before, the new Google Developers platform is so named to reflect our focus on you, and not just on the tools we provide.

Follow the links below to take a look at the full range of Ads API docs on Google Developers:

We’ll continue to try to improve the Ads API docs on Google Developers while, over time, Google Code returns to its original purpose as an open source project hosting service. Visits to the old Google Code docs will be redirected to the corresponding Google Developers docs throughout 2012, so be sure to update your bookmarks soon.

If you have any questions about these changes please reach out to us through any of the Ads API forums or office hours.

Lesley Burr, Ads Developer Relations Team

Brushing up on DFP API Forecasting

2012-03-30T12:28:00.000-07:00

With the addition of the new test networks to replace the sandbox environment networks, we’d like to do a review of how to test your forecasting on test networks. Since the test networks don’t serve ads, you have no traffic history to provide forecasting data. Instead, the API returns predictable results in the Forecast object so you can effectively test your application.

Forecast Service with Test Networks

The forecast service can be used by calling getForecast with a new line item or getForecastById with the ID of an existing line item. In production, these calls will tell you whether you can expect the line item to deliver the booked clicks/impressions based on how your network’s done in the past. In the test network, the only two parameters that affect the forecast results are the lineItemType and unitsBought fields on the line item. The expected responses are summarized below and in our documentation.

Input (Line Item Field)		Output (Forecast Field)
lineItemType	unitsBought	availableUnits	forecastUnits (matchedUnits)	deliveredUnits
Sponsorship	50	1,200,000	6,000,000	600,000 prospective: 0
Sponsorship	!= 20 and != 50	1,200,000	1,200,000	600,000 prospective: 0
Not Sponsorship	<= 1,000,000	unitsBought * 2	availableUnits * 3	600,000 prospective: 0
Not Sponsorship	> 1,000,000	unitsBought * 2	availableUnits * 3	600,000 prospective: 0

It is a good idea to include a test case where the forecasting service throws an exception so your application can handle error conditions correctly. You can trigger the service to throw a SERVER_NOT_AVAILABLE error by setting the line item type to sponsorship and the units bought to exactly 20.

Dealing with Production Quota

In addition, please be mindful that in production (as opposed to test networks), forecasting is a resource intensive process on the server and too many back-to-back requests may cause the API to throw an EXCEEDED_QUOTA error. When this occurs, we recommend backing off briefly before retrying to bring the requests per second down. Recall that the quotas are based on the number of requests per second rather than an absolute number of requests. You are less likely to get rate limited by the API with a steady stream of requests rather than with short bursts of many requests.

We appreciate any feedback from you regarding features you’d like us to highlight or about the API in general. Please don’t hesitate to leave us a suggestion on our forum or come chat with us at one of our DFP API Office Hours Hangouts.

- Jeffrey Sham, DFP API Team

A New Way to Test the DFP API

2012-03-28T15:57:00.000-07:00

We are pleased to announce a better way to develop and test your code with the DFP API. In v201203 you now have the ability to create a test network through a few easy steps. As an added bonus, you can now access the new test and production networks via the normal login screen. Read below for more information on the new self-service way of creating a development test environment for the API.

Create a Google Account
You'll first need a new Google account since you are only allowed one test network per email address. You'll use this account to authenticate with the API when creating the test network. There is no need to worry about your other DFP accounts and whether they have been linked, you only need a valid Google account.

Setup Your Client Library
As stated earlier, this feature is only available in the API so you'll need to set up your preferred client library in your development environment.

Execute the Example Code
Each of the client libraries has an example that you can run with your Google account credentials. This sample code executes the NetworkService.makeTestNetwork() service to create the network. After running this, your network will be ready to use and you will get a printout similar to the message below.

If you instead receive an error with the message
AuthenticationError.GOOGLE_ACCOUNT_ALREADY_ASSOCIATED_WITH_NETWORK
you will need to create a new Google account and try again.

Differences for the Test Network
A test network differs from a production network; in particular, a test network does not serve ads and can not be used in conjunction with any ad tags. As a result, the ForecastService provides mock forecasting information as specified in the documentation. Lastly, a test network offers only small business account features. If you need access to DFP Premium features contact your account manager for assistance.

Client Libraries
Once you've made the transition to a new test network you will no longer need to use the sandbox options in the client libraries. The new test networks utilize the same API endpoint as your production network so you only have to change your credentials and network code when preparing your code for a production release.

Sandbox Deprecation
In the coming months we will be phasing out support for the sandbox networks. Please take the time to migrate to a test network to ensure your testing is not interrupted.

Stay tuned for more DFP API blog posts including one discussing forecasting in the test networks. As always, let us know if you want to see any new features or blog posts on our forum.

- Paul Rashidi, DFP API Team

Announcing v201203 of the DFP API

2012-03-26T13:30:00.000-07:00

The newest version of the API, v201203, is at your service. It includes a brand new testing environment, read-only access to video creatives, team level filtering, and more. A full list of features can be found on our release notes page.

Test networks

Starting in v201203, you’ll be able to create test networks, which offer a wider range of functionality than the existing sandbox networks. To create test networks, you'll need a new Google account. Once you’ve called NetworkService.makeTestNetwork() with that account, you’ll sign in to test networks the same way as production, without having to sign up for a DFP account. Additionally, all SOAP requests can now be sent to https://www.google.com instead of https://sandbox.google.com; moving from test networks to production now will only require you to change your network code. Stay tuned for an upcoming blog post in which we will detail how to use these new networks and our plans for the legacy sandbox environment.

Network codes

In the previous versions, network codes were only required if you belonged to more than one network. Beginning in v201203, network codes will now be required for all requests except NetworkService.getAllNetworks() and NetworkService.makeTestNetwork(). This change will reduce latency for some requests and will make it easier for you to keep track of which requests are going to which networks, especially now that test and production networks have the same domain for requests.

Video creatives

Video creatives are now read-only accessible through the CreativeService. We plan to expose more functionality going forward, but we understand the current need of publishers and 3rd parties to report on and analyze what creatives exist in their network. Look out for more work coming in this area.

Teams

v201201 introduced teams and, as we mentioned, promised future functionality of filtering objects by those teams. In v201203, you’ll be able to set team IDs on inventory, orders, and company. Then, when calls are made with that user, only objects that belong to their team will be returned. You will also receive an error if you attempt to update an object that you don’t have access to.

Stay tuned for upcoming blog posts on the new test networks and network service best practices. As always, let us know if you want to see any new features or blog posts on our forum.

- Adam Rogal, DFP API Team

Spring 2012 Office Hours

2012-03-13T09:00:00.000-07:00

Google+ Office Hour Hangouts continue to be a hit across all of the Ads products so we're announcing that we've scheduled new events for the spring season. You can view the newly scheduled hangouts on the Google Developers events page. Please RSVP by clicking the “I’ll be there” button if you plan on attending. You can also continue to follow our schedule by subscribing to the Google Ads Developer Office Hours calendar which is also linked on the sidebar to the right of this blog entry.

In case you haven’t joined us before, you will need 3 things to join the hangout:

A Google+ account (sign up here)
The Google voice and video plugin installed on your computer
A quiet place to hangout so we can hear you

These hangouts are informal and conversational, which make them a great place to ask questions or give us feedback. If you have questions about our office hours program, reach out to us on the forums.
- Paul Rashidi, DFP API Team

Discover DFP API v201201: Syncing Up

2012-03-06T11:00:00.000-08:00

In the newest version of the API, v201201, we’ve added a feature to streamline the syncing of information in your DFP network to another system. Previously, this was possible but required repeatedly downloading the same objects to see if they had been modified. Now, a new PQL field exists, lastModifiedDateTime, which can be used to return objects based on their modification dates. Below is a PHP example that uses the latest client library to display all line items modified in the past 30 days.

// Get the LineItemService.
$lineItemService = $user->GetService('LineItemService', 'v201201');

// Calculate time from thirty days ago.
$thirtyDaysAgo = date(DateTimeUtils::$DFP_DATE_TIME_STRING_FORMAT,
    strtotime('-30 day'));

// Create bind variables.
$vars = MapUtils::GetMapEntries(array(
    'thirtyDaysAgo' => new TextValue($thirtyDaysAgo)));

// Create statement object to only select line items that
// have been modified in the last 30 days.
$filterStatement = new Statement(
    "WHERE lastModifiedDateTime >= :thirtyDaysAgo "
    . "LIMIT 500", $vars);

// Get line items by statement.
$page = $lineItemService->getLineItemsByStatement($filterStatement);

You will notice that we utilized a constant, DFP_DATE_TIME_STRING_FORMAT ('Y-m-d\TH:i:s'), from the library to easily format the date/time string. Also, keep in mind that the date and time specified should be in terms of the time zone that is configured for the network and any timezone specified in the string will be ignored by the server.

We hope you'll use this new feature to help save bandwidth and processing time. You can check out a full working example in PHP or other languages in our client libraries.

Feel free to leave us a comment on the forum with any feedback you have for the API or topics you would like to see in the discover series.

- Paul Rashidi, DFP API Team

Discover DFP API v201201: PQL Report Filtering

2012-02-24T11:20:00.000-08:00

In the v201201 version of the API, we’ve added the ability to perform PQL filtering in reports. As an example of what you can do with this feature, you can now limit the report to only orders and line items you want to see. This will help shorten the report job processing time and reduces the size of the report generated. The following Java code snippet creates a report job to pull all the line items belonging to an order in your network:

Long orderId = Long.parseLong("INSERT_ORDER_ID_HERE");
// Create statement to filter for an order.
Statement filterStatement = new StatementBuilder(
    "WHERE ORDER_ID = :id").putValue("id", orderId).toStatement();

// Create report job.
ReportJob reportJob = new ReportJob();

// Create report query.
ReportQuery reportQuery = new ReportQuery();
reportQuery.setStatement(filterStatement);
reportQuery.setDateRangeType(DateRangeType.LAST_MONTH);
reportQuery.setDimensions(new Dimension[] {Dimension.LINE_ITEM});
reportQuery.setDimensionAttributes(new DimensionAttribute[] {
DimensionAttribute.ORDER_TRAFFICKER});
reportQuery.setColumns(
    new Column[] {Column.AD_SERVER_IMPRESSIONS, Column.AD_SERVER_REVENUE});
reportJob.setReportQuery(reportQuery);

The ‘ORDER_ID’ field in the WHERE clause is a dimension enumeration name. A full breakdown of the supported filter enumerations can be found in the documentation. We encourage the use of bind variables to build reusable filter statements, much like other services in the API where PQL is used. Whenever possible, try to filter on IDs rather than names (i.e. use CITY_CRITERIA_ID over CITY_NAME) since matching by name is case sensitive.

If you also specify the dateRangeType and dimensionFilters fields on the ReportQuery object, the filter statement will be applied in conjunction (in a logical AND) so that each entry in the report will match all of the filter criteria. You can check out a full working example in Java or language equivalent in our client libraries.

This is the first post in the Discover DFP API in v201201 series; our next post will cover syncing objects with the new lastModifiedDateTime field. Leave us a comment on the forum with any feedback you have for the API or topics you would like to see in the discover series.

- Jeffrey Sham, DFP API Team

Retiring support for v201103, v201104, and v201107 of the DFP API

2012-02-10T12:30:00.000-08:00

Today, we are announcing the deprecation of versions v201103, v201104, and v201107 of the DFP API. In 3 months, on May 11th, these versions will be turned off. We are turning off older versions to make sure that everyone can benefit from the improvements in more recent releases and so that we can focus on releasing new features.

As mentioned in previous deprecation announcements, we will always give at least 3 months notice before turning off a version. Our release notes page also contains changelogs for each version, which will help you migrate to a newer version. If you aren’t using one of our client libraries, now would be a great time to start as well. If you have any feedback or comments about this deprecation, or the API in general, please feel free to leave them on our forum or join us in a future hangout on Feb 28th.

- Adam Rogal, DFP API Team

isocket and Shiny Ads deliver new innovations using the DFP API

2012-02-07T10:00:00.000-08:00

Editor’s note: We’d like to share with you this post from John Park about the growing DFP API ecosystem and a few success stories from our partner directory. -- Adam Rogal, Ads Developer Relations Team

With thousands of publishers using the DFP and DFP Small Business ad serving platforms, we know first-hand that no two publishers are identical. Publishers may use in-house billing systems, have unique approval workflows, or use third-party tools to handle their ad operations.

To give publishers the flexibility to easily integrate their unique processes and systems with their ad server, DFP offers publishers an open API to easily create tools that complement their ad operations.

We’ve seen hundreds of developers build new ad serving innovations using the API, including applications to manage inventory, create orders, pull reports, and more. The API has created a new ecosystem of partner innovations, giving publishers access to new ad serving tools and applications. Two such applications come from isocket and Shiny Ads who have used the DFP API to build applications that help publishers manage and sell their ad space.

isocket uses the API to create tools that streamlines sales

Seeing the need to streamline the manual steps involved with buying and selling inventory, isocket engineered a direct and self-service ad sales tool to simplify sales workflows. By leveraging the DFP API, isocket was able to build an application to automate sales processes and save money. “We were interested in using the API because it allowed us to eliminate the hassle of manually coordinating campaigns, while still keeping the important parts like publisher control and approval. Integrating with the DFP API has allowed us to make things a lot simpler for publishers,” said Ben Trenda, VP of Sales at isocket.

Read more about how isocket integrated with the DFP API.

Shiny Ads builds application to help publishers save time

To help facilitate publishers’ direct ad campaign management, Shiny Ads began using
the DFP API to integrate its self-serve advertising platform with DFP in order to help publishers streamline their sales processes. This integration has helped save publishers time since they no longer need to manually book sales orders. “Our solution needs to support DFP - our customers demand it” said CEO and founder Roy Pereira. “The API made integrating with DFP easy for us, and most importantly, easy for our clients. Without the DFP API, Shiny Ads would not have the fully functional solution we have today.”

Read more about how Shiny Ads integrated with the DFP API.

Over the coming months, we’ll share more stories on how our partners are using the DFP API to deliver exciting ad serving innovations. For a complete list of partners who have built applications using the DFP API, please visit our partner directory.

Posted by John Park, Partner Programs Manager, and Adam Rogal, Developer Relations

Announcing v201201 of the DFP API

2012-02-06T15:00:00.000-08:00

The newest version of the API, v201201, brings some frequently requested features including using date time strings in PQL statements, filtering objects based on last modified date and times, including a PQL statement to limit a report (such as just running a report for one order), and more. A full list of features can be found on our release notes page.

Filtering

In v201201, we’ve focused on improving filtering with PQL statements across the entire API. We’ve introduced a better way to do date time filtering, a new lastModifiedDateTime field to search on, and the ability to filter from within a report.

With the ability to filter by date and time fields directly in the PQL statement, you’ll now be able to limit the objects on the server, rather than fetch all line items and checking their startDateTime property one at a time. For example, if you want to retrieve all line items that started so far in January, include

startDateTime

as a predicate of your filter with a date and time string, e.g.

WHERE startDateTime >= ‘2012-01-01T00:00:00’

. Note here that the date and time are in ISO 8061 format, i.e.

YYYY-MM-DDThh:mm:ss

, and the time zone is assumed to be that of the network’s. You can also bind a DateTime object instead of using a string, i.e.

WHERE startDateTime > :dateTime

, where

:dateTime

is bound to a DateTimeValue.

We’ve also added the new lastModifiedDateTime field to companies, creatives, ad units, line item creative associations, line items, orders, and placements. Using this field, you can now query for objects that have changed recently. Combined with the new date and time filtering feature mentioned above, you will be able to pull all objects changed so far this year, e.g.

WHERE lastModifiedDateTime >= ‘2012-01-01T00:00:00’

. If you are a developing an application that has to keep in sync with changes made through the UI, only pulling down objects that have changed since your last fetch time will speed up your calls and decrease processing time.

Finally, one of the largest requests from our developers was to limit what data is returned from within a report. We’ve add the ability to define a PQL statement in a report definition to do just that. Now when you create a report, you’ll be able to supply statements to limit it to just one order, e.g.

WHERE orderId = :orderId

, or with only one salesperson as well, e.g.

WHERE orderId = :orderId AND salespersonId = :salespersonId

.

Creatives

In v201102, we’ve added three new creative types that are only available to small business networks:

FlashExpandableCreative - an expandable creative where the collapsed size is a Flash SWF file and the expanded size is another Flash SWF file.
FlashPushdownCreative - a creative that pushes page content down when the creative expands.
TextAdCreative - a text-based creative.

Teams

We’ve introduced a new service with this version, TeamService, which lets you group users into teams. Although currently not editable via the API, teams will be used to limit access to entities such as companies, inventory, and orders.

Coming soon

Over the next few weeks, you’ll learn about all of the features a bit more in the Discover v201201 series starting first with a discussion of filtering and syncing best practices. Let us know if you want to see anything else on our forum.

- Adam Rogal, DFP API Team

Getting Started With the PHP Client Library

2012-01-26T11:00:00.000-08:00

Recently, we released our first client library walkthrough video for the DoubleClick for Publishers API. This five-minute video guide shows you how to get up and running with the PHP client library from downloading the code to running one of the examples. All you need to get started is a DFP account (production or sandbox) and a machine with PHP 5.2.x and the SoapClient, OpenSSL, and cURL extensions. For new users to the API, it’s a great way to get acquainted with the documentation pages, project site, and client library features.

The video takes you through an explanation of how the getCreativesByStatement example makes an API call and highlights common usage patterns and best practices for the client library. We also show you what happens when a call returns an error and how you can configure logging to get more information and troubleshoot an issue.

Please let us know about any topics you would like us to cover in a video guide or blog by leaving a comment on our forum. You can also chat with us live at one of our DFP API Office Hours Hangouts.

- Jeffrey Sham, DFP API Team

AdWords, DFA and DFP Client Library Updates

2012-01-12T10:41:00.000-08:00

We’re constantly making improvements to our AdWords, DoubleClick for Advertisers (DFA) and DoubleClick for Publishers (DFP) client libraries across all supported languages. Recently, we added the following features. Read the ChangeLogs and READMEs for details on these changes:

GZIP compression used when sending and receiving API calls and reports. (Perl and Java do not have this for AdWords API Report Downloads).
SSL certificate verification.
AdWords only - Examples and support for the new CreateAccountService.

Please see below for a summary of other changes for each library.

DotNet

No other updates.

Java

A preview version of the rewritten Java client library is now available for AdWords, DFA and DFP APIs. Please consider this alpha-quality code; please file any bugs or feature requests on the issue tracker. The new library currently supports Maven2, SLF4J, OAuth and we have plans to support other environments and platforms.

Ruby

Improved parameters validation and error reporting on missing / mistyped fields.
HTTP headers are now logged on DEBUG level.

Perl

Fixes to OAuth logic to better handle misconfigurations.
Several bug fixes.

PHP

AdWords only - Added example to get the clientCustomerId for a clientEmail.
AdWords only - Fixed issue with GetAccountHeirarchy example when used in the sandbox.
Fixed issue with lingering "id" attribute after reference replacement. Added tests for SoapXmlFixer.

Python

Validation and error handling has been improved to make it easier to use OAuth and Google AppEngine.

You can download updated versions of our client libraries from their respective sites, or see a list of all client libraries: AdWords, DFA and DFP.

If you have any questions or would like to discuss these changes, please post on our forums: AdWords, DFA, DFP.

- Kevin Winter, AdWords API Team

More Office Hours in 2012

2012-01-05T11:56:00.000-08:00

Last year we hosted our first office hours for the Google Ads Developer products using Google+ hangouts, and the feedback was overwhelmingly positive. We plan to host more of them in 2012, and sessions for January and February have already been scheduled. Our upcoming hangouts are listed on the Google Developers events page, and we encourage you to click the "I'll be there" button if you plan on attending. You can also follow our schedule by subscribing to the Google Ads Developer Office Hours calendar or by glancing at the sidebar to the right of this blog entry.

In case you haven’t joined us before, you will need 3 things to join the hangout:

A Google+ account (sign up here)
The Google voice and video plugin installed on your computer
A quiet place to hangout so we can hear you

Google App Engine for Java meet DFP API, Part 1: Hello World

2011-12-22T10:41:00.000-08:00

We are excited to start discussing how to use the DFP API from within the Google App Engine (Java) environment. This first blog post in the series focuses on setting up your environment and understanding how to use the API from App Engine. Future posts in this series will build upon the same project to create a sample application. Ultimately, you will be able to make DFP information more accessible within your organization, while also leveraging the ease of scale and deployability that comes with creating applications on Google App Engine.

Setting up your environment

For simplicity sake we will focus on utilizing Eclipse and the Google App Engine Plugin available for Eclipse. Information about setting them up can be found here. If you prefer a different environment setup, you can always view the Getting Started Guide for App Engine for more information.

Create an App Engine project

You’ll need a place to do your coding so create an App Engine project in a similar manner to the screenshots below.

Note: If you would like to download all of the source code in this blog post to follow along you can do so as a tarball or you can browse the code base from our svn repository.

Dependencies

The App Engine Java environment requires JAX-WS when dealing with SOAP interfaces like DFP API so you won’t be able to use the normal Java client library. You’ll need to download this client login auth file to help with authentication. Place this file in your project’s src directory. Next, you’ll need a jar and a wsdl file that we’ve compiled with JAX-WS; place them in the WEB-INF/lib and WEB-INF directory, respectively. See the files highlighted in their respective locations below.

Write some code

Now that you’re set up, it’s time to write some code that uses the DFP API. This first snippet of code performs some setup for your App Engine Servlet.


  /**
   * Perform initialization of servlet and cached resources used to
   * access DFP API.
   */
  @Override
  public void init(ServletConfig config) throws ServletException {
    super.init(config);

    // Generate an authToken.
    try {
      authToken = regenerateAuthToken();
    } catch (Exception exception) {
      throw new ServletException("Could not generate an Auth Token.",
          exception);
    }
  }

  /**
   * Regenerate the client login auth token that the servlet uses.
   * 
   * @throws Exception
   */
  public synchronized String regenerateAuthToken() throws Exception {
    ClientLoginAuth clientLoginAuth = new ClientLoginAuth(EMAIL_ADDRESS, 
        EMAIL_ADDRESS_PASSWORD);
    return clientLoginAuth.getAuthToken();
  }

This next snippet of code handles the actual web browser requests.


  @Override
  public void doGet(HttpServletRequest req, HttpServletResponse resp) 
      throws ServletException {
    try {
      // Retrieve an object handle to our network service.
      NetworkService networkService = new NetworkService();
      NetworkServiceInterface networkServiceInterface =
          networkService.getNetworkServiceInterfacePort();

      // Prepare header object to make server call
      SoapRequestHeader requestHeader = new SoapRequestHeader();
      requestHeader.setApplicationName("Hello World");
      ClientLogin clientLogin = new ClientLogin();
      clientLogin.setToken(authToken);
      requestHeader.setAuthentication(clientLogin);

      // Make protected call to the server.
      String rootAdUnitId = "";
      Network currentNetwork = networkServiceInterface.getCurrentNetwork(
          requestHeader, null);
      // Extract data from object returned from server.
      rootAdUnitId = currentNetwork.getEffectiveRootAdUnitId();

      resp.setContentType("text/plain");
      resp.getWriter().println("Hello, world. Your root ad unit id is: "
          + rootAdUnitId);
    } catch (Exception e) {
      // Perform exception handling.
      e.printStackTrace();
      throw new ServletException("Error occurred. Check logs for specific "
          " details about the error.");
    }
  }

This particular code snippet retrieves the root ad unit for our network whenever someone accesses the application. You can view the full sample servlet code here.

Testing

To make sure your code works, let’s deploy the project locally. Right-click on your project and then choose “Run” and select the “Web Application” option from the submenu. This will deploy your code to a locally running App Engine server. The console will display the URL to access the application (usually http://localhost:8888/). Clicking on this link and then the subsequent servlet link should return a page similar to this.

Next Time

Next time, we’ll extend the project to do some background processing and start using some other services from the DFP API.

Troubleshooting

We really hope you didn’t have an issue, but if you did there is a troubleshooting README file included in the sample code.

Let us know if you have any questions, and happy holidays!

- Paul Rashidi, DFP API Team

A look back at mobile in 2011

2011-12-20T18:40:00.000-08:00

Editor’s note: As many of you are planning your 2012 advertisement strategy, we’d like to share with you this post from Karim Temsamani. It’s a look back on 2011 and provides a great perspective on how mobile really took a step forward in the advertising ecosystem. -- Stan Grinberg, Ads Developer Relations Team

Mobile turned a corner this year. As smartphones and tablets became a part of our everyday lives, business owners’ conversations shifted from 'Why should I advertise on mobile or build a mobile website?' to 'How do I get started?’.

Five major industry trends emerged in 2011 that will carry us into 2012, and beyond.

1 - Everyone goes mobile
Smartphones and tablets proved that they weren’t just for the geekiest - er, ‘tech savviest’ - among us. These devices are increasingly becoming the norm and they continue to change how people connect with each other, and with businesses, everywhere. According to our research with IPSOS earlier this year:

79% of smartphone consumers use their phones to help with shopping, from comparing prices, to finding more product info, to locating a retailer.
70% use their smartphones while in a store.
77% have contacted a business via mobile, with 61% calling and 59% visiting the local business.

It’s not just that more people are using smartphones and tablets (though the numbers are skyrocketing at an accelerating pace)—it’s that a huge, and fast-growing base of smartphone users, now expect to engage with businesses on mobile. The mainstream consumer got mobilized in 2011.

2 - Mobile search transforms shopping, forever
Analyzing mobile search trends helped the industry better understand how people were using their mobile devices in 2011. For starters, we learned a lot about the ‘timing’ of mobile and tablets. These devices enable us to be constantly connected to the internet, as mobile usage has proven to be complementary to the desktop. We got a clearer picture of how search is changing the ways we shop and connect with businesses. More people are looking for deals both en route to stores and within them on mobile - in the retail category, “Black Friday” related mobile queries were over 200% higher this year than in 2010. Users have also developed some mobile-specific shopping habits - for example, 44% of all searches for last minute gifts and store locator terms are projected to come from mobile devices this holiday season. For procrastinators, mobile has come to the rescue!

In October, we looked at some of the newest ways marketers can build their businesses via mobile search. But, this is only the beginning - whether people are trying to find or call a business, compare prices in a store, or visit a site or app directly from their phones, search and search ads will be the tools that shape a new shopping experience, enabling us connect with businesses, research and buy products on or offline, all via mobile.

3 - Progress with the mobile advertising pipes
As an industry, we came a long way in terms of improving the ‘pipes’ - the systems, products and technologies that advertisers use to build, serve, and measure mobile ads. It’s still early days, but the progress with standards like MRAID and the momentum behind HTML5, are helping to rally the mobile community and make it easier for marketers and customers to connect on the platform. Getting existing tools to ‘speak mobile’ has been another key to helping mobile advertising grow-up as quickly users and businesses want it to. Across search and display, the tools the industry is already familiar with are getting mobilized. There’s plenty of work still to do, but significant progress is being made - watch this space in 2012.

4 - Tablets join the mobile party
Tablets made quite a splash this year. Usage trends sharpened - we’re seeing that people people use these devices to shop, consume media, have fun, and they do so most frequently in the evenings. Tablets are a third screen to be reckoned with for marketers - we saw a 440% growth in traffic from tablets in November 2011 compared to December 2010 on the AdMob network. The business potential is tremendous: not only are users more inclined to shop and make purchases on tablets, but because campaigns can be more effective running across several screens instead of one, tablets offer an incremental opportunity for marketers. Our research with Nielsen showed that campaigns on several screens can be ‘Better Together’ - indeed, in cases like Adidas’, that proved to be true.

5 - Businesses start (actually) thinking mobile first
Smartphones and tablets aren’t small desktop computers - they’re new devices being used in entirely new ways. This year, businesses began to embrace this at scale and many saw good things happen when they built ad campaigns and websites specifically for mobile. Ticketsnow’s success with a mobile optimized site - increased site traffic, and more ticket sales - is just one example of the benefits of building for mobile. Initiatives like GoMo and platform-specific ad features will help businesses better connect with mobile customers in the coming months, and beyond.

It’s hard to believe, but as far as the industry has come in 2011, we’re still in the earliest chapters of mobile’s story. The ways people connect to businesses on their mobile devices and the tools they’re using to connect from them progressed by leaps and bounds this year and soon, we’ll see the mainstream shift that changes the way mobile connects people with brick-and-mortar storefronts as well. Mobile will be moving full speed ahead in 2012 so keep those sleeves rolled-up and those seatbelts fastened - we’ll see you then.

Posted by: Karim Temsamani, VP Mobile Ads

Discover DFP API v201111: More Power in Reporting

2011-12-20T09:15:00.000-08:00

In this installment of the Discover DFP API v201111 series, we present new features we’ve added to reports in the API. In addition to merged ad server columns, which helps upgraded publishers reports on both DART and DFP ad servers, you can now use dimension attributes for greater control in reporting.

Dimension Attributes

Dimension attributes let you break down your report by additional fields associated with the dimension. For example, you can now add the trafficker, external ID, and order start date as dimension attributes associated to your order dimension in a delivery report. This is useful if you would like to see how each of your orders is doing and which trafficker was responsible for that order.

In the past, you would get this information by running a report for orders and then looking up the orders with Order Service to inspect the attributes. Now, it’s as simple as adding values to the dimensionAttributes field on your ReportQuery object and the corresponding fields will be integrated into the report. The following code snippet shows you how to create a report job with dimension attributes:

// Create report job.
ReportJob reportJob = new ReportJob();

// Create report query.
ReportQuery reportQuery = new ReportQuery();
reportQuery.setDateRangeType(DateRangeType.LAST_MONTH);
reportQuery.setDimensions(new Dimension[] {Dimension.ORDER});

// Set dimension attributes for order dimension.
reportQuery.setDimensionAttributes(new DimensionAttribute[] {
    DimensionAttribute.ORDER_TRAFFICKER,
    DimensionAttribute.ORDER_START_DATE_TIME,
    DimensionAttribute.ORDER_END_DATE_TIME});

// Set columns to report on.
reportQuery.setColumns(new Column[] {
    Column.AD_SERVER_IMPRESSIONS,
    Column.AD_SERVER_CLICKS});

reportJob.setReportQuery(reportQuery);

You can check out the full example in the RunDeliveryReportExample in the Java client library. Notice that you can only add dimension attributes for dimensions that you have in the report. For example, if you tried to add LINE_ITEM_EXTERNAL_ID, and you only have order (but not line item) as a dimension, you will get the following error:

ReportError.ATTRIBUTES_NOT_SUPPORTED_FOR_REQUEST

Be sure to check out our updated reporting examples in the client libraries and take a look at our documentation for a full mapping of supported dimension attributes and the fields they represent.

We are always looking for ways to improve the API and we’d love to get your feedback. Let us know what you’d like to see in the API or discussed in a blog post by posting on our forum. We’re also more than happy to chat during one of our office hours hangouts.

- Jeffrey Sham, DFP API Team

Discover DFP API v201111: Creative Creatives

2011-12-16T10:00:00.000-08:00

Last month, we announced the ability to create both custom and template creatives using the DFP API. Today we’ll show you can use these premium-only features to create richer creatives with custom HTML.

Custom or template

The difference between custom and template creatives is that custom creatives have their HTML snippet set within them, while template creatives are instantiated from system or user defined HTML snippets. Deciding which one to use depends on your network’s needs. If your network deals primarily with traffickers using the DFP UI, it may be beneficial for them to use creative templates in their workflow. The API could be used to retrieve these templates and report on them, but your traffickers would most likely want to create the creatives from templates in the UI.

However, if you are developing a platform in which traffickers spend most of their day, it may scale better to template the HTML yourself within your content management system (CMS) and use custom creatives for the advertisements. You could store custom HTML snippets and prompt the user for assets to insert. In essence, you would be creating your own templates, but without the overhead of template creatives.

Creating custom creatives

To create a custom creative, you first have to define your HTML snippet:

  String htmlSnippet = "<a href='%%CLICK_URL_UNESC%%%%DEST_URL%%'>"
      + "<img src='%%FILE:IMAGE_ASSET%%'/></a><br>Click for great deals!");
  CustomCreative customCreative = new CustomCreative();
      customCreative.setHtmlSnippet(htmlSnippet);

Notice here that the CLICK_URL_UNESC, DEST_URL, and FILE macros are used to customize the creative at serving time. CLICK_URL_UNESC will insert the clickthrough URL while DEST_URL inserts the URL that the ad points to. The FILE macro will reference any attached assets to the creative, in this case one named IMAGE_ASSET.

  // Set the custom creative image asset.
  CustomCreativeAsset customCreativeAsset = new CustomCreativeAsset();
  customCreativeAsset.setMacroName("IMAGE_ASSET");
  customCreativeAsset.setAssetByteArray(/* Byte array from image. */);
  customCreativeAsset.setFileName(
      String.format("image%s.jpg", System.currentTimeMillis()));
  customCreative.setCustomCreativeAssets(
      new CustomCreativeAsset[] {customCreativeAsset});

You would then call CreativeService.createCreative on customCreative to instantiate on the server. After creating the creative, you can then review it using the creative’s previewUrl attribute or the newly added getPreviewUrl method. When updating custom creatives, you don’t need to pass the asset byte array each time. Instead, you can leave it null with assetId set to what it was assigned to when created. The full example can be found on the Java client library page, as well as in our other libraries.

As a final note, custom creatives can be used for many other purposes beyond the simple image ad above. Including a SWF file as an asset, for example, is a common way of creating flash banner ads. You can even include a Google+ +1 button and customize the +1’s destination URL with the DEST_URL macro.

We have a few more posts lined up for the Discover DFP API v201111 series, but if there’s any other topics you’d like to see, please let us know on the forum.

- Adam Rogal, DFP API Team

Discover DFP API v201111: Suggested Ad Units

2011-12-09T20:54:00.000-08:00

The v201111 version of the DoubleClick for Publishers (DFP) API introduces SuggestedAdUnitService which lets you get and approve those ad units that have tags on your web pages, but no corresponding ad units in DFP. By default, only ad tags that have 10 or more requests will be returned as suggested ad units. They can be approved using performSuggestedAdUnitAction, after which they become ad units and you can manipulate them using InventoryService. To use this service, please make sure you have a premium account and that you have enabled the feature in the User Interface.

Why Use Suggested Ad Units?

A simple use case for suggested ad units is for new publishers or blog owners to create new tags for articles and posts on their site and approve suggested ad units based on the number of impressions they generate. This gives you the chance to see how well your content does before targeting line items to your ad units. The ApproveSuggestedAdUnitsExample from the client libraries will show you how to do this.

A more involved use case for publishing platforms is to tag all the pages generated by the users and perform some operations on content that generates a sizable number of impressions. These operations can include:

Approving the suggested ad unit and targeting line items to it
Promoting the page as featured content
Recognize the user for quality content and auto-approve their pages

Here's a Java code sample of how you would do this:

// Set the number of requests to 50 or more.
Long NUMBER_OF_REQUESTS = 50L;

// Statement to fetch suggested ad units in descending order by number of 
// requests.
String statementText = "ORDER BY numRequests DESC LIMIT 500";
Statement filterStatement = 
    new StatementBuilder(statementText).toStatement();
SuggestedAdUnitPage page = new SuggestedAdUnitPage();

// List of suggested ad unit ids to approve.
List<String> suggestedAdUnitIds = new ArrayList<String>();
page = suggestedAdUnitService.getSuggestedAdUnitsByStatement(
    filterStatement);

if (page.getResults() != null) {
  for (SuggestedAdUnit suggestedAdUnit : page.getResults()) {
    if (suggestedAdUnit.getNumRequests() >= NUMBER_OF_REQUESTS) {
      // Add it to the ID list to be approved.
      suggestedAdUnitIds.add(suggestedAdUnit.getId());
      /*
       * Promoting the page as a featured content.
       * Recognize the user for quality content and auto-approve their 
       * pages.
       */
    }
  }
}

if (suggestedAdUnitIds.size() > 0) {
  // Modify statement to select suggested ad units from the list.
  filterStatement.setQuery(
      "WHERE id IN (" + StringUtils.join(suggestedAdUnitIds, ",") + ")");
  // Create action to approve suggested ad units.
  ApproveSuggestedAdUnit action = new ApproveSuggestedAdUnit();
  // Perform the action.
  UpdateResult result = suggestedAdUnitService.performSuggestedAdUnitAction(
      action, filterStatement);
}

These are just some of the things we think suggested ad units can be used for; we'd love to hear your ideas on our forum or at an Office Hours Hangout.

- Jeffrey Sham, DFP API Team

Discover DFP API v201111: Mobile Targeting

2011-12-02T11:45:00.000-08:00

In the v201111 release of the DoubleClick for Publishers (DFP) API, we're bringing you the ability to target your ad units and line items specifically for the mobile platform. The following walk-through based on the CreateMobileLineItem example of the client libraries describes how to create mobile-targeted line items.

Set your Target Platform

The first step is to set the new attribute targetPlatform to MOBILE to specify that the line item is targeted towards mobile platforms rather than the default web browser platform. Please note that the target platform attribute has also been added to ad units and that attribute needs to be set to MOBILE as well for the targeting to work.

Set your Targeting

We've introduced four mobile targeting options to enable you to target the right platform:

Here is how you set up your targeting to target just Google devices:

Technology manufacturer = new Technology();
// The ID for the Google device manufacturer was fetched from the 
// Device_Manufacturer PQL table.
manufacturer.setId(40100L); 

DeviceManufacturerTargeting manufacturerTargeting = 
    new DeviceManufacturerTargeting();
manufacturerTargeting.setDeviceManufacturers(
    new Technology[] {manufacturer});
manufacturerTargeting.setIsTargeted(true);

TechnologyTargeting technologyTargeting = new TechnologyTargeting();
technologyTargeting.setDeviceManufacturerTargeting(
    manufacturerTargeting);

Targeting targeting = new Targeting();
targeting.setTechnologyTargeting(technologyTargeting);

LineItem lineItem = new LineItem();
lineItem.setTargeting(targeting);

That's it! Your line item is now set to target just Google devices.

For mobile device targeting, you can specify two lists of devices: one that is targeted and one that is excluded. This allows you to target a device manufacturer but exclude certain devices within that family. However, if a device is part of a device targeting inclusion list, another device from the same manufacturer cannot be in the exclusion list. For example, putting the Nexus S in the inclusion list and the Nexus One in the exclusion list will result in the following targeting error:

GenericTargetingError.CONFLICTING_INCLUSION_OR_EXCLUSION_OF_SIBLINGS @ targeting.deviceFamilyTargeting

Instead, we recommend targeting the Google device manufacturer and excluding the Nexus One with the device exclusion list.

As always, we value your feedback, so feel free to leave your questions or comments on our forum or join us at one of our upcoming developer Hangouts.

- Jeffrey Sham, DFP API Team

Announcing version v201111 of the DFP API

2011-11-30T10:30:00.000-08:00

Today we’d like to introduce you to the v201111 version of the DoubleClick for Publishers API. v201111 is one of our largest versions yet; it includes some highly-requested features such as full support for mobile ad serving, new creative types including templates, video player environment targeting, reporting updates, and suggested ad units. A full list of features can be found on our release notes page.

Mobile

As part of our ongoing effort to expand our publishers’ networks to mobile platforms, we’ve made it easier than ever to create and target mobile inventory in the API. Starting in v201111, you’ll find the targetPlatform field on the AdUnit and LineItem objects. This field allows you to specify that an ad unit represents a piece of mobile inventory, or that a line item is only meant to serve to mobile ad units. If a line item is marked as mobile, you can also specify manufacturer, carrier, and device targeting. New examples for how to create mobile ad units and line items will be made available next to their web counterparts in the client library examples shortly.

Creatives

In v201111, we’ve added a few new creative types, most importantly template creatives and custom creatives. Although both allow you to create richer advertisements, they differ in how you will want to use them in your solution. While custom creatives allow you to specify an arbitrary htmlSnippet with accompanying assets, creative templates allow you to reuse creative formats that will appear on the DFP user interface. Using creative templates, you can then create template creatives in which you can set variables to an already defined html snippet by the template.

We’ve also added the ability to view creatives as they would be served. To do this, pass the web page’s URL containing the appropriate ad tags, creative ID, and line item ID to the new LineItemCreativeAssociationService.getPreviewUrl() method.

Video

Along with the new mobile support in the API, we’ve expanded our video capabilities. In v201108, we added the ability to specify that a line item will serve to a video player environment. By enabling this setting, you can associate companion ads to run alongside the video. In v201111, as a DFP video publisher with a content feed, you can target individual videos within your content management source as well as positions within those videos.

Inventory

We’ve also added the SuggestedAdUnit service. This premium-only service enables you to add a new ad unit to an ad tag before defining it in DFP. This allows you to run forecasts for it before traffickers can start targeting line items to it; this functionality is similar to auto-created zones in DART for Publishers. If the ad server receives at least 10 requests for an undefined ad unit, the SuggestedAdUnitService.getSuggestedAdUnitsByStatement method will return that suggested ad unit. The suggested ad units can then be approved using the ApproveSuggestedAdUnits action. You can find an example of how to do this in our client libraries. Please also make sure that you are a premium user and that you have enabled this feature in your account through the User Interface. For more information, see the premium inventory help page.

Reporting

For v201111, we’ve added new columns and the feature to break down reports by dimension attributes. Whereas in the past you would have to manually correlate reports with objects fetched from services, this new feature allows you to include information such as a line item’s start time, an order’s trafficker, or an order’s external ID directly in the report to better integrate DFP reports with your system.

Follow-up posts in the discover series

Over the next few weeks, you’ll have the chance to get to know all of the features a bit more in the Discover DFP v201111 series starting first with the updated features for the mobile platform. And as a final note, if you haven’t signed up for our first ever hangout yet, we’d love to see you there!

- Adam Rogal, DFP API Team

Kickback and Hangout: DoubleClick for Publishers API Office Hours

2011-11-22T09:31:00.000-08:00

The DoubleClick for Publishers API team is excited to announce our first Google+ Hangout Office Hours session on December 7th at 2pm Eastern (11am Pacific). Across the Google Developer Relations team we have seen tremendous positive feedback regarding these Hangouts and we are looking forward to opening a new channel for our developers to converse and ask questions about the API. Specifically, the DFP API team is interested in understanding how you, our developers, use the API so we can continue to improve it.

The Office Hours will be run in a question-and-answer format so please bring your questions about the DFP API and the DFP Upgrade. Let us know you’re planning to attend by clicking the “I’ll be there” button on the developers.google.com page for this event.

Just a few housekeeping items to remember:

If you have a particularly complicated question we ask that you send it to us ahead of time by adding it to this forum post.

To join the hangout you’ll need to have a Google+ account (sign up here) and the Google voice and video plugin installed (download available for Windows, Mac, and Linux).

Hangouts are currently limited to ten people at a time, so if you aren’t able to join right away please try again later in the hour as a slot may have opened up.

Additional information about Hangouts is available in the Google+ Help Center.

- Paul Rashidi, DFP API Team