Are you getting started with the AdWords API but short on time to read the documentation? Do you need a reference implementation of a particular API operation? Check out our client libraries code examples which have undergone extensive renovations in the last libraries release!

The code examples are one of the best resources to learn the API and understand version changes. It is also helpful to have a working code to troubleshoot issues you may have with your own implementation. You can find the list of the client libraries and the resources for each library on the AdWords API site.

There were a number of changes introduced which we hope will make the examples code base more useful and easy to follow:
  • The code examples are now oriented around typical use cases rather than the API-specific operations. To get Criteria report look for the getCriteriaReport example, to create text ads - for the createTextAds example.
  • The number of input parameters was reduced which means you can run more examples as-is now, without adding specific object IDs.
  • For each example the code is wrapped into a function which can be called with parameters. This makes it easier to find out what parameters are required and improves examples testability.
  • Some of our Best Practices are now also demonstrated in the examples and described in the comments.
We’ve also changed the example files layout. We’ve noticed developers find it easier to navigate defined sections:
  • BasicOperations: start here if you are new to the AdWords API. This directory contains examples of basic operations such as creation, updating and deletion of most commonly used objects. The examples demonstrate the principles used in the rest of the API: selectors, predicates, paging, grouping of operations.
  • Targeting, CampaignManagement: these sections contain more advanced examples on the AdWords API such as geo targeting, location extensions, experiments and ad parameters.
  • ErrorHandling: examples in the ErrorHandling directory demonstrate how to handle different kind of errors occurring during the API calls. The errors covered here are API-specific (e.g. not network errors) and not transient so they could not be solved by retrying the exact same request.
  • Reporting: this section includes examples on how to retrieve a report with the client libraries. You can find the list of reports and their fields available on our codesite page.
  • AccountManagement: examples in the AccountManagement section will be helpful if you manage more than one account via the API. Here you can find code which retrieves accounts’ hierarchy or finds units spent on particular account.
  • Optimization: If you are looking for keyword or placement ideas or traffic estimations, you can find the examples in this section.
  • Remarketing: conversion tracker and audience operations are shown in examples in the Remarketing section.
  • Misc: this section contains examples that don’t fit into any other category and also some library-specific code samples. Check out our OAuth authorization code example here.
Browse updated examples code in: DotNet, Python, Ruby, Perl, PHP. We are working to update examples for Java and JavaScript as well.

As always, please feel free to ask any questions regarding the AdWords API on our forum or during scheduled office hours.

- Danial Klimkin, AdWords API Team
Labels: , ,

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.

 - , DFP API Team
Labels: , , ,

In April 2012, we will be making two changes to the allowed_vendor_type field of the Ad Exchange real-time bidding protocol. Before describing the upcoming changes, let’s review how to use technology vendors on the exchange.

Ad Exchange vendor policies


One of the benefits of buying on the DoubleClick Ad Exchange is the ability to use technology vendors for ad serving, research, remarketing and more. To protect Ad Exchange publishers, we certify vendors before they’re allowed to run on the exchange. And once they’re certified, we divide them into two categories, outlined in our Help Center:
  1. No Declaration Required: Vendors that are whitelisted to run across the exchange, and therefore do not need to be declared in a bid response.

  2. Declaration Required: Vendors that publishers are permitted to block, and therefore must be declared in a bid response.

    3. Because Ad Exchange buyers have access to sites in the Google Display Network (GDN), the GDN runs an additional certification process to determine which vendors may run on their network. Therefore, there is a third label applied to vendors:

  3. GDN Allowed: Vendors that are permitted to run on the Google Display Network. Note that categories 1 and 2 still apply to this subset; that is, some GDN Allowed vendors require declaration, and others don’t.
GDN Allowed vendors are listed in the GDN Requirements for 3rd Party Ad Serving. On this page, navigate to Vendors list (global) under the Requirements on the Google Display Network through the DoubleClick Ad Exchange section. Vendors marked with a + sign are bucket 2, Declaration Required.

An overview of the changes


In April 2012, we will make two simplifications to the allowed_vendor_type field of the Ad Exchange real-time bidding protocol.
  1. Removal of No Declaration Required vendors: In the bid request, the allowed_vendor_type field will only contain vendors from category 2, Declaration Required; you will no longer see any bid requests with vendors from category 1. Accordingly, your bid responses should only contain vendors from category 2 (though your response will not be rejected if it contains a category 1 vendor). We have updated our vendors.txt file to include only the vendors that need to be declared.

  2. Removal of allowed_vendor_type for GDN requests: Because every GDN site has the same set of allowed vendors, we will no longer include allowed vendors in bid requests for GDN sites (denoted by seller_network: “GCN”, soon to be updated to “GDN”). However, if the vendor you’re using falls into the Declaration Required bucket, you must still include it in your bid response. We have listed these vendors - those that are allowed on the GDN, and won’t appear in bid requests, but still require declaration - in gdn-vendors.txt.
