If you run an app that shows web pages carrying Google ads, this one is aimed at you, even if you have never thought of yourself as an app monetisation business.

Google has started sending compliance emails to publishers about the WebView API for Ads, and the wording is worth reading closely. What was, until recently, described as something developers were encouraged to do is now a mandatory requirement.

If you have already implemented it, there is nothing more you need to do. If you have not, or if you are not sure whether it applies to your apps, this is probably worth a few minutes of your attention.

WHAT THE WEBVIEW API FOR ADS DOES

When your app opens a web page inside a WebView (a WebView on Android, a WKWebView on iOS) and that page serves ads through AdSense code or Google Publisher Tag, the ad tags have no idea they are running inside an app. As far as they are concerned they are loading in a browser. The WebView API for Ads changes that. It registers the WebView with the Google Mobile Ads SDK so the SDK can pass app signals, such as your app ID and app version, through to the tags on the page.

Two things follow from that. The first is reporting and targeting. Those app signals let Google treat the inventory as in-app browser inventory rather than anonymous web traffic, which activates reporting and targeting use cases that are otherwise only available to native app traffic. The second, and the real motivation on Google’s side, is spam and invalid traffic protection. A registered WebView gives Google a clearer picture of where an impression actually originated, which makes it harder for traffic to be passed off as something it is not. That is good for advertiser trust in the inventory, and by extension for the price it clears at.

The SDK attaches message handlers to the registered WebView and listens for ad events fired by the tags on the page but changes about how the ads are requested or rendered. You are simplyadding a handshake between the app and the web content.

WHO THIS APPLIES TO

If you have a native app that loads any of your web pages inside a WebView, and those pages carry Google display ads, then it is you.

News and lifestyle apps that open articles in a WebView rather than rebuilding every page natively. Hybrid apps built in a framework like Flutter or React Native, where large parts of the experience are web content inside a wrapper.

If your app only shows native ad formats requested directly through the Mobile Ads SDK, this does not apply to you. The requirement is specifically about web content, carrying web ad tags, displayed inside an app.

WHAT ARE THE RESULTS OF NON-COMPLIANCE

Google has not published a hard cutoff date, and the email language is deliberately non-specific, which gives Google the freedom to act at its own pace, but our view is that there is no upside to waiting to find out exactly where that line falls.

HOW TO HANDLE CONSENT

There is the detail in Google’s own documentation that carries potentially serious consequences for publishers who owns both the app and the web content inside it. The WebView API for Ads does not carry consent across. If you collect consent in the app using an IAB TCF or CCPA flow, that consent is not propagated to the ad tags running inside the WebView. From a consent perspective, the tags on the page are a separate entity.

You can be entirely compliant at the app level whilst still serving ads in the WebView without a valid consent signal. This means gathering consent in the WebView context as well, through your CMP, so the tags on the page receive a signal they can act on.

WHAT TO DO NOW

Start with an audit. Go through your apps and find every place a WebView is loading web content that serves Google ads. Check the Mobile Ads SDK version each app is running against the minimums above, because plenty of apps are well behind. Decide how you are going to handle consent inside the WebView before you write the integration. Then build it, test against Google’s test page, and ship it in your next release.

We spend a lot of our time working on things like this. There are more than 150 apps running on the Tradecore SDK, and in-app monetisation. If you are running apps and do not have someone whose job is to stay on top of changes like this one, get in touch to learn about our unified monetisation SDK.