Tag Archives: AdSense

Easier Upgraded URL migration with Feed and FeedMapping modifications

With destination URLs becoming read-only on July 1, 2015, we’re making your migration to Upgraded URLs simpler. If you come across some extra attributes in Feed and FeedMapping, there’s a good reason for that.

We’re helping you skip the approvals process for existing site links during migration by modifying your Feeds and FeedMappings behind the scenes. The changes are already available, and you should see extra attributes in each of your Feeds and FeedMappings.

Expect to see attributes in Feeds with these FeedAttribute names:
  • SitelinkFinalUrls
  • SitelinkFinalMobileUrls
  • SitelinkTrackingUrl
The FeedMapping attributeFieldMappings now have extra AttributeFieldMappings related to these Sitelinks Placeholders:
  • FINAL URLS
  • FINAL MOBILE URLS
  • TRACKING URL
Your sitelink feeds are now compatible with the new Upgraded URLs.

Questions? Visit us on the AdWords API Forum or our Google+ page.

Nadine Sundquist, AdWords API Team

Help us help you with your DFP API questions

If you’re a DFP developer using our API, no doubt you’ve had a question or two at some point during your integration with DFP. You’ve probably visited the DFP API forums, if not posted to them. Today we just wanted to remind you of a few simple things you can do to help us answer your API questions more efficiently.

Let us know who you are

Including the following information with every question you ask helps reduce the turnaround time for your question:

Send us SOAP logs

SOAP logs contain the raw XML that describes the requests and responses of the API calls you make. These logs can help narrow down issues much faster. If you’re using one of our client libraries, you can visit its GitHub page to learn how to enable logging. For example, Java’s is here.

Here are some additional tips around SOAP logging.

  • When sending us logs, try to send the minimal amount of SOAP logs that clearly show the error or issue that’s occurring. If you send your entire SOAP log for the day, it’ll take longer for us to go through and increase your turnaround time.
  • If you’re seeing errors in your production environment and don’t have full SOAP logging enabled due to space constraints, consider logging only request IDs from the SOAP response instead. Not all errors will necessarily have a request ID, but if they do, that ID can help us look up your error.
  • If you’re not comfortable posting SOAP logs on the forums, you can either (1) paste a snippet of your code instead, or (2) reply directly to us by using reply privately to author.

Distinguish a product issue from an API specific issue

Generally, if an error or issue occurs in both the DFP web UI and API, it is most likely a product-level issue and non-specific to the API. To help determine this, you can try reproducing what you’re doing via the API in the web UI to see if you get the same error or issue. Product-level issues are better handled by your account manager or by posting to the DFP product forums.

If you’re still unsure, you can always post your issue in the API forums and we will be glad to help you out.

 - , DFP API Team

Upcoming changes to Paid and Organic Query report

We are updating the Paid and Organic report to include only text ad statistics. Impressions and clicks for mobile app install ads and Product Listing Ads will be excluded from this report starting July 13, 2015.

These formats serve in places other than on search results, so we are excluding them to provide you a better comparison across paid and organic listings at the query level. If you use data from the Paid and Organic report in any of your AdWords API or Scripts applications, then make sure you update them to adjust for this data change. Historic stats for mobile app install ads and Product Listing Ads will continue to be available from this report type up to the following report dates:
  • Product Listing Ads - up to and including March 23, 2015
  • Mobile app install ads - up to and including July 13, 2015
If you have any further questions about this change, let us know via the API or scripts forum, or Google+ page.

Anash P. Oommen, AdWords API Team

Announcing Three New Reporting Dimensions for AdMob Publishers

Today we’re announcing the availability of three new reporting dimensions created specifically for AdMob publishers: APP_ID, APP_NAME, and APP_PLATFORM.

Here’s how they work:

  • APP_ID - This dimension matches the store ID of an application. It will be prefixed with “1:” for an App Store ID (iOS) and “2:” for a Google Play ID (Android). For example, “1:476954712” or “2:com.labpixies.lineup”.
  • APP_NAME - Matches the name of an application, like “Flood-It!” or “Line Up”.
  • APP_PLATFORM - This dimension can partition results by platform (e.g. “Android” or “iOS”).

These new dimensions are available now in the AdSense Management API. If you’re unfamiliar with it, the AdSense Management API is a web-based API that you can query to get information about your AdSense account. There are client libraries for a number of platforms, though any standard HTTP client can send requests to it and parse the responses. With a little code and these new dimensions, you can create custom reports about a single app, a family of them, or even your entire platform lineup!