As always, please reach out to your Google account team with any questions about this change.

Posted by Eileen Duffy, Ad Exchange Trainer
Labels: ,

We would like to once again remind you that after February 29, 2012, calls made using the following AdWords API versions will return errors:
  • AdWords API versions v13, v200909, v201003, v201008, v201101
We strongly encourage you to make the move to v201109 before the February 29th deadline. This will give you the opportunity to identify any issues before it is too late to roll back to previous versions.

In addition, check that you have no automated or scheduled scripts running that are using old code.

To ensure that your code uses only v201109, be sure you are using the latest version of our client libraries.

If you have specific migration questions, you can asking them in upcoming office hours or on the forum. Additional migration resources are available here.

Posted by Katie Miller, AdWords API Team
Labels: ,

The newest version of the DFA API is now available: v1.17. This release includes a variety of bug fixes, many of which resolve issues that you reported on our forum. It also pares down a few outdated and unused operations.

The newest version of the DFA API is now available: v1.17. This release includes a variety of bug fixes, many of which resolve issues that you reported on our forum. It also pares down a few outdated and unused operations.

Bug Fix Highlights

Some of the bugs tackled in this release include:

Deprecation and Sunset of v1.15

With this new release, our friend v1.15--the version from two releases ago--is now deprecated. As previously announced, we will continue to support it until March 3rd, 2012 at which time it will be entirely removed from service. Be sure to migrate any applications currently using v1.15 to one of the two supported versions by this time. Come benefit from the v1.17 fixes!

Sunset of v1.16 in Early June

Keeping with our standard release cycle, v1.16 will be sunset in early June. Please use this time window to make arrangements for migrating any v1.16 implementations before it is retired.

Complete Release Notes

This post reflects just some of the changes in the release. Our updated release notes page gives you a more in-depth breakdown of what has changed since the previous version. Please refer to this page when upgrading your applications.

As always, we highly value your feedback and questions. Please join us on our forum whenever you’d like to reach us.

 - , DFA API Team
Labels: ,

Demographic reports allow you to see the performance of your ads by age groups and gender on the specific sites in the Display Network that provide this information. As part of a greater effort to simplify AdWords, the DEMOGRAPHIC_PERFORMANCE_REPORT is being deprecated and will no longer be available in the API starting on or around March 21, 2012. You can back up the historical demographic data for your campaigns by downloading these reports before they sunset.

Demographic reports allow you to see the performance of your ads by age groups and gender on the specific sites in the Display Network that provide this information. As part of a greater effort to simplify AdWords, the DEMOGRAPHIC_PERFORMANCE_REPORT is being deprecated and will no longer be available in the API starting on or around March 21, 2012. You can back up the historical demographic data for your campaigns by downloading these reports before they sunset.

Please be aware that this change doesn’t impact demographic exclusions for your campaigns, which are done via the AgeRange and Gender criteria in the CampaignCriterionService. If you have additional questions about this deprecation, please reach out to us on the AdWords API forum or one of our regular Google+ Hangout office hours.

 - , AdWords API Team

Labels: , ,

This is a reminder that after February 29, 2012, calls made using the following AdWords API versions will return errors:
  • AdWords API versions v13, v200909, v201003, v201008, v201101
If you would like your applications to run without interruption, you must migrate to AdWords API v201109 by February 29th. Migration resources are available ...
This is a reminder that after February 29, 2012, calls made using the following AdWords API versions will return errors:
  • AdWords API versions v13, v200909, v201003, v201008, v201101
If you would like your applications to run without interruption, you must migrate to AdWords API v201109 by February 29th. Migration resources are available here. In addition, if you have specific questions, we encourage you to attend office hours or post questions to the forum.

Posted by Katie Miller, AdWords API Team

Labels: ,

The DoubleClick Ad Exchange launched five years ago (logging its first impression in June 2007), and it didn’t take long for the product to open up to developers. In 2008, we launched a ...
The DoubleClick Ad Exchange launched five years ago (logging its first impression in June 2007), and it didn’t take long for the product to open up to developers. In 2008, we launched a real-time bidding (RTB) protocol, enabling sophisticated buyers to analyze and bid for impressions in real time. As the Ad Exchange and RTB grew, so did our pool of developers.

