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.
![]() |
Not yet an AdSense user? Sign up now! |
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:
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
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:
The BannerWrapper GameObject is a wrapper for a BannerView.
// 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);
}
// 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.
Today we're releasing v2.3 of the DCM/DFA Reporting and Trafficking API. This release brings a number of enhancements, such as:
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.
Give it a try and let us know if you have any questions!
AppConversions
in v201509 or v201506 with AppPlatform: ITUNES
, you’ll need to make sure that you’re using the correct AppConversionType.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.AppConversionType
DOWNLOAD changed to FIRST_OPEN for iTunes apps. Here’s what you will need to do: AppConversionType
DOWNLOAD rather than FIRST_OPEN.AppConversions
with an AppPlatform
of ANDROID
.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_sdkVideoViews
, which have previously been unavailable via API reporting. AdWords API version v201509 has updated its reporting to match these changes.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.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.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.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 |
Clicks
column in v201506 will match the Interactions
column from v201509 if you subtract out video interactions.