Data Destinations

Data Destinations is available as an add-on feature. If you are interested in adding this to your account, please reach out to your account representative for more details.

When FullStory is deployed on your site or app, we ingest a massive amount of raw data that we then clean and structure into analytics-ready event data. All this data is used to power FullStory's search and digital experience analytics features when you want instant, out-of-the-box analysis. However, there are times when you need to dive deeper into the data to truly understand custom use cases. FullStory has already captured the most complete product experience dataset, and now we are making this data available to our customers via Data Destinations.

What is Data Destinations?

Data Destinations enables FullStory customers to sync their digital experience data directly into their cloud data warehouse, such as Snowflake or Google BigQuery. FullStory will manage the structuring, delivery, and deduplication of captured events without customers needing to engage their engineering teams to build custom ETL pipelines.

With Data Destinations, you can merge FullStory's digital experience with data from your other essential business platforms to get a complete picture of your business's health. Now, every analyst at your company can explore FullStory data directly through their preferred SQL interface or an existing Business Intelligence tool.

When should I use it?

Data Destinations is the answer for customers who want to integrate FullStory's digital experience data into their internal reporting pipelines. With this technology, FullStory will sync all the events captured from your product into your data warehouse in an analytics-ready format so that you can monitor the metrics that matter most to your business. Perform robust analyses of your product and model KPIs relevant to your business.

How does it work?

We will manage a regular sync process that directly pushes all captured user events into your warehouse. We'll also handle all of the logic around retries and deduplication to ensure that you always have the most accurate data at your fingertips.

Integrations

There are two supported integrations. Please review the additional documentation that supports installing these integrations:

• Snowflake

• Google BigQuery

• Amazon Redshift

Note: FullStory only supports one active destination per org

How to enable

To get started, navigate to Settings > Integrations > Data Destinations and select Snowflake BigQuery or Redshift, depending on which warehouse you use to store your data. Once you've saved your credentials, the integration will push data to your warehouse for as long as the integration remains active. Keep in mind only one destination is supported at a time. If you want to change destinations, remove any existing Data Destinations integrations first.

FullStory's approach to data

Built to Support Planned Workflows

The Data Destinations feature is designed for customers with dedicated analytics support who want to automate their data ingestion and reporting process. This feature will only sync data captured when the integration is active and will not sync data retroactively. To ingest all the data FullStory processes, you should activate a destination when installing the FullStory JS tag or SDK.

Future Proof Schemas

FullStory has designed our data model around an expectation for two main types of data: required fields and conditional fields. For fields that are required on every event, we have extracted those fields into a dedicated top-level column. Our goal is to avoid sparse data in the raw table, so any field that is conditional to the event type is packed into the source_properties or event_properties columns as JSON objects. This data model allows FullStory to add new event_types and properties without having to run costly data migrations every time a new event is defined. FullStory will maintain a consistent and future-proof data model while enabling customers to handle denormalization and aggregation downstream.

Sync Interval vs. Update Window

Sync interval is a concept that tracks the cadence with which FullStory syncs new events to the warehouse. Captured events flow into FullStory constantly, then get bundled into a package each hour and pushed to the warehouse destination. All events ingested into FullStory's servers within that hour are included in the package.

Due to the nature of web traffic, distributed systems, and worldwide users, not all events will hit FullStory's servers chronologically. There are some scenarios where events come out of order, like swan song events that appear hours after they occur. FullStory's reporting pipeline treats pages and sessions as top-level entities. All events that flow into the system will be associated with a page, a session, or both. This relationship is then used to derive metrics like "session length" and "active time on page." When a late event is captured, FullStory will reprocess the page or associated session to "put the events back in order." When this reprocessing happens, FullStory will also push the updated events out to the warehouse, sometimes overwriting the data previously associated with that event. This is called the Update Window, or the rolling lookback period where FullStory may update events in the warehouse. For a small set of edge cases, events may be reprocessed after the update window, causing minor discrepancies between the FullStory UI and the data warehouse data. A very long update window reduces discrepancies but can make it harder to "close the books" from an accounting perspective.

Event Time vs. Processed Time vs. Updated time

Event time is an immutable field that records the timestamp of each event according to the user's device.

Processed time is a timestamp field indicating when the event was captured and processed by FullStory's servers. On average, 95% of events are captured and processed within 20 minutes of the original event time. Several events, including server side events, may reach FullStory's servers much later than the original event time. Depending on the contents of these late events, FullStory may need to reprocess them to report on the most accurate metrics, including session length, page active time, etc. In these scenarios, the Processed Time for all events in the session or on the page will be updated and the events will be re-synced to the warehouse.

Updated time is the equivalent of running current_timestamp in your warehouse every time a record gets inserted or updated. This field tracks the last time a record in your warehouse was changed and can be used as a filter to determine which new records to pull into your query.

Moving Analysis to the View layer

Our approach to support a future-proof data model means we are pushing all of the data FullStory captures into a pre-defined set of columns. This proves efficient from a data processing standpoint and sets clear expectations around the data contract. With that said, it has some implications when approaching queries. Specifically, FullStory's underlying events table needs to be unpacked and denormalized into analytics-ready models to make querying easier, especially for BI tools.

To help with this process, FullStory has published a set of DBT SQL transformations that you can deploy in your warehouse. These views will not solve every use case possible, but they aim to provide context around how the data can be transformed and explain how many of the metrics within FullStory can be calculated.

Event Source Info

Every event now contains contextual information about where that event came from and how the event was passed into the FullStory system. To keep your custom event payload from overloading with these extra parameters, we've implemented support for Source Properties. This will make it transparent where the event came from (web, app, or server integration) and which FullStory API endpoints were invoked to pass the event. You can easily QA your instrumentation by performing data quality checks against your other systems.

