Showing posts with label dfp. Show all posts

We are out of beta!

Thursday, October 27, 2011 | 12:12 PM

Labels: , ,

In February 2010, we announced the new DFP API and have come a long way since the announcement. We’ve been busy innovating and have released seven versions of the API, including production access to the API in October last year.

Today we’re excited to announce that the DFP API is moving out of beta and is available to all publishers.  As part of this announcement, the DFP API program policies and terms of service have been updated to reflect this change. Additionally, activating your account to use the API can now be enabled by your account administrator.

If you have previously signed up for the DFP API using our production sign-up form, your API access will continue to work but please review and agree to the new terms of service.

We’re excited to take the API out of beta and make it available to all publishers, and we’d like to say a special thank you to the developer community who has provided us with great feedback to help get the API to this point.

DFP API Team

Deprecation of v201101, v201010, and v201004

Monday, May 23, 2011 | 3:00 PM

Labels: , ,

Today, we are announcing the deprecation of versions v201101, v201010, and v201004 of the DFP API. In 3 months, on August 22nd, 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.

We will always give at least 3 months notice before turning off a version. We will also supply information on migrating from deprecated versions on our release notes page . We suggest that if you aren’t using one of our client libraries , now would be a great time to start.  In the client libraries, we provide lots of code examples that you’ll be able to use as a “rosetta stone”, going from one version to the next. Since this may be the first migration for many of you, below are some tips for migrating from v201004.

Bind variables have been renamed to Value

In v201004, bind variables were named Params . In v201101, they were renamed to  Values . To migrate your code, you may have to instantiate the new Value class instead of Param. You will also have to consider that Statement  now takes an array of String_ValueMapEntry .

Authentication changes

Tokens are now wrapped in a complex type. For example, where you would once just put <authToken>, you now include an <authentication> element with the proper xsi-type i.e. xsi-type=”ns1:ClientLogin” (where ns1 is the DFP API namespace). For a full discussion of this change, see the blog post on Announcing v201103 .

New targeting

Several targeting features  have been added since v201004. These include geographical , day-time , user domain , and custom targeting . If you were setting these targeting options for lineitems on the DFP website and not including them in the API, you may have already been messaged that you should update your API version.

Reporting changes

There were a few changes to reporting introduced in v201103. In v201004, ReportQuery  could have a custom startDateTime  and endDateTime . To align the API with the features of the product, the ReportQuery  object now only takes dates for startDate  and endDate . Furthermore, this also fixes an issue where an additional day past the endDateTime was being returned. When migrating, you may be able to remove this custom code that fixed this behavior.

We hope that these tips will help you migrate your code faster and if you have any feedback or comments about this deprecation, or the API in general, please feel free to leave them on our forum .

Adam Rogal, DFP API Team

v201104 - Simplified APIs for geographical targeting and custom criteria

Friday, May 6, 2011 | 2:00 PM

Labels: , , , ,

The next version of the DoubleClick for Publishers (DFP) API, version 201104, is now available. In this release, we've made some updates to LineItem targeting. Specifically, you’ll find a more consistent geographical targeting interface as well as a simplified CustomCriteria API.

A full changelog for v201104 can be found in the release notes.

GeoTargeting

From this version of the API onward, when targeting a LineItem to a geographical location, ID numbers are now used to identify locations instead of string values. Specifically, when creating your Targeting, you won't use RegionLocation, MetroLocation, CityLocation, or CountryLocation objects, and thus, there's no need to pass strings such as "Chicago" or "US."

Instead, whether you’re targeting a country or a city, you simply create a Location object using only its ID number, where the ID number corresponds to a given country, city, etc.

After you pass the Location object to the service, in either a create or update method call, the Location object will return as the corresponding subclass, e.g. MetroLocation, CityLoction, or CountryLocation; this is to simplify the targeting process while still providing meaningful data about your locations.

Here’s an example of creating a Location object using only its ID number and handing it to a GeoTargeting object.

Location regionLocation = new Location();
// Target New York City.
regionLocation.setId(1023191L);
geoTargeting.setTargetedLocations(
    new Location[] {regionLocation});

To find the IDs of the locations you wish to target (New York City in our example), you'll need to call the Publisher Query Language (PQL) service, as shown below.

