[go: up one dir, main page]

Is your AdWords API client application still using ClientLogin? If so, you should start your migration from ClientLogin to OAuth 2.0 as soon as possible.

Your AdWords API client applications must be fully migrated to OAuth 2.0 before ClientLogin is sunset in June 2014, as previously announced. If you don't migrate by then, your client applications will fail -- they won't be able to access your MCC account or any AdWords account via the API.

How do I get started?

We have prepared a ClientLogin to OAuth 2.0 migration guide which includes:

  • Detailed migration strategies based on use cases
  • Code samples to automate parts of the migration
  • Client library-specific migration videos, code, and pertinent OAuth 2.0 documentation

You don't want to worry about your applications failing, so get started now. For most developers with a single top level MCC, this migration will involve only a few configuration and code changes. But if you run into any issues with your particular application or AdWords accounts, you'll be glad you left plenty of time before the sunset to work things out.

We are here to help

If you run into any issues, or if you have any questions, please reach out to us on the AdWords API Forum.

- Ray Tsang, AdWords API Team

Labels: , ,

In v201311 we changed how the API returns locations to:
  • More granularity in targeting 
  • Streamlined code paths 
  • Increased flexibility for handling location objects
Along with the update to location objects, we've also expanded the list of targetable locations far beyond what was previously available. If you look at new Geo_Target table - which replaces the individual City, Country, Metro, Postal Code, and Region tables - you’ll find that you now have far more control over where your ads will serve. In the past, the smallest location you could target was a city; now, you can target something as specific as an Airport.

Many of you have asked how to migrate from the deprecated PQL tables to the new Geo_Target table.

Instead of having a table for each geo locations type, we combine everything into a single table with the type defined as a new column. This not only makes things easier for you, it also allows us to add even more types of locations to target in the future without having to make new tables.

As far as how the old tables relate to the new Geo_Target table, the Country, City, Postal_Code, and Region tables will map to their respective namesake columns, with only the Metro table being different, now mapping to the more canonical DMA_Region. To see how simple it is to replicate the old behavior, look at this Python example that pulls down the targetable City locations.

If you’re not entirely sure how to break out your targeting into smaller geo locations, we’ve got you covered there too - instead of trying to make your own relational mapping between cities, metros, regions, and countries, the new Geo_Target table simplifies the task with the ParentIds field, which yields a list of parent location IDs that encompass a child location.

For the new year, make a resolution to switch over to the new Geo_Target table and reap the benefits thereafter.

 - , DFP API Team
Labels: , , , ,

When we launched the new DFP a couple of years ago, one of the major changes was a new API and accompanying support infrastructure. The DFP API brought many significant enhancements to DFP and is a core component of our overall offering. However, as our publishers and partners went through the upgrade process, they had to rebuild any DART API integrations from scratch. In addition, due to the rapid development cycle of DFP, we were pushing out new versions very quickly.

While the terms of service for our API call for only a 6-month window to support each version, to limit the impact to our developers, we've continued to support every version of the DFP API released to date -- that’s 12 and counting. While we've had a “soft” deprecation for older versions, we've only removed documentation - those versions have continued to run.

By the end of this year, all upgrades will be complete and the release schedule for the API will continue on a regular quarterly basis. Given the growing use of our API -- not to mention the growing number of versions we’re supporting -- we’ll need to begin hard deprecations for older versions. As a result, we’re introducing a new deprecation schedule and want to give all our developers enough time to plan for upgrades.

Going forward we are planning to deprecate each version one year after its release. This means at any time we’ll be supporting four versions. For example, when the Q1 release (v201402) comes out, we’ll deprecate support for the Q2 release of the previous year (v201302). That depreciation will be a “soft” one and it will still run until the Q2 release before being completely turned off; i.e. every version will be accessible for approximately 14 months.

In order to help developers adjust, we’ll be phasing in this new schedule. Our next scheduled release will be in Q1. On April 1st, 2014, we will be turning off v201206 and older, and putting v201302 and lower into “soft” deprecation. On August 1st, we’ll be turning off v201302 and older, and v201308 and v201306 will go into “soft” deprecation.

As of April 1st, 2014, these will be the only versions supported on DFP:

 Version  State 
 v201402  Scheduled 
 v201311  Supported 
 v201308  Supported 
 v201306  Supported 
 v201302  Soft deprecated 
 v201211  Soft deprecated 
 v201208  Soft deprecated 
 v201206  Deprecated 
 v201204  Deprecated 
 v201203  Deprecated 
 v201201  Deprecated 
 v201111  Deprecated 
 v201108  Deprecated 

As of August 1st, 2014, these will be the only versions supported on DFP:

 Version  State 
 v201408  Supported 
 v201405  Supported 
 v201402  Supported 
 v201311  Supported 
 v201308  Soft deprecated 
 v201306  Soft deprecated 
 v201302  Deprecated 
 v201211  Deprecated 
 v201208  Deprecated 

And finally, as of approximately a year from now, these will be the only supported versions:

 Version  State 
 v201411  Supported 
 v201408  Supported 
 v201405  Supported 
 v201402  Supported 
 v201311  Soft deprecated 
 v201308  Deprecated 
 v201306  Deprecated 

If you are using any version less than v201308 right now, you need to upgrade by August 1st, 2014 and if you are using any version less than v201211 right now, you should plan to upgrade in Q1 2014.

Our recommendation is to upgrade to v201311 now. This will delay your need to upgrade until Q1 2015.

