DoubleClick For Advertisers API Blog

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

noreply@blogger.com (Anonymous) — Mon, 21 Nov 2011 11:59:00 -0500

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

noreply@blogger.com (Anonymous) — Mon, 14 Nov 2011 10:00:00 -0500

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

noreply@blogger.com (Anonymous) — Mon, 26 Sep 2011 09:23:00 -0400

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

noreply@blogger.com (Anonymous) — Fri, 16 Sep 2011 15:26:00 -0400

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

noreply@blogger.com (Anonymous) — Mon, 12 Sep 2011 14:40:00 -0400

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

noreply@blogger.com (Anonymous) — Thu, 7 Jul 2011 13:47:00 -0400

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

noreply@blogger.com (Anonymous) — Mon, 20 Jun 2011 16:59:00 -0400

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

Introducing DFA API v1.14

noreply@blogger.com (Anonymous) — Mon, 13 Jun 2011 17:26:00 -0400

A new version of the DoubleClick for Advertisers (DFA) API has arrived: v1.14. This release consists entirely of security and performance enhancements. It does not alter the objects exposed by the API.

Deprecation of v1.12

The version from two releases ago, v1.12, is now considered to be deprecated. As previously announced, v1.12 will be removed from service on July 9th, 2011. Be sure to migrate any applications currently using v1.12 by this time. Consider it an opportunity to move to v1.14!

Sunset of v1.13 in Early October

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

With the release of v1.14, we have updated our release notes page. Please bring any feedback or questions you may have to our forum.

- Joseph DiLallo, the DFA API Team

New Resources for PHP and Ruby DFA API Developers

noreply@blogger.com (Anonymous) — Wed, 1 Jun 2011 12:57:00 -0400

We've expanded our DoubleClick for Advertisers (DFA) developer resources once again! You can now find new PHP and Ruby code examples for download on our code examples page.

We have added reporting examples to our selection of PHP examples. These examples show how to request the generation of a new report and how to get the status and download URL for reports. Additionally, we now offer this same set of examples in Ruby. These new Ruby examples will help get you started on any Ruby projects you have that integrate with DFA.

We hope you will find these new resources useful. If there is anything that you’d like to see next or something you think would be especially useful, let us know! Feedback is always welcomed on our forum.

- Joseph DiLallo, the DFA API Team

Sharing Floodlight Settings Across Advertisers

noreply@blogger.com (Anonymous) — Wed, 27 Apr 2011 13:51:00 -0400

The DoubleClick for Advertisers feature known as Floodlight allows you to gather metrics on specific actions taken by users who visit your site after viewing or clicking on one of your ads. The Help Center guide on using Floodlight provides a breakdown on what the features and settings do and how you can use them. The DFA API currently uses the legacy term “Spotlight” when referring to Floodlight settings. We will refer to all objects by their API names.

Setting up Floodlight tracking through the API exposes one notable difference from the UI workflow explored by the Help Center guide: Floodlight settings are tied to a SpotlightConfiguration object, not to an advertiser. These configuration objects can be associated with additional advertisers. A new SpotlightConfiguration is generated every time an advertiser is created, and although they share the same ID number, both objects are distinct from each other.

The first step to sharing settings is to set up the configuration that is going to be used. The choice of which configuration to use is not especially meaningful. You should pick one of the advertisers who is going to be in the group sharing these settings and use its accompanying configuration. This advertiser will not have a special status in the group using the same settings; all of the advertisers use the settings in the same way. Once you've picked your configuration, set up all the SpotlightActivities and SpotlightActivityGroups that you will need.

