If I asked you "why do you love this time of year?", I might get back a variety of responses ranging from "the fall foliage where all the leaves change color," or "turkey, stuffing, and pumpkin pie," or perhaps the most obvious answer since the advent of steamed milk - "pumpkin spice lattes." For me, it's none of those things. The reason why I get uncomfortably excited every year when November rolls around is because the DFP release & deprecation schedule aligns perfectly so that the last release of the year happens right about now. So without further ado, I present you with the latest and greatest version: v201511.

Trafficking Updates

We've been going back and cleaning up our APIs to make them simpler and easier to use. Remember that target platform unification change we made? Now that you've switched over to using TargetPlatform.ANY (and why should you miss out on that sweet mobile traffic because of a pesky ENUM?) we've removed it entirely from the LineItem and AdUnit objects. On the creatives front, Template and Custom creatives now use CreativeAssets for associated assets.

Sales Manager Updates

On the sales manager front, we've exposed a few reporting dimension attributes: PROPOSAL_FLAT_FEE and PROPOSAL_LINE_ITEM_FLAT_FEE, which represent the billing setting for the flat fee checkbox in the UI. In addition, if setting deliveryRateType and roadblockingType are things that you have been wishing for, consider your wish granted. In v201511, you can now set DeliverySettings on ProductTemplates.

See full release notes here.

As a reminder, with each new release comes a new deprecation. If you're using v201411 or earlier, it's time to look into upgrading. v201408 will be sunset at the end of November 2015, and v201411 will be sunset at the end of February 2016. If you have any questions about upgrading, let us know on the developer forum.

 - Nicholas Chen, DFP API Team

On Monday, November 30, 2015, in accordance with the deprecation schedule, v201408 of the DFP API will be sunset. At that time, any requests made to v201408 will return errors.

If you're still using v201408, now's the time to upgrade to the latest release and take advantage of new features like line item level reconciliation (see our guide here). To do so, check the release notes to identify any breaking changes, grab the latest version of your client library and update your code.

Some changes to look out for:

• Flash creatives have been updated to use CreativeAssets.
• Report DimensionFilters have been replaced by PQL equivalents.
• The ReportService's getReportJob has been replaced with getReportJobStatus. The new method returns only the ReportJobStatus.
• The ForecastService was given a facelift, adding support for a new kind of forecast and more granular breakdowns.
• LineItem.startDateTime and LineItem.endDateTime now require a timeZoneID. You can retrieve all of the supported time zone IDs from the Time_Zone PQL table.
• Type fields have been removed from all entities. Use class names, instance of, or xsi:type instead.

This is not an exhaustive list, so as always, don't hesitate to reach out to us with any questions. To be notified of future deprecations and sunsets, join the DFP API Deprecation Announcements group and adjust your notification settings.

 - Chris Seeley, DFP API Team

Recently, we announced the availability of native ads for apps in DFP. Here, we’re going to introduce you to creating native creatives with the DFP API using the ads Java client library. A native creative consists of a set of assets (headline, image, etc.) which are sent to mobile apps for custom rendering in their own code (see our Android and iOS developer guides for details).

Native creatives are actually just another type of template-based creative. While the DFP UI abstracts this, in the API you create a native creative using a TemplateCreative with the system-defined native template ID. The creative template IDs available in your network can be retrieved by the getCreativeTemplatesByStatement method in the CreativeTemplateService. You can also view these IDs in the UI under Delivery > Creatives > Native ad formats (see the ID below each native ad format name in the table). The native app install template ID is 10004400.

    TemplateCreative nativeAppInstallCreative = new TemplateCreative();
    nativeAppInstallCreative.setCreativeTemplateId(10004400L);

Because native creatives do not have a predetermined size, you need to set a placeholder size of 1x1.

    Size size = new Size();
    size.setWidth(1);
    size.setHeight(1);
    size.setIsAspectRatio(false);
    nativeAppInstallCreative.setSize(size);

Finally, specify a name and destination URL; this example is for the Pie Noon app:

    nativeAppInstallCreative.setName("Pie Noon native ad");
    nativeAppInstallCreative.setDestinationUrl(
        "https://play.google.com/store/apps/details?id=com.google.fpl.pie_noon");

Settings specific to native creatives are set via template variables. An app install native creative requires the following unique template variable names to be set:

