Tag Archives: dfp_api

Saying Goodbye to v201411

On Monday, February 29th, 2016 (to make your lives easier, we slipped an extra day into February this year so you get a bonus day) we will be sunsetting v201411 of the DFP API in accordance with our deprecation schedule. At that time, any requests made against v201411 will begin returning errors. If you’re still actively using v201411, make a New Year’s resolution to switch over to our newest version to get the latest and greatest features available (like enhanced forecasting methods). To do so:

  1. Take a peek at our release notes and look for any breaking changes.
  2. Download the newest version of the client library for your platform.
  3. Start making requests with your updated application!

Some major changes in the newest version are:

This is not an exhaustive list, so feel free to reach out to us with any questions.

 - , DFP API Team

Register now for the March 2016 Display Ads API Workshops

We're pleased to announce that we’ll be holding a series of Display Ads API Workshops in March 2016. These workshops are a half-day of tech talks, group discussions, and office hours geared toward developers who use the DoubleClick for Publishers API, Interactive Media Ads SDK, or Mobile Ads SDKs.

These API workshops are a great way for you to meet with the display ads API team and ask questions in person. The workshops are also a great opportunity for members of the community to bring their feedback directly to us, and exchange ideas and best practices with fellow developers.

The workshops will be held in the following cities:

For more information on the workshops’ agenda and a preview of our talks, please see our workshop page.

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

 - , DFP API Team

Adjusting the DFP sunset schedule

It's been two years since we moved to a regular deprecation schedule. And thanks to developers like you, we've been able to regularly release new versions and features while maintaining code health.

To continue this trend, we'll be simplifying the sunset schedule by tightening our belts a little. Starting with v201511, versions will be sunset one year after release. This will help us reduce the number of out-of-band deprecations. A shorter lifecycle means dated features can ride off into the sunset as intended. Plus, it's easy to remember when the version you're using is about to bite the dust, even if you're not signed up for deprecation announcements or don't obsessively check our deprecation schedule.

We strive to make upgrades easy. If you think they're not, please tell us why on our developer forum so we can make it better.

 - , DFP API Team

Announcing v201511 of the DFP API

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.

 - , DFP API Team

Sunset of the v201408 DFP API

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:

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.

 - , DFP API Team

Creating native creatives with the DFP API

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.

 - , DFP API Team

Announcing v201508 of the DFP API

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.

 - , DFP API Team

Integrating with DFP as a third party

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.  - , DFP API Team

Sunset of the v201405 DFP API

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:

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

 - , DFP API Team

Changes to DFP Reporting, now with more deprecation!

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:

Columns without equivalent replacements:

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!

 - , DFP API Team