Sharing through the API is simple: Advertisers have a field named spotId which takes in the SpotlightConfiguration's ID number. You have to fetch your advertisers from the server, change this field to the shared configuration ID number, and then save the advertisers. In code, doing this would be as simple as:
// The ID of your set-up configuration here. long sharedConfigId = 12345; // The IDs of your advertisers who will share here. long[] idsOfAdvertisersSharing = {23456, 34567, 45678}; // Fetch the advertisers who need to receive settings. AdvertiserSearchCriteria advSearchCriteria = new AdvertiserSearchCriteria(); advSearchCriteria.setIds(idsOfAdvertisersSharing); AdvertiserRecordSet recordSet = advertiserService.getAdvertisers(advSearchCriteria); // Update your advertisers. for (Advertiser advertiser: recordSet.getRecords()) { advertiser.setSpotId(sharedConfigId); advertiserService.saveAdvertiser(advertiser); }

Once you’ve got this set up, you can easily share with more advertisers by grabbing any advertiser currently using your configuration and inspecting its spotId field to get your configuration’s ID number.

As a final pointer, if you’re looking for the base configuration settings, you’ll want to modify your SpotlightConfiguration object. Though the UI displays these settings as part of the advertiser, they reside in the SpotlightConfiguration through the API.

If you have any additional questions about setting up Floodlight through the API, you’re always welcome to voice them at our forum.

- Joseph DiLallo, the DFA API Team

Announcing the DFA Python Client Library

noreply@blogger.com (Anonymous) — Fri, 8 Apr 2011 16:35:00 -0400

Python aficionados rejoice: It’s your time in the client library spotlight. Access to the DoubleClick for Advertisers (DFA) API is now easier than ever with the release of our second open source client library. This library aims to assist you in writing Python DFA clients, and lists among its features:

The ability to hide the SOAP layer from end users.
On demand logging of all SOAP messages.
Support for API calls against the production and test environments.
Automatic data type conversion for all API call parameters.

Additional information can be found at the DFA API code site’s client libraries page. Bugs and feature requests can be filed at the Ads APIs Python Client Libraries' issues page.

As always, please bring your questions or feedback to our forum.

- Joseph DiLallo, the DFA API Team

Reminder: Sunset of v1.11 on April 16th, 2011

noreply@blogger.com (Anonymous) — Wed, 6 Apr 2011 11:50:00 -0400

As previously mentioned in our v1.13 announcement post and once before that, we will be sunsetting v1.11 of the DFA API on Saturday, April 16th 2011. Please make sure to migrate all applications to one of the two supported versions.

Any questions about updating your applications or our deprecation policy are welcome on our forum.

- Joseph DiLallo, the DFA API Team

New and Updated Resources for DFA Developers

noreply@blogger.com (Anonymous) — Wed, 30 Mar 2011 09:16:00 -0400

Continuing our efforts to aid developers using the DoubleClick for Advertisers (DFA) API, we have updated our Java examples and the .NET client library with support for v1.13. These updates include coverage for the new report web service complete with examples. In addition, there are now PHP examples located on our examples site.

RCReport Translated to the Web Services

Many of you have been taking advantage of command line tools known as RCRunner to download reports from Report Central. One of the new examples of the report web service is a fully functional migration of RCRunner’s RCReport program from the Java DART API to the DFA API. It is currently available in Java and C#. Mimicking the functionality of the RCQueryRunner program is not possible with the web services.

We hope you will find these new resources useful. We are currently planning to create a Java client library next, though it will not be ready for release for some time to come. If there is anything that you’d like to see next or something you think would be especially useful, let us know! Feedback is always welcome on our forum.

- Joseph DiLallo, the DFA API Team

Introducing v1.13 and the Report Service

noreply@blogger.com (Anonymous) — Tue, 15 Mar 2011 09:27:00 -0400

Today we’re announcing the next version of the DoubleClick for Advertisers (DFA) API, v1.13. The main highlight of this release is the new report service, which allows you to to generate and retrieve reports.

Reporting Comes to the Web Services

The report service brings the ability to generate reports from predefined queries, check on them periodically to see when they have finished being compiled, and retrieve a URL where you can download the completed report. You can’t create a query through the DFA API, instead you must use the website interface or the Java DART API. A query only has to be created and saved through these tools once, and then you can generate reports from your query via the DFA API for as long as it remains useful. Please see the updated DFA API vs Java DART API page for direction on how to migrate to the new service.