• Headline
• Body
• Image
• Price
• Appicon
• Calltoaction
• Starrating
• Store
• DeeplinkclickactionURL

Note that creative template variables are case sensitive and those of type AssetCreativeTemplateVariableValue (“Image” and “Appicon”) must have a unique filename.

You can find the full Java example on how to create native creatives in our GitHub repository here. All of our other ads client libraries have similar examples.

As always, if you have any questions, feel free to drop us a line on the DFP API forums or the Ads Developer Google+ page.

 - Vincent Tsao, DFP API Team

It’s finally here, the release everyone some of you have been waiting for: v201508. I know you’re excited and probably want to go download an updated version of the client library right away, but give me a second to tell you why you should be excited.

We’ve improved the reconciliation services in the DFP Sales Manager API, making for easier updates and reporting. There’s a bunch of changes to trafficking creatives giving you more control and visibility over your creative library. We’re also cleaning house on reporting, making the columns and dimension attributes you know and love that much easier to use.

(see full release notes here).

DFP Core

DFP trafficking objects received a few facelifts in this version.

• We removed IDs from CreativePlaceholders (don’t worry, they weren’t being used anywhere).
• On the creatives front, we switched Flash creatives over to use CreativeAssets, which should make duplicating and reusing flash creatives much easier. And we added CreativePolicyViolations to each creative so you can know exactly why a creative or line item was paused.
• We’ve updated line item creative associations by adding a DeleteLineItemCreativeAssociations action to match UI functionality. It should be noted that deleting them is a permanent action and not simply a change in status. Deleted LICAs will no longer be accessible in the UI or API.

Sales Manager

If it’s been your dream to reconcile your delivery and billing data at the line item level, you should probably sit down for this, because featured in this release is the addition of the ReconciliationLineItemReportService which brings parity to the reconciliation process in the UI.

Additionally, we’re adding a few replacement DimensionAttributes to our ReportService - PROPOSAL_LINE_ITEM_LAST_RECONCILIATION_DATE_TIME, PROPOSAL_LINE_ITEM_RECONCILIATION_STATUS, and their LINE_ITEM_* equivalents to use for when you start reconciling line items. See the related blog post on the removal of the RECONCILIATION_RECONCILIATION_STATUS and RECONCILIATION_LAST_DATE_TIME columns found here.

Reporting

We’ve removed all DimensionFilters, as stated earlier this year (ones that have significant usage are replaced with PQL filters), added two new dimensions for ORDER_DELIVERY_STATUS as well as AGGREGATED_DEMAND_CHANNEL, and renamed the Nielsen metrics from NIELSEN_OCR_* to NIELSEN_*.

As a reminder, with each new release comes a new deprecation. If you're using v201408 or earlier, it's time to look into upgrading. If you have any questions about upgrading, let us know on the developer forum.

 - Nicholas Chen, DFP API Team

Does your company want to provide third-party services for DFP but is unsure how to get started? If so, you're in luck! We've just published a new guide on how to integrate with DFP as a third party. The guide covers the major topics that new integrators commonly run into:

• How to get started.
• How to test your DFP integration.
• How to properly set up authentication to access a client's network.
• How to keep up to date with API versions.
• Where to get support.

All this information can be yours just by visiting our guide.

If you have any questions, feel free to drop us a line on the DFP API forums or the Ads Developer Google+ page.  - Vincent Tsao, DFP API Team

On Monday, August 31, 2015, in accordance with the deprecation schedule, v201405 of the DFP API will be sunset. At that time, any requests made to v201405 will return errors.

If you're still using v201405, now's the time to upgrade to the latest release and take advantage of fresh new features like DeliveryForecasts. To do so, check the release notes to identify any breaking changes, grab the latest version of your client library and update your code.

Some changes to look out for:

• The endpoint URL for requests has changed from https://www.google.com to https://ads.google.com. We updated this in the default settings of our client libraries, but double check your local configuration files as well.
• LineItem.startDateTime and LineItem.endDateTime now require a timeZoneID. You can retrieve all the supported time zone IDs from the Time_Zone PQL table.
• The ForecastService was given a facelift, adding support for a new kind of forecast and more granular breakdowns.
• All MERGED_* reporting metrics have been deprecated and removed.
• The ReportService's getReportJob is now getReportJobStatus. The new method returns only the ReportJobStatus, not the entire ReportJob.