Finally, just a reminder that v201311 is the last version to support ClientLogin and OAuth 1.0 authentication mechanisms. All future versions only support OAuth2. It’s also the last version supported by the old Java client library which means there’s no support for new API releases next year. When v201311 is deprecated in Q4 of 2014, everyone will need to be on a newer version using OAuth2 and the new Java client library.

If you have any questions, please let us know on our Ads Developer Google+ page.

-- The DFP API Team
Labels: ,

We’ve noticed some confusion around which identifier to use after upgrading to the new AdMob front-end, so we’d like to take this opportunity to explain the terminology and the format of the identifier that the Google Mobile Ads SDK expects for serving AdMob ads (DFP and Ad Exchange identifier formats remain unchanged).

Previously, we referred to this identifier as “publisher ID” if you were serving AdMob only, which represented a string of 15 hexadecimal characters starting with the letter “a”, such as a141234567890ab. If you were using mediation, we referred to the identifier as “mediation ID”, which represented a string of 16 character hexadecimal characters such as e123456789012345.

In the new AdMob, this identifier is referred to as “ad unit ID” and has a format of ca-app-<publisherId>/<slotname>. The term publisherId now represents a unique account identifier with the format pub-xxxxxxxxxxxxxxxx (16 digits) and slotname identifies a unique ad space and has the format nnnnnnnnnn (10 digits).

If you configure the Google Mobile Ads SDK with an incorrectly formatted ad unit, the ad request will fail with the error message: "Cannot determine request type. Is your ad unit id correct?". Make sure your ad unit has the format ca-app-pub-xxxxxxxxxxxxxxxx/nnnnnnnnnn without any whitespace.

Note that passing just the publisher ID from your new AdMob account, for example pub-1234567890123456, will return the error message above. Instead, you should find the full ad unit ID you wish to use from your apps in the Monetize tab on apps.admob.com.

As always, we’re available on our forum to answer any technical questions you may have about Google Mobile Ads. You can also find us on Google+.

 - , Mobile Ads Developer Relations

Labels:

Version 1.4 of the AdSense Management API is now available and comes with new features mainly based on suggestions and requests from developers: If you are new to the API, check out the new getting started video that covers everything you need to know to start your integration with the AdSense Management API.



Remember to visit the AdSense API forum or our Google+ page if you need any help implementing these new features!

- , AdSense API Team
Labels: , ,

After launching the new AdMob in May, we’ve been excited about how the platform could enable us to build new tools to benefit your apps business. Today, we’re announcing two new features; ad network optimization and impression goal campaigns for house ads, that can help you earn more from your apps.

Ad network optimization

Many app developers use more than one ad network to improve fill rate in their apps. Yet the challenge of earning the most revenue from networks remains. Allocating impressions to the best-performing networks often means manually comparing CPM reports, a method that doesn’t capture the most recent CPM.

Ad network optimization is a free service that makes the process a whole lot easier; it evaluates the CPM of each network in your mediation stack, and dynamically reorders them so the network with the highest CPM serves an ad to your app.

Once set up, AdMob continually obtains the freshest possible CPM value from each ad network and compares them. In addition, you can enable the AdMob network to bid alongside other networks on each impression. Ad network optimization currently supports AdMob, InMobi, JumpTap, and MdotM, with more ad networks coming soon.

Impression goal campaigns

AdMob house ads are an essential way to promote other apps to your users, using your own inventory, free of charge. Now, with impression goal campaigns, you can set a limit on the number of impressions you want to serve in a house ads campaign.

Impression goal campaigns are served via AdMob Mediation and take precedence over other ad sources in the mediation stack. Having more control over your house ad impressions means you can more intelligently cross-promote apps from your portfolio, while balancing the revenue you earn from mediated networks. Alternatively, you can work out a deal directly with an advertiser outside of AdMob, to run their campaign in your app.

Both of these features are only available through the new AdMob, so if you haven’t upgraded your account yet, we recommend you do.

Check out the new AdMob help center to get started with ad network optimization and impression goal campaigns.

Posted by Vishay Nihalani, Product Manager, AdMob

Labels:

[Update 2/17/2014: Based on developer feedback, we have moved the date of this change back to March 3, 2014.]

We're making a change to how the contentBid setting works in “Display Network Only” campaigns. Here's some background on the change and how it might affect you.

Currently, if you have a campaign that targets only the Display Network, then you can use a CpcBid at the adgroup level to specify a default bid and a display network bid override for content networks. In the past, we've allowed users to specify a contentBid in a "Display Network Only" campaign type, even though contentBid is useful only for "Search & Display Networks" campaign type. This allowed users to switch between "Search & Display Networks" and “Display Network only” campaign types without modifying their bids.

Since display campaigns have become so much more specialized over time, we've recently removed support for switching “Display Network only” campaigns to other campaign types. This makes contentBid setting obsolete for “Display Network only” campaigns, so we are removing the ability to set contentBid for “Display Network only” campaigns in AdWords API. The default bid value will be used for serving your ads on Google Display Network.

What this means for you

If you do not set contentBid at the adgroup level for a “Display Network only” campaign, this change will not affect you.

Starting on February 18th, 2014, if you set contentBid for a “Display Network only” campaign, then you will start receiving a ReadOnlyError.READ_ONLY error for all versions of the API. You can use the fieldPath of the ApiError object to identify the operation triggering the error.