Reminder About Sunset of v1.11

As previously announced, v1.11 will be removed from service on April 16th, 2011. Be sure to migrate any applications currently using v1.11 to one of the two supported versions by this time.

Sunset of v1.12 in Early July

With this release we are announcing the planned end of v1.12 far in advance of its early July sunset date. Please use this time window to make arrangements for migrating any v1.12 implementations before it is retired. Support for v1.12 will continue for the standard length of time; we are merely announcing the end earlier to give you more time to prepare.

Complete Release Notes

With the release of v1.13, we have updated our release notes page to give you a more in-depth breakdown of what has changed since the previous version. Please refer to this page when upgrading your applications.

Adding reporting functionality to the web services has been a highly anticipated feature. Please bring any feedback or questions you may have about both the report service and the release to our forum.

– Joseph DiLallo, the DFA API Team

Setting Up the Rotation of RotationGroups

noreply@blogger.com (Anonymous) — Thu, 10 Mar 2011 10:29:00 -0500

Standard ads have many settings you can use to fine tune how your creatives are served and to whom they are delivered. Among the important decisions to be made for each ad is which of the 5 types of rotations should be used to determine which creative to serve. Putting these ads together through the API, where they are known not as standard ads but as RotationGroups, requires the use of certain fields for some types of rotations and not others. It is important to know which fields you are expected to use and when.

The RotationGroup Fields

The RotationGroup object has two fields you need to use, rotationType and creativeOptimizationEnabled. The rotationType field represents which of the 5 rotation types to use, but there are actually only four unique values. The optimized rotation type is a type of weighted rotation, and as such shares the same rotationType value as the weighted rotation. The creativeOptimizationEnabled field is used only to distinguish between a weighted rotation, where it is false, and an optimized rotation, where it is set to true. All other rotations leave this value as false.

The CreativeAssignment Fields

The CreativeAssignment object that represents each creative in a rotation has two fields that help set up a rotation, sequence and weight. The sequence field is required only for the sequential rotation type, and values should not be set for the others. The weight field is required for both the weighted and the optimized rotations. Weighted rotations use this value directly to determine the serve percentage of each ad, but optimized rotations will modify the values. An initial value is required for optimized rotations. For the best performance of the optimization process, the weight value for optimized rotations should be set to the minimum creative weight set at the Campaign level in the CreativeOptimizationConfiguration object.

Which Fields Are Required For Each Rotation Type

	rotationType	creativeOptimizationEnabled	sequence	weight
Random	Yes (1)	No	No	No
Sequential	Yes (2)	No	Yes	No
Weighted	Yes (3)	No	No	Yes
Best Performing	Yes (4)	No	No	No
Optimized	Yes (3)	Yes	No	Yes*

* The best practice recommendation for setting up optimized rotations is to always set the initial weight for each creative added to the rotation to the minimum optimized serve percent value set at the campaign level.

Using the handy table above as a reference, you should be able to take advantage of the rotation types DoubleClick for Advertisers has to offer. If you have any questions about how to set these rotations up or other questions about managing your ads through the API in general, please bring them to our forum.

– Joseph DiLallo, the DFA API Team

Creating Simple Scripts With the API

noreply@blogger.com (Anonymous) — Tue, 15 Feb 2011 12:19:00 -0500

The DoubleClick for Advertisers (DFA) API provides a comprehensive set of services that can be used to create applications that mediate all of your interactions with your DoubleClick account. But the API doesn’t have to be used solely for making enterprise-level software solutions. Everyone, even DoubleClick clients who use the website interface for the majority of their trafficking needs, can create small scripts or programs to automate repetitive or laborious tasks. However, users of the website interface should first determine if exporting and importing Traffic Sheets could fulfil their needs. In either case, small API routines may be able to provide some value.

An example in code: Cleaning up inactive ads

