How to Track TWA App Traffic in Google Analytics

When you publish your Progressive Web App (PWA) to the Google Play Store using a Trusted Web Activity (TWA), your app runs inside a highly optimised, full-screen instance of the user's default browser. Because a TWA shares cookies, local storage, and the rendering engine with the system browser, it provides a seamless user experience. However, this shared environment presents a distinct challenge for developers and product managers: how do you differentiate between standard web visitors and users who have installed and opened your app from the Google Play Store?

By default, standard web analytics tools like Google Analytics 4 (GA4), Plausible, or Fathom will categorise TWA traffic as normal web traffic. This makes it impossible to measure app-specific engagement, retention, or conversion rates. To build an accurate picture of your app's performance, you must explicitly flag and isolate traffic originating from your TWA package. This guide explores the most reliable methods to configure traffic tracking and attribution for your converted Android app.

The Dual-Identity Challenge of TWA Analytics

Because a Trusted Web Activity is fundamentally a web browser running inside an Android wrapper, web analytics scripts execute exactly as they would on a desktop or mobile browser. Standard tracking libraries automatically capture device types, browser versions, and operating systems. However, a TWA user running Chrome on an Android device will look identical to a standard mobile web user running Chrome on Android.

To solve this, you need to pass a unique identifier from your native Android wrapper to your web application during the initialisation phase. Once your web application detects this identifier, it can store the state and pass it along with your analytics page views and custom events.

Method 1: Appending Tracking Parameters to the Launch URL

The most robust, reliable, and widely adopted method for tracking TWA traffic is appending custom query parameters to your app's launch URL. When your TWA launcher launches the web application, it requests a specific start URL defined in your Android configuration.

By appending standard UTM parameters or a custom query flag to this URL, your web application can instantly identify the traffic source. Typically, you should modify the start URL in your Android build configuration or your manifest mapping to include specific parameters.

For example, instead of launching your base URL:

https://example.com/

You configure your TWA launcher to open:

https://example.com/?utm_source=google-play&utm_medium=twa&utm_campaign=android-app

When a user opens your app from their Android home screen, your web application detects these parameters in the URL. Your web analytics script then automatically records the traffic source as Google Play, attributing all subsequent page views and actions within that session to the Android application.

Handling Session Persistence and Internal Navigation

While appending query parameters to the launch URL works perfectly for the initial entry point, those parameters are lost as the user navigates to other pages within your application. If a user clicks a link to an internal page, the query parameters disappear from the address bar, and subsequent page views might be recorded as standard web traffic.

To prevent this, you should write a simple JavaScript utility to detect the TWA parameter on load, write a flag to browser storage, and read that flag on subsequent page views.

Here is an architectural breakdown of how to implement this state preservation:

First, your web application checks the URL on load. If the custom TWA parameter is present, your script sets a value in sessionStorage or localStorage. For analytics tracking, sessionStorage is generally preferred because it naturally expires when the session ends, matching standard web attribution models.

Second, whenever your web analytics library initialises or tracks a new page view, your script checks for the presence of the TWA flag in storage. If the flag exists, you programmatically send a custom dimension or parameter along with the page view payload, ensuring that every page view within that session is tagged as an Android app interaction.

Method 2: Customising the User-Agent String

Another powerful method to identify TWA traffic is appending a custom identifier to the browser's User-Agent string. A Trusted Web Activity allows developers to append a custom string to the default User-Agent used by the underlying browser engine.

For example, if your standard user agent is:

Mozilla/5.0 (Linux; Android 13; Pixel 6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Mobile Safari/537.36

You can configure your native TWA wrapper to append an identifier such as TWA-Android-App to the end, resulting in:

Mozilla/5.0 (Linux; Android 13; Pixel 6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Mobile Safari/537.36 TWA-Android-App

On your web server or within your client-side JavaScript, you can check the navigator.userAgent string for the presence of your custom identifier. If the string is found, you can categorise the user as a TWA app user. This method is highly secure and does not rely on URL query strings, meaning it remains active even if users navigate deeply within your site during their first session.

Comparing Tracking Methods

To choose the best approach for your specific stack, it is helpful to compare the two dominant implementation strategies:

Configuring Google Analytics 4 (GA4) for TWA Tracking

Once you have configured either URL parameters or User-Agent modification, you must set up your analytics platform to process and display this data clearly. Here is how to configure Google Analytics 4 to isolate your TWA traffic:

If you are using the UTM parameters approach, GA4 will automatically parse utm_source=google-play and utm_medium=twa into the standard Session Source and Session Medium dimensions. You can immediately create a custom segment or custom audience containing only users where the session source matches your defined value.

If you prefer a custom parameter approach, or if you are using the User-Agent method, you should send a custom event parameter (such as is_twa: true) with every tracking call. You must then register this parameter as a Custom Dimension in your Google Analytics admin panel. Once registered, this Custom Dimension can be used to filter standard reports, construct custom exploration dashboards, and compare conversion funnels between mobile web visitors and native Android installs.

Attributing Installs with the Google Play Install Referrer

In addition to tracking active usage, many developers need to understand which marketing campaigns or websites drove users to install their app from the Google Play Store. The Google Play Store charges a one-off 25 USD developer registration fee, making it highly accessible to launch your app, but acquiring users still requires strategic tracking.

To track acquisitions, you can integrate the Google Play Install Referrer API. When a user clicks a marketing link containing campaign parameters, is redirected to the Play Store, and subsequently installs your TWA app, the Play Store stores those parameters. Your native TWA container can retrieve this install referrer data upon first launch and pass it directly to your web application, allowing your analytics to accurately attribute the installation back to the original marketing source.

Testing and Validating Your Tracking Setup

Before releasing your app update to production, you must verify that your tracking implementation is functioning correctly. The most straightforward way to test this is by running your app on an Android device or emulator with a USB debugger attached.

Open Google Chrome on your development machine, navigate to chrome://inspect, and select your running TWA. Inspect the page, go to the console, and verify that your script successfully writes the TWA identifier to sessionStorage. Next, check the Network tab or use tools like GA4 DebugView to confirm that your custom events and dimensions are being transmitted with the correct payloads. Proper validation ensures your marketing and product data remains accurate from day one.