// Get the PublisherQueryLanguageService.
PublisherQueryLanguageServiceInterface pqlService =
    user.getService(
        DfpService
            .V201104.PUBLISHER_QUERY_LANGUAGE_SERVICE);

// Create statement to select all targetable cities.
StatementBuilder statementBuilder =
new StatementBuilder(
    "SELECT id, CityName FROM City"
    + "WHERE targetable = true AND CityName = ’New York’");

// Get all cities.
ResultSet resultSet = pqlService.select(
    statementBuilder.toStatement());

// Now grab the ID from the resultSet.
Row row = resultSet.getRows(0);
String[] values = PqlUtils.getRowStringValues(row);
String id = values[0];

Alternatively, note that you can also manually look up the ID for a given region in our documentation.

If you'd like to see a complete example, GetAllCitiesExample demonstrates how to query the PQL service for the relevant IDs, while CreateLineItemsExample demonstrates using the IDs for GeoTargeting.

CustomCriteria

The CustomCriteria interface has been simplified in a similar way. Custom targeting keys and values are now exclusively referenced by their ID numbers. Due to this change, the API no longer provides predefined or freeform CustomCriteria. Instead, keys and values must be created ahead of time, then referenced by ID in the CustomCriteria object.

First, you must create the key and value objects. See the original CustomCriteria announcement for a demonstration.

Once the key and value objects have been created, the next step is to plug in the corresponding IDs into the CustomCriteria object.

// Create custom criteria.
CustomCriteria customCriteria = new CustomCriteria();

// Grab the IDs of the keys and values you wish to target.
Long keyId = ...
Long valueId1 = ...
Long valueId2 = ...

// Assign the keys and values.
customCriteria.setKeyId(keyId);
customCriteria.setValueIds(new long[] {valueId1, valueId2});

// CustomCriteria allows us to target either as IS or IS_NOT.
customCriteria.setOperator(
    CustomCriteriaComparisonOperator.IS);

For further insight, please look at CreateCustomTargetingKeysAndValuesExample and TargetCustomCriteriaExample .

As always, we love to hear from our developers and we look forward to any and all feedback on our forum.


-- David Kay, DFP API Team

Authentication changes with 2-step verification

Wednesday, February 16, 2011 | 1:30 PM

Labels: , , , ,

We recently an announced an advanced opt-in 2-step verification process to help make your Google Accounts significantly more secure. 2-step verification adds an extra layer of security to your Google Account by requiring unique “verification codes” in addition to your username and password at sign-in. This means that if your password is stolen, you still have an extra line of defense against a potential hijacker.

Enabling 2-step verification on a Google Account associated with an DFP Account may lead to an authentication issue when using the DFP API, which uses ClientLogin ClientLogin provides the authentication functionality used by the DFP API, and is not designed to ask for the verification codes in addition to the password. Therefore, APIs accessing this interface must instead use a special password called an application-specific password.

For 2-step verification users, the ClientLogin API will return an error indicating that the user needs to use an application-specific password if the user tries to login with his regular account password. When this happens the response will contain an extra field that indicates that the error was due to a missing 2-step verification code, and not incorrect credentials.


    Error=BadAuthentication
    Info=InvalidSecondFactor
   

We recommend that your application detect this error and remind the user to use an application-specific password. The API doesn’t accept verification codes, but application-specific passwords can be created for an account that allow authentication without a verification code. These can be used in the ClientLogin API just like regular passwords, and they do not expire. To obtain an application-specific password, the user needs to log in to their Google Account and click on "Authorizing applications & sites ."




Under the application-specific passwords section, they should provide the name of the tool or application for which they wish to generate a password. The generated password will only be displayed once, and although it can’t be recovered later it can be revoked at any time.




Here’s what the generated password looks like:




To learn more about application-specific passwords, visit the Google Accounts Help Center Official Google Blog for the complete announcement.

As always, please post any questions to the DFP API Forum .


-- Adam Rogal, DFP API Team

Announcing v201101 and custom targeting support

Monday, February 7, 2011 | 1:00 PM

Labels: , , , , , ,

Today we are excited to announce the next version of the DoubleClick for Publishers (DFP) API, version 201101. Highlights of this release include the ability to define custom targeting criteria, and the new Publisher Query Language service.