To avoid getting errors, you should:
  • modify your code to set the default adgroup bid instead of contentBid
  • clear out the contentBid field to make sure that AdWords will start using the default adgroup bid when serving your ads
  • if you store campaigns in a local data store, re-sync your data store with AdWords to pick up the updated default bid values
If you're still using contentBid to set ad group display bids in “Display Network only” campaigns within a few days of February 18th, 2014, we plan to do a one-time migration of those bids to become your ad group default bid. This migration is intended to ensure your ads serve with the correct bid; you must still make sure your code is able to handle ad group bids on the Display Network properly.

If you have any questions about this change or the AdWords API in general, you can post them on our developer forum. You can also follow our Google+ page for updates about the AdWords API.

Anash P. Oommen, AdWords API Team
Labels: , , ,

Editor's note: re post from Inside AdSense blog. --Stan Grinberg

As the holidays approach, you can expect an increase in smartphone usage, especially in activity with gaming apps. Each year around this time, millions of new mobile devices are activated and billions of apps are downloaded. A recent AdMob study* also revealed that downloading and playing gaming apps are users’ top priority when getting a new smartphone, which represents a special opportunity for developers.

A new strategy for game-app developers can help them make the most of this increase in usage. Game developer Izumi Artisan used this strategy to increase his revenue by 60%, and so today we’ll share the details on how he achieved these results.


Step 1) Create a strategy guide for your game and post it on your website
Game guides, strategy manuals, and walk-throughs have become commonplace for gamers looking to get the edge or just take the easy path through a tricky section of a game. As a result, numerous third party game-strategy sites have popped up, and are attracting users in mass numbers.

This represents a great opportunity for you as a game developer, as you can create your own strategy or walk-through guide and host it on your website. There are many examples of successful game guides on the Web that you can use as a model when creating your own. The guides will vary in structure and length depending on the format of the game, so we suggest browsing a few to find the most suitable format. If there are already third-party guides competing for your users’ attention, try releasing the “Official” guide to separate yourself from the rest of the pack.

Step 2) Monetize your new website with AdSense
Creating great content and putting it on the Web is an important step for those looking to generate income online. To start earning revenue from your online content you can use AdSense to show highly relevant ads on your website.

With AdSense, advertisers will bid against each other to show their ads next to your content. The ads that appear are highly targeted, so they’re likely to be interesting to your visitors. AdSense also offers a number of great features including customization options to control the appearance, placement and type of ads that will show up on your site, as well as the ability to restrict the subject matter of the ads.

If you’re not already an AdSense publisher, sign up for a free AdSense account.

Step 3) Use house ads in AdMob to drive users to your new website
One of the most difficult pieces of building a successful website is attracting visitors. As a game developer, you have the benefit of an existing and engaged audience -- your users. By taking advantage of this built-in audience you can quickly generate demand for your new web content...you just have to point them in the right direction.

You can do this by using AdMob’s house ad feature, which lets you display your own promotions to your users at no cost. By creating a “house ad” promotion for your new website and displaying it in an appropriate section of your game (i.e., on the home screen, or in-between game play, etc.), you can easily generate awareness for your web content while preserving a good experience for your users. The great part is, you won’t need to push a new version of your app since the house ad can be updated directly within the AdMob interface.


Sign up for an AdMob account here. It’s free.

Be sure to make the most of the app usage increase that comes with the holiday season by trying this strategy. Have these tips worked for you? Do you have other tips to share? Let us know in the comments!

Posted by Max Sack - Publisher Advocate


*Mobile Apps Consumer Study, AdMob and Parks Associates, Oct 2013
Labels: ,

We are glad to announce the following new features in AdWords scripts.

1. Ad Rotation settings

AdWords supports an ad rotation setting that determines which ad in your ad group should show when you have multiple ads in your campaign. You can now access and modify this setting through the getAdRotationType and setAdRotationType methods of the Campaign object. When setting the adRotationType, you can use the string values OPTIMIZE, CONVERSION_OPTIMIZE, ROTATE, or ROTATE_FOREVER.

2. Support for identifying entity types

We now support a getEntityType method on all the AdWords entity classes like Campaign, AdGroup, etc. This method will return the name of the type, and can be used to identify the type of the object. E.g. 

var campaign = AdWordsApp.getCampaignByName(
    "My campaign").get().next();
Logger.log(campaign.getEntityType()); // prints "Campaign"

3. Retrieve deleted objects

You may now retrieve deleted objects and their stats by explicitly requesting them in your AWQL. E.g. The following code snippet retrieves all deleted campaigns. 

var deletedCampaigns = AdWordsApp.campaigns()
    .withCondition("Status='DELETED'").get();

Note that for backward compatibility purposes, we do not return deleted objects by default.

We hope you enjoy these new features. If you have questions or feedback, please visit us on our official forum.

Anash P. Oommen, AdWords Scripts Team

Labels: , ,

Are you a student who loves to code or has a great idea for a mobile app? Maybe you’re building one right now. Imagine that one day your app could be seen by millions of users.

You’re invited to take part in The AdMob Student App Challenge, a mobile app contest open exclusively to students around the world. The goal is to build a great app (either Android or iOS), create a revenue stream using AdMob's in-app advertising, and tell us about your experience in a written business report. You can either build the app on your own or form a team of up to five students.

To win the Challenge, you'll need a great app and a good business strategy that focuses on how you manage the project, gain users and leverage AdMob. In the next few weeks we’ll be announcing the respected app industry leaders who’ll be on the judging panel.

