Screen flow & screen_view

What is screen_view?

Each time a tester lands on a logical screen in your app, the SDK can record a screen_view event with a screen_name you control (or derive from your navigation graph). Events batch to the same ingest API as sessions and heartbeats.

On the server, transitions and dwell time are inferred from the order of screen_view events within a session — you do not send separate “screen exit” events.

What organizers see in Dozenflow

When screen_view data is present, Stats includes screen flow views: top screens, common paths, and funnels built from real tester navigation. Without screen events, session and roster metrics still work — screen flow stays empty until you integrate tracking.

Screen flow is an organizer feature in the Dozenflow app and web dashboard. Testers only need your APK with the SDK; they do not need Dozenflow for basic screen_view telemetry.

Ready now — Android

These Maven artifacts are published and documented for production use:

Version 0.2.17 on Maven Central. The navigation module does not pull Compose into apps that only use the core SDK.

Manual tracking (any UI stack on Android)

Call trackScreen whenever the user-visible screen changes — works with Views, custom engines, or before you wire auto-tracking:

ClosedTest.trackScreen("Home")
ClosedTest.trackScreen("Settings")
ClosedTest.flush() // optional: force upload

Also available: trackInteraction, trackEvent. See manual events in the core SDK guide.

Navigation Compose auto-tracking

Add the optional artifact alongside the core SDK:

dependencies {
    implementation("com.groundspaceteam:closed-test-sdk:0.2.17")
    implementation("com.groundspaceteam:closed-test-sdk-navigation-compose:0.2.17")
}

import io.closedtest.sdk.navigation.ClosedTestScreenTracking

@Composable
fun AppNav(navController: NavHostController) {
    navController.ClosedTestScreenTracking()
    NavHost(navController, startDestination = "home") {
        composable("home") { HomeScreen() }
        composable("settings") { SettingsScreen() }
    }
}

By default, screen_name is the route template from the graph (e.g. profile/{userId}) — query strings and resolved argument values are omitted to reduce PII risk.

Custom names:

navController.ClosedTestScreenTracking { destination ->
    when (destination.route) {
        "profile/{userId}" -> "profile"
        else -> ClosedTestNavScreenNames.fromRoute(destination.route)
    }
}

Outside Compose, use navController.installClosedTestScreenTracking() and close the handle when the Activity is destroyed.

Platform roadmap

All bridges target the same ingest contract (screen_view + screen_name). Server and Dozenflow stay stack-agnostic.

Cross-platform design notes: CROSS_PLATFORM_SCREEN_GRAPH.md in the SDK repository.

Naming & privacy

• Choose stable, low-PII screen_name values — avoid emails, usernames, or raw IDs in names.
• Prefer route templates or semantic labels (checkout, profile) over dynamic paths.
• Follow the ingest spec for allowed event fields — see the SDK repo spec.md.

Further reference

• Closed Test SDK — integration guide
• SDK_USAGE.md on GitHub
• closed-test-sdk repository
• Easy start (5 steps)
• Sign in to web dashboard