Tag Archives: AdSense

Introducing Builders in AdWords Scripts

We are introducing Builders as the standard way to create entities in AdWords scripts. You can use Builders in either synchronous or asynchronous mode. You can also check whether the operation was successful or not, and take appropriate actions depending on the operation’s outcome. The following code snippet shows how to create a keyword using builders.


// Retrieve your ad group.
var adGroup = AdWordsApp.adGroups().get().next();

// Create a keyword operation.
var keywordOperation = adGroup.newKeywordBuilder().
.withCpc(1.2)
.withText("shoes")
.withDestinationUrl("http://www.example.com/shoes")
.build();

// Optional: examine the outcome. The call to isSuccessful()
// will block until the operation completes.
if (keywordOperation.isSuccessful()) {
// Get the result.
var keyword = keywordOperation.getResult();
} else {
// Handle the errors.
var errors = keywordOperation.getErrors();
}
The current release adds builder support for ads and keywords. The existing builders for ad groups and Ad Extensions - phone number, site links and mobile apps have also been standardized. The addSitelink, addPhoneNumber, and addMobileApp methods of AdGroup and Campaign classes will now return the resulting operation.

We are also deprecating the following creation methods. These methods will work fine for now, but they will be sunset in the future. You can learn more about this new feature on our guide. If you have questions or feedback about this feature, let us know on our forum.

Announcing v6.5 of the Google Mobile Ads SDK for Android

Today we’re announcing the release of v6.5 of the Google Mobile Ads SDK! It’s listed as Google Play services 6.5 (Rev. 22) in the Android SDK manager, and is available for download right now. Those of you using Android Studio should download Google Repository (Rev. 14) to get the latest Gradle artifacts.

Under the hood improvements (greater stability, more efficient use of resources) make up most of the changes, but we’re pleased to note that this will be the first version of the SDK to support a split jar architecture. Previously, the SDK was compiled as a single, all-encompassing JAR file. Beginning with this release, however, it’s also built into separate JARs, each covering a specific domain of functionality. Interactive Media Ads (IMA) and Mobile Ads developers can now reference part of the Play Services SDK without needing to import the whole thing. This in turn reduces the APK size and memory footprint of your applications.

Taking advantage of the new architecture is easy -- you just need to change how you’re incorporating the SDK in your build process. Here’s an excerpt from a typical build.gradle file for an app that uses the SDK to display mobile ads:


dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.google.android.gms:play-services:6.+'
}

And here’s one that targets the ads library specifically, new in v6.5:


dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.google.android.gms:play-services-ads:6.+'
}

That’s it! Gradle will now incorporate the new, smaller JAR into your application. If your app consumes other services from the SDK, simply add the relevant JARs (play-services-games or play-services-location, for example) to your build file as well.

IMA developers can make this change now. If you’re a Mobile Ads developer, one important thing to note is that the new split jar architecture currently works only with projects that configure banner ads in Java code, and not in XML. We plan to support XML configurations in the future, but for now if you’re defining and configuring your AdViews in an XML layout file, you should continue to reference Play Services in the existing manner.

You can read the Google Play Services Announcement on the Android Developers Blog for a summary of what’s new with this release. For a full list of Mobile Ads SDK changes, check out our release notes. For technical questions, post them on our forum.

Filtering report data by custom targeting key ID in the DFP API

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

Step 1: Use CustomTargetingService to get your keys and values

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

    WHERE customTargetingKeyId IN (17, 18, 19)

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

Step 2: Use the values in a report query

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

    WHERE CUSTOM_TARGETING_VALUE_ID IN (3211, 88990, 123456)

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

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

IMA SDK for iOS Beta 10 Release

Last week we released beta 10 of the IMA SDK for iOS. This release comes with a few new features including the following:

  • Ad rendering via the new WKWebView in iOS 8
  • Addition of calling classes in delegate methods
  • New TAPPED event for tracking user taps on the ad container

The most important thing to know about this release is that you will now need to include the WebKit framework as an optional framework in your implementation and build for 64-bit support. If you are a Cocoapods user, this will be done for you in the generated xcworkspace when you upgrade to beta 10 via pod install.

Ad rendering via the new WKWebView in iOS 8

We’ve moved ad rendering from UIWebView to the new WKWebView in iOS 8 implementations. This should fix a number of issues we saw with the old web view in iOS 8, including skip button unresponsiveness and delayed tracking event firings. As a side effect of this change, you’ll need to include the WebView framework as an optional framework in your project and build for 64-bit support. If you’re a Cocoapods user, this will be done for you when you run pod install to get the latest version of the SDK.

Addition of calling classes in delegate methods

After the beta 9 release, we noticed that a few of our delegate methods were missing a reference to their calling class, which put them out of line with iOS standards. We’ve resolved this issue in beta 10 and marked the old methods (without a reference to the calling class) as deprecated. You can see a list of the new methods in our release notes.

New TAPPED event for tracking user taps on the ad container

