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.

Today we’re launching the Ad Exchange Real-Time Bidding Optimization Series on the developer's blog to share updates, best practices and optimization tips with AdX developers. Our goal is to provide knowledge to our clients to help keep their proprietary bidders healthy, successful and evolving. To start things off the first blog post in the series covers post-filtered bids.

When using Ad Exchange, one of the most important factors is ensuring that your bid response is participating in the auction. If the bid response makes it to the auction, it has a better chance at improving win rate: percent of impressions won out of all bids submitted. However, it’s possible that some of your bids may not be entering the auction due to bid response filtering.

We’ll review bid response filters later in this blog entry: what they are, and how to ensure your bid responses are not filtered out. But before we dive in, let’s define bid response filtering.

What is bid response filtering?
Each real-time bid that is submitted to Ad Exchange undergoes a screening process before it can enter the live auction. During this process, your bid may be filtered due to publisher exclusions or incorrect use of the RTB BidResponse protocol. Among other things, we check for malformed URLs, ads that fall into a category the publisher has blocked, or incompatible elements in the bid response (e.g., a buyer who has declared an expandable ads technology vendor, but who has not actually trafficked an expandable ad).

Here is a basic visual representation of the process a bid goes through, including bid response filtering, to make it into the auction and win:

What are the main bid response filters?
As the bid response progresses through the process illustrated above, it might be filtered out by Google, the publisher, or during the actual auction for many different reasons. Each of the main bid response filtering mechanisms are discussed in detail below.

Google Filtered: First, Google will review the bid response to determine if both the ad creative and bid are compliant with Google’s policies and standards. Here are the most common reasons your bid response will be filtered out by Google:
Disapproved ad means that the ad in the bid response was disapproved due to one of several reasons. In order to determine the exact reason for which your ad was disapproved, review your snippet status report. The snippet-status-report-proto.txt file lists all the issues described in the <DisapprovalReason> section of the report. This is usually the culprit when your bid has been filtered out!
Note: The snippet status report will also show ads that have not been checked and are filtered.
And as a proactive measure, the creative REST API provides methods for submitting a creative for verification, for checking the status of a creative that you have submitted, and for retrieving a list of all your active creatives before bidding on the creative ad.

Max CPM is 0 or negative means the bid (max_cpm_micros) set in the bid response was 0 or a negative value. Change the bid to a positive value. If you are not interested in bidding for a particular bid request, be sure to return an empty bid response with the processing time set, not just an empty (0 bytes) response.

Click through URL is too short means for bid responses where html_snippet is set, the click_through_url is less than eleven characters. For example, the URL http://a.b would be too short. Verify that your click_through_url is more than eleven characters.

Click through URL is unparsable means the click_through_url in the bid response is malformed and cannot be parsed. For example, 'http://myad' will not work, since the domain name has to include at least one '.' (period).

Incorrect use of bid response protocol means that there is an improper setting in the BidResponse. In order to determine the proper protocol, review Building the Response and the realtime-bidding.proto.txt file. The realtime-bidding.proto.txt file defines the appropriate settings that should be included in the BidResponse. Examples of incorrect protocol use include: buyer_creative_id not set in the BidResponse or setting both the html_snippet and video_url fields in the BidResponse (only one should be set).

Poor landing page quality means that the landing page was disapproved by Google. Review the landing page of the ad to make sure the website provides a good user experience as measured by:
  • Relevant and original content: The site needs to be relevant and have original content, it should not copy text from another site. 
  • Transparency: The site needs to be very clear on what the business model is and what the information will be used for. 
  • Ease of navigation: The site should be easy to navigate and it should not be intrusive to users. 
Publisher Filtered: Once the bid makes it through Google’s review, it is reviewed again to ensure it adheres to the publisher’s requirements. For each piece of ad inventory, the publisher can add exclusions. Here is a list of the main reasons a bid could be filtered by a publisher:
Sensitive category URL excluded means that the click_through_url in your bid response was either detected or declared with a sensitive category which was excluded by the publisher for this request. In order to determine the sensitive categories for each publisher, you will need to review the excluded_sensitive_category field in the bid request and the publisher settings report. The publisher-settings-proto.txt file lists the categories that are excluded. Your snippet status report will show the sensitive category with which your snippet’s click_through_url was classified by Google.

Product category URL excluded means that the click_through_url in your bid response was either detected or declared with a product category that has been excluded by the publisher for this request. In order to determine the product categories prohibited by each publisher, review the excluded_product_category field in the bid request and the publisher settings report. The publisher-settings-proto.txt file lists the categories that are excluded. Your snippet status report will show the product category with which your snippet’s click_through_url was classified by Google.