This is not an exhaustive list, so as always, don't hesitate to reach out to us with any questions.

 - Chris Seeley, DFP API Team

After our last round of spring cleaning, we've gone back to the drawing board to take another look at how we could make reporting better. There currently is an abundance of Dimensions, DimensionAttributes, and Columns (and more coming with each release), so in an effort to simplify the list of fields, we will be sunsetting the following reconciliation-related dimension attributes / columns in all versions. This will happen on September 1, 2015.

Columns with equivalent replacements:

• RECONCILIATION_LAST_DATE_TIME replaced by dimension attribute: PROPOSAL_LINE_ITEM_LAST_RECONCILIATION_DATE_TIME and LINE_ITEM_LAST_RECONCILIATION_DATE_TIME
• RECONCILIATION_RECONCILIATION_STATUS replaced by dimension attribute: PROPOSAL_LINE_ITEM_RECONCILIATION_STATUS and LINE_ITEM_RECONCILIATION_STATUS

Columns without equivalent replacements:

• LINE_ITEM_RECONCILED_RATE (in <= v201502)
• CONTRACTED_REVENUE_CONTRACTED_PLACEMENT_NET_REVENUE (in <= v201411)
• CONTRACTED_REVENUE_CONTRACTED_PLACEMENT_GROSS_REVENUE (in <= v201411)
• DISCOUNT_BREAKDOWN_ADDITIONAL_ADJUSTMENT (in <= v201411)

While the first two have equivalent replacements, the latter ones are not being replaced, as they don’t exist in core product reporting either.

This means that usage of these columns / dimension attributes will begin throwing errors in all versions starting September 1st. If your network is actively using any of these, please update your reports to switch to the supported fields or remove them entirely. If you have any questions, comments, or concerns about this, you know where to reach us!

 - Nicholas Chen, DFP API Team

Believe it or not, the DFP API Team eat, breathe, and live the DFP API. We wake up in the morning thinking, "How can I make the DFP API even better?" Seriously, I have had dreams about the API. It’s weird, but I’m not embarrassed to admit that.

In an effort to delight our developers even more, we’re turning the proverbial mic over to you - our customers - to help us help you. Here’s your chance to let us know how we could be better – better support, better features in the client libraries, better content in workshops, better examples, better haircuts... really, anything. Simply fill out our survey with your thoughts here.

 - Nicholas Chen, DFP API Team

Hello, DFP API developers! We just wanted to let you know of some minor DFP API changes that affect all versions of the API. Most likely these won’t affect your integration with DFP, but we’re announcing them here for transparency.

Deleted line item creative associations (LICAs) are no longer persisted

Deleted LICAs are no longer persisted in the product. This will affect all versions of the API. There are two things to be aware of as a result of this. First, the method getLineItemCreativeAssociationsByStatement will no longer include these deleted LICAs. Second, if you’re syncing your LICAs daily, you may notice fewer LICAs coming back. As a reminder, you can always use the action DeactivateLineItemCreativeAssociations if you want to keep them around, but not use them. This change is already in effect.

Creative placeholders are no longer assigned an ID

We are also getting rid of CreativePlaceholder.id because it is not used or referenced anywhere in the API. This field will be removed in v201508. For all versions prior to v201508, this ID now comes back as 0, instead of an ID assigned by Google. This change is also already in effect.

If you have any concerns or questions about these changes, you can always contact us on the DFP API forums and we’ll be glad to help you out.

 - Vincent Tsao, DFP API Team

If you’re a DFP developer using our API, no doubt you’ve had a question or two at some point during your integration with DFP. You’ve probably visited the DFP API forums, if not posted to them. Today we just wanted to remind you of a few simple things you can do to help us answer your API questions more efficiently.

Let us know who you are

Including the following information with every question you ask helps reduce the turnaround time for your question:

• your network code
• the user ID of the DFP user you’re authenticating as

Send us SOAP logs

SOAP logs contain the raw XML that describes the requests and responses of the API calls you make. These logs can help narrow down issues much faster. If you’re using one of our client libraries, you can visit its GitHub page to learn how to enable logging. For example, Java’s is here.

Here are some additional tips around SOAP logging.

