Skip to main content

Mobile

info

This package has been superseded by the Unified Digital that combines data from both web and mobile sources. For more information, see the Unified Digital page.

Package Configuration Variables

This package utilizes a set of variables that are configured to recommended values for optimal performance of the models. Depending on your use case, you might want to override these values by adding to your dbt_project.yml file.

note
All variables in Snowplow packages start with `snowplow__` but we have removed these in the below tables for brevity.

Warehouse and Tracker


Operation and Logic


Contexts, Filters, and Logs


Warehouse Specific


Config Generator

You can use the below inputs to generate the code that you need to place into your dbt_project.yml file to configure the package as you require. Any values not specified will use their default values from the package.

Warehouse and Tracker
Schema (dataset) that contains your atomic events
Database that contains your atomic events
Target name of your development environment as defined in your `profiles.yml` file
The name of the table that contains your atomic events
The users module requires data from the derived sessions table. If you choose to disable the standard sessions table in favor of your own custom table, set this to reference your new table e.g. {{ ref("snowplow_mobile_sessions_custom") }}
Operation and Logic
The maximum numbers of days of new data to be processed since the latest event processed
The maximum allowed number of days between the event creation and it being sent to the collector
The number of hours to look before the latest event processed - to account for late arriving data, which comes out of order
The maximum allowed session length in days. For a session exceeding this length, all events after this limit will stop being processed
Number of days to limit scan on `snowplow_mobile_base_sessions_lifecycle_manifest` manifest
The date to start processing events from in the package on first run or a full refresh, based on `collector_tstamp`
Number of days to look back over the incremental derived tables during the upsert
Session Identifiers

> Click the plus sign to add a new entry
User Identifiers

> Click the plus sign to add a new entry
Contexts, Filters, and Logs
App IDs

> Click the plus sign to add a new entry
Filter Platform

> Click the plus sign to add a new entry
Screen View Passthroughs

> Click the plus sign to add a new entry
Session Passthroughs

> Click the plus sign to add a new entry
User First Passthroughs

> Click the plus sign to add a new entry
User Last Passthroughs

> Click the plus sign to add a new entry
Warehouse Specific
The catalogue your atomic events table is in
(Redshift) Entities or SDEs

> Click the plus sign to add a new entry

Project Variables:

vars:
snowplow_mobile: null

Output Schemas

By default all scratch/staging tables will be created in the <target.schema>_scratch schema, the derived tables, will be created in <target.schema>_derived and all manifest tables in <target.schema>_snowplow_manifest. Some of these schemas are only used by specific packages, ensure you add the correct configurations for each packages you are using. To change, please add the following to your dbt_project.yml file:

tip

If you want to use just your connection schema with no suffixes, set the +schema: values to null

models:
snowplow_mobile:
base:
manifest:
+schema: my_manifest_schema
scratch:
+schema: my_scratch_schema
optional_modules:
app_errors:
+schema: my_derived_schema
scratch:
+schema: my_scratch_schema
screen_views:
+schema: my_derived_schema
scratch:
+schema: my_scratch_schema
sessions:
+schema: my_derived_schema
scratch:
+schema: my_scratch_schema
user_mapping:
+schema: my_derived_schema
users:
+schema: my_derived_schema
scratch:
+schema: my_scratch_schema