We’ve got some awesome prizes if you win: The winning team will receive:

  • A 7-night trip to San Francisco with spending money, including a trip to the Google headquarters in Mountain View.
  • The winning app will be featured on the Google Play store and on the Play Store's social channels (certain conditions apply).*
  • An opportunity to star in your own case study video to tell your story.
  • A Nexus 7 device for each team member.

As well as one overall winner, there'll be a winner from each of the four global regions (North America, Latin America, Europe, Middle East & Africa, and Asia Pacific), who'll receive computing devices and an honorary mention on the AdMob website.

The Challenge starts today and you have until March 31, 2014 to build a winning app. Visit the AdMob website to learn more and to register. The winners will be announced in May 2014.

Follow the AdMob G+ page for regular updates and announcements.

Posted by Mike Schipper, Product Marketing, AdMob

*Only apps made available through the Play Store will have an opportunity to be featured. See the Official Rules for more details.

Labels: ,

In order to deliver reliable services to AdWords API users across the globe, we use a Token Bucket algorithm to meter requests and determine the queries per second (QPS) rate. This is intended to prevent malicious or out-of-control software from overwhelming the AdWords API servers and affecting other users.

We recognize that your AdWords API client application may sometimes exceed the limit and receive a RateExceededError due to factors not fully in your control. Don’t worry. RateExceededError is usually transient and automatically resolved after 30 seconds of inactivity.

Rate limits fluctuate based on different variables, including server load. So we don’t recommend a fixed QPS limit to developers. That’s why it’s extremely important to understand how to handle RateExceededError, and develop your software with rate limits in mind.

Please take a look at our detailed AdWords API Rate Limit guide to learn more about:

  • Different types of rate limits and rate limit scopes
  • Operational limits for different account access levels
  • Recommended practices to avoid exceeding different rate limits
  • Tips for handling RateExceededError gracefully in your application, if it happens
- Ray Tsang, AdWords API Team
Labels: , ,

Today, we are launching v201311 of the DFP API. This release includes improvements to location targeting and expanded PQL functionality. It is the final version to allow ClientLogin and OAuth1.0 authentication, and provide support for the old Java client library. A detailed list of these features and what’s changed can be found on our release notes page.

It’s all about location, location, location

Starting in v201311, we are making an important change to how you interpret targeted locations; Location objects will no longer come back as subtypes. Instead, they now contain a type field that indicates what kind it is. Since this field is a string, you can now handle new types as they are introduced, rather than having to update to a newer version of the API. This means faster turnaround times to get features into the hands of your customers. A displayName has also been added to easily show your users what is being targeted, just like our UI does. Note, there is no change to how you target locations, and all fields except for id remain read-only.

We believe this is a positive step forward as we continue to streamline the API; the switch to a single Location object aligns with the recently released Geo_Target table and reduces the number of code paths of your application. Stay tuned for a follow-up blog post about best practices and how to migrate your application.

More through PQL

As mentioned in our previous release post, the new LINE_ITEM table provides a quick and easy way to fetch information about your line items. Today, we are releasing the AD_UNIT table to do the same for your inventory. We’ll be releasing more tables soon, so be sure to let us know in the forum what tables you’d like to see next.

One of our popular feature requests is the ability to filter reports by parent ad units, i.e. by sections of your inventory. Now, with the AD_UNIT_ANCESTOR_AD_UNIT_ID dimension, you can filter by any ad unit within the inventory hierarchy. See the RunInventoryReport example in each client library for more.

We've also updated the ActivityService to no longer require an activityGroupId in PQL filter statements. We've updated our GetAllActivities example to reflect this as well.

Deprecation announcements

As we stated in our previous blog post, v201311 will be the last version to support the ClientLogin and OAuth1.0 authentication mechanisms. Starting in 2014, new versions will only support OAuth2. As you plan your application updates for the new year, please take this into consideration.

Finally, if you are a Java developer, v201311 will be the last version supported by the old Java client library. If you haven’t migrated to the new Java client library yet, now would be a great time to do so.

As always, if you have any suggestions or questions about the new version, feel free to drop us a line on our Ads Developer Google+ page.

 - , DFP API Team
Labels:

The AdWords, DFP, and DFA APIs can take a user agent string in the SOAP headers, and the client libraries all allow you to set this string in their configuration files. This post explains why it’s in your own best interests to set this value to something unique and useful for each of your applications. We will be enforcing this soon in the Client Libraries - you won't be able to leave it as the default setting, or set an empty string. So, come up with a fitting string for your application and start using it in your headers now, if you’re not doing so already!

Here at Google we have the means to check our logs to see the SOAP requests you make, the responses we send you, and any internal error messages that might have been generated if something went wrong. If something appears wrong from your side, you can contact us, and tell us what happened and when, and we can search these logs for your developer token, network code, or specific features of the request that went wrong. In many cases that can be enough for us to be able to help you diagnose and solve that problem.

But many of you are developing more than one product. And sometimes the problem you’re trying to diagnose doesn't come down to a particular single event. Sometimes there’s a behavior over time we’re trying to pin down. And there are a lot of requests and responses in our logs.

If you can tell us the UserAgent or ApplicationName string you set for a particular version of a particular product that appears to be misbehaving, we can much more quickly and easily tell you how many of each request type it made, and when, and what the success rate for those requests were.

Likewise, if you’re trying to migrate from one version of the API to another, we can tell you if you are still making requests using the old API release, and also exactly which version of which application.

Supplying a useful UserAgent or ApplicationName string also enables us to proactively reach out to you when we see something going wrong or notify you of upcoming API changes that may affect you. We could then tell you exactly which behavior of what product and release will be impacted.