• When sending us logs, try to send the minimal amount of SOAP logs that clearly show the error or issue that’s occurring. If you send your entire SOAP log for the day, it’ll take longer for us to go through and increase your turnaround time.
• If you’re seeing errors in your production environment and don’t have full SOAP logging enabled due to space constraints, consider logging only request IDs from the SOAP response instead. Not all errors will necessarily have a request ID, but if they do, that ID can help us look up your error.
• If you’re not comfortable posting SOAP logs on the forums, you can either (1) paste a snippet of your code instead, or (2) reply directly to us by using reply privately to author.

Distinguish a product issue from an API specific issue

Generally, if an error or issue occurs in both the DFP web UI and API, it is most likely a product-level issue and non-specific to the API. To help determine this, you can try reproducing what you’re doing via the API in the web UI to see if you get the same error or issue. Product-level issues are better handled by your account manager or by posting to the DFP product forums.

If you’re still unsure, you can always post your issue in the API forums and we will be glad to help you out.

 - Vincent Tsao, DFP API Team

Today we are releasing v201505 of the DFP API. This release brings changes to the ReportService and new features to the Sales Manager API, including advanced ProposalLineItem actions.

In v201505, the ReportService loses all MERGED_* metrics. These metrics, relics from DART migrations, are being deprecated. For more details, check out our earlier blog post. Additionally, the getReportJob method has been replaced by getReportJobStatus. The report utilities in our client libraries have been updated, but you should verify this in your code as well. Migration is straightforward, as shown in this Java example:

    // v201502 code
    ReportJobStatus status = reportService.getReportJob(reportJobId).getStatus();

    // v201505 code
    ReportJobStatus status = reportService.getReportJobStatus(reportJobId);

Sales Manager users get new ProposalLineItem actions, including ActualizeProposalLineItems and ReleaseProposalLineItems. You can also use BypassProposalWorkflowRules and include a comment when approving workflow requests.

For a full list of these and other changes, check the release notes.

As a reminder, with each new release comes a new deprecation. If you're using v201405 or earlier, it's time to look into upgrading. If you have any questions about upgrading, let us know on the developer forum.

 - Chris Seeley, DFP API Team

It's that time again - time to say goodbye to another version of the DFP API. In accordance with our deprecation schedule, v201403 has been deprecated and is scheduled for sunset on Tuesday, June 30 2015. At that time, any requests made to v201403 will return errors.

If you're currently using v201403, there's still time to migrate to the latest and greatest v201502. To do so, check the release notes to identify any breaking changes, grab the latest version of your client library, and update your code!

Things to look out for include:

• OAuth SOAP headers are no longer supported. You'll need to pass authentication information in HTTP headers instead. If you're using a client library, we took care of this for you.
• Line item fields unitsBought and unitType have moved into the Goal object.
• The endpoint URL for requests has changed from https://www.google.com to https://ads.google.com. We updated this in the default settings of our client libraries, but double check your local configuration files as well.
• LineItem.startDateTime and LineItem.endDateTime now require a timeZoneID. You can retrieve all the supported time zone IDs from the Time_Zone PQL table.
• The ForecastService got a facelift, including renaming existing methods and adding support for a new kind of forecast.

This is not an exhaustive list, so as always don't hesitate to reach out to us on our API forum with any questions.

 - Chris Seeley, DFP API Team

Now that it’s spring again (in the Northern Hemisphere at least), it’s time for DFP’s annual spring cleaning! In this edition, we’ll be doing some pruning of our ReportService. What does this mean for you? We’re sunsetting some reporting dimensions, attributes, and metrics in existing versions (before the version is fully sunset), so your reports will break if you don’t migrate before the shutoff dates. I know what you’re wondering: “should I panic?”. Absolutely not. This type of behavior rarely occurs, so as long as you phase out usage for these particular fields, you should be fine moving forward.

Merged Metrics

Remember when Doubleclick for Publishers was called DART? I, too, get nostalgic about our old ad server, but it’s been a couple of years since we transitioned to the new DFP platform, and it’s just about time when the merged reporting columns are no longer useful (these columns only existed so you could continue reporting on delivery that spanned DART and DFP). In all versions after v201502, we will no longer provide merged reporting columns and dimension attributes in the API, that is, anything starting with 'MERGED_' or contains '_LIFETIME_MERGED_.' After August 1, 2015, these columns and dimension attributes will stop returning data entirely and will return INVALID_COLUMNS in all versions that still include them.