Custom targeting

Custom targeting allows you to define your own targeting criteria (such as age, gender, or content) that DFP wouldn't otherwise be able to determine. To use custom targeting, you create keys and values, target your line items to those key-value pairs, and then add them to your website's ad tags.

Similar to creating ad units and then targeting them with line items, using the custom targeting API is broken into two steps. First, you will create custom targeting keys and values with the CustomTargetingService, and then you will target these keys and values with the LineItemService. To target the keys and values, set the customTargeting field with a CustomCriteriaSet object. The custom criteria set object contains the targeting expression as an ORed set of ANDed custom criteria. The leaf nodes of the tree are key-value pairs of either free-form or predefined criteria.

If you had the expression (age=17 OR (gender=male AND age=42)), this would be represented as two custom criteria sets with logicalOperator.AND, [age=17] and [gender=male, age=42] ORed together. The custom criteria sets would be children of the customTargeting field.

Below is a diagram that will help you understand how the tree must be organized. The first level is the customTargeting field of the line item. The second level is the ORed custom criteria sets, the children of customTargeting. The final level is the custom criteria that belong to each custom criteria set, ANDed together.



In the above example of (age=17 OR (gender=male AND age=42)), the custom criteria set would look something like this:



For more examples on how to create and target custom criteria, please see the CreateCustomTargetingKeysAndValuesExample.java example as well as the TargetCustomCriteriaExample.java example.


Publisher Query Language service

The new PublisherQueryLanguageService allows you to query for data in the DFP network. You can use the service to pull information about geographical targeting that you could only previously retrieve by downloading one of the CSVs on the geographical targeting page. You can retrieve all targetable cities, for example, by sending a PQL statement like:


SELECT * FROM City where targetable = true

You would receive a ResultSet object similar to the one found in JDBC. Notice that we have included the targetable column in each of our tables to select on locations which can be successfully targeted in line items. A full list of tables can be found on the services reference page and we plan to expand this to other tables in the future.


New release notes page

With this new version, we have also modified our release notes page to give you a better per-object breakdown of new and deprecated fields and services. This will make upgrading your implementation that much easier.

Custom criteria targeting has been our most requested feature and we are eager to receive any feedback you may have through our forum. Also, if there are any blog posts about specific topics you may want, please do not hesitate to make requests on our forum as well.

– Adam Rogal, DFP API Team

Announcing the .NET client library

Thursday, December 16, 2010 | 3:00 PM

Labels: , , ,

We are happy to announce the release of our new DoubleClick for Publishers .NET client library.The DoubleClick for Publishers API .NET Client Library makes it easier to write .NET clients which access the DFP platform.

Main features include:

  • Support for .NET SDK 2.0 and above.
  • Outgoing and incoming SOAP messages are monitored and logged.
  • Support for API calls to sandbox and production environments.
  • As opposed to autogenerated stubs from wsdl.exe, you don't have to specify xxxSpecified = true for each nullable property.
  • Support for specific DFP exceptions instead of generic SoapExceptions.

Additional information can be found at the DFP API code site’s client libraries page.

Bugs and feature requests can be filed at https://code.google.com/p/google-api-dfp-dotnet/issues/list.

Please post any questions or feedback to the DFP API Forum.

– Adam Rogal, DFP API Team

Introducing v201010 and Geographical Targeting

Tuesday, November 9, 2010 | 2:00 PM

Labels: , , , , ,

Today, we are pleased to announce the launch of the latest version of the DoubleClick for Publishers (DFP) API. The latest version of the API (v201010) includes several exciting new features including geographical targeting. To learn how to use geographical targeting in the DFP API, please review the instructions below.


Geographical targeting

You can find geographical targeting as a new field of the LineItem.targeting property. Note that this field was added as part of the new version in a way that backwards compatibility is maintained. As we release new features, we will continue to do so in a backwards compatible manner.

The geographical targeting API is very similar to what you may have seen in the DFP UI, ranging form countries to cities which can be included or excluded as criteria. The rules for how these locations can be targeted are present in the description of the GeoTargeting class. Below is an example of how you would target the United States and Quebec, Canada, but exclude Chicago and the New York metro area.

