Screen View in Mobile Analytics — What It Is, Key Metrics and How to Track

What Is Screen View?

Screen View is an analytics event that is sent when a mobile application screen is opened. The event contains the screen name (screen_name), class (screen_class) and a timestamp. Unlike web analytics, where page_view is tied to a URL, in mobile applications screens are identified by the name of the Activity, Fragment, ViewController or Custom View.

Screen View Event Structure

The previous_screen parameter is especially important: it allows restoring the sequence of transitions and building a Screen Flow — a map of user paths through the application.

Screen View vs Page View: Key Differences

Screen View and Page View solve the same task — recording a view — but in different environments. On the web, a URL uniquely identifies a page, and Page View is tied to document loading. In mobile applications, a screen is a UI state that does not necessarily correspond to a separate address.

• Page View is tied to an HTTP request and URL — Screen View is tied to a lifecycle event of Activity/ViewController
• Page View is not duplicated when going back (cache is used) — Screen View is sent again each time the screen is opened
• Page View is typically shorter — users view a web page faster than a mobile screen with interactive elements

Another difference is context depth. Screen View in a mobile application includes state parameters: whether the user is authorized, what data is loaded, whether the screen is opened in edit mode. Page View on the web rarely carries such context — it only records the fact of URL loading. This makes Screen View more informative for product analytics, since each event can be segmented by state.

Typical Mistakes When Working with Screen View

The first mistake is sending screen_view on every state change within a screen (tab switching, opening a popup). Screen View should only record a full transition to a new screen, not micro-interactions.

The second mistake is using a technical class name instead of a readable name. "ProductDetailActivityKt" is useless for an analyst — use "Product Details" in screen_name.

The third mistake is sending screen_view without the corresponding fields. An empty screen_name creates a set of garbage records that cannot be grouped. Always pass at least screen_name and screen_class, even on test screens.

How to Track Screen View?

Implementation of Screen View tracking depends on the navigation architecture. Let us look at automatic and manual approaches using Jetpack Compose and SwiftUI as examples.

Android: Automatic Tracking in Jetpack Compose

Use LifecycleEventObserver at the NavigationComponent level. Each time a user navigates to a new route, the screen_view event is triggered.

class ScreenTrackingObserver(
    private val analytics: AnalyticsProvider
) : LifecycleEventObserver {

    override fun onStateChanged(
        source: LifecycleOwner,
        event: Lifecycle.Event
    ) {
        if (event == Lifecycle.Event.ON_RESUME) {
            val route = source.getRouteFromLifecycleOwner()
            analytics.logScreenView(
                screenName = route.screenName,
                screenClass = source.getLocalClassName()
            )
        }
    }
}

// NavHost connection
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

This approach guarantees that screen_view is sent every time the screen returns to the foreground, including returning from the background. Lifecycle.Event.ON_RESUME is the right moment for tracking, not ON_START or ON_CREATE.

iOS: Automatic Tracking in SwiftUI

In SwiftUI, the onAppear modifier built into each View is used. For automation, a ViewModifier is created.

struct ScreenTrackingModifier: ViewModifier {

    let screenName: String

    func body(content: Content) -> some View {
        content.onAppear {
            Analytics.shared().logScreenView(
                name: screenName,
                className: "\(Self.self)"
            )
        }
    }
}

extension View {
    func trackScreen(_ name: String) -> some View {
        modifier(ScreenTrackingModifier(screenName: name))
    }
}

// Usage:
ProductDetailView()
    .trackScreen("Product Details")

The trackScreen modifier is added to any View with a single line. This is a clean and scalable solution for SwiftUI projects.

Screen View in Multi-Module Projects

In projects with a modular architecture, each module can use its own screen naming, which leads to duplication of screen_name. A centralized ScreenName enum solves the problem — all screens are named according to a single standard in one place. Adding a new screen only requires a new constant in the enum, rather than searching through the entire codebase.

Use a sealed class to describe screen_name with grouping by feature: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. This simplifies filtering in analytics reports.

Screen Flow: Analytics of Screen Transitions

Screen Flow (or Path Analysis) is a visualization of the sequence of screens a user goes through. It is the primary tool for identifying bottlenecks in navigation.

Building a Screen Flow

Each Screen View with the previous_screen parameter provides a graph edge: CatalogScreen → ProductDetails → CartScreen. By aggregating all transitions, a path map is built. A three-step funnel based on Screen Flow shows where users drop off.

• Step 1: HomeScreen → CatalogScreen (95% proceed)
• Step 2: CatalogScreen → ProductDetails (65% proceed — 35% leave)
• Step 3: ProductDetails → AddToCart (30% proceed — we lose another 35%)

According to Mixpanel (2024), Screen Flow analysis reveals up to 40% of UX issues that are not visible when analyzing individual events. For example, a frequent transition ProductDetails → HomeScreen without a purchase indicates a problem with the price or product description.

Drop-off Analysis

Drop-off is a point where a user leaves a scenario. If 60% of users leave after the Loading screen, the problem is in loading speed or animation. If after a Paywall — in the cost or value of the subscription.

Screen Flow in Firebase and BigQuery

Firebase does not provide a ready-made Screen Flow report, but screen_view data is available in BigQuery. Build a query that groups transitions by pair (previous_screen, screen_name) and counts the frequency. The result is a transition matrix that can be visualized in Looker Studio as a Sankey diagram.

Supplement the Screen Flow with segmentation: separately for new users (first 7 days) and returning users. New users more often get stuck on onboarding screens, while experienced users reach target actions faster. Comparing the two flows reveals adaptation bottlenecks.

Tools for Screen View Analytics

Choosing a tool for Screen View analytics depends on budget, stack, and required level of detail. Let us look at three popular solutions.

Firebase Analytics (free)

Firebase automatically tracks screens via the screen_view parameter in every event. No additional code is required after SDK integration. Limitation: screen_name is generated from Activity/ViewController, which does not always produce readable names.

Amplitude (professional)

Amplitude offers a built-in Pathfinder — a visual Screen Flow builder. Supports user properties and cohort segmentation. Allows renaming screens on the server side without changes to the application code.

Mixpanel (mid-market)

Mixpanel provides a real-time Flows report. It can show not only linear transitions but also branches — which screens are visited after a specific one. Integrates with iOS, Android, Flutter and React Native SDKs.

Impact of Screen View on Performance

Each screen_view event is a network data send. If an app sends screen_view on every tab switch (20+ per minute), it creates unnecessary load. Optimization: buffer screen_view and send in a batch every 5 seconds. Firebase automatically aggregates events, but custom SDKs may send each call immediately.

Measure the overhead of tracking: add a timestamp to each screen_view and calculate the delay from onResume to sending. If the delay exceeds 100 ms, tracking affects UX. Use a background thread for sending to avoid blocking the UI thread. On low-end devices, the difference is noticeable.