Say hello to your new one-stop shop for ads developer news

When we originally launched this blog in 2010, we sought to provide you with the most up-to-date information on the DoubleClick for Advertisers API, as well as useful resources to help with API development. Recently, we've realized that the content we produce can be shared between multiple Ads API developer communities and for this reason we have decided to create one central blog. With this in mind, we'll now be posting on the new Google Ads Developer blog. There, you'll also find information on our AdWords API, AdSense API, DoubleClick for Publishers API, and Google AdMob SDK products.

If you're a subscriber of this blog, your feed will automatically be redirected, so you won't have to do a thing to keep getting the latest news. If you decide you'd like to subscribe to a particular label on the new blog (for example, only receive those posts labeled as "dfa_api"), you can choose to do that as well. Also, the old content of this blog is not going anywhere and will continue to be available, even after we switch to the new blog.

The Ads Developer blog will continue to be run by the same team, bringing you all the information you need as an ads developer. We look forward to seeing you over at http://googleadsdeveloper.blogspot.com/.

Posted by the DFA API Team

Automatic Detection of Flash Asset Properties through the API

We had previously explored manually managing the clickTags of your Flash creatives through the DFA API. When you need to update a creative’s exits to point to new locations, this information can be very useful, but there is another useful option when you’re first creating a creative that uses Flash. DFA automatically detects several properties in Flash creative assets including clickTags, which you can use to avoid having to manually enter these values into a Flash creative.

The Flash asset’s detected properties are returned in the CreativeAssetSaveResult object obtained when saving the asset. These values will not be automatically pulled into any creatives later made using this asset; they must still be explicitly set when making a creative object. Fortunately the properties are returned as the same object types that can be put directly into a creative. Using these automatically detected values is as easy as copying them over from the result object. You can see how these values can be used in the following code snippet:

// Create the Flash creative asset and save it.
CreativeAsset flashAsset = new CreativeAsset();
flashAsset.setForHTMLCreatives(true);
flashAsset.setAdvertiserId(advertiserId);
flashAsset.setContent(getAssetDataFromFile(pathToFile));
flashAsset.setName(assetName);
CreativeAssetSaveResult flashAssetSaveResult = 
    service.saveCreativeAsset(flashAsset);

// Create a Flash in-page creative using data returned from saving the
// asset.
FlashInpageCreative flashCreative = new FlashInpageCreative();
flashCreative.setClickTags(
    flashAssetSaveResult.getClickTags());

HTMLCreativeFlashAsset parentFlashAsset = new HTMLCreativeFlashAsset();
parentFlashAsset.setAssetFilename(flashAssetSaveResult.getSavedFilename());
parentFlashAsset.setFrameSize(flashAssetSaveResult.getFrameSize());
parentFlashAsset.setFlashVersion(
    flashAssetSaveResult.getFlashVersion());
flashCreative.setParentFlashAsset(parentFlashAsset);

// Set the rest of the properties on the FlashInpageCreative and 
// save it.

You can receive detected values again by grabbing the asset from our server and saving it unchanged. This will return another CreativeAssetSaveResult object without creating a duplicate creative asset. Having to request and then retransmit the entire Flash file can be a slow, heavyweight interaction, so you should avoid doing this when possible. If you’re using the same Flash asset to back multiple creatives, it is to your benefit to make all of your creatives while your asset’s save result object is still in scope rather than saving the same asset once per creative.

Questions about automatic detection of Flash properties or any DFA API topic are always welcome on our forum. Hope to see you there!
– Joseph DiLallo, the DFA API Team

Announcing the Java Client Library and Updated Resources

We've added a third client library for use by DFA developers, this time in Java! The library is an early release that takes advantage of a new framework for client libraries supporting our ads APIs.

Some features of the DFA library and the new framework include:

• Distributed via Maven


• Requests and SOAP messages are logged using the SLF4J logging facade, allowing you to plug in the logging framework of your choice


• Automatic handling of SOAP headers


• Easy management of credentials, authentication, and session information

You can read more about the Java client library and download an example project utilizing it on its Google Code site.

In addition to launching this new client library, we have also updated our existing developer resources. The Python and .NET client libraries now support v1.15. The Ruby and PHP standalone examples have been updated for v1.15 and both now have ten additional examples. The standalone Java examples have been retired in favor of the Java client library and will no longer be updated with each release.

Your concerns and questions are always welcome on our forum. We are especially interested in hearing any feedback you have about the new client library.

– Joseph DiLallo, the DFA API Team

Managing clickTags through the API

The DFA platform supports many different types of creatives including those that utilize Flash. Flash In-Page Creatives have many unique features and settings including the ability to set multiple exit points for your Flash assets, which the platform refers to as “clickTags.”