Presently, close to 75 percent of all Ad Exchange spend comes via RTB. Some of our largest buyers are agency trading desks and demand-side platforms that were created around the RTB opportunity. Simply put, Ad Exchange thrives thanks to the work of our developer community.


Today, we officially welcome Ad Exchange developers to the Google Ads Developer Blog. We’ll be using the blog to update Ad Exchange developers on news, best practices, and beta features. We’ll also highlight upcoming events like webinars, Google+ Hangouts, and on-site Developer Day workshops.

The Ad Exchange team is excited to engage more with our developer community. To subscribe to Ad Exchange news, click on our ad_exchange feed.

Posted by Ad Exchange Team
Labels:

Welcome back to Chart Tuning! In this second half of the series we will show you how to define the different views for our chart and implement the zooming functionalities.

Welcome back to Chart Tuning! In this second half of the series we will show you how to define the different views for our chart and implement the zooming functionalities.

Before diving into the code explanation, check out the live example and the source code of the example chart if you haven’t yet.

Defining week and month view

Now that all our data is in place, we can get the visualization started. First we create a ChartWrapper by calling getChartWrapper. After setting the data table for our chart, we set the visualization mode to month and we can draw the chart.

The function setMonthView shows:

  • how to set the view window of the chart so that the values on the X axis (the dates) goes from 0 to the last day of the current month

  • how to add the required text to points on the X axis

  • how to visualize the subset of columns that we want in the month view.

The function setWeekView shows how to set the view window so that we show seven points centered on the user’s selection and how to visualize all the columns, as per requirement of the week view.

Handling events

Google charts can fire events for which you can listen. Events can be triggered by user actions: for example a user clicks on a chart. This comes in handy for our zooming functionality, as we need to intercept a user clicking a column in the chart.

To listen for these clicks, we add an event listener on the chart, and call the setWeekView function when the select event occurs.

Job done!

And that’s it, our chart is ready!

Have you noticed the graceful transition of the chart when using the zoom functionality? Transition animations are one of the latest additions to the Google Chart Tools, and you can experiment with different transition behaviors to properly tune your chart!

Some more thoughts on the User Experience

The zooming effect is nice to see, and when we’re in week view, we can use it to scroll the chart without changing a single line of code: if we click on one of the columns, the view centers on the selected point.

Thinking about the user experience, we have to consider that it might not be clear for our user that the zooming effect is activated when clicking on one column, or that they can still scroll the chart by clicking the other columns.

We can provide a better user experience by adding a button to toggle between week and month view; when in week view, we can add two arrow buttons to allow the user to scroll to the previous or the following week.

Why don’t you try to modify the source code to implement this feature request? We will add our solutions to the example chart source code on February 21, and then discuss possible solutions and other improvement ideas during the AdSense Management API Office Hours scheduled for that day.

For any questions or suggestions, don’t hesitate to engage with us in our forums:

Update: our solution has been added to the AdSense API showcase project.

 - , AdSense API Team

Labels: ,

You asked for an AdMob SDK release schedule to time your own app releases, and we listened. From here onwards, AdMob will ship an Android and iOS SDK release in the first two weeks of January, April, July and October.

You asked for an AdMob SDK release schedule to time your own app releases, and we listened. From here onwards, AdMob will ship an Android and iOS SDK release in the first two weeks of January, April, July and October.

We are excited about adding clarity and predictability to your development cycles, while bringing you powerful features that accelerate your business with each SDK release.

AdMob SDK v6.0 ships in April. Stay tuned!

 - , Product Manager, AdMob

Labels:

During Chart Tools Week, we showed you how to create a basic dashboard for AdSense reporting using the AdSense Management API and Google Chart Tools.

In this new two-part series, we’ll examine more advanced charting techniques that will improve the look and feel of our chart as well as enable user interactivity.

During Chart Tools Week, we showed you how to create a basic dashboard for AdSense reporting using the AdSense Management API and Google Chart Tools.

In this new two-part series, we’ll examine more advanced charting techniques that will improve the look and feel of our chart as well as enable user interactivity.

We’ll also show you how to use the Google Closure Library to ease some of the data manipulation tasks when writing a JavaScript application.

The goal