Declared vendors excluded means the bid response has declared a vendor_type which has been excluded by the publisher’s ad slot in the bid request. In order to determine the vendor types allowed by each publisher, review the allowed_vendor_type field in the bid request and the publisher settings report. The publisher-settings-proto.txt file will show you the allowed vendors.

Declared attributes excluded means the bid response has declared attributes which were excluded by the publisher’s ad slot in the bid request. In order to determine the allowed_vendor_type per publisher, you will need to review the excluded_attribute field in the bid request and the publisher settings report. The publisher-settings-proto.txt file will list the excluded attributes. 

Auction Filtered: After the bid response passes the Google and publisher reviews, it makes its way to the auction. However, the bid may not enter the auction if it was lower than the publisher’s required min CPM. If this is the case, a ‘Max CPM is lower than the publisher’s min CPM’ message will be generated.
Max CPM is lower than the publisher’s min CPM means the bid response contained a max_cpm_micros value that was less than the publisher’s min_cpm_micros setting. Ensure your bidder reviews the min_cpm_micros required by the publisher per bid request in order to bid properly on the impression. The min_cpm_micros value is listed in the AdSlot section of the bid request, you can review more details in the realtime-bidding-proto.txt file. 

Remember, each bid response that is filtered out is a valuable impression you’ve missed out on. Therefore, 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 
Have questions or want to get a report for your bid response filtering issues? Reach out to your Ad Exchange account team.

Posted by the Ad Exchange Team

Today, we are pleased to announce the launch of v201211 of the DFP API. The focus of this version is on enhancing our API so that you, as a developer, have more options available when encountering API issues. In particular, we’ve added a number of new objects that will help you avoid nondescript SERVER_ERRORs and help work with new features. We’ve also launched the new creative wrapper service and other smaller features, which can all be found on our release notes page.

Improved error handling

Starting today, we’re offering two new enhancements to the API that will make it easier to handle exceptions when calls don’t go as planned. The first addition is the UnsupportedCreative type. Previously, if you tried to fetch a new type of creative using an older version of the API, you might receive a SERVER_ERROR, a “fault occurred while processing” message, or a 502 HTTP error status code. Now, when the API detects that you are fetching a creative that wasn't defined when your API version was released, it will return the creative as an UnsupportedCreative. The returned creative will expose all the fields of the base type and what the unsupported creative type was. You can then search our release notes for announcements of any new creative types to determine which version you should upgrade to, or use the forum to let us know that you are waiting on a new creative type to be released in the next API version.

The second enhancement is the addition of a new enum choice, UNKNOWN, to all existing ApiError types. When you receive an ApiError with UNKNOWN, you’ll be able to log that exception separately (by examining the error in your try/catch blocks) and then let us know on the forum that you received this error so we can help you narrow down what the true cause was. In the future, we’ll be adding UNKNOWN to a few more enums so that if your API version can’t express the actual enum value, you’ll still be able to process as much as you can about the object without having a severe failure.

Note: Both UnsupportedCreative and the UNKNOWN enum choice have been added to all API versions, thus changing the WSDLs for all versions and services. A failed API call would most likely not give you any information; these new changes give you the option to regenerate your client code or download a new version of our client libraries (available soon) to receive the benefits of these changes on existing versions. In versions prior to v201211, unsupported creatives will be filtered instead of returned.

Deprecation reminder

As we mentioned in September, v201108, v201111, and v201201 have been deprecated and will be turned off on December 10th. If you have not upgraded to a newer version yet, now would be a great time to do so. We’ll be more than happy to help with any specific questions on our forum.

Upcoming DFP Google Developers Live (GDL) sessions

On December 5th, we’ll be hosting another GDL session. We’ll be interviewing a few DFP API developers about their integrations and if they have any tips for other developers.

If you haven’t yet, follow us on our Ads Developer Google+ page. We'll be publishing some great tips soon there and would love to hear your requests.

 - , DFP API Team

There’ve been many questions posted to the AdWords API forums regarding the new Shared Budgets feature that was introduced into the AdWords API in version v201209. To help, we’ve put together an FAQ which you can find here.

To aid migration, we've also re-introduced the v201206 behavior that allowed the mutating of budgets via the CampaignService. After v201209 this functionality will be removed.

