Fullstory creates pixel-perfect renditions of user journeys for our customers so that they can find and eliminate frustration and provide the best user experience. Recreating every action for every user across thousands of websites is no small achievement. Our Fullstory script is the core technology that captures all of these events and sends them to our servers for search and replay. This article outlines the key features of our data capture technology and how our customers can manage the data capture process to prevent sensitive user data from being sent to our servers.
Bootstrapping
Browser events are the fuel that power the Fullstory engine. Before these events can be sent to Fullstory, our data capture script needs to be downloaded and run in the browser.
Step 1: Execute the Fullstory snippet in the browser
The Fullstory snippet is a small JavaScript statement that lives (ideally) in the <head> element of a web page. The snippet defines a handful of JavaScript API functions and begins downloading the fs.js script.
Step 2: Load the data capture script
The fs.js script is about 60Kb large and loads asynchronously, meaning that it won’t block other assets (like images and styles) from loading while it is being loaded. In other words, asynchronous loading prevents fs.js from interfering with the overall page load, ensuring that users see content as quickly as possible. The fs.js script contains all of Fullstory’s data capture code, JavaScript API code, and privacy exclusion code.
Step 3: Check Org settings
What’s an “Org” anyway? Orgs are how Fullstory refers to customer accounts. Each account gets its own Org Id, which is included in the Fullstory snippet. Each Org has distinct settings: session quotas, element exclusions created in the Fullstory app, and several configuration items.
Once fs.js is loaded, it requests Org settings via a call to a /rec/page URL and then applies those settings before anything is captured. It is also during this step that the fs_uid cookie is set. The fs_uid cookie is a first-party cookie that is used to group sessions together for anonymous users.
Step 4: Attach event listeners and begin capturing
The fs.js script attaches event listeners to all manner of browser events. These include:
-
Button clicks
-
Mouse movements
-
Scrolling the window
-
Resizing the window
-
Touches (for mobile browsers)
-
Key presses (of the nature, "some key was pressed", not tied to specific keys)
-
Page navigation
-
DOM Mutations - aka changes to visual elements in the browser
-
Network requests (retrieving images, styles, or data from safe-listed backend services)
-
And more
Web page elements that have been excluded will not send keystrokes, DOM mutations, or value change events to Fullstory's servers.
Note: Fullstory does not record keystrokes (as in the keydown or keyup events), but rather input change events which show text in an input.
All captured events are temporarily "bundled" in a queue on the browser and flushed to Fullstory's servers every 5 seconds via a call to /rec/bundle. Before events are sent to Fullstory's servers, all event data are compressed by upwards of 60%. This reduces the amount of data sent over the wire to Fullstory's servers. The entire bootstrapping process usually takes less than 300ms and is imperceptible by users. More details about Fullstory's script performance can be found here: Performance and the Fullstory Script.
Data Capture
Fullstory captures data on sites built with any framework (React, Angular, Polymer, etc.) and can capture any element outside of WebGL and plugins like Flash (we offer limited support for Canvas). Once the Fullstory script is up and running, it will continuously send events to Fullstory until the user navigates away from the site or closes the tab/browser. It will capture data across tabs and within any iFrame owned by the customer.
All HTML markup will be sent to Fullstory as well as any inline images and styles. Image or CSS references (e.g. the `src` attribute of an `<image>` element or the `href` of a `<link>` element) will be saved and then the assets will be fetched by a Fullstory bot and stored on Fullstory’s servers for future replay. During replay, any hosted image or css asset references will be rewritten to be retrieved from Fullstory’s servers rather than the customer’s servers.
If the site is not publicly available, Fullstory will enter Fallback mode during replay and will attempt to fetch assets from the customer’s servers. In this case, replay will work as long as the Fullstory customer is watching the replay on the same internal network where the internal site is hosted.
Privacy and consent controls
In addition to robust element exclusion controls, Fullstory provides an API that enables our customers to build data capture opt-in and opt-out user flows for their end users.
-
consentenables/disables data capture for individual elements or groups of elements -
shutdownandrestartwill turn of data capture entirely (shutdown) or restart it once shutdown (restart) -
Capture on startup will not capture anything until the
restartAPI call has been made
Our customers define the user experience for opt-in and opt-out while integrating with these APIs to control when and what events are sent to Fullstory.
Playback
Fullstory recreates the view that your users' see in their browsers by faithfully reconstructing all of the captured events exactly as they occurred during your users' experience. Some of these events are further analyzed to create frustration metrics (for example Rage Clicks, Dead Clicks, and Error Clicks) and stored in our search database creating filters and funnels.
Learn more by exploring our common technical questions.