We suggest you use the format <CompanyURL>:<AppName>:<Version> so for example:

        example.com:ReportDownloader:V3.2

Here’s where to look and what to set for each Client Library:


Client Library
Product
Props File / setup method
Setting Name
Java
AdWords
ads.properties
api.adwords.userAgent
Java
DFA
ads.properties
api.dfa.applicationName
Java
DFP
ads.properties
api.dfp.applicationName
PHP
AdWords
auth.ini
userAgent
PHP
DFP
auth.ini
applicationName
Perl
AdWords
adwords.properties
userAgent
.Net
AdWords
App.config
UserAgent
.Net
DFA
App.config
ApplicationName
.Net
DFP
App.config
ApplicationName
Ruby
AdWords
adwords_api.yml
user_agent
Ruby
DFP
dfp_api.yml
application_name
Python
AdWords

run the "config.py" script
userAgent
Python
DFP

run the "config.py" script
applicationName

And if you’re generating your own SOAP and not using a Client Library, please set the string directly in the headers yourself.

So why not make this simple change, if you aren't making use of it already, and set the UserAgent or ApplicationName string for each of your application releases? You never know when it will mean the difference between hours of digging or a quick fix.

Feel free to ask questions or give us feedback via the G+ page.
Labels: , ,

AdWords scripts allow you to create and email PDF documents, complete with pretty formatting and images. You can schedule a script that emails a professional-looking PDF report to your client weekly, complete with logos, watermarks, signatures, and other artwork. This blog post discusses this feature in more details.

Sending an attachment

The following snippet sends an email with an attachment: 
// assuming you have a good-to-go blob, more on that later.
MailApp.sendEmail(
    "us...@example.com",
    "TPS report",
    "Please find the TPS report attached to this email",
    {attachments: [blob]}
);
BLOB stands for Binary Large OBject. In Google Apps Script, blobs are used as the in-between data format that allows different services to pass data to each other.

Creating a BLOB

Start with an HTML string, and use Utilities.newBlob() to convert it into a blob: 
var html = "<h1>TPS report</h1><p>Please read this carefully and respond " +
    "by end of day...</p>"
var blob = Utilities.newBlob(html, MimeType.HTML);
Converting a blob into PDF is as easy as 
var pdfBlob = blob.getAs(MimeType.PDF);
Dealing with images

A reasonable attempt looks like this: 
var html = "<img src='url_of_the_image'>";
But that, unfortunately, won't work. The PDF generator never actually fetches resources that your HTML links to, so the image won't make it into the PDF. You need to specify the source of the image inline instead, as a base64-encoded string: 
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADIA..." />
Don't worry about the contents of the base64-encoded strings - they are gibberish and will consume lots of screen space if printed out.

Putting it all together

The following snippet will fetch the image from imageUrl, embed it into the PDF, and email the results to us...@example.com: 
// fetch the image. This example assumes it's a PNG.
var imageBlob = UrlFetchApp.fetch(imageUrl).getBlob();

// grab its bytes and base64-encode them.
var base64EncodedBytes = Utilities.base64Encode(imageBlob.getBytes());

// create HTML.
var html = "<h1>TPS report</h1><img src='data:image/png;base64," +
    base64EncodedBytes + "'/>";

// create a blob, convert it to PDF.
var htmlBlob = Utilities.newBlob(html, MimeType.HTML);
var pdfBlob = htmlBlob.getAs(MimeType.PDF);

// give it a name - this will become the file name of the attachment.
pdfBlob.setName("tps_report.pdf");

// send the email.
MailApp.sendEmail(
    "us...@example.com",
    "TPS report",
    "Please find the TPS report attached to this email",
    {attachments: [pdfBlob]}
);
Instead of fetching the image from the URL, you can upload it to Google Drive and use DriveApp to fetch it: 
var blobFromDrive = DriveApp.getFilesByName(imageFileName).next().getBlob();
So there you have it - blobs aren't just fun to say, they're useful as well. If you have questions or feedback about this feature or AdWords scripts in general, you can post them on our developer forum or our Google+ page.

Posted by Ilya Netchitailo, AdWords Scripts Team
Labels: , ,

Consumers are increasingly using smartphones and switching between devices along their path to purchase. So it's become harder for marketers to see the full conversion path and measure ROI using traditional online conversion tracking.

That's why we recently introduced Estimated Total Conversions. Estimated Total Conversions provides a more complete and accurate view of all of the conversions driven by AdWords -- including conversions that start on one device and end on another.

Many new metrics related to Estimated Total Conversions are now available in the AdWords API. When you use the Account Performance Report, Campaign Performance Report, or Ad Group Performance Report, you can now access the following fields:
  • CostPerEstimatedTotalConversion
  • EstimatedCrossDeviceConversions
  • EstimatedTotalConversionRate
  • EstimatedTotalConversions
  • EstimatedTotalConversionValue
  • EstimatedTotalConversionValuePerClick
  • EstimatedTotalConversionValuePerCost
  • ValuePerEstimatedTotalConversion
To see the new Estimated Total Conversions statistics, you need AdWords conversion tracking set up through either the AdWords UI or ConversionTrackerService in the AdWords API. You'll also need a sufficient volume of conversions within an account, campaign, or ad group so that reliable estimates can be made.

Keep in mind, estimated conversion values are available only for search ads on Google traffic at this time.

As always, please feel free to ask any questions regarding the AdWords API on the G+ page or the forum.