One case where the API can really shine is cleaning up a campaign. If you’ve got particularly long-running campaigns, or if you frequently change the ads shown in your placements based on dates, you can clean up all of the ads that have stopped running by archiving them and unassigning them from their placements. Ads will be automatically set to inactive for various reasons, the most important being if they have passed a hard cut-off date or if they have reached their delivery goals.

Looking at a snippet of the code from a program that would accomplish this demonstrates the two important parts - generating a record set and looping through all the pages in a paged record set, making changes as necessary:
// Create Ad Search Criteria AdSearchCriteria adCriteria = new AdSearchCriteria(); adCriteria.setPageSize(10); adCriteria.setCampaignId(campaignId); // Get ads. AdRecordSet results = adService.getAds(adCriteria); if (results.getRecords() == null || results.getRecords().length == 0) { System.out.println("Found no ads associated with the given campaign."); } else { System.out.println( "Found " + results.getTotalNumberOfRecords() + " ads associated with " + "this campaign."); // Loop through all pages. for (int i = 0; i <= results.getTotalNumberOfPages(); i++) { if (i != 0) { adCriteria.setPageNumber(i); results = adService.getAds(adCriteria); } // For each ad, check to see if it should be modified. for (AdBase ad : results.getRecords()) { if (ad.isActive()) { // This ad is still active. It will not be modified. } else { // This ad is inactive. It will be archived and removed from all // placements and archived. ad.setPlacementAssignments(new PlacementAssignment[] {}); ad.setArchived(true); adService.saveAd(ad); } } } }

You can find a complete open source Java class that removes inactive ads from campaigns on our examples site.

Intended use of the API

It is important to realize that the API is not optimized for looping through all of the information in your account. It is possible to grab every advertiser you have, fetch every campaign for each advertiser, then look at each campaign’s ads, each ad’s creatives, etc. This is very slow, creates a lot of unnecessary traffic, and should always be avoided if possible. You should regularly take advantage of the options provided by each type of SearchCriteria object to focus in on the areas you need to see without forcing the API to return tons of extraneous information. The search criteria objects in each service are not identical; some allow you to narrow down your searches based on fields specific to what you are searching for. Understanding and using these extra fields will greatly speed up any applications you write that pull down a lot of data.

Going further

The basic pattern here is simple: generate the tightest record set as possible, page through the record set, check to see if each object is one you want to modify, and if so make the changes you want. You can create tools following the same pattern to do all sorts of repetitive tasks, such as mass renaming or replacing a placement assignment with another within all ads associated with the retired placement. If you frequently encounter situations where everything that matches some criteria needs to be altered, having a program or script like this on hand can save you a lot of time. Do note that the API already has operations for copying creatives, campaigns, and ads, so you do not need to create tools to make duplicates. These functions are provided and fast.

If you have any questions about tools like this, or if you can think of a task that is so common it should be part of the API, please bring your questions or ideas to the API forum.

- Joseph DiLallo, the DFA API Team

Sunset of v1.11 on April 16th, 2011

noreply@blogger.com (Anonymous) — Mon, 7 Feb 2011 15:27:00 -0500

Please be aware that we will be sunsetting v1.11 of the DFA API on Saturday, April 16th, 2011. In accordance with our release schedule, we will continue to support v1.12 and the upcoming v1.13 release beyond this date. All applications must be migrated to one of the newer versions before this time.

This announcement is earlier than usual in an effort to give you more time to prepare. We will be supporting v1.11 for approximately one month past the release of the newest version, which is the standard length of time.

Any questions about migrating your applications can be brought to our forum.

-- Joseph DiLallo, the DFA API Team

New DFA .NET Client Library

noreply@blogger.com (Anonymous) — Tue, 1 Feb 2011 13:33:00 -0500

We are happy to announce the release of our new DoubleClick for Advertisers .NET client library.

The DoubleClick for Advertisers API .NET Client Library makes it easier to write .NET clients which access the DFA 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 test, beta or 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 DFA exceptions instead of generic SoapExceptions.

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

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