There are three scenarios in which you’re using these columns:

1. Just for fun.
2. Because you forgot you’re using them.
3. Because you have lifetime line items that have carried over from DART (in which case you’ll have to recreate these). To give you an example, if the metric you care about is impressions, you can get the DART delivery portion by subtracting the portion of delivery from DFP Premium (AD_SERVER_IMPRESSIONS) from the MERGED value (MERGED_AD_SERVER_IMPRESSIONS) which represents the aggregate DART and DFP Premium volume. Additionally, you should make the switch to the non-merged columns and dimension attributes as soon as possible.

Dimension Filters

But wait, there’s more! Our next API version (v201505) will be the last to support some of our infrequently used dimensionFilters.

• MOBILE_LINE_ITEMS
• WEB_INVENTORY_UNITS
• MOBILE_INVENTORY_UNITS
• WHOLE_NETWORK
• PARTNER_STATS_TYPE_ESTIMATED
• ACTIVE_ADVERTISERS
• PARTNER_STATS_TYPE_RECONCILED
• WEB_LINE_ITEMS
• ALL_SALESPEOPLE

In each of the cases above, the filters either no longer provide meaningful information (as is the case with mobile vs. web line items and ad units with platform unification complete), or weren’t being used at all.

Similar to the changes above, after August 1, 2015, these dimension filters will return an INVALID_DIMENSION_FILTERS error in any version that still includes them.

So if you’re using any of the reporting features above, consider this an early heads up (and an opportunity) to refactor some of your code for spring cleaning.

As usual, if you have any questions, comments, or concerns, don’t hesitate to let us know on the forums.

 - Nicholas Chen, DFP API Team

A few weeks back we hosted a workshop for the Display Ads APIs and SDKs where we gave presentations on the DFP API, IMA SDK, and Mobile Ads SDK. If you weren’t able to attend, or want a refresher on something you saw that day, you can check out our presentation videos and slides. If you have any questions about those videos, feel free to ask on our respective forums:

• DFP
• IMA
• Mobile Ads

 - Shawn Busolits, IMA SDK Team

One of the most used services in the DFP API is the LineItemService. Many of you are already utilizing the Line_Item table in the PublisherQueryLanguageService to create match tables on fields like Status or ExternalId, but with newer API versions, more and more fields are available as columns. Did you know that as of v201411 the Line_Item table includes a column for Targeting? With so many line item fields now accessible through PQL, the Line_Item table might be a viable replacement for your read operations.

What's the advantage? Faster response times. As an example, I pulled 5,000 line items from a network using both the LineItemService and the Line_Item PQL Table, printing page offsets as the results arrived. Take a look at the results:

* Actual response times may vary. Line item fields only available in participating PQL Tables.

Using the PublisherQueryLanguageService shaved off 17 seconds for a respectable speed increase of 15%.

However, if your application doesn't need some of the heavier fields, you'll see a much bigger gain. Check out what happens when we leave out Targeting:

The sparse selection offered by the PublisherQueryLangugeService means our data size is smaller, cutting the total time by a whopping 45%!

If you're looking for a performance boost in your LineItem read operations, give the Line_Item table a try. We've got example code in each of our client libraries to get you started. If you have any questions, don't hesitate to reach out to us on our API forums.

 - Chris Seeley, DFP API Team

Today we are releasing v201502 of the DFP API. This release includes a revamp of the ForecastService, including support for Delivery forecasts. There are also new video features including GRP settings on line items, GRP breakdowns in forecasts, and new VIDEO_VIEWERSHIP report columns.

Sales Manager gains three new services for Packages, ProductPackages, and ProductPackageItems. Additionally, the ProposalLineItemService will now return ProposalLineItems that were created from Packages. There's also improved support for workflow rules with WorkflowValidationErrors.

Finally, Type fields have been removed from all entities. Please update your code to use xsi:type, class names, or instance of.

A detailed list of these and other changes can be found on our release notes page.

Using the new ForecastService

