Screen view and engagement tracking
Screen view tracking captures screen changes within the app.
- iOS
- Android (Kotlin)
- Android (Java)
Screen View Tracking in UIKit
The screen view tracking for UIKit views is enabled by default. It can be set in TrackerConfiguration like in the example below:
let trackerConfig = TrackerConfiguration()
.screenViewAutotracking(true)
.screenContext(true)
Using method swizzling in the ViewController class, the tracker automatically detects when screens are loaded (triggered by viewDidAppear in a ViewController) and tracks events that include information about the current and previous view controllers.
Screen View tracking in SwiftUI
The tracker is able to track screen view events when selected view components appear in the SwiftUI lifecycle.
To provide this functionality, it implements an extension over the View component which lets you annotate the components the events should be tracked for using the snowplowScreen() function:
import SwiftUI
struct ProductList: View {
var body: some View {
List {
...
}
.snowplowScreen(name: "ProductList") // this will ensure that screen view events are tracked for this view
}
}
You can provide additional context entities to be tracked with the screen view events and also choose the tracker namespace to use:
import SwiftUI
struct ProductDetail: View {
var product: Product
var body: some View {
List {
...
}
.snowplowScreen(
name: "ProductDetail",
entities: [ // list of context entities attached to the events
(
schema: "iglu:com.acme_company/example/jsonschema/2-1-1",
data: [ "name": product.name ]
)
],
trackerNamespace: "ns" // namespace of tracker to track the event with
)
}
}
Screen View tracking in traditional Activity-based apps
The screen view tracking for Activities (screens) is enabled by default. It can be set in TrackerConfiguration like in the example below:
val trackerConfig = TrackerConfiguration("appId")
.screenViewAutotracking(true)
.screenContext(true)
Using the Android Application.ActivityLifecycleCallbacks interface, the tracker automatically detects when Activities are loaded and tracks events that include information about the current and previous Activity.
Screen View tracking in Jetpack Compose apps
Apps built with Jetpack Compose are constructed from Composable functions rather than Activities, and so the built-in ScreenViewAutotracking will not work.
One possibility for an equivalent functionality is to add a navigation listener, which can track a screen view for each new destination.
fun autoTrackScreenView(navController: NavController) {
navController.addOnDestinationChangedListener { _, destination, _ ->
Snowplow.defaultTracker?.track(ScreenView(destination.route ?: "null"))
}
}
Try out this example in the Compose demo inside the Android codebase.
Depending how your app is configured, this listener may result in a ScreenView being tracked when the app returns from background. This is not how the tracker is intended to work; our screen engagement feature tracks the time spent on a screen whether in foreground or background. If you are experiencing this extra ScreenView (and ScreenEnd) being tracked, consider adding a check to the listener callback.
Screen View tracking in traditional Activity-based apps
The screen view tracking for Activities (screens) is enabled by default. It can be set in TrackerConfiguration like in the example below:
TrackerConfiguration trackerConfig = new TrackerConfiguration("appId")
.screenViewAutotracking(true)
.screenContext(true);
Using the Android Application.ActivityLifecycleCallbacks interface, the tracker automatically detects when Activities are loaded and tracks events that include information about the current and previous Activity.
Screen view event and screen context entity
Automatic screen view tracking tracks two pieces of information:
- The tracker automatically tracks each screen change using a
ScreenViewevent. - If the
TrackerConfiguration.screenContextproperty is enabled, the tracker attaches aScreenentity to all the events tracked by the tracker reporting the last (and probably current) screen visible on device when the event was tracked.
The Screen entity is conditioned by the internal state of the tracker only. To make an example, if the developer manually tracks a ScreenView event, all the following events will have a Screen entity attached reporting the same information as the last tracked ScreenView event, even if it was manually tracked and the app is in a different screen.
Indeed, disabling the screenViewAutotracking only, the tracker can still attach Screen entities automatically based only to the manual tracking of ScreenView events, and vice versa.
Screen engagement tracking
This feature has been added in the version 6.0.0 of the iOS and Android trackers.
Screen engagement tracking is a feature that enables tracking the user activity on the screen. This consists of the time spent and the amount of content viewed on the screen.
Concretely, it consists of the following metrics:
- Time spent on screen while the app was in foreground (tracked automatically).
- Time spent on screen while the app was in background (tracked automatically).
- Number of list items scrolled out of all list items (requires some manual tracking).
- Scroll depth in pixels (requires some manual tracking).
This information is attached using a screen_summary context entity to the following events:
screen_endevent that is automatically tracked before a new screen view event.application_backgroundevent.application_foregroundevent.
Screen engagement tracking is enabled by default, but can be configured using the TrackerConfiguration.screenEngagementAutotracking option.
For a demo of how mobile screen engagement tracking works in action, please visit this demo.
- iOS
- Android (Kotlin)
- Android (Java)
let trackerConfig = TrackerConfiguration()
.screenEngagementAutotracking(true)
val trackerConfig = TrackerConfiguration("appId")
.screenEngagementAutotracking(true)
TrackerConfiguration trackerConfig = new TrackerConfiguration("appId")
.screenEngagementAutotracking(true);
Screen time
Screen time is tracked automatically by the tracker based on the screen view events.
Additionally, the tracker makes use of application_background and application_foreground events to distinguish between screen time in foreground (foreground_sec property in screen_summary entity) and screen time in background (background_sec property).
Make sure that lifecycle autotracking is enabled (it is by default) in order for the tracker to be able to distinguish between these two states.
The foreground time is translated into the engaged time during modeling with the unified dbt package (see below). Foreground and background time together result in the absolute time on screen.
List item view tracking
Part of screen engagement is tracking how much users saw on the screen. There are two ways that this information can be tracked:
- By the number of items in a list viewed on the screen.
- By the scroll depth on the screen in pixels.
The first approach assumes that there is a single list displayed on the screen, ideally with items of the same size. In this scenario, the track can track the index of the last viewed item and the total count of all items.
To provide the tracker with the information that a new list item was viewed by a user, the app will track a ListItemView event.
Although it is tracked as an event, the tracker won't send it individually to the collector (as long as screenEngagementAutotracking is enabled) but will process the information into the next screen_summary entity and discard the list item view event.
- iOS
- Android (Kotlin)
- Android (Java)
let event = ListItemView(
index: 1, // Index of the item in the list.
totalItems: 10 // Total number of items in the list.
)
Snowplow.defaultTracker()?.track(event)
Using the snowplowListItem modifier in SwiftUI
If you are using SwiftUI in your app, you can use the snowplowListItem view modifier to automatically track list item views.
Annotating the items in your list will ensure that they are tracked as they become visible.
import SwiftUI
struct ProductList: View {
var products: [Product]
var body: some View {
List {
ForEach(Array(products.enumerated()), id: \.1.url) { offset, product in
NavigationLink {
ProductDetail(url: product)
} label: {
...
}
.snowplowListItem(index: offset, itemsCount: products.count) // will track the ListItemView event automatically
}
}
.snowplowScreen(...)
}
}
val event = ListItemView(
index = 10, // Index of the item in the list.
itemsCount = 100 // Total number of items in the list.
)
Snowplow.defaultTracker?.track(event)
ListItemView event = new ListItemView(
10, // Index of the item in the list.
100 // Total number of items in the list.
);
Snowplow.defaultTracker.track(event);
Scroll depth tracking
The second approach for tracking how much users saw on the screen is to track the scroll depth in pixels. This may be useful in case you have a single scroll view on the screen which can be scrolled horizontally, vertically or in both directions.
To give the tracker the information of the scroll depth, one can use the ScrollChanged event.
Similarly like in the ListItemView event, this event won't be send to the collector as an individual event (as long as screenEngagementAutotracking is enabled) but will be processed into the screen_summary entity tracked with the next lifecycle or screen end event.
The ScrollChanged event contains information about the scroll offset as well as the content size (size of the content shown in the scroll view) and the dimensions of the scroll view on the screen.
To track the event in UIKit on iOS, for instance, you can make use of the scrollViewDidEndDecelerating and scrollViewDidEndDragging callbacks in UIScrollViewDelegate.
- iOS
- Android (Kotlin)
- Android (Java)
let event = ScrollChanged(xOffset: 15, yOffset: 30, viewWidth: 15, viewHeight: 20, contentWidth: 200, contentHeight: 100)
Snowplow.defaultTracker()?.track(event)
val event = ScrollChanged(
xOffset = 15, // Horizontal scroll offset in pixels.
yOffset = 30, // Vertical scroll offset in pixels.
viewWidth = 15, // Width of the scroll view in pixels.
viewHeight = 20, // Height of the scroll view in pixels.
contentWidth = 150, // Height of the content of the scroll view in pixels
contentHeight = 100 // Width of the content of the scroll view in pixels
)
Snowplow.defaultTracker?.track(event)
ScrollChanged event = new ScrollChanged();
event.setXOffset(15); // Horizontal scroll offset in pixels.
event.setYOffset(10); // Vertical scroll offset in pixels.
event.setViewHeight(20); // Height of the scroll view in pixels.
event.setViewWidth(30); // Width of the scroll view in pixels.
event.setContentHeight(100); // Height of the content of the scroll view in pixels
event.setContentWidth(150); // Width of the content of the scroll view in pixels
Snowplow.defaultTracker.track(event);
Modeled data using the Snowplow Unified dbt package
Starting with version 0.2.0, the Snowplow Unified Package will process the screen engagement information in the screen_summary entity to provide the following metrics:
- In the
snowplow_unified_viewsderived table:engaged_time_in_swill contain the screen foreground time.absolute_time_in_swill contain the screen foreground + background time.last_list_item_index,list_items_count, andlist_items_percentage_scrolledwill contain information about the number of viewed items in a list.horizontal_pixels_scrolled,vertical_pixels_scrolled,horizontal_percentage_scrolled,horizontal_percentage_scrolledwill contain information about the scroll depth in pixels.
- In the
snowplow_unified_sessionsderived table:engaged_time_in_swill contain the screen foreground time.absolute_time_in_swill contain the screen foreground + background time.
- In the
snowplow_unified_usersderived table:engaged_time_in_swill contain the screen foreground time.absolute_time_in_swill contain the screen foreground + background time.