// Get the LineItemService.
LineItemServiceInterface lineItemService =
    user.getService(DfpService.V201010.LINEITEM_SERVICE);

// Create geographical targeting.
GeoTargeting geoTargeting = new GeoTargeting();

// Include the US and Quebec, Canada.
CountryLocation countryLocation = new CountryLocation();
countryLocation.setCountryCode("US");
RegionLocation regionLocation = new RegionLocation();
regionLocation.setRegionCode("CA-QC");
geoTargeting.setTargetedLocations(
    new Location[] {countryLocation, regionLocation});

// Exclude Chicago and the New York metro area.
CityLocation cityLocation = new CityLocation();
cityLocation.setCityName("Chicago");
cityLocation.setCountryCode("US");
MetroLocation metroLocation = new MetroLocation();
metroLocation.setMetroCode("501");
geoTargeting.setExcludedLocations(
    new Location[] {cityLocation, metroLocation});

// Create the line item.
LineItem lineItem=new LineItem();
lineItem.setName("Geo targeted line item");
lineItem.setTargeting(
    new Targeting(geoTargeting, inventoryTargeting));

// Finish setting line item properties...

// Create the line items on the server.
lineItem = lineItemService.createLineItem(lineItem);

Note that some locations use ISO codes, while some use friendly names. These codes can be found on the geographical targeting code list page and can also be downloaded as CSVs from the links at the top of that page.


What else is new?

In addition to geographical targeting, v201010 includes several other changes and improvements. All of these changes can be found here.

As we continue to release new features to our API, we look forward to receiving your feedback on our forum.


-- Adam Rogal, DFP API Team

Welcome to the Production API

Tuesday, October 12, 2010 | 12:00 PM

Labels: , ,

A few months ago we introduced the new DoubleClick for Publishers (DFP) API to enable publishers and third-parties to customize and extend how they use DFP. The API comes in two flavors: sandbox and production environments. When we initially released the API, all developers could use the the sandbox environment to to test their code without affecting their live ads.

Today, we're excited to announce that we are now accepting applications for production API access. The production environment represents the data you see in your DFP account, and allows access and changes to your live data.

To request access to the production API environment, please complete this form. After filling out the form, you will be contacted regarding your eligibility to participate.

We recommend you review the differences between production and sandbox access before you apply:

  • Sandbox accounts were all created as DoubleClick for Publishers premium solution networks, regardless of which edition of DFP you actually use. If you are a DFP Small Business publisher, there will be a few differences when using the API on your live account. More information can be found on our account types page.

  • Inventory is structured differently between DFP Small Business accounts and premium solution DFP accounts. We’ve launched the new NetworkService to help developers work with both types of accounts. You’ll find the CreateAdUnits example and the GetInventoryTree example especially useful while learning about the differences.

Over the last 6 months, we’ve gathered tremendous feedback from the developer community and we hope you will keep it coming. You’ll also notice that we’ve reorganized our API documentation to make it easier to navigate. We are committed to answering all questions about the API, especially on our forum, and look forward to seeing what you develop!


-- Adam Rogal and the DFP API Team

Introducing the ReportService and ForecastService

Wednesday, June 9, 2010 | 2:00 PM

Labels: , , ,

Today we are launching two brand new services for the DFP API - the ReportService and the ForecastService. The goal of these two services is to enable you to gain a better understanding of the performance and the availability of your network.

The ReportService

The ReportService enables you to run the same reports seen in the DFP user interface, as well as create custom reports that can be run programmatically to analyze the performance of a network on multiple dimensions and attributes. In the client libraries, we provide examples for running three typical reports (delivery, inventory, and sales) that many users of DFP Small Business (and former GAM customers) should be familiar with. We also provide utilities for scheduling and downloading reports as well.

The ForecastService

The ForecastService enables you to gain an understanding about current availability as well as forecasted inventory. The service works in one of two ways. You can first check the availability of an exiting LineItem by running the method getForecastById. The result will be a description of the total forecasted units that the line item will take, along with its current progress. Imagine the following use case:

  1. You schedule a sponsorship LineItem to run for the following month and you have guaranteed the customer that you will serve at least 100,000 impressions.
  2. You run getForecastById on that LineItem and discover that at the current unitsBought, the customer will only receive 80,000 impression, as returned by Forecast.forecastUnits.
  3. You then update the line item to a higher percentage and rerun getForecastById until you can successfully fulfill the guaranteed impression count.