If you can’t find the answer to your specific question, please post it on the forum or attend one of the AdWords API Office Hours Hangouts. You can also follow our Google+ page for updates about the AdWords API.


We know that you depend on having a free, easy-to-use and robust test environment to test AdWords API clients. We had created the AdWords API sandbox, but it differed enough from the production environment to affect your development and testing. We listened to your feedback of wanting the same versions, features and error messages as the production environment.

As a result, we are introducing test accounts on the production system in place of the AdWords API Sandbox.

The AdWords API Sandbox is now deprecated and will be sunset on Dec 15, 2012. We strongly encourage all developers to obtain a test account to continue testing.

AdWords API Test Accounts

  • Calls made using a test account will be free, so you can develop and debug your applications without spending API units.
  • There will be identical error handling for test and production accounts and hence less time spent troubleshooting bugs or working around differences between the two systems.
  • Test account campaign data has no effect on live campaigns, so you can test campaign management without affecting live campaign data and without serving ads to users.
  • Test accounts do require a developer token. However, an approved token is not a prerequisite to using a test account. So if you are a new developer, you can start experimenting with the AdWords API even while your token is being reviewed.

Getting Started with your Test Account

If you already have an AdWords API developer token, or have recently applied for one, you can obtain a test account, and start testing on the production system. You can find more details about how to get a test account on the AdWords API Developers site.

If you are a new developer and don't have a developer token yet, please apply for a token first. You don't need to wait for your developer token to be approved before using it with a test account.

Again, the AdWords API sandbox will be sunset on Dec 15, 2012. After this date, you will need a developer token, either approved or pending, to test your API clients.

So don't wait, go get your test account, and get on with developing great apps!


Recently, we started cautioning publishers against using GADInterstitial’s loadAndDisplayRequest:usingWindow:initialImage: method with mediation. We saw some odd behavior occurring when publishers used that method. This blog post outlines a way to implement the functionality of this method while avoiding the problems that had been associated with it.

The original method replaced the rootViewController of the window temporarily while the splash image was being shown. Since you have control of your view controllers as the publisher, this step is unnecessary. Assuming you want to show the splash image on app startup, you can place your interstitial code in your rootViewController’s viewDidLoad: method. This method is called after the view hierarchy is loaded into memory.

On a high level, all you need to do is initialize a UIImageView and add it into your view hierarchy in the viewDidLoad: method. To be extra careful, you may also want to hide the status bar while your splash image is being shown.

