In-app browsers allow app developers to display web content, without users’ having to leave the app. They are commonly found in popular social, news, search, and H5 game apps.
In-app browsers are often powered by mobile app OS components (like WebView and WKWebView). The default settings in these components are sub-optimal for ads monetization. That is, app developers have to optimize these components in order to maximize ad revenue performance.
Analyzing in-app browser traffic can provide valuable insights. Consider sharing these insights with your app developers, especially if they indicate a fixable issue. Insights may also inform a monetization strategy. You can target in-app browser traffic for direct sales, and at the app ID level.
To aid in analysis, Google Ad Manager identifies in-app browsers and the apps that host your content and ads. There are new app and browser dimensions, and new values in existing dimensions. Keep in mind that identification of in-app browser traffic and hosting apps is imperfect, and relies on signals app developers must send.
In-app browser insights and recommendations will differ by app ID. While some apps may benefit from implementing best practices, others may have already done so. Consider testing ads use cases on each of the top apps that host your ads.
In this article:
- Explore in-app browser inventory and performance
- Comparing in-app browser traffic to other traffic
- Optimizing in-app browser traffic
Explore in-app browser inventory and performance
In-app browser dimensions added to explorers, Home workspaces, forecasting, data transfer, and reporting help to surface important performance insights about your in-app browser ads.
Dimensions
The most relevant dimensions for in-app browsers are:
Note: Not all dimensions are available in all areas. Comparing in-app browser traffic to other traffic shows how these dimensions are expected to intersect.
Explorers
Traffic Explorer provides a view of your data based on arbitrary cuts of inventory by targeting expressions. Audience explorer data helps you target audiences more precisely to maximize yield. Look for the in-app browser value in the Top browsers card for both explorers.
Home workspaces
The following cards on your Home workspace can display insights related to in-app browser traffic.
Identity insights
The identity insights card helps you understand the availability of various user identifier types on your traffic that may affect the performance of your ads. In-app browsers may have settings that affect which of these IDs are available. For example third-party cookies are turned off by default on Android WebView; app developers can turn them on.Performance summary
Break down or filter by in-app browser dimensions in the “Performance summary” card to track performance over time.
Forecasting and Data Transfer
To forecast your in-app browser inventory volume, review your inventory forecast setup. In step 13, select any of the relevant in-app browser dimensions in the targeting picker.
In-app browser traffic is reflected in Data Transfer reports with the Browser, BrowserId and MobileAppId fields.
Reporting
Ad Manager reporting helps you create and schedule customized reports with support for most in-app browser dimensions.
Identify the top apps hosting your ads
- Sign in to Google Ad Manager.
- Follow the instructions to create a report.
- Select App ID and App names dimensions.
- Select the Total impressions metric.
- Filter by Browser category = “In-app browser”.
Sort the report by “Impressions” to view your top apps.
Ideally all in-app browsers would provide App ID in ad requests, but not all do. When Ad Manager shows “(Not applicable)” in this dimension, it means the app is not supplying one, or Ad Manager is not interpreting the app’s hints correctly. If you’re aware of missing available hints in Ad Manager, let us know. You can increase coverage of this dimension by adding the WebView API for Ads, see Signals for more information.
Identify your apps hosting your ads
-
Following the steps for Identify the top apps hosting your ads.
- Filter by App ownership status = “Owned”.
The resulting report is narrowed to the apps you’ve claimed for targeting. If you haven’t claimed any apps for targeting, set up published and unpublished apps. Note that this is irreversible.
Track the distribution of in-app browser ad requests across app versions
App developers may need to upload new versions of their apps after following the developer guidance. Track app versions against performance metrics using the app version dimension:
- Sign in to Google Ad Manager.
- Add the App version dimension.
- Add the Total impressions metric.
Ideally all in-app browsers would provide App version in ad requests, but not all do. When Ad Manager shows “-” in this dimension, it means the app is not supplying one, or Ad Manager is not interpreting the app’s hints correctly. If Ad Manager is missing available hints, let us know. Increase coverage of this dimension by adding the WebView API for Ads. See Signals for more information.
Comparing in-app browser traffic to other traffic
Using the in-app browser value, you can isolate, filter or compare performance metrics by web, app, and in-app browser traffic. You can combine the Browser or Browser category dimensions to other dimensions for any report or explorer (where available). Other dimensions include Inventory types, Request type, and App ownership status.
Here is how web, app, and in-app browser segments will appear across these dimensions:
| Desired traffic segmentation | Browser category dimension | Browser dimension | Inventory types dimension |
Request type |
App ownership status dimension |
|---|---|---|---|---|---|
| App | Not applicable (App) | Any browser (like, Chrome) | Mobile app or In-stream video | Mobile Ads SDK or Video tag | Owned, Not Owned, or Not applicable |
| In-app browser | In-app browser | In-app browser | Web, AMP, In-stream video, or other | Any tag (non-mobile SDK) | Owned, Not Owned, or Not applicable |
| Web | Any browser (like, Chrome) | Any browser and version number (like, Microsoft Internet Explorer 11) | Web, AMP, or other | Any tag (non-mobile SDK) | Not applicable |
Contextual data used for targeting mobile app traffic may be missing for in-app browser traffic. For example, in-app browsers don’t send a mobile device submodel. While you may be able to target device manufacturer “iPhone”, you won’t be able to target “iPhone 8”. Full targeting capability for apps using the Webview API for ads is coming soon.
Optimizing in-app browser traffic
After exploring and understanding your in-app browser traffic, you may have found ways to improve it, including:
- Selling it directly by targeting
- Testing and guiding app developers
Targeting in-app browser traffic
Holistically targeting in-app browser
The Browser targeting type is useful for advertisers who are trying to reach an audience using a specific browser, like an in-app browser.
To target in-app browser inventory:
- Sign in to Google Ad Manager.
- Go to wherever you'd like to apply targeting (for example, line item targeting).
- In the targeting picker, choose Browser and include In-app browser (x.x).
In Ad Manager, ads served to in-app browsers are considered web traffic, not app traffic. App ads are served in apps, though not with in-app browsers. This means Inventory type for In-app browser (x.x) is never Mobile app. See Comparing in-app browser for more details on how app and web traffic is classified, and how targeting types differ.
Targeting specific in-app browser apps
To target in-app browser on a per-app basis:
- Sign in to Google Ad Manager.
- Select Inventory, then Apps, and then "Apps: In-app browser".
- Enable targeting for a suggested app and/or Finish setup:
- Enable targeting affects visibility of the app in the targeting picker. When toggled on, you will find the app in the mobile application “Targeting type”.
- Finish setup allows ad serving for mobile app traffic and targeting for in-app browser traffic.
- Include in-app browser apps in targeting through the Mobile application targeting type.
Learn more about confirming and completing app setup.
Testing and developer guidance
Once you’ve identified the top apps hosting your ads in their in-app browsers, we recommend testing proper setup, full signaling, and click behavior using the test page https://webview-api-for-ads-test.glitch.me. By searching, sharing, or sending a message with this URL inside an app, you can navigate the app’s browser to this URL to perform tests.
Settings
Consider reminding app developers from your top apps to follow WebView (Android) and WKWebView (iOS) best practices for ads monetization. These guides contain instructions on how to enable in-app browser services that ads rely on, including:
- Cookies
- Local storage
- Video playback
Signals
In-app browsers may lack signals that optimize ads performance. While AdSense, IMA SDK for HTML5, and Google Publisher Tag gather some signals from webviews, the WebView API for Ads improves the signals that Ad Manager collects. For example, the WebView API ensures App ID and App version is collected, minimizing the amount of traffic showing “(Not applicable)” for either of these dimensions.
Using the WebView API for Ads (Android, iOS) in your own apps is one way to comply with webview policy. Consider asking developers from your top third-party apps to use the WebView API for Ads in order to improve signal fidelity for your ad traffic.
You can confirm an app is using the Webview API for Ads by navigating its in-app browser to https://webview-api-for-ads-test.glitch.me#api-for-ads-tests.
Click behavior
Advertisers pay more for inventory that leads to conversions. If clicks on ads don’t function properly, conversion rates and publisher payouts suffer.
Consider testing click behavior in the apps that host your ads. Navigate their in-app browsers to https://webview-api-for-ads-test.glitch.me#click-behavior-tests. Ask app developers to fix click problems in Android and iOS.
Consider making clicks on in-app browser ads open in Custom Tabs and SFSafariViewController. These browser technologies support automatic credit card form filling and popular sign-in services that boost advertiser conversion rates.
To ensure users can always reach a full browser to complete an advertiser conversion, consider asking app developers to:
- Provide users a way to bounce out of in-app browsers to their default browser.
- Provide users a way to disable in-app browsers and set the app to open links in their default browser.