Tag Archives: AdMob

Fetching invalid product offers in Content API

The Shopping Content API now supports the retrieval of invalid product offers. This means that offers such as those with an invalid category or a mismatched URL can now be retrieved and reviewed via the API. This will enable you to more easily view invalid product offers and debug API requests. Going forward, invalid product offers that are newly inserted via the API will be available for review in the Diagnostics tab of the Merchant Center.

How should you go about retrieving your invalid offers from the API? You can do this by using a new optional URL parameter that has been added to the products.list method, called includeInvalidInsertedItems. (Yes, it's a long name; we apologize for the extra keystrokes.) If you set this parameter to true, your response will include products that were invalid at the time of insertion. The default value is false, so if you don't include the parameter in your request, you will not have invalid products in your response. This preserves existing behavior, with the exception that if you have invalid product offers from feeds, they will also not be returned in the response. Note that you can still use the 'get' and 'delete' methods to reference product offers directly by ID, even if they are invalid. No additional parameter is needed for those methods.

We are introducing one new error when inserting product offers, called "The item could not be inserted". An invalid offer is inserted only if it does not overwrite an existing valid offer. When there already is an existing valid offer, an additional error is returned, stating "The item could not be inserted". This also means that the product offer will not be available for review from products.list nor in the Diagnostics tab. Product offers are matched based on the full product ID, of the form channel:languageCode:countryCode:offerId.

It's important to remember that the new includeInvalidInsertedItems parameter will only filter between valid and invalid product offers, as determined at insertion time, ignoring whether they were or not later disapproved. This means that it will return invalid product offers inserted both from the API and from feeds. To distinguish between approved and disapproved product offers, use the Productstatuses Service.

To try out this new parameter, add includeInvalidInsertedItems as a query parameter to your products.list request. If you have more questions or feedback, please head on over to our developer forum.

Preparing for universal ads in DCM

As you may have heard, universal ads are launching to DCM accounts throughout November and December 2015. The centerpiece of these new ads is a set of unified compatibilities that remove the distinction between in-app and in-page environments. To learn more, visit our DCM user or partner support sites.

What does this mean for DCM/DFA Reporting and Trafficking API users?

Currently, the API does not expose these new compatibilities, although full support is coming in a future release. Until then, the in-app and in-page compatibilities you currently use will remain available. This means that there are no immediate changes necessary to your applications, but you may notice some discrepancies between the values presented by the API and UI:

API compatibility
New UI compatibility
APP
In-app
APP_INTERSTITIAL
In-app interstitial
IN_STREAM_VIDEO
In-stream video
WEB
Display
WEB_INTERSTITIAL
Display interstitial

What can API users do to prepare?

To make your future transition to universal ads easier, we recommend that API users begin transitioning off of in-app placements now. Be aware that it will no longer be possible to traffic in-app placements once universal ads support is added to the API, and existing in-app placements will not be automatically converted to use the new unified compatibilities.

Instead, newly trafficked placements should be created using in-page compatibilities. These placements will be mapped directly to the new unified compatibilities (as seen in the table above), making them immediately eligible to serve in both environments.

Questions about this or anything else DCM API related? Contact us via our support forum.

Announcing the Google Mobile Ads API Demo apps

The Google Mobile Ads API Demo apps for Android and iOS are now available. These new apps contain advanced examples for both AdMob and DoubleClick for Publishers (DFP) that demonstrate features of the Google Mobile Ads SDK that can help you improve the user experience and maximize ad revenue. Whether you’re a new publisher or a seasoned veteran of the SDK, the API Demo apps showcase new ways to customize ad requests, experiment with multiple ad sizes, and compare AdMob and DFP technologies.

Download the API Demo apps for Android and iOS today and explore new ways to improve your integration with the Google Mobile Ads SDK!

If you have any questions regarding the new API Demo apps, feel free to contact us through our forum.

Check out the latest workshop content!

We’ve completed the last round of the AdWords API Workshops, and you can check out all the content online by visiting the official website, www.adwordsapiworkshops.com, and clicking on Resources.

Be sure to also check out our YouTube channel for the recorded presentations.

If you have any questions about the AdWords API Workshops, you can post them on our forums. Check out our Google+ page for Ads APIs updates.

DoubleClick Ad Exchange Seller REST API Report changes

On November 17th, 2015, we'll be updating the Ad Exchange Seller REST API to make it consistent with the user interface. Specifically, we'll remove the ability to download saved reports or retrieve the dimensions we retired in April.

Requests made after this date for these dimensions will result in that dimension being ignored and requests for saved reports will result in an error.

As a reminder, the dimensions we retired in April are:

  • AD_FORMAT_CODE
  • AD_UNIT_ID
  • AD_UNIT_CODE
  • DSP_ID
  • EXPANSION_TYPE_CODE
  • PLATFORM_TYPE_CODE

For a full list of available dimensions, please see the AdX Seller REST API documentation.

Follow our Google+ page for other announcements and updates.

-- Dean Lukies, Ads Developer Relations

Multiple scenes and ads in Unity

When developing with AdMob in Unity, it is a common practice to make your banner ads persist across multiple scenes. This blog post will highlight best practices to accomplish this with the Google Mobile Ads Unity Plugin.

The most straightforward approach is to link the lifecycle of ads to that of the scenes they’re displayed in. When transitioning from one scene to another, existing ads are destroyed before leaving the first scene. New ads can then be created and displayed in the next scene.

The downside of this approach is that every scene transition would result in a new banner request. This may not be desirable if scene transitions are frequent and occur quickly.

An alternative is to use a GameObject as a wrapper for banners or interstitials. By default, each GameObject in a scene will be destroyed once the new scene is loaded (unless you use additive scene loading). However, you can make a GameObject survive across scenes by marking it with DontDestroyOnLoad. You can then use the GameObject.Find method to obtain references to the wrapper GameObject from scripts in other scenes.

Here is an example of how to use a GameObject to wrap banner ads:


// FirstSceneScript.cs
void Start() {
// Create a wrapper GameObject to hold the banner.
GameObject myGameObject = new GameObject("myBannerAdObject");
myGameObject.AddComponent<BannerWrapper>();
// Mark the GameObject not to be destroyed when new scenes load.
DontDestroyOnLoad(myGameObject);
}
The BannerWrapper GameObject is a wrapper for a BannerView.

// BannerWrapper.cs
using System;

using UnityEngine;
using GoogleMobileAds;
using GoogleMobileAds.Api;

public class BannerWrapper : MonoBehaviour {

public BannerView bannerView;

void Start()
{
bannerView = new BannerView(
"your_ad_unit_id", AdSize.SmartBanner, AdPosition.Bottom);
AdRequest request = new AdRequest.Builder().Build();
bannerView.LoadAd (request);

bannerView.Show();
}
}

In SecondSceneScript.cs, which is attached to the second scene, you can find a GameObject by name, get the BannerWrapper component, and access the BannerView:


// SecondSceneScript.cs
void Start () {
GameObject myGameObject = GameObject.Find("myBannerAdObject");
BannerWrapper bannerWrapper = myGameObject.GetComponent();
bannerWrapper.bannerView.Hide();
}

By managing your ads efficiently and seamlessly across scenes, you are sure to provide a better ad experience for your users. If you have any questions about Unity integration, you can reach us on our forum. You can also find our quick-start guide linked here. Remember that you can also find us on Google+, where we have updates on all of our Google Ads developer products.

Announcing v2.3 of the DCM/DFA Reporting and Trafficking API

Today we're releasing v2.3 of the DCM/DFA Reporting and Trafficking API. This release brings a number of enhancements, such as:

Deprecation and sunset reminder

In accordance with our deprecation schedule, this release marks the beginning of the deprecation period for v2.1, which will sunset on February 29th, 2016.

As a reminder, February 29th is also the end of the extended migration window we've provided to users of v2.0 and earlier versions of the API. The current schedule is as follows:

API Version
Deprecation Date
Sunset Date
v1
3 Aug 2015
29 Feb 2016
v1.1
v1.2
v1.3
v2.0
v2.1
4 Nov 2015

To avoid an interruption in service, all users are required to migrate off of these versions by the sunset date.

Learn more

As with every new version of the DCM/DFA Reporting and Trafficking API, we encourage you to carefully review all changes in the Release Notes. For those of you looking to get going right away, updated client libraries are now available. If you're just starting out, the Get Started guide is a great reference to help you get up and running quickly.

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

Changes to validation for AdWords API iTunes AppConversions

What’s new?

The validation for AppConversions will become stricter starting on November 9, 2015. If you’re using AppConversions in v201509 or v201506 with AppPlatform: ITUNES, you’ll need to make sure that you’re using the correct AppConversionType.

What was the old behavior?

When v201509 was first released, the API would not throw an error if the incorrect value was sent in a request for an iTunes AppConversion. The API automatically converted to the correct AppConversionType. For example, if the value DOWNLOAD was passed into v201509 for an iTunes AppConversion, then that value would automatically be converted to FIRST_OPEN.

What is the new behavior?

In v201509, AppConversionType DOWNLOAD changed to FIRST_OPEN for iTunes apps. Here’s what you will need to do:
  • For v201506 or earlier, you must pass in AppConversionType DOWNLOAD rather than FIRST_OPEN.
  • For v201509 or later, you must pass in FIRST_OPEN instead of DOWNLOAD.
Passing in the incorrect value will result in the error DOMAIN_EXCEPTION from the API starting on November 9.

Note: This only impacts iTunes conversions. There will be no changes to the validation for AppConversions with an AppPlatform of ANDROID.

Where can I learn more?

For more information on mobile apps and conversions, check out these guides: Questions? Visit us on the AdWords API Forum or our Google+ page.

Proguard and AdMob mediation

If you’re an Android developer who uses ProGuard to post-process builds, you already know the improvements it can make to APK size and speed. Just as handy, though, is its ability to obfuscate your compiled code by stripping out debug information and renaming classes, methods, and fields to generic identifiers. It’s a great way to discourage reverse-engineering of your application. If you’re an AdMob publisher who uses mediation, however, you need to take special care when configuring ProGuard in order to avoid obfuscating some of the code used in the mediation process.

AdMob mediation needs two classes to maintain their original names in your final APK: AdUrlAdapter and AdMobAdapter. If either of those has been renamed by ProGuard, it can cause the SDK to incorrectly return “no fill” responses for the AdMob demand in your mediated ad units.

The good news is that it’s easy to avoid this problem. Just add the following two keep options to your ProGuard configuration file:


-keep class com.google.ads.mediation.admob.AdMobAdapter {
*;
}

-keep class com.google.ads.mediation.AdUrlAdapter {
*;
}

These options instruct ProGuard to avoid renaming the two classes, and to leave the names of their fields and methods unobfuscated as well. With the original names intact, the mediation system will be able to instantiate them dynamically whenever they’re needed, and your otherwise obfuscated application won’t miss out on any AdMob impressions.

The third-party networks your app mediates may also need certain classes exempted from obfuscation. Be sure to check with those networks to find out if they have recommendations for ProGuard configuration.

If you have technical questions about this (or anything else relating to the Google Mobile Ads SDK) stop by our forum.

tags: android, admob_mediation, mobile_ads_sdk

Reporting changes in AdWords API v201509

AdWords API v201509 introduces some changes to reporting columns, particularly Clicks. Recently, AdWords introduced new columns called Engagements and Interactions. It also added reporting columns related to video campaigns such as VideoViews, which have previously been unavailable via API reporting. AdWords API version v201509 has updated its reporting to match these changes.

The new Interactions field, available in API performance reports, can be thought of as the main action a user takes with the ad format: clicks for text ads, engagements for Lightbox ads, and views for video ads. Previously, views for video ads were not returned in API reporting, so having access to this data is new.

Prior to v201509, the Clicks field always included both clicks and engagements. Starting in v201509, the Clicks field includes only click actions, like clickthroughs to a landing page or clicks to call. This means that clicks on video ads, which are unpaid, will be included in this field. However, engagements for Lightbox ads will not be counted.

If measuring performance across multiple ad formats, you might consider using Interactions to view the total number of primary user actions on ads, all in the same column. Clicks, Engagements, and VideoViews are available as well for more fine-grained reporting by ad format.

The table below summarizes the changes in each field for various ad formats.

Field
v201506
v201509
Clicks
Text ads: clickthrough to a landing page

Lightbox ads: hover to expanded ad format
Text ads: clickthrough to a landing page or clicks to call

Lightbox ads: clickthrough to a landing page

Video ads: clickthrough to a landing page
Engagements
N/A
Lightbox ads: hover to expanded ad format
VideoViews
N/A
Video ads: view
Interactions
N/A
Text ads: clickthrough to a landing page or clicks to call

Lightbox ads: hover to expanded ad format

Video ads: views

Please note that reporting in v201506 and previous versions is unaffected; they return the same data that they always have, represented the same way. This means that when comparing the data you receive from older versions of the API to user interface reports, or to v201509 reports, the numbers will not directly match up. Video-related stats will still be excluded from v201506. The Clicks column in v201506 will match the Interactions column from v201509 if you subtract out video interactions.

For ease of reporting, it’s recommended to migrate to v201509 as soon as possible.

Keep in mind these aren’t the only reporting changes in v201509 — for more details on conversion-related reporting changes, please see the release notes.

If you have any questions about this or other aspects of the AdWords API, please contact us via the forum or the Ads Developers Plus Page.