- (void)viewDidLoad {
  [super viewDidLoad];

  interstitial_ = [[GADInterstitial alloc] init];
  interstitial_.adUnitID = @"MY_INTERSTITIAL_ID";
  interstitial_.delegate = self;

  // Remember whether the status bar was hidden or not.
  hideStatusBar_ = [UIApplication sharedApplication].statusBarHidden;
  [UIApplication sharedApplication].statusBarHidden = YES;
  GADRequest *request = [GADRequest request];
  request.testing = YES;
  [interstitial_ loadRequest:request];

  // Initialize your splash image and add it to the view.
  imageView_ = [[UIImageView alloc] initWithImage:[UIImage  imageNamed:@"InitialImage"]];
  [self.view addSubview:imageView_];

If you only want to show the splash image and interstitial the first time the app is loaded, you can write a boolean into NSUserDefaults and check that boolean before you present the interstitial in viewDidLoad:.

As a final step, you must remove the imageView_ from the view hierarchy once the interstitial comes in. Remember that you also need to remove it if the interstitial fails. To reduce code duplication, you can put this logic into it’s own method.

- (void)restoreController {
  [imageView_ removeFromSuperview];
  // Restore status bar to state it was before hiding.
  [UIApplication sharedApplication].statusBarHidden = hideStatusBar_;

#pragma mark GADInterstitialDelegate

- (void)interstitialDidReceiveAd:(GADInterstitial *)ad {
  NSLog(@"Received ad successfully");
  [interstitial_ presentFromRootViewController:self];

- (void)interstitial:(GADInterstitial *)ad
didFailToReceiveAdWithError:(GADRequestError *)error {
  NSLog(@"Failed to receive ad with error: %@", [error localizedFailureReason]);
  [self restoreController];

- (void)interstitialWillDismissScreen:(GADInterstitial *)ad {
  // Remove the imageView_ once the interstitial is dismissed.
  [self restoreController];

If you have any questions about the AdMob SDK, reach out to us on the forum or join us for our upcoming AdMob office hours. You can also follow us on the Google Ads Developer plus page.

We value our partnership and want to notify you of an important upcoming change for third party ad serving (3PAS) to Google owned and operated properties, including YouTube.

To provide greater security and ensure the privacy for our users, all ads, whether display or in-stream video, that are served to signed-in Google users must be Secure Socket Layer (SSL) compliant no later than January 15, 2013. After this date, the amount of inventory available on Google properties to non-SSL compliant buyers will be limited.


  • DoubleClick Ad Exchange (AdX) buyers must declare that a 3PAS ad is SSL-compliant via Real-Time Bidding (RTB) in the BidResponse or the AdX UI 
  • All 4th-party calls to other technologies must be made from SSL-compliant vendors that have been certified by Google 
  • All video companion banner ads must be SSL-compliant 

Note that if an ad is declared as SSL-compliant but makes any non-SSL-compliant responses, the ad will be disapproved.

RTB Protocol
To identify inventory requiring an SSL-compliant response, the excluded_attribute field (BidRequest.AdSlot.excluded_attribute) will include the value 48, which represents the RichMediaAdsVendor: RichMediaCapabilityNonSSL creative attribute from the dictionary file creative-attributes.txt. If the creative attribute value 48 is not present in the excluded_attribute field, both SSL-compliant and non-SSL-compliant ads can be returned. You should use this field to ensure that your ad serving technology responds properly to bids. This field will be present in BidRequests for both display and in-stream video ads.

User Interface
For 3PAS ads, there will be an additional checkbox in the Ad Exchange UI to declare that an ad is capable of serving both SSL and non-SSL ads. This checkbox will be available soon for both display and in-stream video 3PAS ads and will be un-checked by default.

For non-3PAS ads, there are no changes in the UI.

In-Stream Video
In addition to the above changes, there are specific changes that must be made for In-Stream Video ads to be eligible for SSL inventory:

  • VAST: All VAST (Inline and Wrapper) URLS must serve over HTTPS when the ad request is made with HTTPS. 
  • Media and tracking URLs: All tracking pixels and creative assets (including media files) must serve over HTTPS when the VAST URL is served over HTTPS. 
  • Companion ads: All Companion banners, including any 4th-party calls, must serve over HTTPS when the VAST URL is served over HTTPS.

We understand that this change places additional burden on your team and we will do our best to help you through this process. In the interim, please do not hesitate to contact your Google technical account manager with any questions.

Posted by the Ad Exchange Team


Some API users have noticed a difference between the search volume numbers returned by the TargetingIdeaService in versions v201206 and later compared to earlier versions and the user interface.

When running a query of 'STATS' request type with the latest API version, you will typically get a higher number for search volume compared to the user interface. The reason for the difference is that the volume returned by the latest API includes Search Partners data in its calculation, while the UI and the older API versions don’t have this metric available.

We understand this change may have caused confusion for some customers and we plan to include an option to choose which networks to account for in future API versions.


We understand the importance of documentation when navigating a system as complex as the AdWords API. For this reason, we would like to remind you about the reference materials available on our Developers site

First off, we’ve updated the Selector Fields page that provides information about the fields that can be used in generic selectors. This information is available on an object’s individual reference page, but we’ve collected it together across entire services for quicker lookups.

Next, we’ve added more columns to the Report Types page to include a field’s type, its behavior, and its XML and display names. The behavior of a field in the generated report describes its effect on zero impression rows as well as whether the field represents historical data or the latest object state.

Finally, we’ve added new tips to our Best Practices Guide on topics such as grouping batch job operations by ad groups and campaigns and using the partial failure feature. The guide is a great resource for developers starting an AdWords API project, but is also useful for established developers trying to increase the efficiency of their applications.

There is a feedback link on the top right hand corner of every page where you can report documentation issues. For technical help, visit our forum or office hours. You can also follow the Google Ads Developer page for all Ads-related updates.


Today we’re happy to announce the launch of the new DoubleClick Ad Exchange Seller REST API. With it, you can list your inventory and programmatically run reports, opening up possibilities such as:
  • checking out how much money you made last month, on your phone
  • adding stylish charts to your earnings reports
  • making your own reporting interface, suited to your specific needs
  • using real ad unit or channel performance data in your internal systems, to help with business decisions.
This API, like all of our new APIs, is built on the same RESTful, standards-based technology stack you’re used to. This means you have access to all sorts of useful tools for trying out the API, such as the APIs explorer (which is also built into the documentation for each method), and our generic, cross-API client libraries.

Give it a try, and let us know if you have any questions!

Editor’s note: "reposting from Google Mobile Ads Blog post by Morgan Hallmon." -- Stan Grinberg, Ads Developer Relations Team

Apps are a powerful way to keep your most loyal users engaged, and can also be a real driver of revenue for marketers big and small. When advertising apps, the key is to know what’s working and what’s not. While advertisers have already been able to measure their Android app downloads within AdWords, we’ve now launched the ability to track iOS downloads that were driven by in-app display ad campaigns.

To set up iOS conversion tracking, advertisers need to create a single code snippet in their AdWords account and install it in their app. This snippet is accessible in the AdWords interface in the same place where advertisers have been able to codelessly track Android downloads. With iOS conversion tracking, marketers can better understand which campaigns are most effective at driving app downloads. These enhanced insights help marketers iterate on app promotion strategies to reach their return on investment goals, with the help of features like the Conversion Optimizer for apps.

Figuring out what ads are working is key for marketers like Sho Masuda, Vice President of Player Marketing for GREE, a leading mobile social game app developer. GREE has used click to download and in-app advertising solutions with AdWords to promote their app, and Masuda says, "Google’s host of tracking and optimization tools help us quickly iterate and maximize ROI across our app promotion campaigns. iOS conversion tracking will help us gain even deeper insights into our Google app promotion efforts for our iOS apps.

If you’d like to learn more about how to track value beyond the app download, you can watch a recording of our Learn with Google webinar “Understanding your App Users with Google Analytics” here.


Since releasing version 6.2.0 of our Android SDK on Tuesday, we have identified a high priority bug which causes apps to crash when our SDK returns certain types of ads. We’ve made a server-side fix which stops the crash-inducing ads, and are also issuing an SDK hotfix to prevent any similar issues from happening in the future.

Please download the new 6.2.1 SDK here and update your apps at your earliest convenience. And Happy Friday from AdMob!

Posted by Chrix Finne, Product Manager

This is a reminder that on Friday October 26th, 2012, the following versions of the AdWords API will be sunset:
  • v201109
  • v201109_1
Calls made to these versions after Friday October 26th, 2012 will fail. It is therefore critical that you migrate to AdWords API v201206 or later if you want your applications to continue to run without interruption.

If you have any questions about these sunsets or about the AdWords API in general, please post on the forum. Follow our Google+ page for updates about the AdWords API.


Good news, everyone! Version 1.2 of the AdSense Management API is now available, and with it come two new features:
  • the ability to retrieve saved ad styles
  • the ability to retrieve and run saved reports

In addition, we’ll soon be deprecating versions 1.0 and 1.1. These will both be sunset six months from now, on April 17, 2013. Migration to the new version should be extremely simple, since version 1.2 is a superset of both previous versions, with no breaking changes.

If you have any questions or comments, let us know in the forum!


We’re excited to announce the release of the AdMob SDK v6.2.0 for Android and v6.2.1 for iOS. The iOS update is mostly a bugfix release, but now requires you to link against the StoreKit framework, which will allow us to experiment with innovative ad experiences. The Android release includes changes to DFP App Events and Custom Events that we’ll discuss below.

DFP App Events

The Android AppEventListener interface has changed slightly to include the ad that fired the app event. The new interface definition is:

public interface AppEventListener {
  void onAppEvent(Ad ad, String name, String info);

If you previously implemented onAppEvent(String name, String info), you’ll have to update this method signature when upgrading to v6.2.0.

Custom Events

Due to popular demand, we’ve added the ability to pass information to your custom event. We’ve also added a destroy() method so you can clean up your custom event. The new CustomEventBanner interface definition is:

public interface CustomEventBanner extends CustomEvent {
  void requestBannerAd(CustomEventBannerListener listener,
                       Activity activity,
                       String label,
                       String serverParameter,
                       AdSize size,
                       MediationAdRequest mediationAdRequest,
                       Object customEventExtra);
  void destroy();
The customEventExtra object is sent to your custom event by creating an instance of CustomEventExtras and passing it to the AdRequest. The following example sends the string “hello custom event” to your custom event class:
final String CUSTOM_EVENT_LABEL = “MyCustomEventLabel”;
AdRequest adRequest = new AdRequest();
CustomEventExtras extras = new CustomEventExtras();
extras.addExtra(CUSTOM_EVENT_LABEL, "hello custom event");

When calling CustomEventExtras.addExtra(), make sure the key is the same as the label of the custom event you defined in the AdMob UI. The AdMob SDK searches CustomEventExtras for the object corresponding to the label of the custom event, and invokes requestBannerAd on your custom event class with that object. You can call addExtra() for each custom event class you have, and AdMob Mediation will send the appropriate object to the custom event it invokes. If AdMob can’t find an object for your custom event label, it will pass null to requestBannerAd().

A destroy() method has also been added to the custom event interface so you can perform any necessary cleanup. The AdMob Mediation framework will invoke destroy() when it refreshes the AdView.

Check out the release notes for the full list of changes in this version. If you have any questions about the latest AdMob SDK, please reach out to us on the forum or join us for AdMob office hours. You can also follow us on the Google Ads Developer plus page for AdMob-related updates.


With November on the horizon, we’d like to remind DFA API users of two important upcoming changes. Both of these changes were previously announced in August.

Java DART API Version Enforcement

To give you the best experience connecting to ReportCentral, it has become necessary to stop supporting older versions of the Java DART API. Starting November 3rd, 2012, we will only accept requests from the 3 latest versions, which are currently 13.4, 13.6, or 13.8. We have continued to improve our DFA Reporting API and still recommend all users switch to this new offering as soon as possible.

Removal of our Deprecation Policy

Also on November 3rd, 2012, our deprecation policy will no longer be in effect. Our commitment to our APIs and our users remains strong, and we will strive to announce all changes to our APIs long before they launch.

Please feel free to post any questions or concerns you may have on our forum.

In an effort to continue to improve report download functionality in the AdWords API, we’ve made some changes in v201209 to improve error handling and debugging for developers. In a future release, we also plan to separate API downloads from UI downloads to make the downloaded reports easier to work with for developers.

In v201209 we’ve introduced a new XML format for report download errors. Currently, we return a text string with the error message embedded within it. For example, if you mispelled the field Date as Datee:

!!!2|||-1|||ReportDefinitionError.INVALID_FIELD_NAME_FOR_REPORT @ ; trigger:'Datee'???

In v201209, this error will be returned in this XML format (HTTP response codes will remain unchanged):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

The new error reporting format will make it easier to handle report download failures. If you’d like to preview these changes, you can pass this special HTTP header when downloading reports for versions prior to v201209:

apiMode: true

Support for this new XML error format will be added to client libraries for v201209. We’ve also published an XSD including this new report download error XML at:

For v201209, you can see it here. Some other things to keep in mind with these new changes:
  • Remember to make sure you provide the version in the report download URL. With the next major release (and when specifying this new HTTP header), version will be required when downloading reports.
  • AdHoc reports must be used - it will no longer be possible to download by reportDefinitionId.
If you have any questions about this new XML format or the AdWords API in general, please post on the forum. Follow our Google+ page for updates about the AdWords API.

Update: The sunset of v201206 is now moved to March 25th, 2013.

We’re pleased to announce the launch of AdWords API v201209, which includes the ability to share budgets across multiple campaigns, set up demographic targeting at the ad group level, opt into a rotate indefinitely option for ad text, as well as some reporting changes that make errors clearer. Below we’ve highlighted some of the new features available to all users. A complete list of changes is available in the release notes.

v201209 highlights:

  • Shared budgets - The AdWords API now supports sharing budgets across campaigns through the new BudgetService and top-level Budget entity. All budgets are now potentially shareable so you need to first create a budget that is not associated with any particular campaign, and then assign campaigns to this budget via CampaignService. 
  • Rotate indefinitely - CampaignService now has a fourth option for the ad rotation setting called ROTATE_INDEFINITELY. Read more about it in this announcement
  • Ad group-level demographic targeting - Demographic targeting criteria (Age Range and Gender) are now available at the Ad group level (positive and negative). Note that you can continue to set negative targets at the Campaign level. 
  • Reports - A new XML format is being introduced to report download error responses that makes it easier to parse the error messages. Also, report downloads using reportDefinitionId are no longer supported, and a valid AdWords API version must now be supplied in the URL for all report download requests. 

With the release of v201209, we are deprecating v201206 and sunsetting it at the end of February 2013.

As with every new version of the AdWords API, we encourage you to review the resources in the release notes. If you have any questions please post on the forum or attend one of the AdWords API Office Hours Hangouts.

- The AdWords API Team


An authorization method is a scheme the client application uses to gain access to account information. AdWords, DoubleClick Ad Exchange Buyer and DFP APIs support several authorization methods including ClientLogin, OAuth1.0a and OAuth2.0. If you are still using an email address and a password to access the API, you are using the ClientLogin method which is now deprecated and is scheduled for sunset.

In a previous blog post we’ve covered general aspects of OAuth2.0 authorization and its benefits. To describe the process in more details, we’ve created a new article that shows how to use it with our official Ruby client library.

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.


The recently released Version 2.0 of cocos2d for iPhone deprecated the use of RootViewController in cocos2d projects. Previously, we showed you how to integrate AdMob ads by leveraging the RootViewController. Here, we show you the updated way of integrating AdMob ads into cocos2d v2.0 projects.

All of your initialization can now be done in the layer where you’d like the ad to show. In your layer’s init function, you can set up your ad banner as you would normally.

-(id) init
    // Do other layer initialization here.

    adBanner_ = [[GADBannerView alloc] initWithAdSize:kGADAdSizeBanner];
    adBanner_.adUnitID = @"YOUR_ADMOB_PUBLISHER_ID";
    adBanner_.delegate = self;

The tricky part here is setting the rootViewController property for your GADBannerView and putting it into your view hierarchy. Version 2.0 of cocos2d uses a UINavigationController as its top-level view controller. The main OpenGL view is placed inside this controller. You want to set your rootViewController to be the main navigation controller.

AppController *app = (AppController*) [[UIApplication sharedApplication] delegate];
[adBanner_ setRootViewController:[app navController]];

There are performance considerations to think about when adding a GADBannerView into your hierarchy. Overlaying UIKit layers on top of OpenGL layers can lead to lower frame rates for apps that draw often. However, with newer hardware, this performance decrease is less of a concern. As always, we recommend that you profile your application’s performance to determine what works in your situation.

For our example, we will add the GADBannerView on top of the OpenGL view. This involves accessing the view being shown from the sharedDirector object.

[[CCDirector sharedDirector].view addSubview:adBanner_];

Remember that since you are creating GADBannerView objects, you will have to clean them up with dealloc as well.

- (void) dealloc {
  adBanner_.delegate = nil;
  [adBanner_ release];
  [super dealloc];

You should now see AdMob ads show up in your cocos2d application. If there are any other integration topics you would like to see, or any technical questions you have, please let us know about them on the forum or check out our G+ page.


A new release of the DFA Reporting API, version 1.1, extends the ability of your applications to tap into the power and flexibility offered by our new reporting platform.

Feature Parity with ReportBuilder

Using the DFA Reporting API, you can now take advantage of all of the report types in ReportBuilder:


The API contains support for CROSS_DIMENSION_REACH reports, but the backend currently does not. Support for these reports will be turned on at a later date and will be accessible through version 1.1.

Additionally, you may now set a list of recipients to be emailed when a scheduled report runs. We have paved the way for downloading reports in different formats, though currently CSV is the only available option.

A Few Backwards Incompatible Changes

We have taken the opportunity to make a few backwards incompatible changes to the API. It will not be standard procedure to make changes like this in minor version releases, but since the API is still relatively new, locking down the final structure of our API now will reduce changes later and ease development. These changes include:

  • Report files and report criteria now share the same dateRange kind.
  • The urls object in the File resource has changed to support report formats other than CSV.
  • A customRichMediaEvents and an activities kind have been added, both of which are reused between different report types.

Our updated release notes page has a full list of changes for your reference. As always, we highly value your feedback and questions. Please join us on our forum whenever you’d like to reach us.


Today, we released v6.2 of the AdMob SDK for iOS developers. This release includes a number of bug fixes as well as some important changes for iOS 6 and the iPhone 5. This post will go through some important differences developers should keep in mind when working with AdMob v6.2. All of our developer docs have already been updated to reflect these change.

XCode 4.5 and iOS 6

We’ve made a number of changes to add support for both iOS 6 and the iPhone 5. This means that you will need to use XCode 4.5 and build against iOS 6 when using our SDK. You can still support down to iOS 4.3 by setting your “Deployment Target” to iOS 4.3 in your project’s Application Target.

Support for armv7s

The iPhone 5 is powered by the A6 processor which uses the armv7s architecture, so targeting armv7s will optimize your app to run on iPhone 5. We’ve dropped support for the armv6 architecture and added support for the armv7s architecture in this release (we also still support armv7). New projects created via XCode 4.5 default to supporting armv7 and armv7s, meaning that this shouldn’t be an issue as long as you’re using the correct version of XCode.

If you’re targeting the armv7s architecture, you will not need to add the -all_load linker flag to your projects anymore. If you were using this specifically for AdMob, you can now safely remove the flag from the “Other Linker Flags” section of your project’s “Build Settings”. You will still need to have the -ObjC linker flag in this section.

Identifier for Advertising

We are now also using Apple’s Identifier for Advertising for personalization and reporting. You will have to link against the AdSupport framework in your applications when using the AdMob SDK in order to support this feature. You can do this by adding the AdSupport.framework to the “Linked Framework and Libraries” section of your application’s Target settings. Make sure that you link the framework using the “Optional” setting if your application can run on an iOS version below iOS 6.

Auto Layout Support

Apple introduced Auto Layout for iOS 6 to help support multiple screen sizes. All of our AdMob banners have been updated to work with Auto Layout. When using Auto Layout (in code) with a GADBannerView, you must:

  • Remember to set the translatesAutoresizingMaskIntoConstraints property on the GADBannerView to NO
  • Make sure the GADBannerView’s frame is big enough to receive the ad type requested

We will release some sample code showcasing best practices when using Auto Layout very soon.

You can download the latest SDKs from our downloads page. If you’ve got any other questions or concerns about using the new AdMob SDK, please ask us in the forum or check out our G+ page.


Last week, we caught up with Vishay Nihalani from the AdMob team in Mountain View, CA. Vishay is the Product Manager for the AdMob Mediation effort here at Google. Mediation helps developers easily integrate and manage multiple ad networks into their Android and iOS applications. Vishay was able to provide some useful insight on why AdMob built mediation, what the benefits are, and what to expect in the future. Let’s find out what he had to say.

Hello, Vishay. Thanks for taking the time to talk to us about AdMob Mediation! Can you tell us what prompted AdMob to develop a mediation framework?

That’s a great question. When Google acquired AdMob, we also acquired AdWhirl, an open source ad mediation solution that helped developers fill every ad request instead of only a few requests. The popularity of AdWhirl made it clear that mediation was something that developers wanted.

At Google, we decided to take the concept of AdWhirl a step further by integrating mediation directly within AdMob, allowing us to scale the product and add new features that developers need.

What is the benefit of switching to AdMob Mediation?

Developers should use mediation to make sure that no ad request goes unfilled. AdMob mediation in particular has some cool features that help you to maximize your revenue by using the highest paying networks first. Since many networks tend to focus on specific regions, AdMob allows you to set eCPM values at the country level as well.

Like AdWhirl, AdMob Mediation is free no matter how many impressions you serve, allowing you to scale your app and take full advantage of this feature.

Should I still use mediation if I’m only using AdMob?

Mediation is largely geared for multiple networks, but there are advantages to using mediation even if you’re only using AdMob. Using mediation, you can quickly serve house ads to all your users. You can use mediation to add a promotion advertising campaign for a new app you’ve just launched before showing a network ad, or to promote your other apps if the AdMob network has no ad to fill your request.

Why did AdMob decide to do client-side mediation as opposed to server-side integration?

One of our main goals with AdMob Mediation is to scale to as many ad networks as possible. Not all ad networks have server side APIs, and we didn’t want to have this barrier to joining our mediation offering.

Another huge benefit to client-side mediation is that it is transparent and neutral. Any third party network can easily plug into AdMob Mediation, and all interactions between the third-party SDK and the third-party ad server is completely independent of AdMob. A good example of this is the skyscraper format - even though the AdMob network doesn’t offer skyscraper ads, AdMob Mediation still supports third-party ad networks who want to serve skyscraper ads through mediation.

Finally, doing client-side mediation allows us to easily add new partners. We don’t have to wait for the next AdMob SDK release cycle to launch them.

Can you tell us about any new features coming to AdMob Mediation, or where the product is headed?

We’re planning to make it even easier to integrate mediation into your application by making all ad network placements mediated by default. This means you won’t need to swap out IDs when you switch to mediation. We want to make it easier to help maximize your revenue, and we have some features in the works that we think developers will be excited about!

Enough about mediation...Tell us about some of your hobbies/interests outside of work.

I play a ton of soccer and I love to travel. Sometimes I even travel to watch soccer. I attended the World Cup in 2010, and I’ve already blocked off my calendar for Brazil 2014!

Wow, that’s exciting! Other than the World Cup, what was the most exciting part about visiting South Africa?

I went shark cage diving with great white sharks not far from where the Indian and Atlantic oceans intersect. There was this intense moment where a great white was lured in by the bait and was thrashing at a tuna’s head about a foot away from my face! It was a serious Jaws moment.

Thanks for the interview, Vishay. Now get back to work and help us make more money!