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.
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
Step 2: Load the recording script
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:
Scrolling the window
Resizing the window
Touches (for mobile browsers)
DOM Mutations - aka changes to visual elements in the browser
Network requests (retrieving images, styles, or data from safe-listed backend services)
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: Performance and the FullStory Script.
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.
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.