How does FullStory recording work to recreate my users' experience?

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 web sites is no small achievement. Our recorder 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 recording technology and how our customers can manage the recording 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 recording 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 recording 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 recording 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 (“record page”) URL and then applies those settings before anything is recorded. 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 recording

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)

  • Keystrokes

  • 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. All recorded 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 (“record 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 recorder performance can be found here: https://help.fullstory.com/spp-ref/performance.

Recording

FullStory records sites built with any framework (React, Angular, Polymer, etc.) and can record any element outside of Canvas, WebGL, and plugins like Flash. Once the recorder is up and running, it will continuously send events to FullStory until the user navigates away from the recorded site or closes the tab/browser. It will record 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 that is being recorded 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 recording opt-in and opt-out user flows for their end users.

  • FS.consent enables/disables recording for individual elements or groups of elements.

  • FS.shutdown and FS.restart will turn of recording entirely (FS.shutdown) or restart it once shutdown (FS.restart)

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 recorded events exactly as they occurred during you 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.

Need to get in touch with us?

The FullStory Team awaits your every question.

Contact us