The ForecastService also enables you to check if a potential line item will fulfill its requirements before it is booked. Imagine the following actions on taking place on a dashboard page:

  1. You fill out the dashboard for a LineItem with a set of initial estimates of the priority and duration to reach a guarantee to the customer of 5000 clicks.
  2. The dashboard would then call getForecast supplying the hypothetical line item that happens to be set to standard priority.
  3. Running getForecast on thatLineItem shows that the available clicks is only 4000, as returned by Forecast.availableUnits.
  4. You interpret this result as there are either competing line items of the same priority that can be adjusted, or you can book the line item anyways knowing that other line items with a lower priority may not meet their expectations.

Intended use in the sandbox

We'd like to make it very clear that the results you get from running either of these services in the sandbox will return a limited amount of data, since your account isn't serving live traffic. On production API accounts, these services return the same data you see in the user interface. Any requests made against the ReportService in the sandbox will return a blank report with only the correct columns. For the ForecastService, the service will return specific test data for the input, depending on the line item attributes such as unitsBought and lineItemType.

During this period, we hope that we can gather valuable feedback (which you can leave on our forum) about the features of these two new services. Feedback regarding topics like providing the correct set of columns to choose from on reports, or whether retrieving forecasts is straightforward would be most helpful. We understand that production access is still a top priority and we hope that the launch of these two services shows that your feedback is important to us as we continue to develop the API.

-- Adam Rogal, The DoubleClick for Publishers API Team

Taking a closer look at the Publisher Query Language and the future

Friday, May 7, 2010 | 3:00 PM

Labels: , ,

Recently we launched v201004, and with that introduced the new Statement object which gives support for one of our top requested features - bind variables. In this blog post, we will take a closer look at the Publisher Query Language (PQL), Statements with bind variables, and what we have in store for the future.

Publisher Query Language

PQL plays a very significant role in the DFP API by providing the developer with a robust way of filtering which objects should be retrieved or modified before the request is completed. In other words, if you would like to retrieve only orders which are in the draft state, you could take one of two approaches. You could fetch all orders within your network and filter them one by one or instruct the server to only fetch orders in the draft state before returning all results. By doing the latter, the DFP API allows developers to create smaller and more direct requests, and, in turn, increases the efficiency of their code.

PQL has a very similar syntax to SQL, but does not include keywords such as SELECT or FROM; they are implied by the method which uses the PQL statement. The following piece of code constructs a Statement capable of fetching orders in the draft state and retrieves those orders:

  // Create a statement to only select orders in the
  // 'DRAFT' state. 
  Statement filterStatement = new Statement();
  filterStatement.setQuery("WHERE status = 'DRAFT' LIMIT 500");
  OrderPage orderPage =
      orderService.getOrdersByStatemet(filterStatement);

The documentation included for each "get*ByStatment" (e.g. getOrdersByStatement) method indicates which PQL fields map to which object properties.

Paging

The result for "get*ByStatment" calls are pages specific to the service; i.e. an OrderPage is returned by getOrdersByStatement. The limit for the number of objects that can be fetched for a single PQL request, and in a single Page, is 500. Because of this, you should always include LIMIT 500 in your statement. However, if you would like to fetch more than 500 objects, you will need to page through the results by including an OFFSET <#> in your statement as well. To page through orders in groups of 500, for example, in your statement, you would include LIMIT 500 as well as an OFFSET of an interval of 500.

This can be represented by the following code:

  // Sets defaults for page and filter.  
  OrderPage page = new OrderPage();
  Statement filterStatement = new Statement();
  int offset = 0;

  do {
    // Create a statement to get all orders.
    filterStatement.setQuery(
        "WHERE status = 'DRAFT' LIMIT 500 OFFSET " + offset);

    // Get orders by statement.
    page = orderService.getOrdersByStatement(filterStatement);

    if (page.getResults() != null) {
      int i = page.getStartIndex();
      for (Order order : page.getResults()) {
        System.out.println(i + ") Order with ID \""
          + order.getId() + "\", name \"" + order.getName()
          + "\", and advertiser ID \"" + order.getAdvertiserId()
          + "\" was found.");
        i++;
      }
    }
    offset += 500;
  } while (offset < page.getTotalResultSetSize());