Our goal is to produce this Column Chart showing the earnings per day for the current month. We also want a zoom feature, with the following requirements:

  • The chart is initially shown in a month view: standard columns are shown for the days of the current month up to the current day. For the current and future days we draw the columns with a different visualization style, to visually outline the uncertainty of the data measurement. On the X axis we show 4 or 5 titles, for day 1, 8, 15, 22 and 29 (except for non leap year February). The title is the day of the month.

  • By clicking one of the columns, the user can zoom the chart to a week view. In the week view we show the values over the week centered on the day selected by the user: 7 columns are visualized, and for each data point we show the title on the X axis. We also add two other columns to the data visualization in order to supply more detailed information:

  • Finally, we add to the visualization a Zoom Out button to allow the user to go back to the month view. The Zoom Out button will disappear when the user zooms all the way out.

Dive with us into the source code of our example chart to see how easy this task can be! You can find instructions on how to setup the example project to use Closure in the README file.

Getting to the goal: fetching the data

After the Google API JavaScript client has loaded, the OAuth 2.0 flow completes, and the user logs in, makeApiCall is called to start the generation of the chart.

The first thing we do in makeApiCall is fetch our data from the AdSense Management API. We want DATE to be the dimension for our report, and EARNINGS, PAGE_VIEWS_RPM and AD_REQUEST_RPM as our metrics. To determine start date and end date, we can use the Google Closure Library as shown in the getRequestParams function. After that we are ready to send our request.

Formatting the data: using roles

Once we have the data, the next step is to format it into a DataTable that will be consumed by our chart. The addTableHeaders function shows how to add the columns that we need for our chart. Two column declarations might catch your attention:

dt.addColumn({'type': 'string', role: 'tooltip'});
dt.addColumn({'type': 'boolean', role:'certainty'});

For these columns we are using DataTable Roles, an experimental feature of the Google Chart Tools that can be used to describe the purpose of the data in a column. Using the tooltip role we can edit the text to display when the user hovers over data points. Using the certainty role we can indicate whether a data point is certain or not, and have the column visualized in a different way accordingly.

Formatting the data: the content

After defining the columns, we can add rows of data to our DataTable. To do this, we need to keep the following into account:

  • The AdSense Management API will return a result for a day only if there is a nonzero value for that day. In other words, if one day we had zero views, the API will not return a result for that day. This also means that we will not get results for days in the future.

  • We want to make the certainty of a data point visible, so that we have a different visualization for measures that are certain and measures that are in progress or not started.

For the first point, we need to iterate through the values returned from the API. If a DATE is not present in the response, we add a row with value zero for all the metrics for that DATE to the table. To satisfy the second point, we need to check if the current day of the iteration is the current day of the month or a day in the future. If it is in the future, we need to flag the row as uncertain.

Remember that the rows part of the API response will be an array similar to:

"rows": [
  ["2012-01-03", "28", "46", "41"],
  ...
  ["2011-11-07", "2", "3", "3"]
]

The function addTableRows implements the data manipulation algorithm, using Closure to help out with dates formatting and days iteration.

The function formatRow shows how to create rows for our DataTable and add data for our tooltip and certainty columns. In the example, we have built the tooltips to show the full name of the day of the week for each data point, to help the user to better contextualize the value.

Enough for today!

At the end of day one, we have all the data ready to be visualized. Tomorrow we’ll see more on how to define our week and month views and implement the zooming functionalities.

In the meantime, don’t hesitate to ask your questions, leave your suggestions, and engage with us in our forums:

 - , AdSense API Team

Labels: ,

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.

 - , DFP API Team
Labels: ,

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
Labels:

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:
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.

- , DFP API Team
Labels: ,

When you need to retrieve a large set of objects, such as a list of criteria for an account, it’s tempting to use one simple query with a paging parameter to pull the data from the server page-by-page.

While this approach is acceptable for most queries, it has some limitations:

  • The AdWords API does not allow you to retrieve data whose start index is past 50000
  • Unit cost for the request will depend on the number of pages and will be relatively expensive
  • A parallel update request may interfere with the process
  • Error handling and retry logic could be complex

We recommend using one of the following approaches instead:

  1. Use AdHoc reporting to obtain data. With reports, you can still retrieve most fields available through SOAP requests, with the added bonus of AdHoc reporting being faster and free of unit costs.
  2. Try to narrow the query as much as possible with predicates. Group queries by Campaign and AdGroup to retrieve only required data and to fit all results into one response.

Also, you can save bandwidth and retrieve large results faster by enabling transparent gzip compression. Check out our best practices page for more details on this feature and other recommendations.

As always, please feel free to ask any questions regarding the AdWords API on our forum or during scheduled office hours.


 - , AdWords API Team
Labels: , ,