Source Properties Fields

User Info

User data, such as the user ID or custom user properties you pass through FS.identify, is available in the Data Destinations event data. All user data can be found within `identify` event types. This user information can be easily joined back onto all events using the device_id column. While this approach does require an additional join, it provides better support for sessions that are identified out of chronological order. If a session is identified after being synced to the warehouse, we emit one new identify event rather than updating existing records for that session.

Schemas and Event Definitions

Events Table Data model

Event Types and their Properties

These definitions are provided for informational purposes only. Please remember that you can only use this information in accordance with FullStory's terms.

Defined Events, Pages & Elements

FullStory now includes lookup tables in the warehouse for the defined events, pages, and elements that you create in the FullStory app so that you do not need to recreate these definitions in SQL logic.

The definition tables will be updated on each sync to reflect the current name and description set in the UI. As events are captured and processed by FullStory's event stream, we will evaluate the definitions of all active data objects at that point in time and enrich the event data with all matching object IDs. This object ID can be used to join back to the corresponding lookup tables for names and descriptions. The object ID can also be used to group and filter event data for analysis. For example, you could query for unique visits to your checkout page or for all click interactions with your "Sign Up" element.

Schema for Object Definitions

event_properties.event_definition_id

event_properties.additional_event_definition_ids

source_properties.page_definition_id

event_properties.target.element_definition_id

event_properties.target.additional_element_definition_ids

Due to the nature of the event stream, object IDs are only enriched from when they were created forward, similar to how FullStory reports activity in Journeys. This means that changing the definition of an existing object will only match applicable events from the time of that change forward. It will not apply retroactively to the historical data in your warehouse. See below for a diagram explaining the flow of how data is processed.

Example Data Flow Diagram for Defined Events

These lookup tables may introduce a many-to-1 relationship between events and object definitions. To account for this we have separated the most specific match, the one that will be used for analysis in the FullStory UI, from all other matching object definitions.

• For defined events and defined elements you will also see fields in the data for additional_event_definition_ids and additional_element_definition_ids respectively. Since multiple defined events can point to the same underlying event and multiple defined elements can point to the same underlying selector, we expose these so you are able to run different types of analyses in the warehouse from the behavior we apply in the FullStory UI.
• For the FullStory UI we choose the object with the most specific definition that matches the data, then we aggregate the data based on that object alone (ignoring the additional matches to avoid duplicate counts). The ID that you see in event_definition_id and element_definition_id will reflect that most-specific ID that will be used for reporting in the FullStory UI
• Multiple defined pages cannot point to the same URL

Note: This feature is available by default for all customers who activate Data Destinations after 9/11/23. If you activated Data Destinations prior to that date, please reach out to support to have this feature enabled.

FAQ

How often will data be synced between FullStory and my Data Destination of choice?

The FullStory pipeline syncs to your integrated warehouse on an hourly basis when your integration is active and correctly configured. Each sync contains the events processed by FullStory in the prior hour. Due to the distributed nature of the Internet and FullStory's capture pipeline, a complete set of events are not guaranteed to be available every hour. Any missing events will be reconciled automatically during subsequent syncs. We expose both event_time and updated_time columns in the data that can be used to tune your queries as needed.

Are there any plans to add other Data Destinations in the future?

Yes, we plan to add more destinations in the future based on customer demand. If there's a destination you'd like added, make sure to let us know.

I see more event types in the event filter list in the UI than I see in the data. Is something missing from the data?

No, All captured data is included in the Data Destination Sync. Some of the "events" that are shown in the UI are derived from the same underlying event_type. For example, "Refreshed URL" in the UI is a navigate event_type with event_properties:navigate_reason= 'reload' in the warehouse.

There are a number of events that have a NULL event_type. What are those records representing?

FullStory's data capture pipeline is heavily distributed, so there is no guarantee that events arrive (through our ingestion pipeline) in chronological order. As our pipeline processes these events, it associates them with a view_id and orders them chronologically. If an event is synced to the warehouse and then FullStory receives a new event for the same view_id with an older timestamp, both events will be updated so they are in order. This will create two new events in the warehouse and null out the previously synced event.

Is it possible to configure event types that we do not want to sync? For example, if we decide that we do not want "change" events, is it possible to not have those sent?

Currently, FullStory only supports syncing all captured events to your warehouse. Events that you are not interested in can easily be filtered out in your SQL analysis. We are exploring the possibility of adding event filters prior to the sync. If this is something you would be interested in, please reach out for more information.

I see two tables, one called events and another called raw_events but raw events is empty. Is that expected?

Yes, the raw_events table is used in the Snowflake data load process as a temporary staging table. This table may include some data while the hourly load process is running but should be empty at all other times. Consumers of the data can ignore this table and should only use the events table for operational queries.

Does Data Destinations support a Bi-directional sync?

Not yet, but we would love to hear more about any use cases you've got in mind or any workflows that you'd like to enable.

I see a slight discrepancy between FullStory UI metrics and warehouse data.

All timestamps in the warehouse are in UTC whereas the FullStory UI localizes metrics based on your browser's local timezone. To align these timezones, apply a timezone conversion from UTC to your local timezone in your SQL query.

Data Security Warning: If FullStory receives a data deletion request from a customer, and that customer's data has already been exported to their warehouse, FullStory will not be responsible for deleting the previously exported data, once it is out of FullStory's possession. Once the data has been synced to a customer's system, it is the responsibility of the customer to ensure the data is secure and that they adhere to all privacy, security, and other applicable regulations.