---
title: Track WebViews - Android
description: Track webviews with the Contentsquare Android SDK
lastUpdated: 04 May 2026
source_url:
  html: https://docs.contentsquare.com/en/csq-sdk-android/experience-analytics/track-webviews/
  md: https://docs.contentsquare.com/en/csq-sdk-android/experience-analytics/track-webviews/index.md
---

> Documentation index: https://docs.contentsquare.com/llms.txt
> Use this file to discover all available pages before exploring further.

WebView tracking links the Contentsquare SDK to the JavaScript tag running inside your WebViews to support analytics and Session Replay for web content displayed within your app.

Android compatibility

Contentsquare **only** allows to track instances of `android.webkit.WebView`. `androidx.browser.customtabs` is **not** supported: The CSQ SDK **cannot** track what is happening within its context, and its content will **not** be visible in replays.

## Enable tracking in WebViews

### Where to inject your WebViews?

It is **essential** that the registration is done before a URL is loaded in your WebView. With that in mind, you should register your WebViews in `onCreate()` for Activities and `onCreateView()` for Fragments. Unregister them in the corresponding `onDestroy()` or `onDestroyView()` methods.

No matter where you decide to add the following injection code, keep in mind that it will not take effect until the next WebView content reload.

### WebView tracking lifecycle

Use the [`CSQ.registerWebView()`](../command-reference/#csqregisterwebview) API to start tracking a specific WebView and [`CSQ.unregisterWebView()`](../command-reference/#csqunregisterwebview) to stop tracking it.

### Tag setup

To complete the implementation, inject the **CS Tag in WebView mode** on your pages.

See 📚 [Mobile Apps WebView Tracking Documentation](https://docs.contentsquare.com/en/webview-tracking-tag/#manual-injection).

## Full example

Here is an Activity implementation. Register the WebView in `onCreate()` and unregister it in `onDestroy()`:

```kotlin
    override fun onCreate(savedInstanceState: Bundle?) {
          super.onCreate(savedInstanceState)
          setContentView(R.layout.activity_web_view)


          val webView = findViewById<WebView>(R.id.webview)
          webView.settings.javaScriptEnabled = true
          webView.webViewClient = object : WebViewClient() {}


          // Inject the Bridge between the CS Tag in WebView mode and the SDK
          CSQ.registerWebView(webView)


          webView.loadUrl(DEFAULT_WEB_VIEW_CONTENT_URL)
          webView.reload()
    }


    override fun onDestroy() {
          super.onDestroy()


          val webView = findViewById<WebView>(R.id.webview)
          CSQ.unregisterWebView(webView)
    }
```

If you are using Fragments, the approach is similar, but should be done in the `onCreateView()` method for registration and `onDestroyView()` method for unregistration.

## Validate your implementation of WebView tracking

*Currently, there is no way of validating the implementation on the native side only.*

### Validating the implementation on the web side

Once you arrive on the screen with the tracked WebView, you should see the following logs in sequence:

1. **JS interface injected:**

   ```plaintext
   [WebView] Js interface added to the webView
   ```

2. **WebView registered:**

   ```plaintext
   [WebView] Registering WebView on native side
   ```

3. **Tag configuration received — confirms successful tag to SDK communication:**

   ```plaintext
   [WebView JS log] (TAG_CONFIGURATION) [Config]
   ```

4. **Tracking active:**

   ```plaintext
   [WebView] onWebViewTrackingReady
   ```

Specific logs are then emitted for:

* Page views fired by the WebView Tracking Tag in the same format as for screen views: `Screenview - Screen name: {{page name given}} - Screen number: 11`
* Taps and swipes detected by the WebView Tracking Tag in the same format as for defaults taps and swipe but with the target matching an HTML DOM element value: `Tap - Target: {Last view info: div:eq(0)} - Unresponsive: false`

***Going further:*** If you still have doubt, you can look for logs by filtering on `WebViewEventProcessor`. Their presence will confirm that it is well implemented on both web and native sides.