For more information on building and customizing AdMob reports, check out the reporting section of the AdMob developer site. You can also use the API Explorer to test out queries that include these fields.

 - , Mobile Ads Developer Relations

Mobile site or app? Learn how digiSchool made its decision

When it was created in 2011, French company digiSchool was a pioneer by offering free teaching content for which users would otherwise have had to pay. They were growing rapidly. However, they had to make an important decision to grow even further: mobile site or mobile app?

After extensive user testing, digiSchool noticed that mobile apps were best for delivering content like quizzes, lessons, and videos, but a mobile site was better for reading the news. “Depending on the device, a user needs very specific interfaces. We had to figure out whether content worked best on a mobile site or an app.”,  Thierry, co-founder of digiSchool, explains.

They decided to build a mobile site with Responsive Web Design (RWD) to meet their visitors’ needs. This has been key to the success of digiSchool’s mobile site. It has proven to be a scalable, complete solution that doesn't require changes across multiple sites, and has enabled digiSchool’s mobile site to evolve rapidly.

Discover how digiSchool decided to go mobile and how they became a market leader for digital education in France. To learn how you too can provide a great site experience for all of your users, don’t forget to check out our Multi-Screen Starter Guide.



Posted by Anne Goldmann
AdSense Account Manager

Source: Inside AdSense


New features in AdWords scripts

We have made the following changes to AdWords scripts.

Support for passing arguments into parallel functions

You can now use a string argument to pass account-specific information into a parallel function when using the MccApp.executeInParallel() method. The code snippet below shows how to use this feature: 

function main() {
  // Select the accounts you want to process.
  var accountSelector = MccApp.accounts().withIds([1234567890, 3456787890]);

  // Construct a config object that contains account-specific information.
  var accountFlags = {
    '1234567890': {
       'label': 'Brand 1 campaigns',
     },
    '3456787890': {
       'label': 'Brand 2 campaigns',
     }
  };

  // Convert the config object into a string.
  var optionalInput = JSON.stringify(accountFlags);

  // Process accounts in parallel.
  accountSelector.executeInParallel("processClientAccount",
    "afterProcessAllClientAccounts", optionalInput);
}

function processClientAccount(args) {
  // Convert the account flags from string to config object.
  var accountFlags = JSON.parse(args);
  var accountConfig =
      accountFlags[AdwordsApp.currentAccount().getCustomerId()];

  // Process your client account here.
  var label = accountConfig['label'];
  ...
}

function afterProcessAllClientAccounts(results) {
  ...
}
Learn more about working on accounts in parallel.

Support for clearing ad group bid modifiers

You can now use the clearMobileBidModifier() method of AdGroup to clear bid modifiers at the ad group level and default to the campaign-level bid modifier.

Support for Upgraded URLs in app extensions

We have added support for Upgraded URLs in app extensions. The setLinkUrl() method in MobileApp, AccountMobileApp, CampaignMobileApp and AdGroupMobileApp classes and withLinkUrl() method of MobileAppBuilder class have been marked deprecated and will start throwing user errors on July 1, 2015. If you use any of these methods in your script, make sure you update them to use the setFinalUrl() / withFinalUrl() methods instead.

Deprecated CallOnly field in phone extensions

We have deprecated the call-only field in phone extensions. The following methods have been marked as deprecated and will start throwing user errors on June 14, 2015: If your ad extensions use the call-only feature, migrate your campaigns to call-only campaigns by following the instructions here.

Transition to viewable cost-per-thousand impression (CPM)

We’d like to remind you that later this year, all cost-per-thousand impression (CPM) bids will transition to a new type of bid called viewable CPM (vCPM), and CPM bidding will no longer be available. You can learn more about vCPM on our help center.

AdWords scripts already use the correct CPM version, based on campaign settings, so no code changes are required from your end for this transition. Our updated documentation now refers to CPM as the generic cost-per-thousand impression bidding instead of a specific flavor (e.g., maxCPM or vCPM).

If you have any questions about these changes or AdWords scripts in general, you can post them on our developer forum.

Anash P. Oommen, AdWords Scripts Team

New Swift Samples for the IMA SDK

We’re excited to announce the addition of Swift samples to the IMA SDK! To view these samples check out our GitHub repo. Along with these new samples we’ve also added Swift snippets to our quick start guide.

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

 - , IMA SDK Team

Announcing two new versions of the Google Mobile Ads SDK, plus the Native Ads beta!

