How FullStory helps you get more from what you’ve got

Picture this: You’re a director of product at a startup that’s just getting its sea legs, let’s say one focused on SaaS. Your marketing team puts a meeting on your calendar to discuss a new website. This is amazing news from a visibility standpoint…but you’ve got to look beyond the launch and think about the data you’re collecting. Understanding who is going where and why they’re doing what they’re doing is vital to your company’s growth (not to mention your bonus). 

How can you keep data consistent from one application to the next? 

Many companies do this by starting with a data layer, a JavaScript object that collects data on your website in a standardized way. Every tool you connect to your website—analytics, heat mapping, chat bots, etc.—accesses this one layer of data, which ensures two things:

• Each tool gets the data it needs.

• The data each tool uses is the same.

What does a data layer do?

Most websites, softwares, and applications have a series of layers, each with a different purpose: 

• A presentation layer, which is what the visitor to your website sees. Oftentimes this layer is built using HTML and CSS.

• A data layer, the layer for collecting and managing the data produced. It’s a JavaScript object, often an array.

• An application layer with all the tools you connect to your website, like Google Analytics, Facebook Pixel, and more. These are usually JavaScript snippets.

Every website has a presentation layer, and almost every site has some sort of application layer. But not every site has a data layer to act as a dependable place to collect data as it’s generated. Without a data layer, data collection becomes the responsibility of other layers–and that’s a problem.

Here’s why: 

When you rely on the presentation layer to collect data, through processes like DOM scraping or CSS selectors, any change you make to the design or structure of your site will impact the data you collect. Small design changes can morph into huge data headaches. 

Using the application layer to collect data is problematic in a different way because each tool would be allowed to collect its own data, each in a slightly different way. For instance, a page in Google Analytics might have a different name than in Mixpanel. Although it might not seem like a big deal, think about how it would complicate something as simple as trying to make sense of your website’s overall performance. 

A data layer not only creates a dedicated place for data collection, but it’s also insulated from changes to other layers. Your stream of data won’t be subject to switching tools, design, or layout. It also makes sure each tool receives the data it needs to do its job. For example, say your new site needs some web analytics, so you turn to Google Analytics as well as Google Tag Manager (GTM) as your tag management system. With a data layer in place, implementing these tools won’t impact your website’s data. 

Put simply, a data layer can make your data more reliable and enhance functionality. What’s more, a data layer encourages your team to understand and align around data strategy.

The data layer and FullStory

Many FullStory customers have invested significant time and effort into building a data layer that lets them track custom events and user variables, often via data layers provided through vendors like Google, Tealium, or Adobe. 

As such, customers often ask how the data collected in  their  data layer can be made available in FullStory. Data layers contain important business data, including ecommerce conversion information and user profile data. It was through our work with customers that we discovered this rich vein of data that FullStory could mine to provide them more insights into the performance of their websites. 

Enter the Data Layer Observer (DLO, which is not to be confused with English rock band Electric Light Orchestra or ELO). 

FullStory’s DLO is an open source library we built to tap into a customer’s data layer(s): JavaScript objects curated on webpages during user sessions, used commonly by analytics platforms such as Adobe Analytics and Google Tag Manager. With this information, FullStory is able to automatically capture common data layer attributes and make them available in our application as custom events or user variables. 

Our out-of-the-box integration works with:

We have taken an intentional approach to data recording using vendor guidelines, and FullStory does not record user-specific information out-of-the-box. Here’s an example of how it works:

Maggie is a checkout product manager for a large ecommerce website. For years, her company has used Adobe Analytics to measure the effectiveness of different campaigns. She brought on FullStory hoping to gain more insight into the “why” behind what she’s been analyzing in Adobe. But since many of the variables she leverages in Adobe (e.g. cart total, element impressions, AB test cohort) aren’t available in FullStory, getting answers is a headache. It seemed her options were either to go without this data in FullStory, or (re)create custom events and fields for things that already exist in the Adobe data layer.  

With the Data Layer Observer (DLO) Maggie can get a script she can add to her site (similar to the recording snippet) to bring data layer variables into FullStory. All she needs to do is add “rules” that decide what variables will be observed. FullStory provided Maggie with a set of ready-to-use rules based on the CEDDL spec, and she got things squared away in no time. 

Interested in learning more? Check out this FullStory Knowledge Base article on DLO for additional information on how it works and how you can put it into action.