Questions or feedback are always welcome at the DFA API Forum.

– Joseph DiLallo, The DFA API Team

Billing Invoice Notation Available For Use

noreply@blogger.com (Anonymous) — Mon, 10 Jan 2011 14:57:00 -0500

We first mentioned the addition of the Billing Invoice Notation field in our full v1.12 Release Notes. At the time of the release, this field was not yet fully supported and was available only for testing purposes. As of this week, you may start taking full advantage of this optional feature. The Billing Invoice Notation field allows you to streamline your billing process by associating each campaign with a code from your billing system or other internal systems. This code will appear on future DFA billing invoices.

Your questions, about this feature or otherwise, are always welcome on the forum.

-- Joseph DiLallo, the DFA API Team

Getting Help With the DFA API

noreply@blogger.com (Anonymous) — Fri, 7 Jan 2011 14:03:00 -0500

There are multiple routes to get in touch with DoubleClick support that each specialize in different areas. Our API users have a channel dedicated to sharing their questions and concerns about the web services: the DFA API forum. It is here that you can ask questions and look through those previously asked by other users. Everyone is welcome to gain knowledge from their fellow developers and Google employees who specialize in the API. Please remember that the forum is targeted towards the DFA API and not the Java DART API. This handy chart highlights the differences between the two.

We look forward to seeing you on the forum.

-- Joseph DiLallo, the DFA API Team

Reminder: Sunset of v1.10 on January 8th, 2011

noreply@blogger.com (Anonymous) — Wed, 5 Jan 2011 16:28:00 -0500

As previously mentioned in our v1.12 announcement post, we will be sunsetting v1.10 of the DFA API on Saturday, January 8th 2011. Please make sure to migrate all applications to one of the two supported versions.

Any questions about updating your applications or our deprecation policy are welcome on our forum.

-- Joseph DiLallo, the DFA API Team

Understanding Pricing of Placements and Placement Groups

noreply@blogger.com (Anonymous) — Mon, 20 Dec 2010 14:44:00 -0500

The humble placement is the workhorse of DoubleClick for Advertisers ad slotting, each representing a single space on a publisher’s website. However, certain types of media buys, such as homepage take-overs in which every slot on a single page is purchased, warrant the use of an additional structure - the placement group - combining multiple placements together.

For those of you performing these types of media buys, pricing is set for placements using a hierarchy. While placements are each set with their own pricing information, they can later be grouped together into placement groups, each of which has its own pricing information. Whether you're dealing with a package or a roadblock group type, placements always inherit the pricing data set for their placement group. Through the API it is still possible to request information for individual placements after they have been placed into a group and what is shown may not be what you’d expected. The following snippet of code will print out some information about a placement, demonstrating what happens to a placement’s pricing schedule when it becomes part of a placement group:


// Get placement.
Placement placement = placementService.getPlacement(placementId);
// Set up date formatter to make dates human-readable.
SimpleDateFormat sdf = new SimpleDateFormat("d MMM yyyy");
// Display placement name, placement group, and pricing info.
System.out.println("Placement with name \"" + placement.getName()
   + "\", part of placement group \"" + placement.getPlacementGroupId()
   + "\", was found.");
PricingSchedule pricingSchedule = placement.getPricingSchedule();
System.out.println("The pricing schedule runs from "
   + sdf.format(pricingSchedule.getStartDate().getTime()) + " to "
   + sdf.format(pricingSchedule.getEndDate().getTime()) + ".");
PricingPeriod[] pricingPeriods = pricingSchedule.getPricingPeriods();
for (PricingPeriod result : pricingPeriods) {
  System.out.println("This pricing period runs from "
      + sdf.format(result.getStartDate().getTime())
      + " to " + sdf.format(result.getEndDate().getTime()) 
      + " with the rate of " + result.getRateOrCost() 
      + " for " + result.getUnits() + " units.");
}