Today we’re pleased to announce two new versions of the Google Mobile Ads SDK: version 7.5 for Android, and version 7.3.1 for iOS. Included is a brand new way to monetize your apps with the Google Mobile Ads SDK: native ads!

With native ads, publishers can display ad assets directly in native views, using layouts and storyboards they design to fit their user experience. You now have the power to monetize with ads that are seamless with content!

Native ads are currently in a beta with a limited group of publishers, but the code is included in the latest releases of the Mobile Ads SDK for iOS and Android. Those of you using Android Studio can download Google Repository (Rev. 19) via the Android SDK Manager to get the latest Gradle artifacts, and developers with Eclipse projects can find it listed as Google Play services (Rev. 25). Publishers with iOS apps can snag the latest SDK for that platform by updating their Podfile to pull version 7.3.1.

For AdMob, DFP, and AdX publishers, there are two system-defined native ad formats: App Install and Content. Each provides a set of image and string assets that make up the ad. App Install ads contain assets named “price,” “star rating,” and so on, while Content ads have “body,” “logo,” and others. See the AdMob and DFP help center articles for more information about the formats.

Publishers using DFP can also take advantage of custom native ad formats. With a custom format, you can create your own set of asset definitions, and then upload creatives with a matching set of values.

Native ads are loaded using the new AdLoader and GADAdLoader classes, which can request a single format or several at the same time, helping you maximize the value of your impressions. Here’s an example showing how to request an App Install ad on Android:


AdLoader adLoader = new AdLoader.Builder(this, DFP_AD_UNIT_ID)
        .forAppInstallAd(new NativeAppInstallAd.OnAppInstallAdLoadedListener() {
            @Override
            public void onAppInstallAdLoaded(NativeAppInstallAd ad) {
                /* display the ad */
            }
        }).build();
adLoader.loadAd(new AdRequest.Builder().build());

And here’s the iOS equivalent:


self.adLoader = [[GADAdLoader alloc]
                   initWithAdUnitID:DFP_AD_UNIT_ID
                 rootViewController:rootViewController
                            adTypes:@[ kGADAdLoaderAdTypeNativeAppInstall ]
                            options:nil];
self.adLoader.delegate = self;
[self.adLoader loadRequest:[GADRequest request]];

Check out the native ads guide (Android | iOS) for more information about native ads. For a full list of Mobile Ads SDK changes, check out our release notes. For technical questions, post them on our forum.

 - , Mobile Ads Developer Relations

Share your feedback on AdSense, AdMob, and other Google publisher solutions

It’s time to share your feedback! To improve our product and services, we send out a survey to a random group of our publishers every 6 months. The next survey will be sent soon and we’re looking forward to hearing from you.

Your feedback and comments are important to us, and we really do read and consider everything you write. Thanks to previous suggestions, we’ve launched a number of new features to improve our services and help you grow your earnings. These include the redesign of the performance reports with a brand new dashboard, Matched content to help you increase engagement with your site visitors, and welcoming Malay and Hindi languages to the AdSense family.
You may receive a survey by email over the coming weeks. To make sure that you can receive the survey email, please take the following steps as soon as possible:


Whether you’ve completed this survey before or you’re providing feedback for the first time, we’d like to thank you for sharing your valuable thoughts. We’re looking forward to feedback!




Posted by Adriana Satmarean
AdSense Publisher Happiness Team

Source: Inside AdSense


Announcing v201505 of the DFP API

Today we are releasing v201505 of the DFP API. This release brings changes to the ReportService and new features to the Sales Manager API, including advanced ProposalLineItem actions.

In v201505, the ReportService loses all MERGED_* metrics. These metrics, relics from DART migrations, are being deprecated. For more details, check out our earlier blog post. Additionally, the getReportJob method has been replaced by getReportJobStatus. The report utilities in our client libraries have been updated, but you should verify this in your code as well. Migration is straightforward, as shown in this Java example:


    // v201502 code
    ReportJobStatus status = reportService.getReportJob(reportJobId).getStatus();

    // v201505 code
    ReportJobStatus status = reportService.getReportJobStatus(reportJobId);

Sales Manager users get new ProposalLineItem actions, including ActualizeProposalLineItems and ReleaseProposalLineItems. You can also use BypassProposalWorkflowRules and include a comment when approving workflow requests.

For a full list of these and other changes, check the release notes.

As a reminder, with each new release comes a new deprecation. If you're using v201405 or earlier, it's time to look into upgrading. If you have any questions about upgrading, let us know on the developer forum.

 - , DFP API Team