The loop will end when there are no pages left, i.e. the offset is greater than or equal to the to the total result set size.

Bind variables

Bind variables were recently introduced to allow for reusing of the same template PQL statement combined with varying parameters. To change the PQL statement above to differ which status is being selected, 'DRAFT' is changed to the bind variable status, represented by :status. Note that bind variables can be any name - not just the name of their property. We chose :status here for simplicity.

  // Create a statement to only select orders in the state
  // bound to status.
  Statement filterStatement = new Statement();
  filterStatement.setQuery("WHERE status = :status LIMIT 500");

To bind to :status, you will need to create a parameter map with a String_ParamMapEntry coupling :status with a StringParam. Note that ":" is not included in the bind variable name in the parameter map.

  // Create the string parameter.
  StringParam stringParam = new StringParam();

  // Create bind parameters map.
  String_ParamMapEntry[] paramMap = new String_ParamMapEntry[] {

      new String_ParamMapEntry("status", stringParam)
  };

  filterStatement.setParams(paramMap);


 Before you make the call to getOrdersByStatement, set the stringParam value to the specific status.

  stringParam.setValue("DRAFT");

In this case, because status was bound to a variable declared before the parameter map, you can set the variables value at any time.

The first iteration of the while loop above would then produce the following XML snippet:

  ...
  <filterStatement>
    <query>WHERE status = :status LIMIT 500 OFFSET 0</query>
    <params>
      <key>status</key>
      <value  xmlns:ns2=
          "https://www.google.com/apis/ads/publisher/v201004"  
          xsi:type="ns2:StringParam">
        <value>DRAFT</value>
      </value>
    </params>
  </filterStatement>
  ...

Planned features and production

The release of v201004 was the culmination of the last step before we can begin rolling out access to the production API and we will have more information about signing up to for production use in the coming weeks. We are still hard at work on the forecasting and reporting service and will have some news about those in the following weeks as well.

We appreciate all of the great feedback we've been receiving on the forum, both on the API and the client libraries, and we''ll continue to incorporate it as we continue development.

-- Adam Rogal, The DoubleClick for Publishers API Team

Introducing Google's DoubleClick For Publishers API

Monday, February 22, 2010 | 8:00 AM

Labels: , ,

Today, we announced the next generation of our ad serving technology for online publishers, the new DoubleClick for Publishers (DFP) from Google. I am pleased to announce that the new version of DFP comes with a modern API that enables publishers and third-parties to customize and extend the product.

As we mentioned in our Google blog post, for the past few years, we've been investing in a suite of solutions — AdSense, ad-serving technology and the DoubleClick Ad Exchange — to help online publishers make the most money possible from their content, whether they sell advertising through their own sales force directly, through an ad network such as AdSense, or a combination of both. We saw an opportunity to improve these solutions by combining Google's technology and infrastructure with DoubleClick's display advertising and ad serving experience. The new DoubleClick for Publishers is a result of that combination of strengths, as is the API that comes with it.

The new API is available to publishers who use DFP, as well as to third-parties and vendors who would like to build applications on top of DFP. A growing community of developers is already working on sales, order management, workflow and data visualization tools. We've incorporated feedback on the existing DART for Publishers API and believe the new API is a significant step forward. It uses SOAP, a standard and widely-adopted messaging technology that uses HTTP requests to transmit and receive XML data between your client and our servers. This means you can use it with virtually any programming language of your choice. We have a wealth of public documentation available online and there are numerous code samples and client libraries ready for you to download.

To learn more about the new API, there are a few places to get started:

When you are ready to begin development, please sign up to receive access to a sandbox development environment. In this environment, you will be able to explore the API without worrying about affecting your production accounts. API access to production DFP accounts is being rolled out in waves to customers who have used the sandbox environment and will be granted as resources allow. Please start your development effort using the sandbox environment now. You'll be able to contact us when your application is ready to test in the production environment through a new sign-up form that will appear on our online documentation and on our blog.


We are looking forward to working with you and seeing what you build!

Alex Vogenthaler
Product Manager, DoubleClick for Publishers