There are a number of ways interstitials can be incorporated into applications that play video. One common integration we’ve seen is displaying the interstitial right before a video is played. This blog post will show you how to do this on iOS.

Set Up Your Video Player

For this specific example, we’re going to use MPMoviePlayerController. This class makes it easy to integrate video playback into your iOS application. However, make sure not to use MPMoviePlayerViewController as we want to have control over our own view controller.

- (void)viewDidLoad {
  [super viewDidLoad];
  NSURL *bundleURL = [[NSBundle mainBundle] bundleURL];
  NSURL *movieURL = [bundleURL URLByAppendingPathComponent:@"Video_Name_Here.mp4"];
  player_ = [[MPMoviePlayerController alloc] initWithContentURL: movieURL];
  //  Don’t add the player_ into the view hierarchy yet
  [player_.view setFrame:self.view.bounds];  // player's frame must match parent's
  player_.controlStyle = MPMovieControlStyleFullscreen;
  [[NSNotificationCenter defaultCenter]

We add an observer at this point to tell us when the movie is done playing. This is typically when our view controller will transition away from the MPMoviePlayerController’s view.

Set Up Your Interstitial

Set up a GADInterstitial object as you normally would and and call loadRequest: at an appropriate time in your application flow. Present the interstitial once it comes back.

- (IBAction)showMovieInterstitial:(id)sender {
  self.interstitial = [[[GADInterstitial alloc] init] autorelease];
  self.interstitial.delegate = self;
  self.interstitial.adUnitID = @”YOUR_IDENTIFIER_HERE”;
  [self.interstitial loadRequest: [GADRequest request]];

- (void)interstitialDidReceiveAd:(GADInterstitial *)interstitial {
  [interstitial presentFromRootViewController:self];

The trick here is that after you receive and present your interstitial, you’re going to have to add your MPMoviePlayerController’s view into your view hierarchy. You want to make this look seamless so that as the interstitial is dismissed, the movie player looks as though it is in the background. This means making the view hierarchy change in interstitialWillDismissScreen: (called before the interstitial is dismissed).

- (void)interstitialWillDismissScreen:(GADInterstitial *)interstitial {
  [self.view addSubview:player_.view];

If you’re auto-playing the video, you don’t want to start playing in interstitialWillDismissScreen: as the user will miss a part of the video when the dismissal transition happens. Instead, you can play the movie in interstitialDidDismissScreen:.

- (void)interstitialDidDismissScreen:(GADInterstitial *)interstitial {
    [player_ play];

Remember that you have to unregister for notifications when you are cleaning up your MPMoviePlayerController as well.

- (void)dealloc {
  if (player_) {
   [[NSNotificationCenter defaultCenter]
    [player_.view removeFromSuperview];
    [player_ release];
    player_ = nil;
  interstitial_.delegate = nil;
  [interstitial_ release];
  [super dealloc];

Let us know on the forum if you have any questions about interstitials specifically or the Google AdMob SDK in general. You can also follow us on our plus page for AdMob-related updates.

In the AdSense Management API and AdSense Host API, you can let us manage date calculations for you. Apart from the standard YYYY-MM-DD format, all date fields accept the following special keywords:
  • today
  • startOfMonth
  • startOfYear
With these keywords you can define useful date ranges such as the following:

Start date End date
This month’s performance so far startOfMonth today
This year’s performance so far startOfYear today

But here is the really useful part: there is a handy feature that you can use to calculate relative dates by adding or subtracting days, weeks, months, or years:

Start date End date
Last 7 days’ performance today-6d today
Last month’s performance startOfMonth-1m startOfMonth-1d
Previous six months startOfMonth-6m startOfMonth-1d

You can use up to two operations per date. Let’s say we need to compare last month with the same period last year. We would need two requests like these two requests with these start and end dates:

Start date End date
Last month’s performance startOfMonth-1m startOfMonth-1d
Same month last year startOfMonth-1m-1y startOfMonth-1d-1y

If you want to try these out, we recommend using the APIs explorer. You’ll find it at the bottom of each method documentation page:
If you have any questions about this post or the AdSense APIs in general, visit the AdSense API Forum. You can also follow our Google Ads Developers G+ page for ad-related updates.


App Events, a feature introduced in v6.1.0 of the AdMob SDK, provides DFP developers the ability to create ads that can send messages to their application code. The application can listen for and react to these messages by executing custom code.

This powerful feature lets you do some pretty cool things, such as sending the entire creative code to the app, or telling the app what ad is running. In this example, we’ll show how the app can change background colors when it receives an app event.

The first step is to set up your creative in DFP. The sample below is a 320x50 creative which sends a color=red event when the ad is first displayed, and a color=green event when the ad is clicked.

  <script src="//"></script>
    // Send a color=red event when ad loads."color", "red");
    handleClick = function() {
      // Send a color=green event when ad is clicked."color", "green");
    #ad {
      width: 320px;
      height: 50px;
      top: 0px;
      left: 0px;
      font-size: 24pt;
      font-weight: bold;
      position: absolute;
      background: green;
      color: red;
      text-align: center;
  <div id="ad" onClick="handleClick()">Happy Holidays!</div>

The creative above references the AdMob API for Ads JavaScript, and calls to send app events. You can check out an example of the creative below, and view the developer console to see logging statements when the app events are being fired.

The next step is to have the application code listen for these app events. Here are the iOS and Android versions of this method, respectively:

// iOS
- (void)adView:(DFPBannerView *)banner
    didReceiveAppEvent:(NSString *)name
    withInfo:(NSString *)info {
  NSLog(@"Received app event (%@, %@)", name, info);
  // Checking for a "color" event name with information being a color.
  if ([name isEqualToString:@"color"]) {
    if ([info isEqualToString:@"red"]) {
      self.view.backgroundColor = [UIColor redColor];
    } else if ([info isEqualToString:@"green"]) {
      self.view.backgroundColor = [UIColor greenColor];

// Android
public void onAppEvent(Ad ad, String name, String info) {
  String message = String.format("Received app event (%s, %s)", name, info);
  Log.d(LOG_TAG, message);
  if ("color".equals(name)) {
    LinearLayout layout = (LinearLayout) findViewById(;
    if ("red".equals(info)) {
    } else if ("green".equals(info)) {

Remember to register this callback on the banner view:

// iOS
[bannerView_ setAppEventDelegate:self];

// Android

That’s it! If you load this ad into your banner view, your application will change its background color to red when the ad is loaded, and green when the ad is clicked. This example can be extended to change the implementation of the app event listener or to fire app events at any point during the creative’s lifecycle.

Let us know on the forum if you have any questions about app events specifically or the Google AdMob SDK in general. You can also follow us on our plus page for AdMob-related updates.

Edit: Fixed plus page link.

Despite the fact that winter is upon us, DFP API developers are resisting the urge to slow down their integration efforts. We continue to see increased traffic on the forum and hear about new integrations nearly every day. To keep this momentum going and keep you up to date on the DFP API we'd like to share two exciting developments with you.

Yesterday we announced the DFP Third Party Partner Directory on the DFP Product blog. This listing is available to all our publisher partners and let's them know about all the great innovative products available from our DFP developer ecosystem. To get your solution listed as one of our preferred DFP partners integrate with the DFP API and submit an application to this form.
Second, for those of you still thinking about integrating with DFP, check out our recent hangout with Yieldex or tune in to Google Developers Live today to join in the discussion with maanto. Come hear directly from your peers as they describe the experience of working with the new API. We hope to see you there.

As always, let us know if you want to see any new features or blog posts on our forum.

We’ll soon be sunsetting v1.0 and v1.1 of the AdSense Management API so we encourage you to migrate to v1.2 as soon as possible. To get you started, follow this simple guide.

If you don't use the client libraries you need to replace the version on the base URL that you are using:
That will allow you to continue using the API as you were and should require no further modifications to your code.

If you use the client libraries, what you need to do depends on the language you use:
  • Java
    Download the latest client libraries and replace your project dependencies.
  • PHP
    Make sure you get the latest files from the trunk of the repository. You may only need to replace trunk/src/contrib/Google_AdSenseService.php but you should update all the files you use.
  • Python
    Good news for you! No need to download any libraries, the discovery service knows what to do. Create the service as follows:
    http = httplib2.Http()
    service = build("adsense", "v1.2", http=http)
  • C#
    Download the latest client libraries and replace your project dependencies.
To make sure you’re using the latest version, list your saved ad styles. It’s a new feature only available to v1.2, so if you don’t get an error, you’re on the right track.

To learn about the AdSense Management API read the docs and post your questions on the AdSense API Forum and we’ll do our best to help you! Also, follow our Google Ads Developers G+ page to receive important announcements and tips.


With the AdWords API v201206 launch we announced support for the Flexible reach targeting setting. This targeting enables advertisers to fine tune where ads are shown by choosing settings at the ad group level instead of the campaign level.

The new setting is already applied to all campaigns created since the release. As API versions prior to v201206 have been sunsetted now, we are working to upgrade all outstanding campaigns to use Flexible targeting. This change will be introduced gradually on the server side to all legacy campaigns. Please ensure your client applications are fully compatible with API version v201206 and later, and work properly with Flexible reach targeted campaigns.

You can easily determine if a campaign is still using legacy targeting by checking the value of the useAdGroup property in TargetRestrictSetting. To manually switch such a campaign to the new targeting:

  • Send a CampaignService mutate request with SET operation updating the setting to true.
  • Run an AdGroupService mutate request to specify the targeting type you want.

The targetAll value determines if the targeting is broad (true) or specific (false) for the given CriterionTypeGroup. Note that this upgrade is a one-way operation—once enabled Flexible targeting can't be disabled.

As always, please feel free to ask any questions regarding the client libraries or the AdWords API on our forum or during scheduled office hours. You can also follow the Google Ads Developer page for all Ads-related updates.


We recently announced that the Java DART API now has version limitations placed upon it. Going forward, we are going to only support the 4 most recent versions of this API. With a release cycle of approximately 3 months, this translates into one required update per year. Now that you may need to migrate to a newer version, we will be posting release announcements on this blog to keep you up to date.

Java DART API Releases Version 14.2

A new version of the Java DART API is now available: 14.2. There are no changes pertinent to DFA developers in this release. Since this is now the fourth officially supported version, no one needs to migrate to a newer version of the Java DART API at this time.

We strongly recommend you migrate from the Java DART API to the DFA Reporting API, our new reporting platform, at your earliest convenience.

DFA API v1.18 Sunset Pushed Back

We previously announced that version v1.18 of the DFA API would be sunset in December. This sunset has been pushed back until after the holiday season. You should still migrate to v1.19 as soon as possible in order to future-proof yourself, but no immediate action is required at this time. The new sunset date for v1.18 will be announced on this blog at a later date.

All of your questions are always welcome on our forum.


AdWords allows you to target your ad groups to people of specific ages and genders on Google’s Display Network. Version v201209 of the AdWords API adds support for this feature.

To enable demographic targeting in an AdGroup, add a Gender or AgeRange criterion using the AdGroupCriterionService. You can target a criterion by adding a BiddableAdGroupCriterion, and exclude one using NegativeAdGroupCriterion. You can use the bid property of BiddableAdGroupCriterion to set a bid for a specific gender or age range. The following C# code snippet shows the concept in action, where we target male users with a specific CPC of two dollars and exclude users of age range between 18 and 24 years old.

// Create biddable ad group criterion for gender, male. See
// for
// criteria ID.
Gender genderTarget = new Gender(); = 10;
BiddableAdGroupCriterion genderBiddableAgc = new BiddableAdGroupCriterion();
genderBiddableAgc.adGroupId = adGroupId;
genderBiddableAgc.criterion = genderTarget;

// Set a specific bid for male.
ManualCPCAdGroupCriterionBids bid = new ManualCPCAdGroupCriterionBids();
bid.bidSource = BidSource.CRITERION;
bid.maxCpc = new Bid();
bid.maxCpc.amount = new Money();
bid.maxCpc.amount.microAmount = 2000000;
genderBiddableAgc.bids = bid;
// Create negative ad group criterion for age range 18 to 24. See 
// for
// criteria ID.
AgeRange ageRangeNegative = new AgeRange(); = 503001;
NegativeAdGroupCriterion ageRangeNegativeAgc =
    new NegativeAdGroupCriterion();
ageRangeNegativeAgc.adGroupId = adGroupId;
ageRangeNegativeAgc.criterion = ageRangeNegative;
// Create operations.
AdGroupCriterionOperation genderBiddableAgcOp =
    new AdGroupCriterionOperation();
genderBiddableAgcOp.operand = genderBiddableAgc;
genderBiddableAgcOp.@operator = Operator.ADD;
AdGroupCriterionOperation ageRangeNegativeAgcOp =
    new AdGroupCriterionOperation();
ageRangeNegativeAgcOp.operand = ageRangeNegativeAgc;
ageRangeNegativeAgcOp.@operator = Operator.ADD;
// Add ad group criteria.
AdGroupCriterionReturnValue result = adGroupCriterionService.mutate(
    new AdGroupCriterionOperation[] {genderBiddableAgcOp,

The criteria IDs for gender and age range are available from and respectively.

When targeting by demographics, you can choose to target or exclude people whose age or gender haven’t been identified, by targeting the Undetermined category. However, keep in mind that Google doesn't infer demographics for all people, and most websites don't provide demographic information for their customers. In addition, some websites on the Display Network opt out of demographic targeting. Excluding the Undetermined demographic category might prevent a substantial number of people from seeing your ads. So, we recommend that you exclude this category only if your campaign results indicate that you should.

If you have any questions about this new feature or the AdWords API in general, you can ask us on our developer forum, or at the upcoming live office hours with the Developer Relations team. Follow our Google+ page for updates about the AdWords API.


We recently announced several changes and improvements to the way we report AdWords impression share (IS). We are now making these changes available through the v201209 version of AdWords API reports as well.

Around the second week of December, the following new columns will be available for account, campaign and adgroup performance reports:

  • ContentImpressionShare
  • ContentBudgetLostImpressionShare
  • ContentRankLostImpressionShare
  • SearchBudgetLostImpressionShare
  • SearchExactMatchImpressionShare
  • SearchImpressionShare
  • SearchRankLostImpressionShare

We now provide distinct search and display columns, so you can clearly separate search and display impression share. We also support “Hour of day” segmentation to evaluate how your ad coverage varies by the hour. You can get hourly segmentation of impression share data by requesting the HourOfDay column in your reports.

Finally, we’re improving the accuracy of how we calculate impression share data. As previously mentioned on our product blog and via social media, historical IS reporting data is now only available going back to October 1, 2012.

Phasing out old IS columns in February 2013

With the new IS columns now available, we’re planning to phase out the old IS columns (BudgetLostImpressionShare, ExactMatchImpressionShare, ImpressionShare and QualityLostImpressionShare) in February 2013.

If you face any issues with the above changes or have any questions about the AdWords API, you can ask us on our developer forum, or at the upcoming live office hours with the Developer Relations team.