Snowplow Unified Digital Model
The Snowplow Unified Digital Model aggregates Snowplow's out of the box page view, screen view, and page ping events to create a set of derived tables - views, sessions and users - that contain many useful dimensions as well as calculated measures such as time engaged and scroll depth.
This model consists of a series of modules, each producing a table which serves as the input to the next module. The 'standard' modules are:
- Base: Performs the incremental logic, outputting the table
snowplow_unified_base_events_this_runwhich contains a de-duped data set of all events required for the current run of the model. From this table it also generates the
snowplow_unified_events_this_runtable, which coalesces multiple fields to combine web and mobile fields coming from different contexts / sdes.
- Views: Aggregates event level data to page view / screen view level,
view_id, outputting the table
- Sessions: Aggregates event level data to a session level,
session_identifier, outputting the table
snowplow_unified_sessions. Includes other events but requires at least one
page_pingevent in the session.
- Users: Aggregates session level data to a users level,
user_identifier, outputting the table
- User Mapping: Provides a mapping between user identifiers,
user_id, outputting the table
snowplow_unified_user_mapping. This can be used for session stitching.
While using any entity in our packages is possible thanks to modeling entities, a large set of common web and mobile entities are built into the processing of the package to add to your derived tables. Note these are in addition to those required to run the package.
|Enabled via Variable
|Enabled via Variable
|Core Web Vitals
Engaged vs. Absolute Time
At a view- and session-level we provide two measures of time; absolute, how long a user had the page open, and engaged, how much of that time the user was on the page. Engaged time is often a large predictor of a customer conversion, such as a purchase or a sign-up, whatever that may be in your domain.
Calculating absolute time is simple, it's the difference between the
derived_tstamp of the first and last (page view or page ping) events within that page view/session.
The calculation for engaged time on web is more complicated, it is derived based on page pings which means if the user isn't active on your content, the engaged time does not increase. Let's consider a single page view example of reading an article; partway through the reader may see something they don't understand, so they open a new tab and look this up. They might stumble upon a Wikipedia page on it, they go down a rabbit hole and 10 minutes later they make it back to your site to finish the article. In this case there will be a gap for those 10 minutes in the page pings in the events data.
To adjust for these gaps we calculate engaged time as the time to trigger each ping (your heartbeat) times the number of pings (ignoring the first one), and add to that the time delay to the first ping (your minimum visit length). The formula is:
and the below shows an example visually for a single page view.
At a session level, this calculation is slightly more involved, as it needs to happen per page view and account for stray page pings, but the underlying idea is the same.
Stray Page Pings (Web only)
Stray Page Pings are pings within a session that do not have a corresponding
page_view event within the same session. The most common cause of these is someone returning to a tab after their session has timed out but not refreshing the page. The
page_view event exists in some other session, but there is no guarantee that both these sessions will be processed in the same run, which could lead to different results. Depending on your site content and user behavior the prevalence of sessions with stray page pings could vary greatly. For example with long-form content we have seen around 10% of all sessions contain only stray page pings (i.e. no
We take different approaches to adjust for these stray pings at the page view and sessions levels, which can lead to differences between the two tables, but each is as accurate as we can currently make it.
As all our processing ensures full sessions are reprocessed, our sessions level table includes all stray page ping events, as well as all other view and ping events. We adjust the start time down based on your minimum visit length if the session starts with a page ping, and we include sessions that contain only (stray) pings. We also count page views based on the number of unique
page_view_ids you have (from the
web_page context) rather than using absolute
page_view events to include these stray pings, and account for stray pings in the engaged time. Overall this is a more accurate view of a session and treats the stray pings as if they had a corresponding
page_view event in the same session, even when they did not.
The result of this is you may see misalignment between sessions and if you tried to recalculate them based directly off the page views table; this is because we discard stray pings during page view processing as discussed below, so the values (
absolute_time_in_s) in the sessions table may be higher, but are more accurate at a session level.
For page views, because we cannot guarantee the sessions with the
page_view event and all subsequent
page_ping events are processed within the same run, we choose to discard all stray page pings. Without doing this it could be possible that you would get different results from different run configurations.
Currently we do not process these discarded stray page pings in any way, meaning that engaged time and scroll depth in these cases may be under representative of the true value. Due to session level reprocessing this remains a complicated issue to resolve, but please let us know if you would like to help solve this!