Skip to main content

Media Player

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
Percent Progress Boundaries

> Click the plus sign to add a new entry
Operation and Logic
The date to start processing events from in the package on first run or a full refresh, based on `collector_tstamp`
The maximum numbers of days of new data to be processed since the latest event processed
Number of days to limit scan on `snowplow_media_player_base_sessions_lifecycle_manifest` manifest
The maximum allowed number of days between the event creation and it being sent to the collector
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 look back over the incremental derived tables during the upsert
Percentage of a media needs to be played in order to consider that complete
Number of hours that needs to pass before new page_view level media player metrics from the `snowplow_media_player_base` table are safe to be processed
Minimum number of seconds that a media play needs to last to consider that interaction a valid play
Passed through to `dbt_utils` to match legacy surrogate key behavior.
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
Event names to process

> Click the plus sign to add a new entry
App IDs

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

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

> Click the plus sign to add a new entry
Warehouse Specific
(Redshift) Entities or SDEs

> Click the plus sign to add a new entry

Project Variables:

vars:
snowplow_media_player: 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_media_player:
base:
manifest:
+schema: my_manifest_schema
scratch:
+schema: my_scratch_schema
media_base:
+schema: my_derived_schema
scratch:
+schema: my_scratch_schema
media_plays:
+schema: my_derived_schema
media_stats:
+schema: my_derived_schema
custom:
+schema: my_scratch_schema
media_ad_views:
+schema: my_derived_schema
scratch:
+schema: my_scratch_schema
media_ads:
+schema: my_derived_schema
Was this page helpful?