Since launch, one of our most requested features has been to add the ability to respond to user taps on the ad container while an ad is playing. We’re happy to announce that Beta 10 fulfills this request by adding kIMAAdEvent_TAPPED to the list of AdsManager events. You can start listening to this event by setting up your AdsManager delegate as follows:

  - (void)adsManager:(IMAAdsManager *)adsManager
didReceiveAdEvent:(IMAAdEvent *)event {
if (event.type == kIMAAdEvent_TAPPED) {
// Handle TAPPED event
}
}

This event will be fired any time a user taps on a non-clickable part of an ad (taps on the "Learn more" or "Skip" buttons will not result in a TAPPED event).

As always, if you have any questions feel free to contact us via the support forum.

Announcing the Budget resource for the DoubleClick Ad Exchange Buyer REST API

We’ve just released the Budget resource for the DoubleClick Ad Exchange Buyer REST API, which can be used to set a daily budget for your real-time bidding campaigns. Each PretargetingConfig will have an associated Budget that it is mapped to via the billingId. Once a PretargetingConfig meets or exceeds the budgetAmount set by its Budget, it will no longer receive bid requests for the remainder of the day. Additional information about this resource can be found in the guide.

The Budget resource in the REST API and the BudgetService in the SOAP API can be used interchangeably; however, we recommend that you use the REST API for managing the budgets of your real-time bidding campaigns.

If you have any questions or comments about the Budget resource, please contact us via the forum or our Ads Developer G+ page.

AdWords scripts integrates with more Google services

We’re excited to announce the integration of AdWords scripts with even more Google services, dubbed “Advanced APIs”, allowing you to make use of these Google services directly from your scripts. The current release allows you to connect with:
  • Google Analytics: Update your account based on your website’s performance.
  • Youtube Analytics: Update your account based on your videos’ performances.
  • YouTube: Use YouTube trends or other channels stats to update your account.
  • Big Query : Manage, upload and query big data sets to better optimize your account.
  • Fusion Tables: Store, share and query your data information.
  • Calendar: Set campaign check reminders, enable/pause ads based on events.
  • Task: Manage and read from your Gmail tasks to optimize your account.
  • Prediction: Create, train, and query prediction models on your campaign’s performance data as well as external data sets.
To learn more about advanced APIs, refer to our code snippets and guide.

We encourage you to give this new feature a try and tell us what solutions you would like to have or other API you would like us to add.

As usual please let us know your feedback on the forum - bug reports and suggestions to improve the API usability are most welcome.

Rule-based User Lists in AdWords API v201409

We're excited to announce that you can now create and manage rule-based user lists using the AdWords API starting with v201409. With just one account-wide remarketing tag you can now create different user lists. This has been a frequently requested feature from the AdWords API developer community.

What is a rule-based user list?
A rule-based user list lets you target users based on rules triggered by your account-wide remarketing tag, such as pages viewed on your site or the dates on which your site was visited. The rules in a list can be combined into logical AND/OR expressions, allowing you to fully express the exact audience you want to target.

Once your rule-based user list is in place and you've added the corresponding tag to your site, you can target users in the list and even modify your bids for those users.

Where do I start?
To start integrating rule based lists into your application, take a look at the new Rule Based User List Guide, which will walk you through creating a list with some code examples.

Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.

Change to MccApp.accounts() behavior in AdWords Scripts

In response to your feedback, we are enhancing the MccApp.accounts() method. Starting December 3, 2014, the MccApp.accounts() method will return all accounts (e.g. Express, Video, etc.) that you see when logging in to your MCC account through the AdWords UI instead of just the ordinary AdWords accounts.

Note that once this change is live, your MCC scripts may start getting more accounts when calling the MccApp.accounts() method. You should check your MCC scripts to ensure they can handle the possible extra accounts. You can restrict the accounts that AdWords scripts return by applying an appropriate filter condition in your account selector.

Note that this change doesn’t affect the way other selectors work. For example, you cannot retrieve an AdWords Express campaign by calling AdWordsApp.campaigns() on an AdWords Express account.

If you have questions or feedback about this change, let us know on our developer forum or our Google+ page.

Announcing the release of DFP API v201411

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

Creating VideoRedirectCreatives

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

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

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

Custom targeting filter changes

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

    WHERE status = 'ACTIVE'

LineItem status changes

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

Cross selling features

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

Experimental targeting PQL column

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

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

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

Announcing support for Content API v2 errors in the Merchant Center API Dashboard

We are pleased to announce that the Merchant Center API Dashboard will now also include errors from Content API for Shopping v2. The errors from Content API v1 and v2 are displayed separately, and you can choose either one from the dropdown menu at the upper-left of the Dashboard. Note that if you’ve been using v2 of the API, your dashboard by default will show the Content API v2 errors.



As a friendly reminder, if you haven’t migrated to the Content API for Shopping v2, please start migrating now; v1 will only be available until the end of February 2015. We also have a handy migration guide that can assist you in the process.

If you have any other questions or comments, please don’t hesitate to head over to the developers forum.