The ForecastService can now run Delivery forecasts for multiple line items. These forecasts report the number of units that will be delivered to each line item given the goals and contentions from other line items in the request. Pass prospective line items or line item IDs to getDeliveryForecast or getDeliveryForecastByIds as outlined in this Java example:

    DeliveryForecast existingLineItemForecast =
       forecastService.runDeliveryForecastByIds(new long[] {123L, 456L});

    ProspectiveLineItem prospectiveLineItem1 = new ProspectiveLineItem();
    prospectiveLineItem.setLineItem(myFirstLineItem);

    ProspectiveLineItem prospectiveLineItem2 = new ProspectiveLineItem();
    prospectiveLineItem.setLineItem(mySecondLineItem);

    DeliveryForecast prospectiveLineItemForecast = 
        forecastforecastService.runDeliveryForecast(new ProspectiveLineItem[] {
        prospectiveLineItem1, prospectiveLineItem2});

The existing getForecast and getForecastById methods have been replaced by getAvailabilityForecast and getAvailabilityForecastById, respectively. You must now include AvalilabilityTargetingOptions to specify whether you want to include contending line items or the new TargetingBreakdown.

    ProspectiveLineItem prospectiveLineItem = new ProspectiveLineItem();
    prospectiveLineItem.setLineItem(myLineItem);
    AvailabilityForecastOptions options = new AvailabilityForecastOptions();
    options.setIncludeContendingLineItems(true);
    options.setIncludeTargetingCriteriaBreakdown(true);
   
    AvailabilityForecast forecast = 
        forecastService.getAvailabilityForecast(prospectiveLineItem, options);

Handling Sales Manager Workflows with the API

Updating a Proposal with workflow rules may cause a WorkflowValidationError. The WorkflowValidationError will include a message defined by the network's administrator. For more information about detecting and handling specific error types, refer to this blog post.

As always, if you have any questions or feedback, reach out to us on our API forums.

 - Chris Seeley, DFP API Team

In the coming weeks, we will be deprecating all ACTIVE_VIEW_NOT* report columns in v201405, v201403, v201311 and v201306 of the DFP API. These columns are no longer supported in the DFP query tool, and the DFP API is following suit. The following columns will be affected:

Column.TOTAL_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.TOTAL_ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Column.AD_SERVER_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.AD_SERVER_ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Column.ADSENSE_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.ADSENSE_ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Column.AD_EXCHANGE_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.AD_EXCHANGE_ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Column.ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS
Column.ACTIVE_VIEW_NOT_MEASURABLE_IMPRESSIONS

Migration
Normally all features are supported until the API version is sunset. This deprecation is a rare case where these report metrics are being disabled for existing versions due to product changes related to viewability. If you are using v201408 or later, you will not be affected by this deprecation. If you are currently using these columns in v201405 or earlier, you can replace them with their logical opposites. Alternatively, to retain the same metrics, you can calculate them from the logical opposite and the rate. For example, Column.TOTAL_ACTIVE_VIEW_NOT_VIEWABLE_IMPRESSIONS is equivalent to

Deprecation errors
If you do not migrate, your reports will return the following error:

ReportError.COLUMNS_NOT_SUPPORTED_FOR_REQUESTED_DIMENSIONS

If you have any questions or migration troubles, please reach out to us on our developer forum.

 - Chris Seeley, DFP API Team

A lot of our DFP API developers have been asking recently about how to filter report data by custom targeting key ID. Currently the DFP API allows you to filter report data by custom targeting value ID only. Until we have official support for filtering by custom targeting key ID in reports, you can use the CustomTargetingService and the ReportService together to achieve this goal.

Step 1: Use CustomTargetingService to get your keys and values

You will first need to use getCustomTargetingValuesByStatement and filter by the custom targeting keys you’re interested in to obtain all the corresponding values. For example:

    WHERE customTargetingKeyId IN (17, 18, 19)

If you have a lot of keys and values in your network, a better approach is to store these in a local database and do nightly syncs. Use getCustomTargetingKeysByStatement to obtain all the keys in your network, and then iterate through them, calling getCustomTargetingValuesByStatement for each key to obtain their values. Our client libraries all have examples of this. For instance, the Java example can be found in our ads Java client library GitHub repository. This way, you can look up the values associated with a custom targeting key more quickly and not do an additional API call.

Step 2: Use the values in a report query

Once you have the values for the custom targeting key you’re interested in, you can then use the ReportQuery.statement with the PQL IN clause to filter on the CUSTOM_TARGETING_VALUE_ID dimension. For example, say you were interested in filtering on custom targeting key ID of 7777. You look up the values of 7777 in Step 1, which gives you three value IDs: 3211, 88990, 123456. You can then use the IDs to effectively filter your report data by custom targeting key ID 7777.

    WHERE CUSTOM_TARGETING_VALUE_ID IN (3211, 88990, 123456)