-Takeshi Hagikura, AdWords API Team
Labels: , ,

We've aimed to make transition from DoubleClick for Advertisers to DoubleClick Campaign Manager as seamless as possible for our API users. These two systems differ in a requirement for using In-App creatives - in DFA these creatives can be assigned to any standard placement, while in DCM they must be assigned to a placement with an In-App type. We want to make your transition as painless as possible, so we've added a way for you to handle this situation from either platform.

We've patched 4 new placement types into the DFA API version 1.20:

Placement TypePlacement Type ID Number
Agency Paid In-App14
Agency Paid In-App Interstitial15
Publisher Paid In-App16
Publisher Paid In-App Interstitial17

These types exist in both upgraded and pre-upgrade accounts, with one important difference. Since DFA doesn't actually support In-App placements, using these new placement type identifiers will result in the creation of standard placements instead. For example, saving a placement of type “Agency Paid In-App” (type ID number 14) will result in the creation of an “Agency Paid regular” placement with type ID number 3.

We will never return placements with these new types to pre-upgrade users, and you may continue to traffic In-App creatives to standard placements until you upgrade. During your account's migration to DCM, we will automatically correct the type of any existing placement trafficking In-App creatives as part of your upgrade process. After the upgrade, you will no longer be allowed to traffic In-App creatives to standard placements. To better future-proof your application for your upgrade, create placements intended for In-App using these new type codes even before upgrading to DCM.

We've added this change to our DCM upgrade guide. Feel free to update your applications with these new types as soon as possible. If you have any questions about these new placement types, we're always available at our forum and our Google+ page.

- Joseph DiLallo, the DFA API Team
Labels: ,

With the release of v201309, sitelink descriptions are out of beta and available to all users. Adding more information to your sitelinks can make your ads even more useful and significantly increase ad clickthrough rate. You can now use feed services to retrieve or modify two descriptive lines of text in each of your sitelinks.

If you are already retrieving feed mappings or sitelinks through the API, make sure your code can handle the new placeholder field IDs of 3 and 4. The new IDs may appear in responses from the FeedMappingService for sitelink feed mappings (mappings with placeholder type 1).

As an example of how to improve your sitelinks by using these fields, let's say you have a pizza shop with special offers that you want to display along with your sitelinks. In addition, you want to periodically update the special offers as the seasons change.

Before adding the new description fields, your sitelinks appear as follows.



You modify your feed attributes, feed items, and feed mapping to use the new field types, and now your sitelinks can show with helpful descriptions.



In the month of November you want to to change things up with modified descriptions under "Order Online Now" and "Deals In Your Area". All it takes is updating the feed items mapped to your Campaign or Ad Group, and voila!



Note that the description lines or the sitelinks themselves may not always appear in your Ads or the format that appears could vary.

To update your existing feeds to include these new fields, you'll need to make the following changes.
  • Use the FeedService to add two new FeedAttributes to your feed
  • Use the FeedItemService to set these new attribute values on your FeedItems
  • Use the FeedMappingService to replace the existing FeedMapping with a new one that contains the existing FeedMapping's fields and the two new fields
  • As your specials change over time, use the FeedItemService to update your FeedItems with the latest information
Refer to our Java code sample for more details.

Concerned about losing reporting stats on your ads when you make changes to your sitelink descriptions? Don't worry - as with other sitelink values, AdWords will retain stats when you update your feed items.

Not using feed services? Check out the following resources to get started. Still have questions? Please contact us on the AdWords API Forum or Google+ page.

- , AdWords API Team
Labels: , ,

AwReporting is an open-source Java framework for large scale AdWords API reporting. AwReporting presents an end to end AdWords reporting example that enables usage of report data in a just few minutes.

Here are some of its major out-of-the-box features:
  • Generate reports for all AdWords accounts managed by an MCC
  • Use 15 common reports included in the reference implementation – just follow the code examples to implement more
  • Store downloaded report data in your local relational database, so you can integrate them with your existing applications
  • Optionally use MongoDB for storage
Get started with the project’s GitHub repository. We have also added a full example, KratuBackend, that uses AwReporting to generate AdWords data for our client-side analysis framework Kratu.

Feel free to ask questions or give us feedback via the G+ page or the project’s issue tracker.


-Julian Toledo, AdWords API Team
Labels: ,

With the v201309 AdWords API release, ad group level bid adjustments are now out of Beta and available to all users. This means all API users can make adjustments to their bids when using Remarketing Lists for Search Ads criteria. You can also set bid adjustments for Display Network targets through the bidModifier field in BiddableAdGroupCriterion.

You can adjust your bids anywhere from 10% to 1000% of your original bid to more efficiently manage your bid, ad position, and ROI for different audience segments in either search or display.

Feel free to reach out to us via the G+ page or the forum if you have any questions regarding this feature.

-Danial Klimkin, AdWords API Team
Labels: , ,

The end of the year is always the busiest time for advertisers, and competition for inventory in Ad Exchange is at it’s peak. Are you doing everything you can to ensure your campaigns are delivering on time and on budget?

To lighten the load this holiday season, optimize your ad serving with these simple steps:

Plan ahead for the busiest time of the year
Make a resolution to start planning your seasonal campaigns earlier. Submit your creatives for approval two days before going live and make sure you’re using only certified vendors and declaring them when necessary. The set of allowed vendors and whether they are declarable can be determined using the vendor declaration tool found in the help centre article Declaring 3rd- and 4th-party vendors in the Ad Exchange. Any vendor not on the list in the tool is prohibited As a proactive measure, buyers can use the creative REST API to submit an ad creative for review, to check its status and retrieve a list of all active ad creatives. Be sure your ads are approved before bidding to ensure your campaigns deliver.

