EventDB data guide

Contact your account manager to activate EventDB for the appropriate profiles in your account. For information about configuring the attributes stored in EventDB, see Configure AudienceDB and EventDB.

EventDB stores event-level data captured by the Tealium Collect tag or other Collect library. EventDB uses EventStore as its data source and loads that data into Amazon Redshift for SQL-based querying.

How it works

EventDB loads data from EventStore in the following steps:

1. The Tealium Collect tag sends event data to EventStore, where it’s stored in an Amazon S3 bucket as flattened JSON.
2. When the S3 bucket reaches a size of 100 MB uncompressed or after one hour has elapsed, whichever comes first, the system compresses the data and prepares it for Redshift.
3. After compression, the system copies and imports the data into the Redshift database for your account.

New data is stored in EventDB within 30 to 90 minutes, depending on the load for the Redshift cluster.

Event feeds and tables

Each event feed is stored in the Redshift schema ACCOUNT__PROFILE, where ACCOUNT__PROFILE is your Tealium account and profile separated by a double underscore, for example mycompany__main. Within that schema, each event feed has:

• A base table named events__{event-feed-id}
• A view with descriptive column names: events_view__{feed-name}__{event-feed-id}

The event feed ID is the identifier for the feed in Event Streaming. To find the feed ID, go to Live Events, click the feed, and inspect the URL.

For example, for a feed named “Conversions” with ID 7f78639b-34c2-4f8e-a575-d132c1008c80 in the schema mycompany__main:

The All Events feed uses fixed names instead of a feed ID:

Column naming conventions

EventDB provides two ways to access the same data. The base table uses short, prefixed column names such as pageurl_full_url and firstpartycookies_utag_main_ses_id. The view uses descriptive column names such as event - page url - full_url and event - first party cookies - utag_main_ses_id.

This guide documents the base table column names. The following prefixes indicate the category of data:

Not all prefixes appear in every EventDB table. The following columns are always included:

• DOM attributes (dom_)
• Preloaded Tealium event attributes (udo_tealium_*, udo_ut_*)
• Tag execution data (tags_)
• First-party cookie values (firstpartycookies_)
• Page URL and referrer URL components (pageurl_, referrerurl_)

The following columns only appear if the corresponding event attributes are enabled for EventDB:

• JavaScript variables (js_)
• Page metadata (meta_)
• Custom data layer variables (udo_) — only present if the variables exist in your data layer

For more information, see Configure AudienceDB and EventDB.

Built-in columns

The Tealium Collect tag sends several predefined variables alongside the event data, as described in the following sections.

Default columns

DOM variables

DOM data from the page appears as columns prefixed with dom_. DOM attributes are always sent to EventDB and cannot be excluded. For more information, see Configure AudienceDB and EventDB.

Page URL variables

Referrer URL variables

First-party cookie variables

First-party cookie values use columns prefixed with firstpartycookies_. EventDB captures values from all browser cookies, not just utag_main. The column name reflects the cookie name and key. For example, firstpartycookies_utag_main_ses_id corresponds to the ses_id key in the utag_main cookie.

JavaScript variables

JavaScript variables from the page appear as columns prefixed with js_. The exact column names depend on the variables available on your site. Check your EventDB schema or Live Events to confirm naming.

For example, js_screen_availheight captures the available screen height, and js__tealplc_libraryversion captures the Tealium Private Label Cloud library version.

Meta variables

HTML metadata from the page appears as columns prefixed with meta_.

For example, meta_description captures the page meta description, and meta_og_title captures the Open Graph title.

Tags executed

Each tag that fires on an event generates a column in the following format:

tags_PROFILE_TAGID_executed

PROFILE is the Tag Management profile name and TAGID is the numeric ID of the tag. The value is true when the tag executed on the event, and (null) when it did not.

For example, tags_platform_3_executed indicates that tag 3 in the platform profile executed on the event.

Data layer (UDO) variables

Data layer variables sent with the event use columns prefixed with udo_. For example, a data layer variable named page_name maps to udo_page_name. The maximum character length for any single value is 255 characters.

The Tealium Collect tag also sends several built-in variables in the udo_ namespace:

Performance timing variables

Browser performance timing metrics appear as columns prefixed with udo_timing_. These metrics provide Real User Monitoring (RUM) data about page load performance.

If the value of a timing column equals zero, no timing information was captured. Ignore zero values when reporting or averaging.

Data retention

EventDB data remains available in Amazon Redshift for the length of time specified in your contract. When an event record reaches its expiration date, it’s automatically purged. For more information, see About AudienceDB and EventDB.

Calculate visitor timezone

EventDB doesn’t store the timezone for a visitor directly. To calculate the timezone, compare eventtime with firstpartycookies_utag_main_ses_id on the row where firstpartycookies_utag_main__ss equals 1, which marks the start of the session. Because eventtime is a UTC datetime and firstpartycookies_utag_main_ses_id is an epoch millisecond value, convert firstpartycookies_utag_main_ses_id to a UTC datetime before comparing. The difference between the two values represents the visitor’s UTC offset.

Sample row

The following shows a representative subset of columns from a single EventDB row:

The sample includes account-specific data layer variables such as udo_user_type alongside built-in columns. The data layer variables in your EventDB tables depend on your implementation.