However, please be aware that if you have a lot of custom targeting value IDs to filter on, you should batch them by querying for no more than 500 IDs at a time in the PQL IN clause. For example, you will run your report filtering on the first 500 IDs you’ve collected and save that report. Then you will run the same report on the next page of 500 IDs you’ve collected and so on until you have no more IDs. You can then combine the reports locally so that you have all the data for those custom targeting IDs.

If you have any questions about this, feel free to drop us a line on the DFP API forums or Ads Developer Google+ page.

 - Vincent Tsao, DFP API Team

Today we are releasing v201411 of the DFP API. This release supports creating and updating VideoRedirectCreatives, enhances cross-sell via the new SharedAdUnitService, and adds an experimental Targeting field to the Line_Item PQL table. There are also new Sales Manager enhancements, including derived custom criteria on proposal line items and PQL filtering for Product.lastModifiedDateTime. A detailed list of these and other changes can be found on our release notes page.

Creating VideoRedirectCreatives

You can now use the DFP API to create and update externally hosted and YouTube hosted VideoRedirectCreatives. Simply set the VideoRedirectAsset.redirectUrl to the YouTube or third party URL hosting your ad:

    videoRedirectAsset.setRedirectUrl("http://0.thirdpartyadserver.com/ad.mp4")

You will also need to set the VideoMetadata information for both externally hosted and YouTube hosted ads. For streaming videos, set the minimumBitRate and maximumBitRate; for progressive videos, use the static bitRate.

Custom targeting filter changes

In DFP API v201411 CustomTargetingService.getCustomTargetingKeysByStatement and CustomTargetingService.getCustomTargetingValuesByStatement will return INACTIVE keys and INACTIVE values, respectively. You can filter them by supplying a where clause in a PQL statement:

    WHERE status = 'ACTIVE'

LineItem status changes

To better match the UI, ComputedStatus.NEEDS_CREATIVES has been renamed to ComputedStatus.INACTIVE. Use LineItem.isMissingCreatives to determine if the line item needs creatives.

Cross selling features

If your network is connected to a cross selling host, you can manage your shared ad units with the SharedAdUnitService. To determine if an AdUnit is shared, use the new isSharedByDistributor and crossSellingDistributor fields. We've also added a skipCrossSellingRuleWarningChecks field to the LineItem object so you can override any cross selling warnings.

Experimental targeting PQL column

We've heard your feedback and are adding an experimental PQL column for line item targeting. Fair warning: experimental means we may make breaking changes as we get your feedback and make improvements. The targeting column will be returned with a Value.Type of "TargetingValue", and the value itself containing a Targeting object:

    <Value.Type>TargetingValue</Value.Type>
    <value>
        <inventoryTargeting>
            <targetedAdUnits>
                 <adUnitId>33985943</adUnitId>
                 <includeDescendants>true</includeDescendants>
            </targetedAdUnits>
        </inventoryTargeting>
    </value>

If you've been waiting for a faster way to retrieve line item targeting, try it out and let us know what you think. Head over to the API forum and tell us what works for you, and how we can improve.

 - Chris Seeley, DFP API Team

Are you using the Google Ads API Java Client Library and Java 5 (1.5)? If so, we have important news: starting April 2015, all releases of the Google Ads API Java Client Library will only be compatible with Java 1.6 and higher.

Why this change is happening
The primary reasons for this change are:

• Starting with version 18.0, Guava will no longer release 1.5 backports. The Google Ads API Java Client Library uses Guava's precondition checks, I/O helpers, and other utilities extensively.
• Java 5 is a bit outdated -- it was first introduced in May 2004, and Oracle's support for Java 5 is approaching some key end dates.
• Usage of Java 5 among Google Ads API Java Client Library developers is rapidly declining.

Next steps
If you are using Java 6 or higher, then you're all set -- all releases of the client library on github already support your runtime.

If you are still using Java 5 and need to migrate to Java 6 or higher, check out the following adoption guides from Oracle:

• Java 5 to 6
• Java 6 to 7

Still have questions? Feel free to file an issue on the library's issues page or contact us via our Google+ page.

- Josh Radcliff, AdWords API Team