This year, the REST API has been updated with a new method allowing creatives to be sent for re-review. Should any creatives get disapproved before the start of your seasonal campaign, it is not a requirement that the buyer creative ID change to get the creative re-reviewed. To make use of this feature, use version 1.3 of the REST API.

Make sure your ad creatives are eligible to serve
The last thing you want this time of the year is for your ad creatives to be disapproved. To make sure your campaigns aren’t delayed, make sure to avoid these common policy mistakes:

  • Declare the Correct URL/Multiple URLs: please make sure you have declared the URL that the ad leads to. If you have several URLs for the same ad, they all must be declared.
  • Creative Borders: On all .gif and .swf ads with partially black or white backgrounds, you must add a visible border of a contrasting color to the majority background color of the ad.
  • Content Violations: Remember that Ad Exchange is “family-safe” content only. Therefore, ads that are classified as “limited family safe”, “non-family safe”, and “adult” are not allowed (unless you are participating in the Restricted Category Beta for Alcohol).
  • Fourth Party Calls: if you use fourth-party vendors, please make sure they are certified by Google. You can check which vendors are certified and which need to be declared here.
  • Over-animation: Please make sure your total animation time does not exceed 30 seconds. For looping or repeating animations, the total combined interval time can not exceed 30 seconds. After an animation has stopped, it cannot restart. Read the full policy here.

Review the AdX Buyer Program Guidelines and Ad Exchange Policies and Enforcement Help Center page for additional details.

Ensure your bids make it to the auction (RTB buyers only)
Each bid response submitted to Ad Exchange undergoes a screening process before it can enter the live auction. During this process, your bid may be filtered out by Google, the publisher, or during the actual auction for many different reasons.

To ensure your bid is not filtered, remember to always review the following:

  1. Disapproved ads in the snippet status report
  2. Excluded dimensions in the publisher settings report
  3. Publisher’s min CPM requirement in the bid request

You can read more about post-filtered bids in our developer blog.

As part of your preparation for a smooth running seasonal campaign, make use of the new RTB Dashboard - a tool designed to bring greater transparency to you, as a buyer, and help you refine your bidder to produce more efficient bidding and better results for your campaigns. With RTB Dashboard, you have the ability to review the “RTB insights” section which helps you understand which bids are being filtered out and why.

Plan ahead to make the end of year a success
Nobody wants to start the new year with an unexpected surprise. So, after checking that your ad creatives are approved, make sure your campaigns continue into the new year by reviewing the items below:

  • Campaign End Date: Make sure you’ve set correct campaign end date set. You don’t want to come back from the holidays to find your campaigns switched off by mistake because the end date was set to the default date, 12/31/12.
  • Budgets: Take some time to review campaign budgets before heading out to that holiday party. CTRs remain high throughout these festive times and into the new year and it’s a good idea to plan ahead to ensure budgets don't run out early.

Need help over the holidays?
Hopefully everything goes as planned this holiday season, but if any emergencies like UI outages or major drops in RTB traffic come up, our U.S. support teams will be on hand to make sure you’re back up and running. Please note the U.S. Google offices will be closed on the following days:

  • Tuesday December 24th
  • Wednesday December 25th
  • Tuesday December 31st
  • Wednesday January 1st

If you follow these best practices, you can focus on other initiatives on your wishlist (e.g. mobile, video).

Posted by the Ad Exchange Team

Labels: , ,

If you want to get your campaign management data using the AdWords API, AWQL (AdWords Query Language) is a great choice. AWQL offers an SQL-like syntax for setting up your fields, ordering, paging, and predicates all in one simple string. AWQL is mainly used for reports, but is also supported with some services.

Services Supported

There are currently five services that support AWQL: CampaignService, CampaignCriterionService, AdGroupService, AdGroupCriterionService, and AdGroupAdService.

Here is a Java code comparison that finds the IDs and names of ad groups within a specific campaign. Using the standard methods, you have to set fields, ordering, paging, and predicates separately. 
Selector selector = new Selector();
selector.setFields(new String[] {"Id", "Name"});
selector.setOrdering(new OrderBy[] {new OrderBy("Name", SortOrder.ASCENDING)});
selector.setPaging(new Paging(offset, PAGE_SIZE));
Predicate campaignIdPredicate =
    new Predicate("CampaignId", PredicateOperator.IN, new String[] {campaignId.toString()});
selector.setPredicates(new Predicate[] {campaignIdPredicate});
AdGroupPage page = adGroupService.get(selector);
The same task can be done more simply using AWQL, as shown below. 
String query = 
    "SELECT Id, Name" + 
    " WHERE CampaignId IN [%d]" + 
    " ORDER BY Name ASC" + 
    " LIMIT %d, %d";
query = String.format(query, campaignId, offset, PAGE_SIZE);
AdGroupPage page = adGroupService.query(query);
We also have plans to add support for AWQL to more services in upcoming releases.

Reporting Features

Within AdHoc reports, AWQL also supports the unique DURING clause, which is an easy way to filter results in a given date range. For example, if you were interested in finding campaigns with few impressions during October, you could run a query like this. 
SELECT CampaignId, CampaignName, Clicks, Impressions
FROM CAMPAIGN_PERFORMANCE_REPORT
WHERE Impressions < 100
DURING 20131001,20131031
Remember that stats are only available via AdHoc reports.