For my example placement, this block of code outputs the following:

Placement with name "Bob's Website's 400x600", part of placement group "0", was found.
The pricing schedule runs from 1 Dec 2010 to 24 Dec 2010.
This pricing period runs from 1 Dec 2010 to 24 Dec 2010 with the rate of 1.5 for 10000 units.

This is a straightforward placement with a simple pricing schedule. With a placement group Id number of 0, it isn’t part of a group and is currently using the pricing data displayed above. Now, what will happen if this placement is added to a placement group with different pricing information, including changes in start date, end date, units, and rate of cost? Only one thing changes:

Placement with name "Bob's Website's 400x600", part of placement group "123456", was found.
The pricing schedule runs from 1 Dec 2010 to 24 Dec 2010.
This pricing period runs from 1 Dec 2010 to 24 Dec 2010 with the rate of 1.5 for 10000 units.

The original pricing schedule and pricing period are still returned - they aren’t changed to match the placement group’s. Instead, the placement's own data is merely superseded for as long as it remains part of the placement group. The rule of thumb is simple: if a placement comes back with a placement group Id number other than “0”, the pricing information attached to it isn’t guaranteed to be in use. To view the actual pricing information being used for that placement, request the data associated with the placement group.

While you have to watch out for this one potential road bump, you can leverage the fact that you can remove a placement from its group and automatically reuse any preexisting pricing data. You can always view and modify the pricing information that will be used in this event by examining the individual placement.

Pricing is a very important element of trafficking settings, wouldn’t you say? We’re always available on the forum to answer any questions you may have.

- Joseph DiLallo, the DFA API Team

WebServices API v1.12

noreply@blogger.com (Anonymous) — Tue, 7 Dec 2010 09:09:00 -0500

We are pleased to announce the release of the DoubleClick for Advertisers API Version 1.12.

v1.12 introduces a few additions to the DoubleClick for Advertisers API. This announcement highlights only a portion of the changes in this release. For complete details on all v1.12 changes, please see our Release Notes.

V1.12 HIGHLIGHTS

Override Rich Media exit links: You can now override the exit URLs of a rich media creative in any ad associated with that creative. Previously, the API could only accomplish this for non-rich media creatives.

V1.10 SUNSET IN JANUARY 2011

In accordance with our versioning policy, v1.10 will soon be retired. Therefore, please make sure that you upgrade any v1.10 applications before January 8th, 2011.

As with every new version, we strongly urge you to review the Release Notes section of the DFA API site. Please feel free to share any questions or feedback on our forum.

-- Joseph DiLallo, The DFA API Team

Introducing the new DFA API code site

noreply@blogger.com (Ruben, The DoubleClick for Advertisers API Team) — Thu, 4 Nov 2010 13:07:00 -0400

Want to build applications that talk to DoubleClick for Advertisers but not sure where to start? With the release of the new Google Code site for DFA, developers now have a comprehensive set of guidelines for using DFA’s web services API.

The new site will be your one-stop shop for everything you need to know about the DFA API, from documentation, to code examples and how-to’s, to announcements and product updates. There’s also a forum where users can discuss the API and provide feedback.

The DFA API lets you build applications that talk directly with our ad trafficking system. It’s especially useful for automating routine, as well as integrating DFA with third-party systems. Most popular programming languages are supported, including Java, PHP, Python, .NET, Perl, and Ruby.

-- Ruben Perez, The DoubleClick for Advertisers API Team

WebServices API v1.11 September 11, 2010 Release

noreply@blogger.com (Ruben, The DoubleClick for Advertisers API Team) — Mon, 13 Sep 2010 04:18:00 -0400

DoubleClick is pleased to announce the latest production release of DFA6 WebServices API version 1.11 on September 11,2010.

Read the release notes (DFA sign-in required) for the September WebServices API version 1.11 release to see details of the new features and enhancements available to you.

-- Ruben Perez, The DoubleClick for Advertisers API Team