Through the API, you can set clickTags when you are creating or modifying a FlashInpageCreative object. The aptly-named field “clickTags” contains an array of FlashClickTag objects. Each FlashClickTag object represents one unique exit point from your creative, so if you have multiple exit points, you’ll need multiple objects.

The fields within the FlashClickTag warrant a closer look as to what they represent: the API’s "name" and “value” fields correspond to the website interface's "clickTag name" and "Click-Through URL" fields, respectively. You should place a full string representation of a web address in the value field. The following Java code provides an example of updating a FlashInpageCreative’s clickTags:


FlashInpageCreative flashInpage = (FlashInpageCreative) creativeService.getCreative(creativeId);

FlashClickTag exitOne = new FlashClickTag();
exitOne.setName("clickTag");
exitOne.setValue("http://www.example.com/ilikeone.html");
FlashClickTag exitTwo = new FlashClickTag();
exitTwo.setName("clickTag1");
exitTwo.setValue("http://www.example.com/iliketwo.html");

flashInpage.setClickTags(new FlashClickTag[] {exitOne, exitTwo});
CreativeSaveResult saveResult = creativeService.saveCreative(flashInpage, campaignId);


If you do not have clickTags set for your creative, even if the underlying Flash asset utilizes multiple exit points, then ads that display this creative will redirect clicks to the click-through URL set in the CreativeAssignment associating the creative with the ad. Flash creatives which do have clickTags set cannot be overridden at the ad level. If the ability to override creative exits at the ad level is appealing to you, consider investigating Rich Media creatives which support this feature. You can find some additional information in this help center article, which explains the priorities given to clickTags and click-through URLs set at the creative and ad levels.

If anything about this process is still unclear, please bring your questions to our forum.

– Joseph DiLallo, the DFA API Team

Introducing DFA API v1.15

A new version of the DoubleClick for Advertisers (DFA) API has arrived: v1.15. This release focuses on fixing some bugs that were present in the API. Some of the fixes included in v1.15 are:

• Placement End Date Validation - As previously mentioned on our forum, both campaign and placement end dates always use midnight in the Eastern Time Zone as their ending time. When saving a placement, the placement’s end date was checked against its campaign’s end date before the time of day was converted. This resulted in the API erroneously informing users in certain time zones that their placement end dates were past the end dates of their campaign. Placement end dates will now be converted before they are validated.


• “getAssignedCreativeGroupsToCreative” operation - This operation, located in the creative service, was never returning results. It will now do so.


• Clearing Remarketing Lists - Users were able to set and modify Remarketing lists targeting via the userListExpression field of a targetable ad through the API, but it was not possible to clear them once one had been set. You may now clear these lists.

Deprecation of v1.13

The version from two releases ago, v1.13, is now considered to be deprecated. As previously announced, v1.13 will be removed from service on October 1st, 2011. Be sure to migrate any applications currently using v1.13 by this time. Consider it an opportunity to move to v1.15!

Sunset of v1.14 in Early January

With this release we are announcing the planned end of v1.14 far in advance of its early January sunset date. Please use this time window to make arrangements for migrating any v1.14 implementations before it is retired.

We have updated our release notes page to reflect the addition of v1.15. Please bring any feedback or questions you may have to our forum.

– Joseph DiLallo, the DFA API Team

Requesting Feedback From DFA Developers

Have you found using the DFA API to be a good experience? Is there anything you’d like to see added in future releases? We’d like to know!

Starting today, we’ve placed a survey online where you can share your thoughts with us. We’d like to try to incorporate the opinions of the developer community into our future plans for the technology. You can find our survey here. We’ve also added a link to the survey on the navigation bar of our Google code site.

As always, you can reach us on our forum if you have any questions or comments about the survey.

- Joseph DiLallo, the DFA API Team

DFA Developer Resources Updated for v1.14

Whether you are an existing DFA API developer or building your first application, you can now take advantage of updates to our resources. The v1.14 release of our API did not modify any of the objects in our services, so these examples mainly showcase how to migrate applications from one version of the API to another. You can find the new Java, Ruby, and PHP examples on their project site, while the Python client library and .NET client library updates are located on their own pages.

New Reference Sidebar

We realize that our resources are spread out across multiple sites and it may not always be easy to find what you are looking for. While there is a need for our content to be set up this way, we’ve been trying to make it easier to bring all of this content together. Thus was born a new reference sidebar:

This sidebar appears on the service-level pages of the DFA code site and links to content in our examples and client libraries, as well as to related posts on this blog. A special thanks goes out to Eric Koleda, who originally developed this tool for AdWords developers and has now made it possible for DFA developers to benefit from this work as well.

As always, your feedback is important to us. Please bring any questions or comments to our forum.

- Joseph DiLallo, the DFA API Team