We recommend using AWQL as an expressive, easy way to retrieve data from your AdWords campaigns. Please feel free to ask any questions on the AdWords API forum or on our Google+ page.

- Michael Cloonan, AdWords API Team
Labels: ,

The Ad Review Center is a new feature in AdMob that gives you more transparency and control over the ads which appear in your apps.

Ad Review Center lets you review ads before they appear in your app, and you can see the ads which have already shown in your app, to assess if you want to continue showing those ads to your users. It’s particularly useful for brand-conscious developers.

The Ad Review Center is available to all AdMob developers globally. Getting started is easy: you can manually enable it within your account by visiting the Monetize tab of your account, then clicking ‘Ad review center’ in the left hand navigation and following the instructions. Once its set up, you can choose between two modes:

  • Run ads immediately. This mode gives you the most potential revenue. Ads of all targeting types (contextual, interest-based, and placement) automatically serve to your apps, taking into account whatever filters you’ve already set up in your account. You can then review the ads which have appeared and potentially block them from running again.
  • Hold ads for 24 hours. This mode applies to placement-targeted ads only, which are ads that advertisers have chosen to target to your app specifically. Ads are held up to 24 hours before showing in your apps, or until you explicitly approve them. If you don’t take action within 24 hours, ads will begin showing in your app.

Holding and blocking ads can have a significant impact on your revenue, and ads which are awaiting review or have been blocked don’t compete in the auction. We strongly recommend that you use the Run ads immediately mode, then review and take action if you don’t want particular ads to appear again later.

More details about this new feature can be found on the AdMob Help Center.

Posted by Vishay Nihalani, Product Manager, AdMob

Labels:

With the recent change to the Search Network setting in the AdWords API we’ve noticed a few cases where network settings were used to pause campaigns by disabling all possible networks. To simplify campaign management and reduce ambiguity, we will disallow this campaign state going forward. Any operation disabling every network for a campaign will produce TargetError.TARGET_ERROR starting Nov 12th 2013.

The change will affect only versions v201309 and later. If you use network settings to pause your campaigns and have already migrated to v201309, please use the campaign status PAUSED instead.

If you do not update campaigns with every network target set to false, this change will not affect you.

As always, please feel free to ask any questions on the AdWords API forum or our Google+ page.

- Danial Klimkin, AdWords API Team
Labels: ,

Today, we’re excited to announce version 6.6.0 of the iOS Google Mobile Ads SDK. Highlights include:

  • Added support for arm64 and x86_64 architectures
  • Significantly reduced library size
  • Added adNetworkClassName property on GADBannerView and GADInterstitial
  • Fixed a bug where DFP app events were not firing for interstitials

The new adNetworkClassName property tells you which ad network class served an ad during mediation. This value will be GADMAdapterGoogleAdMobAds for ads coming from the AdMob or DFP network, and GADMAdapterCustomEvents for custom event classes. For other ad networks, this property will return their adapter’s class name.

Check out the release notes for a full list of updates. The latest SDK can be found on our downloads page. You can reach us on our forum with any questions or concerns about the new SDK, and stay tuned for updates on our Google+ page.

 - , Mobile Ads Developers Relations

Labels: ,

We are glad to announce that AdWords Scripts now support Budgets as top-level objects. You can now fetch the budget’s stats, determine whether it is shared, and inspect its delivery method. You can also fetch all campaigns associated with a budget.

To support budgets, we have had to tweak existing APIs a bit. We believe the impact on existing scripts will be minimal; please let us know if you experience any issues, and we'll help you work through them. Here’s what changed: The good news - existing scripts should be largely unaffected by this change. Details below.

Campaign.getBudget()

Thanks to JavaScript flexibility, the same entity can act as both a Number and an Object. Consider this snippet: 
var smartNumber = new Number(48.0);
smartNumber.getIQ = function() { return 150; } // indeed, a smart number!

// smartNumber acts like a regular number:
Logger.log(smartNumber);         // prints '48.0'
Logger.log(smartNumber + 5);     // prints '53.0'
Logger.log(smartNumber > 47);    // prints 'true'

// and you can also call its methods
Logger.log(smartNumber.getIQ()); // prints '150'
We have used a similar approach for the return value of Campaign.getBudget() method. The value returned from that method acts like a number (and thus existing scripts shouldn’t be affected), but also exposes methods from Budget object (getStats(), getDeliveryMethod(), etc.)

The behavior observed by your script may change in the following (unlikely) scenarios:
  • typeof operator - 'object' vs. 'number'
Type of the object returned by getBudget() call has changed from 'number' to 'object': 
Logger.log(typeof(21));             // prints 'number'
Logger.log(typeof(smartNumber));    // prints 'object'
  • === operator
If used for comparison of budget values, the triple-equals operator will now return false instead of true: 
Logger.log(smartNumber == 48);      // prints 'true'
Logger.log(smartNumber === 48);     // prints 'false'
Campaign.setBudget(Number)

We are deprecating this method. The preferred way to change a campaign’s budget, going forward, is via the Campaign.getBudget().setAmount() call.

Campaign.setBudget(Number) will continue working for non-shared budgets in the short term. For explicitly shared budgets, however, the call to this method will throw an exception (while in the past, it would log an error and proceed with the execution).

Happy scripting!

Posted by Ilya Netchitailo, AdWords Scripts Team
Labels: ,