We recently launched v3.0.7 of the Google Mobile Ads Unity Plugin. The updated v3.0.7 Unity package is available for download from the Google Mobile Ads Unity Plugin GitHub repository.
This release introduces support for Native Ads Express. With Native Ads Express, you can create CSS templates that define how ads are presented in your app (things like image sizes, fonts, colors, and so on). These CSS templates are used to generate ad creatives that complement the native look and feel of your app. You can find more information on integrating Native Ads Express into Unity applications in our developer docs.
The v3.0.7 release resolves compatibility issues with the IL2CPP scripting backend and the Google Mobile Ads Unity Plugin. This allows the use of the the IL2CPP scripting backend, a high-performance alternative to the Mono virtual machine and AOT compiler, in Unity applications with the Google Mobile Ads SDK.
The source code and a sample app for the plugin are available in our GitHub repo,asisa changelogfor this release. If you have any questions about Unity integration, you can reach us on our developer forum.(image)
2016-09-21T14:35:26.017-07:00AdWords Scripts now supports Audiences for Search and Shopping campaigns. This release covers all the features you can do through the Audiences Tab in the AdWords UI - target or exclude audiences for an ad group, exclude audiences for a campaign, and apply or adjust bid modifiers. You may also retrieve audiences and their stats associated with ad groups and campaigns. Audience creation is not supported in this release.
UserList.isEligibleForSearch = falsein the AdWords API.
isEligibleForSearchattribute of each UserList.
queryrequest that includes the
IsEligibleForDisplayselector fields. On an ongoing basis, you should periodically check for user lists where eligibility has changed due to improvements in AdWords.
criterionset to an instance of the appropriate type of UserList. Make sure that your application can handle an OperationAccessDenied.OPERATION_NOT_PERMITTED_FOR_CAMPAIGN_TYPE error, which will occur if the particular
UserListin your request is not currently available for Search and Shopping campaigns.
With the Firebase 3.6.0 launch comes the release of version 7.11.0 of the Google Mobile Ads SDK, which has been optimized for the latest release of iOS. Any app that supports iOS 10 should be built against v7.11.0 or higher of the Mobile Ads SDK. AdMob publishers can grab the latest version of the SDK using the
Firebase/AdMob CocoaPod or via the Firebase manual download. DFP publishers can get the latest version from the
Google-Mobile-Ads-SDK CocoaPod or via the Mobile Ads SDK manual download.
"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSCalendarsUsageDescription key with a string value explaining to the user how the app uses this data."
"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothPeripheralUsageDescription key with a string value explaining to the user how the app uses this data."
The latest version of the Mobile Ads SDK has been updated for iOS 10, and will no longer cause these errors to appear.
To comply with the App Store privacy changes, we removed support for the
mraid.storePicture() methods. You will now see that the
mraid.supports("storePicture") methods always return
false. Per the MRAID v2 spec, MRAID creatives should check for support of these features before using them, and correctly handle the case where they’re unavailable.
If you have any questions regarding these changes, please contact us through our forum.(image)
2016-09-14T13:25:27.474-07:00[Update 9/14/2016: The previous version of this announcement indicated that you would be unable to create experiments starting on October 17, 2016. After hearing your feedback, we have decided to continue to allow full
ExperimentServicefunctionality in existing API versions up until the final shutoff date.]
ExperimentServicecan do and more.
As a result of this expanded functionality, the
ExperimentService will be sunset. If you’re still using the
ExperimentService, please take the time to update your code to use campaign drafts and experiments instead.
On February 1, 2017, all experiments running via the
ExperimentService will be stopped. After this date, all
ExperimentService experiments will be deleted, stats will be unavailable, and API calls to the
ExperimentService across all API versions will result in an error.
Please move off the
ExperimentService before February 1, 2017 to ensure that you are able to continue running experiments.
If you have any questions, please post on the forum.
2016-09-02T11:04:28.347-07:00Beginning in November 2016, all new releases of the Google Ads API .NET client library will target .NET Framework 4.5.2+. Currently released client library versions will not be affected.
Additionally, increasing the runtime requirement allows us to make use of new framework functionality, to further improve and modernize the library.
If you have any questions or concerns, feel free to open an issue on the client library's issue tracker.
Productstatuses, while validation issues required the developer to check the returned status from the insertion or update of the product. After this change, developers can retrieve both data quality and validation issues using
Productstatuses, but this means that developers may see more issues returned by
includeInvalidInsertedItemsURL parameter to Productstatuses.list still defaults to
false. This means that, by default, calls only retrieve products which had no validation errors, and thus the retrieved products will only include data quality issues and validation warnings (if any). If you want to retrieve information about products with validation errors, please set this parameter to
Accountshipping: you can retrieve settings uploaded via
Shippingsettings, but not vice versa. Thus, if you currently have shipping settings, you can see what your current settings would look like in the new format expected by
Shippingsettingsby retrieving them using the new service.
Accountshipping, we suggest you either first experiment with
Shippingsettingson another Merchant Center account used for testing, or keep the code to upload settings via
Accountshippingaround until you're sure your new
Shippingsettingscode behaves as expected.
Shippingsettingsservice or other questions about the Content API for Shopping, please let us know on the forum.
CriterionError.CANNOT_ADD_CRITERION_TO_SEARCH_PLUS_CAMPAIGNSerror when trying to add these types.
targetAll=false) option in TargetingSettingDetail, because the new criteria will begin restricting targeting.
2016-08-23T10:24:19.049-07:00If you’re in the Northern Hemisphere like I am, then you’re probably also experiencing the sweltering heatwave we’re enjoying this summer. You know what’s a great way to beat the heat? Stay inside and upgrade your DFP API version to the other hotness: v201608. If the prospect of air-conditioning isn’t enough to draw you away from the allure of melting outside, consider the following additional enhancements! Programmatic & Sales ManagerOne of the biggest features we’re adding to the DFP API is the support for programmatic guaranteed deals. This allows you to perform the end-to-end work of defining your inventory, negotiating with buyers, and trafficking to DFP all using the same great API you know and love (ours). To see how to create and use programmatic objects, see our API guide. In addition to programmatic guaranteed, we’ve further enhanced the ProposalLineItem object by now providing information on whether the pricing model is Gross or Net via the ProposalLineItem.rateCardPricingModel field. TraffickingOn the trafficking front, we’ve added the ability to delineate whether or not a creative isSafeFrameCompatible for applicable creative types such as CustomCreative. We’ve also added viewability tracking event types which can now be found on the ConversionEvent object. And finally, the one you’ve all been waiting for - there’s now support for the popular Html5Creative type. ReportingIt’s not December, but it sure feels like the holiday season. If you’ve ever wanted to run a query you had saved in the UI, the ReportService has got your back. We’ve added ReportService.getSavedQueriesByStatement, which allows you to retrieve reports you’ve created in the UI. You can then run these using ReportService.runReportJob. Of course, since this is an action-packed release, we can’t possibly list out everything we’ve changed in a blog post, so take a peek at the full release notes. As a reminder, with each new release comes a new deprecation (this one’s special, it’s a double deprecation!). If you're using v201511 or earlier, it's time to look into upgrading to v201608. If you have any questions about upgrading, let us know on the developer forum. - Nicholas Chen, DFP API Team[...]
ONE_PER_CLICK("Converted clicks") or
MANY_PER_CLICK("Conversions") at the account level.
MANY_PER_CLICK, and new mutate operations to change this setting will fail with RequestError.INVALID_INPUT.
DISABLEDstatus. This is in line with the upgrade of TrueView campaigns during the integration into AdWords.
2016-08-15T14:11:20.362-07:00Today we’re pleased to announce the new and revamped DFP Playground. Like the previous Playground, you can test PQL statements and examine JSON equivalents of the objects you retrieve from the DFP API. In the new DFP Playground, you can easily switch between services using a tab interface, and you can even view documentation for a particular service with a simple click of a button.
--” for these keywords. Past versions (v201605 and earlier) of these reports will remain unchanged.
NULLscore for these keywords instead of a numeric value.
QualityScorefield, all matching keywords are returned, including those with
QualityScorefield, keywords with
NULLquality score information are excluded automatically. For example,
QualityScore <= 6will include keywords with quality score from 1 to 6 but exclude keywords with
NULLquality score, filter using the condition
HasQualityScore = FALSE.
2016-08-09T13:11:26.500-07:00Today we're releasing v2.6 of the DCM/DFA Reporting and Trafficking API. This release includes a number of highly anticipated features, such as: Reusable targeting templates for ads (learn more) Dynamic asset selection for In-stream video creatives (learn more) Support for the vCPM - Active View placement cost structure (learn more) We've also improved click-through URL management for Display creatives, expanded custom floodlight variable support, and much more. See our release notes for full details. Retiring legacy creative types Beginning with this release, the DCM API no longer supports creating legacy HTML5 Banner and Image creatives. As previously announced, these legacy types have been replaced by the new streamlined Display creative. Additionally, the ability to upload Flash assets into DCM was disabled back in June. Accordingly, this functionality is also being removed from the API beginning with this release. Previous API versions will continue to support uploading Flash assets until their respective sunset dates, but users are strongly encouraged to begin transitioning to HTML5 now. Deprecation and sunset reminder In accordance with our deprecation schedule, this release marks the beginning of the deprecation period for v2.5, which will sunset on February 28th, 2017. After this date, any requests made against v2.5 will begin returning errors. As a reminder, API v2.3 will be sunset on August 31st, 2016. To avoid an interruption in service, all users are required to migrate off of this version 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! - Jonathon Imperiosi, DCM API Team[...]
2016-08-05T09:31:03.945-07:00The transformation of Firebase into a unified mobile platform brought with it new Gradle artifacts and CocoaPods that mobile developers can use to import the Mobile Ads SDK. With these additions, there are now several alternatives for each platform. Thanks to your feedback, we wanted to share a little more information about which ones we recommend and what libraries they include, so here's a quick run-down. Android & Gradle firebase-ads (recommended) This is the best way to get the Mobile Ads SDK into your project. With the firebase-ads artifact, you get everything you need to load and display ads from AdMob, DFP, or AdX, plus Firebase Analytics built in. You'll also be ready to add the client components for any other Firebase services you want to use, like firebase-crash or firebase-config. Unless you have a specific need to use the SDK without Firebase, this is your jam. If you'd like to see a screencast of how to get up and running with AdMob using firebase-ads, check out this episode of the Firecasts series: width="560" height="315" src="https://www.youtube.com/embed/sbXF95-Qneo?list=PLl-K7zZEsYLmxfvI4Ds2Atko79iVvxlaq" frameborder="0" allowfullscreen> play-services-ads For those not using Firebase, this Gradle artifact contains the Mobile Ads SDK on its own. You'll get the client code for AdMob, DFP, and AdX, but no Firebase services. play-services This is the full Google Play services client, also without Firebase. This gives you not only the Mobile Ads SDK, but all the other Google Play services SDKs as well: Maps, Drive, Fit, and so on. Since you're probably not using every API that Play services offers, it's better to import them individually. If you need mobile ads and Play games, for example, just include play-services-ads and play-services-games. play-services-ads-lite The SDK team developed this new Gradle artifact for a very specific use-case. It contains a slimmed-down version of the Mobile Ads SDK designed to work only on devices that have Google Play services installed. If reducing app size is extremely important for you, this can help lessen the impact of the Mobile Ads SDK, but it won't be able to load and display ads on devices that don't have Play services. Make sure you're intimately familiar with your app's install base before considering this tradeoff, and see the Lite SDK guide for more details. iOS & CocoaPods Firebase/AdMob (recommended) This is the Firebase CocoaPod for AdMob and the Mobile Ads SDK. While it's labelled as "AdMob," this pod gives you the iOS client code for DFP and AdX as well. You'll get everything you need to load and display ads from all three sources, plus Firebase Analytics built in. This CocoaPod is also easy to combine with any other Firebase pods your app needs, like Firebase/Crash and Firebase/Database. For most developers, this is the one you want. The Firecasts series has an episode that shows how to import AdMob and Firebase into an app using Firebase/AdMob, so check that out for a detailed screencast: width="560" height="315" src="https://www.youtube.com/embed/03Lh4nK1Z4w?list=PLl-K7zZEsYLn-elkHPhDuuwdCZ93BXnrB" frameborder="0" allowfullscreen> Google-Mobile-Ads-SDK For developers not yet using Firebase, this pod contains just the Mobile Ads SDK. You get everything necessary to show ads from AdMob, DFP, and AdX, but no Firebase services. GoogleMobileAds This is an older, alternate CocoaPod for the Mobile Ads SDK that should no longer be used. Google-Mobile-Ads-SDK is the better choice if you aren't using Firebase. More Info If you've got questions about Firebase and the best ways t[...]
setMobileBidModifier() methodsof the AdGroup and ShoppingAdGroup classes will be deprecated. Updating existing scripts to use the new ad group interface is straightforward. For example,
2016-08-02T14:02:26.294-07:00What’s changing? Starting in late August, platform bid modifiers of campaigns and ad groups attached to Target CPA and Conversion Optimizer bidding strategies will be cleared. Your campaigns will continue to serve as they do currently. Why is this happening? The clearing of these bid modifiers is part of an upcoming feature launch. The new feature will allow users to set platform bid modifiers for entities attached to Target CPA and Conversion Optimizer bidding strategies. In the past, this platform bid modifier value was ignored. By clearing these values for you, we can release the functionality without affecting your currently serving campaigns. How does this affect me? For most users, we will only clear platform bid modifiers on Target CPA and Conversion Optimizer entities. Some customers will also see a shifting of platform bid modifiers where a Target CPA ad group inherits modifiers from a non-Target CPA campaign. Here are some changes that you’ll see in your account before the new features launches: For ad groups, clearing mean the entire AdGroupBidModifier will be removed. For campaigns, clearing means CampaignCriterion.bidModifier will be set to 1.0. If the AdGroupBidModifier.bidModifier or the CampaignCriterion.bidModifier was set to 0.0 to opt-out, the bid modifier will not be touched. If the AdGroupBidModifier.bidModifier or the CampaignCriterion.bidModifier does not target a Platform criterion, the bid modifier will not be touched. The new feature will roll out to all users over the course of three weeks starting in late August. Sometime during those three weeks, we will clear your platform bid modifiers, and shortly thereafter we will enable the feature for your account. You will then see the option to set platform bid modifiers in the AdWords user interface. Bid modifiers set after that point will be preserved. What should I do? Check your code and verify that if you’re setting this platform bid modifier it’s intended because that code will have an effect on bidding after the clearing process.[...]
AREA_OF_INTERESTfor non-search campaigns. Existing non-search campaigns whose
positiveGeoTargetTypeare set to
AREA_OF_INTERESTwill be automatically changed to
DONT_CARE. Any requests that attempt to set this to
AREA_OF_INTERESTfor non-search campaigns will fail.
AREA_OF_INTERESTwill be changed. If you use this setting, the campaign will primarily target a user's area of interest and secondarily his/her location of presence. In other words, if the area of the user’s interest is explicitly present in a search query, such as “flower delivery in NYC”, then it’ll be used. If the search query doesn’t include any areas of interest, say “flower delivery”, the physical location of the user performing the search will be used instead.
A new episode of The Mobile Ads Garage has hit YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.
Did you know that AdMob serves ads to more than two hundred countries and territories? To celebrate, The Mobile Ads Garage presents Episode 8 in two languages! Katie from the Mobile Ads SDK team stops by to help Andrew talk about rewarded video mediation. You'll hear the basics of how and why to use AdMob mediation and the Mobile Ads SDK to show rewarded video ads in both English and Chinese.
Rewarded video is a full-screen ad format in which users watch ads in exchange for something, typically an in-game reward. Because users hold the power of choice, they don't have to see ads they aren't interested in. Plus, publishers can build the view/reward cycle into the mechanics of their games, creating monetization strategies that actually increase user engagement. When you add all that to AdMob's ability to automatically prioritize mediated networks by eCPM, you've got a complete solution.
If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.
We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.(image)
2016-07-28T11:26:10.137-07:00Today we’re announcing the release of AdWords API v201607. Here are the highlights: Expanded text ads. The AdWords API now supports creating these ads in production accounts. Previously, creation of ExpandedTextAds was only supported in test accounts. Greater transparency in quality score. To improve transparency, QualityScore in Keywords Performance and Criteria Performance will report a value of two dashes (--) when there aren’t enough impressions or clicks to accurately determine a keyword’s quality score. The HasQualityScore field introduced in v201605 will now return false for any row without a QualityScore. Finally, for criteria without a quality score, the qualityInfo attribute will no longer be returned by AdGroupCriterionService get and query requests. Price extensions. The new PriceFeedItem type allows you to showcase your services and range of products, along with their costs, with your mobile text ads. Read more about price extensions in this Inside AdWords blog post. Converted clicks is deprecated. ConvertedClicks and its related fields have been removed from all reports in favor of Conversions. Conversions is the ideal way to measure valuable actions, and most advertisers already use Conversions as their primary reporting and bidding metric. Conversions is more flexible and is capable of measuring behavior that spans multiple conversion events or multiple clicks. Check out the recent Inside AdWords blog post for more details. Platform bid modifiers. Bid modifiers specific to desktop and tablet have been added to the campaign and ad group performance reports. Also, managing bid modifiers for desktop and tablet is currently only available in test accounts, but we will be rolling it out to live accounts for all versions over the coming weeks. CustomerService.get is deprecated. The get method of CustomerService has been replaced with the more flexible getCustomers method. Check out our migration guide for details. If you’re using v201601 or v201603 of the AdWords API, please note that they’re now deprecated and will be sunset on August 27, 2016 and October 25, 2016, respectively. We encourage you to skip v201605 and migrate straight to v201607. As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201607 migration guide. The updated client libraries and code examples will be published shortly. If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page. - Josh Radcliff on behalf of the AdWords API Team[...]