FullStory FAQs

If you are interested in changing your plan, please contact your Account Executive or [email protected] to learn more.

Note, if you're changing from a paid plan to a free plan, you can lose settings and data. Please read the specific details.

Can I update the billing contact or information in my account?

Yes! Navigate to Settings > Subscriptionto edit your company and billing details.

Does FullStory provide invoices?

Yes! Navigate to Settings > Subscription to find your past and upcoming invoices. Read more about invoices here.

What if the pricing has changed since I signed up?

Pricing does change occasionally, and you might find yourself on the sweet end of a legacy deal.If we make changes, you'll keep what you had in a Continuity Pack.You can keep that plan as long as you like, but once you make a change we won't be able to switch you back to your old plan.

Yes. FullStory for Mobile Appswith Private by Default technologyis available as an add-on to the FullStory platform and is compatible with applications on Android and iOS.

Note: FullStory for Mobile Apps is not included with free trials of the FullStory platform or with FullStory's Free edition.

About FullStory for Mobile Apps

FullStory for Mobile Apps includes and requires Private by Default technology that empowers product teams to debug experiences on native mobile applications while proactively respecting end-user privacy. Session replay for mobile apps isn't a screen recording and FullStory never captures screenshots from an end-user's device. Similar to FullStory for the web, where session replay represents a re-creation of a digital experience based on recorded changes in the DOM, FullStory's session replay for mobile apps is based on drawing operations, where text, images, and personal data are masked at the source by default, such that masked data never reaches FullStory's servers.

Interested in using FullStory to understand and debug mobile app experiences? Request a demo or contact us to learn how to add FullStory for Mobile Apps to your current account plan.

A note on Data Export

Access to Data Export is dependent on your FullStory plan. Please contact your Account Executive or [email protected] to learn more.

Additional note on Data Export

Looking to go deep with Data Export? Check out The Guide to Data Export. The guide will take you on a deep dive of why you would use Data Export, technical implementation details, and examples to explore with your own data. You can also find SQL recipes for querying Data Export data in the Data Export Cookbook.

When the FullStory JavaScript loads, every object, page event and interaction on your site is automatically recorded and indexed. This system of data collection is what allows our empathy inducing playback to be paired with a powerful search feature. We also use the information we’re collecting to bubble-up relevant, instant feedback for a wide audience, such as Rage Clicks, Error Clicks, and Dead Clicks.

Our primary purpose at FullStory is to provide the best tool possible for you to improve your customer’s experience. Since we’re indexing so many events, we’re aware that there is some pretty powerful data under the hood and much of it could be applied more specifically to your organization. We’re also aware that the programmers, data scientists, and software engineers you have on staff may be salivating at the thought of getting their hands on the hard data we’re collecting! So we designed a feature with your top priorities in mind.

What is Data Export?

The Data Export provides a periodic, raw data extract of events that have been recorded for your organization and an API endpoint to retrieve the data extracts.

Find a detailed overview of the Data Export via FullStory's Guide to Data Export, which includes a case study. See the Walkthrough for Building a Feature Usage Dashboard.

What information is available with Data Export?

See below for a full list of Data Export contents.

How do I use the information from Data Export?

The possibilities are endless! This data set can be used on its own or to supplement existing models that aim to analyze user behavior. You can simply use the data for providing your marketing team with a point and click analysis tool or you can plug it into your fraud detection (e.g.) algorithm to add extremely powerful data to your model. The point is, you know best how the data is most relevant to your business needs.

How often are Data Export files updated?

The data is provided to you in the form of bundles. By default, a bundle contains data about events that occurred during a period of 24 hours. This period can be changed to anywhere between 30 minutes to 24 hours. This bundle will be available to download 24 hours after the last event in this bundle occurred. For example, if your bundle period was set to 6 hours, a data export bundle corresponding to events that happened on Jan 1 between 9:00 AM - 3:00 PM will be available to download on Jan 2 at 3:00 PM.

How does user deletion interact with Data Export?

Data Exports are generated "on-demand," meaning the data in the JSON bundles are fetched directly from our servers at the time that the bundle is requested. Therefore, if you delete `Joe Smith` today and export data files tomorrow, Joe Smith's data will not be in those data files, as FullStory no longer has the user's data to include in the file.

If you are fetching data export files daily, the data that you pull down and store on your servers may include personal data. This means when a user requests deletion, you may also need to delete their data from the data warehouse where you are storing FullStory's data exports.

How do I access Data Export files?

There are two ways to access your Data Export extracts.

Via API: We have exposed an API endpoint to allow a more constant fetch of data.

You can also use this open source tool called Hauser to easily import data into Redshift

Manually: An extract can be downloaded from the FullStory app in one click. The data will be in JSON format and the file will be gzipped. You will have access within FullStory to the previous 100 extracts:

suspicious activity detection

How far back in time can I export data?

Data export availability matches the session retention length that you currently subscribe to. This means that if your account is configured for 2 months of session retention, you will be able to export data for sessions that are up to two months old. It is important to note that once sessions expire and are deleted, they are truly not recoverable.

External Integrations

Export FullStory data to Amazon Redshift or Google BigQuery

Data Export Contents

User/Session Fields

Name

Export Field Name

Description

User Id

UserId

A unique identifier for a user cookie on a given device/browser. This ID may be reset if the User clears their cookies, switches devices, changes browsers, etc. This field is not visible within the FullStory UIsee UserAppKey below for more information.

User App Key

UserAppKey

The user identifier that was passed to FullStory from your system using FS.identify. This field is visible in the FullStory UI as "User ID" when looking at a user's profile.

Individual Id

IndvId

A unique identifier for the Individual that combines all Users with the same User App Key. For example, if you’ve identified user 123 whenever they visit your site, their Individual will include all of their Sessions across devices, browsers, etc. The IndvdId value is not visible within the FullStory UI, but it is part of the session URL.

Session Id

SessionId

The identifier for a particular session, within the context of a single user. Use Session Id and User Id together as a compound key to uniquely identify sessions across all export data.

User Email Address

UserEmail

The email address that was set via FS.identify or FS.setUserVars.

User Display Name

UserDisplayName

The display name that was set via FS.identify or FS.setUserVars.

IP Address

PageIp

The IP address captured at the start of the session.

Custom User Variables

(custom var name)

If you're passing any user variables into FullStory, we'll include them in the export. Each additional variable will appear as a separate field in the export file, where the field name is the variable name as provided to the FS.setUserVars function. Note that, if loading export bundles into Redshift or BigQuery with hauser, the custom variable fields are amalgamated into a single JSON document under a field named “CustomVars” prior to import into the export staging table.

For more information about understanding user and session variables, see From Individual, User, and Session ID to replay.

Page Fields

A “page” tracks each instance when a user loaded a page with a particular URL. The "PageId" is an Id that indicates the page was loaded or refreshed from the web server. A series of events for a single session can have one PageId and multiple PageURLs if it is a Single Page App that loads from the server once (one PageId) and then changes URLs without loading from the server again (a common pattern).

Name

Export Field Name

Description

Page Id

PageId

The identifier for a particular page load/refresh, within the context of a single session. Use Page Id, Session Id, and User Id together as a compound key to uniquely identify pages across all export data.

Page URL

PageUrl

The full URL of the page on which the given event occurred.

Page Duration

PageDuration

The total time this User spent on this page during this session (milliseconds). This is not a running total; every event for a given page will show the same total duration.

Active Page Duration

PageActiveDuration

The active time (mouse movement, text entry, clicks, etc.) this User spent on this page during this session (milliseconds). This is not a running total; every event for a given page will show the same total duration.

Page Referrer URL

PageRefererURL

The page from which the user reached this page. The referrer may be empty if the user manually entered the page URL, or if the referrer has been scrubbed, etc.

Event Fields

Name

Export Field Name

Description

Event Time

EventStart

The absolute time when the event occurred, in UTC, represented as a dateTime from the XML Schema Specification, e.g. 2018-01-04T20:07:11.191Z.

Event Type

EventType

The type of event that was recorded. Typical types are:

“abandon”: A form was abandoned. Learn more about form abandonment.

“change”: The text in a text entry field was changed. The Event Target Text field will contain the new text value.

“click”: An element on the page has been clicked. The Event Target Text field will contain text of the clicked element, if applicable.

“navigate”: a URL change, either to a completely new page or a new hash fragment.

“thrash”: The user moved the mouse cursor erratically or in circles. Learn more about thrashed cursors.

Event Target Text

EventTargetText

Where applicable, this contains the text of the event target and its child elements. For example, if the user clicked a button that says “Pay now”, the event target text would be “Pay now”. Long text may be truncated in some cases for performance reasons.

Event Target Selector

EventTargetSelectorTok

Where applicable, this contains the CSS selector for the event target. This will be a fully qualified descendant selector, starting from the HTML element, and including all CSS selectors of elements that appear in the DOM when walking from the HTML element through its children to the event target. Most non-alphanumeric characters within a selector will be encoded, e.g. “.my\%2Dclass” rather than “.my-class”.

Behavior Heuristics

For some events, one of a series of modifier fields will be set to provide additional information regarding user behavior.

Name

Export Field Name

Description

Rage Clicks

EventModFrustrated

Your customer clicked one or more elements on the page many times in rapid succession, potentially because they were frustrated. For each of the click events in this series of clicks, the numeric value of this field is a running total of the number of clicks that have occurred. It will be zero for click events that were not part of a series of rage clicks. Learn more about rage clicks.

Dead Clicks

EventModDead

Your customer clicked something, but nothing happened. Will be 1 for dead clicks, zero for non-dead clicks.

Error Clicks

EventModError

Your customer clicked something and a console error was generated, either by an actual error occurring, or by logging an error to the console. Will be 1 for error clicks, zero for non-error clicks.

Suspicious Actions

EventModSuspicious

Your customer entered text or navigated to a URL that was suspicious. When set to zero, nothing was suspicious. When 1, it indicates a possible SQL injection attack. When 2, it indicates a possible cross site scripting attack. Learn more about .

Console Statistics

Name

Export Field Name

Description

Console Infos/Logs

PageNumInfos

The number of times the JavaScript function console.log() was called, plus the number of times console.info() was called on the page. This is a running total for the page, and will steadily increase until the user navigates to a new page.

Console Warnings

PageNumWarnings

The number of times console.warn() was called on the page. This is a running total for the page.

Console Errors

PageNumErrors

The number of times console.error() was called, plus the number of JavaScript errors that occurred on the page. This is a running total for the page.

Environment Fields

Name

Export Field Name

Description

Latitude/

Longitude

PageLatLong

The latitude/longitude corresponding to this session. These values are derived using IP geolocation, which is only capable of pinpointing a user’s general area, often just at the city level, not their exact location.

User Agent

PageAgent

The full user agent string for the system on which this session was recorded.

Browser

PageBrowser

The browser that was used for this session, as derived from the User Agent. Current possible values: Chrome, Firefox, Internet Explorer, Microsoft Edge, Safari, Opera, Mobile App, Yandex, Robot, Unknown. New values may be added to this list at a later date.

Device

PageDevice

The device type that was used for this session, as derived from the User Agent. Current possible values: Desktop, Mobile, Tablet, Robot, Unknown. New values may be added to this list at a later date.

Operating System

PageOperatingSystem

The operating system type that was used for this session, as derived from the User Agent. Current possible values: Chrome OS, OS X, iOS, Windows, Windows Phone, Linux, Robot, Unknown. New values may be added to this list at a later date.

Dev Tools Fields

All of the following fields represents the duration (in milliseconds) since the page began to load until the corresponding event was fired.

DOM Content Loaded

LoadDomContentTime

DOMContentLoaded fires when the initial HTML document has been loaded and parsed. Often this milestone occurs before stylesheets, images, and subframes finish loading, so the DOMContentLoaded event occurs before a page is done painting.

Page Load

LoadEventTime

The onload event or "Page Load" fires when the whole page and all of its dependent resources have finished loading. Page Load often occurs later, after the point in time when the page is rendered and interactive for a user.

First Meaningful Paint

LoadFirstPaintTime

The First Meaningful Paint event relates to the moment when the biggest "above-the-fold" layout change has happened and when web fonts have loaded. We believe that this metric relates most closely to a user's experience in terms of perceiving a page to be "loaded".

The Conversions product is available for users who have purchased the Enterprise Edition. To learn more, ask for a demo from your Account Executiveor reach out to [email protected].

Looking for a deep dive on Conversions? Check-out the 4 part series designed to provide more details about the Conversions product. Use this article as a high-level overview to help you get started with Conversions.

1.Navigate to the Conversions tab

Office Hours

2.Adjust the Conversions Composer to select the funnel, cohort, date, and signals to consider

a. Create or Edit a Conversion Funnel by defining the event filters you want to analyze

Wondering about the difference between a Conversion Funnel and a Segment ?

b.Select the Segment of users you want to analyze by adjusting the Performed By filter

c.Adjust the Date Range to include sessions from a specific timeframe

d.Configure the Signalsthat could contribute to your list of Opportunities, including common points of friction, Custom Events and Watched Elements

3.Review the list of top opportunities to improve your Conversion Funnel

4.Select an Opportunity to open a more detailed Opportunity Analysis View

a.The Opportunity Summary provides an overview of the analysis

b.Watch sessions to gain context for users who did or didn’t have this experience and how it impacted their conversion

c. The Opportunity Detail and Breakdown provide more visibility into where this experience is impacting your Conversion Funnel

Already using Conversions, but interested in learning more? Check-out our4 part series of articles, sign-up for live training session, or set-up some 1:1 time with one of our Customer Success Managers during Hugging .

Content-Security-Policy tells the browser what your page should interact with, and that lets the browser stop it if something on your page (maybe something maliciously injected via something like an XSS attack) tries to interact with anything else.

The content of this article is intended for developers with a technical background to get FullStory up and running in an environment where CSP is enforced. It's not intended to prescribe best practices for how your site should approach security as it relates to CSP.

In addition to whatever permissions your site needs without FullStory, there will be two CSP directives that you need to include with FullStory.

connect-src: https://rs.fullstory.com

script-src: https://edge.fullstory.com https://www.fullstory.com

We need connect-src to make connections from your visitors browsers to our servers, to report on the pages the visitors use, and report the events that happen on those pages. There are three pieces of code that will be used by FullStory:

The recording snippet that downloads the recording script (fs.js);

The recording script, fs.js;

Code for any integrations that you may be using with FullStory.

Each of these will require some work to include with your site.

CSPv2 and Script-Src hashes

In its first version, CSP either doesn’t allow inline scripts (that is, script loaded any way except <script src=”www.somewhere.com/path/to/some.js”/>), or it allows any inline script, which is a problem because of XSS and similar injection attacks. In the second version of CSP, however, you can specify which scripts you’re willing to allow to be inline. Of course, because the web is what it is, not all browsers support CSPv2 yet.

We much prefer for the recording snippet to be inline. We prefer it because it starts recording sooner (no waiting for the snippet to load separately), and because not doing it inline means you either have to wait for a synchronous load (which slows your site down) or you need to do extra work to know when you can use our API calls like FS.identify(). An inline snippet solves both problemsbut you need CSPv2 to make it safe.

To use CSPv2, just need to add a hash to the script-src CSP directive above, something like this:

script-src: https://edge.fullstory.com https://www.fullstory.com '[YOUR HASH HERE]'

**That hash is an invalid example; don’t cut-and-paste it.

The correct one for you is going to depend on your snippet, because that contains your orgId, so it’s going to be different for each of our customers. (The hash also changes if you have a trailing blank line or extra spaces, so be careful.) There are websites to compute it for you if you paste the snippet into the site, and it can also be computed using the OpenSSL command

echo -n "snippet value" | openssl dgst -sha256 -binary | openssl enc -base64

The easiest method may be to (in development) use a CSP that doesn’t have the hash, and the browser console will tell you the right value. For example, you will see a message such as:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-ZznlC9tUx8IcYnPzR8RnQYigA4/Vzq86uY90/LM0qcI='), or a nonce ('nonce-...') is required to enable inline execution.

In this case, the hash (sha256-ZznlC9tUx8IcYnPzR8RnQYigA4/Vzq86uY90/LM0qcI=) can be included as part of the script-src directive.

Integrations and inline scripts

If you use any of our integrations, keep in mind that by default, those integrations are injected also, which means they are also flagged as “inline” scripts. You have one of two options in this scenario:

You need a separate hash for each of the inline scripts that will be inlined. As with the snippet, the browser’s console will tell what the value for each integration’s hash should be, too.

or

You can set the value of window["_fs_csp"] = true in the FullStory snippet. This will cause integration scripts to be loaded in a separate script request (rather than being inlined). This may be a bit slower from a performance perspective (accounting for the extra time to make the separate requests for the script), but it removes some of the complexity of having to account for the hash of the integrations.

Again, not all browsers support CSPv2 yet. Relying on it means that old versions of Safari, any version of Internet Explorer, and some mobile or rarely-used browsers will be unprotected. Still, this is a good balance of protection and ease of use, and we expect that “trailing edge” to shrink, so it may be a good solution.

CSPv1 and ‘unsafe-inline’

If you don’t rely on CSPv2, you can always use a CSPv1 script-src with unsafe-inline, although it’s not what we recommend. Still, inline scripts can be hard to get rid of if you started your site with them, so if you already need unsafe-inline, you can use an inline FullStory snippet without adding any new vulnerability. And if your other CSP directives are tight, even if you assume that some sort of injection has put “bad” inline script onto your page, the other directives can prevent any exfiltration as a result, or injection of big or changeable scripts via a <script src=.../> tag. So this is at least an easy way to get many of the benefits of CSP and to limit your exposure. And it is super easy; just include that script-src and the connect-src directive, and you don’t need to worry about anything else.

In this scenario, the script-src tag looks like:

script-src: https://edge.fullstory.com https://www.fullstory.com 'unsafe-inline'

(Note that support for CSPv1, while more prevalent than CSPv2, is still not universal. For example, Internet Explorer 11 and below only support the sandbox directive.)

CSPv1 without ‘unsafe-inline’

Alright, if you can’t use CSPv2, and you’re unwilling to use that unsafe-inline keywordyou do still have an option, although of course it’s the most complicated one.

Your CSP header is going to have, in addition to whatever else your site needs:

connect-src: https://rs.fullstory.com

script-src: https://edge.fullstory.com https://www.fullstory.com 'self'

The complication isn’t what you put into your CSP header itself, it’s what you do with your recording snippet. That is either going to be embedded into your own JavaScript code, which you must be loading from some source URL already, or it’s going to be replaced with something like:

<script src=”https://my.site.com/fs-snippet.js”/ async>

The async keyword is important; that’s what keeps FullStory from slowing your page load at all. And that fs-snippet.js URL is going to return the FullStory snippet from your settings page in our UI (or, we hope, from your web pages already using FullStory). That alone will load FullStory, without an inline script, only slightly slower than if it were inline.

If your site has code of your own, you might put the snippet into your script directly; we wrote it to be safe even if you do both and get two copies on a page somewhere. If you don’t put the snippet into your own script, you might need to add just a wee little bit to allow you to call e.g. FS.identify() whenever you need to:

normal recording snippet here

if (window[“_fs_loaded”]) {

window[“_fs_loaded”]();

}

Those three extra lines are useful so that, elsewhere in your code, you could define window[_fs_loaded] as a function to call FS.identify() only after the snippet had defined the FS namespace object and the various functions in it, something like this:

if (window.FS) {

FS.identify(strUserID);

} else {

window[“_fs_loaded”] = function() {

FS.identify(strUserID);

};

}

You need this because, due to the async load of the snippet, you can’t know whether your code will run before or after the snippet does. If the snippet loads first, and your code after that, the direct call to FS.identify() runs. If your code loads first, and FS with its functions isn’t yet available, a call to FS.identify() is saved in window[_fs_loaded] and will be run later. (If you need to, you can make a fancier version that chains multiple calls, or makes _fs_loaded be an array and loop so all the functions in it are called).

If you have questions, feel free to reach out, and we’re happy to help.

Closing Thoughts

Remember, it’s always good to first test your proposed CSP with a Content-Security-Policy-Report-Only header. If you already do something with CSP but want to tighten it (for example, to chase away unsafe-inline), you can deploy a “new” policy in the CSPRO header, while still enforcing an “old” policy with Content-Security-Policy. But you definitely want to be sure the report-only header doesn’t generate any reports before you start enforcing it and accidentally break your site!

If you do use CSPv2, the hashes will occasionally change, and you’ll need to update your policies. But the snippet is under your control, so you’ll know to do the CSP update whenever you update your snippet, and it will be stable apart from that. Similarly, if you add or remove any integrations, that will change the hash of the integrationsI would leave both the old and the new ones in your CSP for a bit, to account for possible caching as you migrate.

References

https://content-security-policy.com/ has a pretty useful description of the various CSP versions, including which browsers support what. It also includes a browser test tool to see what your browser will actually allow (assuming you can get a copy of the browser you’re interested in).

https://www.w3.org/TR/CSP2/ is the official W3C candidate recommendation for CSPv2.

https://developer.mozilla.org/en-US/docs/Web/Security/CSP is, in effect, the specification for CSPv1. ( https://www.w3.org/TR/CSP1/ is an aborted W3C draft to codify CSPv1, but it discontinued as they skipped up to v2 instead.)

There are dozens of SHA256 generators; one is at http://www.xorbin.com/tools/sha256-hash-calculator. Please remember to be careful about keeping the whitespace exact in your input, because it does change the output!

Sure thing! You can download the W9 using the attachment link below.

Yes! For any search or segment, we'll provide a Top Users Searchie.

The Top Users Searchie will appear under your search results and will correspond to your current search query. You'll be shown users who have the most matching sessions for your current search. The events count is the total events in all of the sessions that match your search criteria for a user.

Click on the user details to view their user card and stats.

Hover a user and click on the magnifying glass to the right to add that user to your search criteria.

FullStory integrates with the popular team productivity tool, Trello, by allowing users to share noteworthy sessions directly to a Trello board as a card.

To enable and set up the integration:

Login to FullStory

Navigate to Settings > Integrations & API Keys

Click the Add button next to Trello.

Click the Authorize button, which will launch a new window (you may need to temporarily disable ad blockers if you have them installed) and open a Trello permissions dialogue. Choose Log in to let FullStory use your Trello account.

Once you've given permission, return to the FullStory window to choose a board and list where new Trello cards will be created. You can also enable and disable the integration from this dialogue.

Now that you're up and running with Trello, there are two methods for sharing sessions to your board:

Sharing from Notes

When viewing a session, click the green Note button to bring up the sharing dialogue. Type your comment and press Share to publish your note and a link to the session to your team's Notes tab.

Click on the Notes tab below the OmniSearch box to view your team's shares. Within each note, you'll see Send to:Trello.

Click the Trello link and the note will instantly be shared!

Sharing from inside a session

Click "Notefrom the playback bar to type a note

Once you've saved your message, find the green note in the right-hand actions timeline

Click the Send to: Slack Trello link to share your note out to the correct tool

Using FullStory, you can see the messages in the user's browser console upon playback.

FS.log() provides you a way to send messages to FullStory silently, without adding noise to the user's javascript console.

For example, here's a call to FS.log(). Note how the browser does not echo the text in its own console log.

Error Clicks

And here's how it shows up in FullStory:

To mark messages as errors or warnings, you'll need an additional argument, like this:

FS.log('error', msg)

Other things you can use for the first argument are 'log', 'info', 'warn', and 'debug'. If there's only one argument `msg`, it's interpreted as

`FS.log('log', msg)`.

This will allow you to search for and pages with large numbers of console errors or warnings:

The FullStory tag for Tealium provides a flexible way to deploy FullStory with Tealium IQ. Identify users, pass custom variables and custom events to FullStory from your Tealium data layer, all without a single line of code.

Table of Contents

1. Tag Installation

2. Standard Data Layer Destinations

3. User Data Destinations

4. Custom Variable Destinations

5. Event Destinations

6. Finding Sessions Using Tealium Variables

Tag Installation

The first step to deploying FullStory via Tealium is to add the tag to your website.

On the Tags tab of Tealium iQ, click the “+ Add” button.

In the Tag Marketplace search box, type “fullstory”.

Find the FullStory tag, and click “+ Add”. The Tag Configuration modal will appear.

In the modal, be sure to enter your Org ID, which is available in your recording snippet on a line that looks like window['_fs_org'] = 'AB123', where AB123 is the Org ID.

Optionally click Next and specify some load rules for the tag.

Click Finish.

Follow your usual process to save and publish the new tag.

After this minimal set of steps, FullStory will be deployed to your site per any load rules, and recording will begin.

Note: that this minimal configuration does not support identifying users or correlating FullStory and Tealium session IDs. To configure these features, continue to the additional data mapping described in the sections below.

Standard Data Layer Destinations

The behavior of the tag can be customized by mapping data layer variables to some Standard destinations defined by the tag:

fs_debug - Controls whether FullStory debug logging is enabled. When enabled, FullStory creates detailed logs on the browser console of its recording activities.

get_fs_session_id - Controls whether the FullStory session ID is sent from FullStory to Tealium. When enabled, the session ID is added to the utag_data object as fs_session_id.

get_tealium_session_id - Controls whether the Tealium session ID is passed to FullStory in any FS.identify and FS.setUserVars calls as the custom variable tealiumSessionId_str.

get_tealium_visitor_id - Controls whether the Tealium visitor ID is passed to FullStory in any FS.identify and FS.setUserVars calls as the custom variable tealiumVisitorId_str.

fs_consent - Indicates whether the current user has given consent for recording. When this destination is mapped, the parameter value is passed to FS.consent. A value of "true" indicates the user has given consent, and FullStory recording proceeds as usual. A value of "false" indicates the user has not given consent, and neither FS.identify nor FS.setUserVars will be called by the tag, to avoid recording any personal data. In addition, when fs_consent is "false" any elements that have been marked as requiring consent in your exclusion settings will be excluded from recording. Note that by default Tealium's built-in Custom Preferences Manager will remove the entire FullStory tag when a user opts out of the tag's assigned category. To avoid full removal of the tag, you must omit it from the set of tags controlled by the preferences pop-up.

Note: all of the above settings are expecting “stringly” typed boolean values, that is to say the string “true” or the string “false”, not the boolean value true or the boolean value false.

As always, don’t forget to save and publish any changes you make to the tag’s data mappings.

User Data Destinations

The minimal configuration described above does not allow for identified sessions in FullStory. To identify users, you must also provide a data mapping for the FullStory user ID. There are three pre-defined user data mappings available:

uid - Contains the unique application ID of the current user, and indicates to that the tag should call FS.identify rather than FS.setUserVars.

uservars.displayName- In the case when there is an identified user, optionally contains the user’s display name, e.g. Joe Schmoe.

uservars.email - In the case when there is an identified user, optionally contains the user’s e-mail address.

If the variables uid, uservars.displayName, and uservars.email are mapped to data layer variables containing the values 1, ‘Daniel Falko’, and ‘[email protected]’, respectively, the tag will make a call to FS.identify equivalent to the following:

FS.identify('462718483', {

displayName: 'Daniel Falko',

email: '[email protected]'

});

Important note: in order for users to be appropriately identified, a variable from the data layer must be mapped to the uid destination, and that variable must be appropriately populated. If the uid mapping is missing, or if the value passed from the data layer to the tag is null or empty, the user will not be identified. Instead of FS.identify, the tag will call FS.setUserVars.

Custom Variable Destinations

FullStory allows for users to specify any amount of custom data on top of user ID, name, and email address. These custom data mappings can be set with the “Custom User Var” option in the “User Parameters” data mappings for the tag.

Begin the data mapping as usual by selecting the variable to map and then clicking “Select Destination”. The mapping modal will appear.

For Category, select “User Parameters”.

For Destination, select the last option, “Custom User Var”

By default, the variable will be mapped to a destination named uservars.custom. Click the destination text at the top of the dialog to make it editable.

Change the name of the custom variable to the name you wish to see in FullStory. Make sure to use a naming convention consistent with the data type of the variable’s value.

Click Close.

You may create many custom fields with different data types, as long as each of them receives a unique name starting with the prefix “uservars.” The below screenshot shows an example where the standard email and display name fields have been defined, along with two string-type custom fields.

Event Destinations

If you are doing event tracking and/or link tracking with Tealium, you can also set up the FullStory tag to pass those events into FullStory as custom events. Every custom event in FullStory has both an event name and a set of custom properties that can be configured in the Tealium data layer. The relevant destinations are:

fs_event_name - This is a string containing the name of the custom event (see the FS.event API call for additional discussion of naming events). If you are using the Tealium Events extension, you should map this destination to the data layer variable tealium_event.

fs_event_object - If you wish to pass custom properties for the event as an entire, pre-built object, you can do so by mapping the data layer variable for that object to the fs_event_object destination. The object's structure must follow the same rules as the custom event properties for the FS.event call; in other words, it may contain nested objects and arrays of atomic values, but not arrays of objects.

fs_event.custom - If you wish to pass custom properties to the event singly, use the fs_event destination. This destination works similarly to the custom variable destination described above. As you map data layer variables, simply replace the text "custom" in the destination name with the property name that you want to pass to FullStory.

Finding Sessions Using Tealium Variables

You'll likely want to find sessions in FullStory using the Tealium session ID or the Tealium visitor ID. Both of these values will come into FullStory as custom variables, which means only the most recent value will be available in the user profile:

To search for older sessions with a specific Tealium session or visitor ID, add a “Any Activity” filter, then click the ellipsis to the right to show a list of custom fields against which you can search. Below is an example of searching by session ID, with one matching user:

Below is an example of searching by visitor ID:

Additional Notes

The tag makes heavy use of the _fs_ready callback. If you are writing extensions that include some some custom JavaScript code, please do not specify your own value for _fs_ready. Such an extension will override the functionality of the tag and stop information being passed between the data layer and the tag.

Yes! The option to save a segment will appear after you add at least one User Filter or Event Filter.

Click the Save Segment...button at the top of the page. Then, name your segment in the pop-up dialog and click Save segment.

Where you can find your saved segments

Your saved segment will appear in Recent Segmentson the left sidebar. It will also be available to the rest of your team by searching in the Find Segment... search bar orShow Allsection.

Note:You or any member of your team can the segment to keep it readily available in the Starred section.

Yes! When you save a segment, it's automatically accessible to your teammates. Teammates can view segments by clicking theFind Segment...search bar or the Show all link at the top and bottom, respectively, of the segment list.

Tip:You can sort segments by their creator and even search for a teammate's email address to see the segments that they saved.

Just started recording and not sure what to do next? This article includes how-to's for learning your way around in FullStory once you have sessions. Prefer to see it live? Join us for training or watch a recording.

Table of Contents

1. Get up-and-running

2. You've got sessions - now what?

3. Set your FullStory account up for success

Woo-hoo! Your FullStory recording snippet is successfully installed on your site, and you're ready to start using session replay to stay close to your customer's experience.

Here's a short list of things to explore next:

Try your hand at search

Save your first segment

Build your first funnel

Learn to navigate Session Replay

Add a segment to your FullStory Digest email

Try your hand at Search

See the big white box at the top of your screen in FullStory? That's OmniSearch.

Get setup OmniSearch lets you easily search for sessions related to specific people or other key data points.

To get started, click anywhere in the OmniSearch input box. FullStory will show a list of suggestions. Pause for a moment to take it all in. These are many of the available data points you can use to search across your sessions in FullStory (although there are plenty others you can discover by clicking the “More” buttons).

Next, start typing the word "clicked" in the OmniSearch input box. FullStory's suggestive search will narrow until it only shows you search criteria related to clicking. Typing into OmniSearch, as an alternative to clicking menu items, is a great navigational tool for the more keyboard-oriented among us.

Now, click on the suggested "Clicked anything" prompt.

The results are all of the recorded sessions where your customers or visitors have clicked on anything while navigating your site or web application.

Nice work! You've got your first search under your belt.

Get ready to save your first segment, or visit the Search Guide to learn more about OmniSearch.

Save your first segment

From your OmniSearch results, the next step is to save your first segment.

Saving segments is helpful for any searches you use frequently because you can revisit them later without needing to rebuild your search.

Click the "Save segment" button and give your segment a name you'll remember, like, for example, People Who Clicked Things.

Click "Save segment" to complete the segment creation.

Bam! Now you've got your first custom segment in FullStory. Your new segment will show up in the left-hand navigation under the "My segments" section.

Build your first funnel

Any time that you build a segment that contains two or more event queries, FullStory will intelligently populate a Searchie with an Event Funnel report showing the conversion rate from one event to the next.

Here's how to find a funnel:

In Omnisearch, just start typingfor any engagement. For example, start typing for some text that a customer might click in a button or a link name. Select an engagement from the suggested results in Omnisearch.

Then, go backup to Omnisearch and start typing again for some different text that a customer might click next after clicking the first link or button. Select that engagement from the suggested results.

FullStory will stack those criteria together under Event Filters.

Now, scroll down and look for the Event Funnel Searchie. The Event Funnel report will show you what percentage (\%) of users took both actions. You can click "More" to expand the details.

Remember: FullStory will build a funnel any time that two or more events (engagements) are included in a search or saved segment.

Learn to navigate Session Replay

With your basic FullStory housekeeping complete, it's a great time to dive in and watch some sessions.

From any segment, view the sessions list and hit the play button for any sessions to start session replay.

In Session Replay mode, you can:

Watch a customer's experience from their point-of-view

See the detailed event stream including searchable clicks, navigations, and more

Learn what browser, User Agent, or viewport size is related to a session

Pause session replay

Change the speed of replay

Choose to skip / or not skip inactivity

Toggle into Full Screen mode

Click 'Dev Tools' to find and debug errors during user sessions

Click 'Share' to make a Note about something remarkable that you notice during session replay

Click over to 'Page Insights' to find Click Maps and learn more about the most-clicked parts of any page

Need some big-picture ideas and inspiration about how to make the most out of session replay? Check out The Definitive Guide to Session Replay.

Add a segment to your FullStory Digest email

Now that you have sessions recorded, you'll automatically start receiving a weekly FullStory Digest email with summary statistics for your recorded data.

Out of the box, that email includes stats for common segments like Everyone, Mobile, New this week, Rage clicked recently, and Signed up.

You can also include your favorite segments in your digest email.

To see how this works, view your newly created custom segment and click "Add to digest" in the top-right corner of the results table.

Now your custom segment has been added to your FullStory digest.

Navigate to Settings > Notifications > FullStory Digest to see all of the segments included in your digest and to further customize the segments included in your email.

Well done! Now that you know how to search, segment, and replay sessions, you've got all of the basic skills you need to wield the power of FullStory to answer questions about your customer experience.

Don't stop now. Navigate forward to " Set your FullStory account up for success."

Recipe:

Which of my over $100 MRR customers have not tried out our new feature?

When you want to ensure customers are getting the most value out of your product, it is often helpful to know if they're using all of your product's features nd if they are using them fully. Use FullStory to see which of your customers have become experts with your new features and which customers may benefit from your helping hand.

Be sure to scope your search to your own business needs by including factors such as MRR/ARR, plan type, sign-up date, or integration status.

Ingredients:

Search

FS.identify or FS.setUserVars

Inspect Mode

Export .CSV

Method:

Use FS.identify or FS.setUserVars to assign plan information to your users. Examples:

Customer's lifetime spend, monthly recurring revenue (MRR) or plan level

Customer sign-up date

An attribute for users who have enabled an integration

Use Inspect Mode to bootstrap a search for users who have clicked on the button for your new feature. (In the below example, we are checking for customers who have clicked our new Help feature)

Modify the search to answer the question: Which of my greater than $100 Lifetime Spend customers has not tried out our new feature?

Add a "when statement" for lifetimeSpend(float) > is greater than > 100

Drag and drop the Click event down from the Event Filter section to the Exclude section so it appears like so:

This search now shows a list of users with a Lifetime Spend greater than $100 who have not clicked the help button

Export your search results as a .csv file to get a quick list of contacts to e-mail with tips and tricks about your new feature.

Recipe:

When are console errors being triggered in our app?

Too often bugs and errors are flagged by our users once they've encountered an error. With FullStory Error Clicks, you can quickly and easily find actions that are leading to errors and fix them proactively.

Ingredients:

Search

Error Clicks

FSTV

FullStory Console

Method:

Use the Error Clicks searchto filter to sessions where a click immediately triggered a console error.

FSTV

Use FullStory Dev Tools to view your JavaScript warnings and errors that were present at the time of the session.

Use to navigate through sessions quickly. Look for patterns of the same button or same pages that are causing errors.

The release of iOS 12.2 and Safari 12.1 changed how first party persistent cookies are handled for Safari users. The expiration of these cookies is hard capped at seven days since the user was last seen. First party cookies set via HTTP response is unaffected by this update and third party cookies will continue to be blocked, as per previous Safari updates.

FullStory uses these first party, persistent cookies to roll up sessions to the user/visitor level. Now that these cookies are force expired after seven days of not being seen, it can cause a perceived bump in the number of people you see in the FullStory Everyone segment, but not the number of sessions.

Safari ITP 2.1 could potentially inflate the number of People (above) you are used to seeing in FullStory, but not the number of Sessions (above)

While most of the effects of Safari ITP 2.1 relate to higher than previous user counts, above, there are two types of searches in FullStory that will yield higher than previous session counts, below. The New This Week Segment and multi-event searches that are across any number of sessions areboth affected by this change.

Safari ITP 2.1 can increase the number of People and Sessions for New this week (above, first) and decrease the number of People and Sessions for across any number of sessions searches (above, second) that you are used to seeing in FullStory

FullStory customers that are most affected by this update are:

Sites with a high amount of Mobile traffic because of Mobile traffic's greater percentage of Safari users

Sites with a low amount of identified usersbecause using FS.identify() api does not rely on browser cookies to identify users

Sites where visitors come to the site infrequently because the cookie renews if the user visits the site within a week

FullStory will continue pursuing short term and long term solutions to this issue, in accordance with our beliefs in end user privacy.

Recipe:

For new traffic this week, how many people land on the pricing page?

You've spent time calculating and perfecting your pricing strategy and then designing a page to communicate this information your new customers. Are they using it? Are they raging against it? Are they contacting Support with questions you thought you answered?

Ingredients:

Search

Searchies

Rage Clicks

Method:

While viewing the Everyone segment, click on New this week

To view new users who visited your pricing page add theEvent FilterVisted URL (path)> is > /pricing (enter the URL path for your pricing page here)

UTM

Scroll down to see visualizations of your results including Device Breakdown, Top Browsers, Top Referrers, and Top sources

Click into any of the Searchies to filter your search further.

Add theEvent FilterRage Clicked > On Anything to see if any customers took their confusion out on their mouse and your page.

Add theEvent Filter > Clicked > Help or Visited URL (path) > /help to see if they tried contacting or searching for Help after visiting the page.

Recipe:

Did the customer check the help center before writing in to support?

When customers reach out to support, they probably aren't randomly knocking at your door. It is possible that writing an email was their method of last resort, only after they had looked around in-app, scrutinized the knowledge base, and come up empty. Use FullStory to ensure you don't create a frustrating feedback loop for your customer.

Ingredients:

Search

FS.identify

Support desk integration OR FS.getCurrentSessionURL

Method:

Find the FullStory session URL associated with the support ticket.*

Watch the session to see if they interacted with your help center.

Alternatively, run a search for "visited page" "yourhelpcenter.app.com/article123" to check if they read the specific article you have in mind:

FS.getCurrentSessionURL

*3 Ways to Find the session URL:

Option 1

Search for the session in FullStory with a date and time range and identifying user details. In this example, we use their e-mail address, but for you this might be a Name, UID, or custom identifying variable.

Option 2

Using one of our Support integrations, retrieve the session directly from the support application. Here is an example of our Zendesk integration:

Option 3

Using, have a session link directly embedded in your support ticket:

URLs consist of multiple distinct parts. Understanding the components of URLs will make searching with OmniSearch easier.

OmniSearch gives the option to search for very specific things by allowing you to search for each of the pieces or the whole thing. FullStory will index each component of the URL (the host, all paths, and any queries), and then you can search for individual paths or query params. For example, if your URL has the path path/to/site, FullStory will index following paths:

/path/to/site

/to/site

/site

You can do a "Starts with" path search for each of the tokens above and it will match.

So, let’s say you’d like to create a search for the following URL: www.example.com/path/resource?id=123#section-id.

In OmniSearch, you have the option to search for the specific URL using Visited URL is www.example.com/path/resource?id=123#section-id, or you could search for one or more of the URL components:

Visited URL (host) is www.example.com

Visited URL (path) starts with /path/resource

Visited URL (query) is ?id=123

Visited URL (fragment) is #section-id

If you have any questions about creating a URL search, feel free to contact us.

create an alert

FullStory records everything*

*That is, FullStory records everything except sensitive data that you exclude from recording. It’s important to note that, when the simple piece of FullStory JavaScript loads, every object, page event and interaction is automatically recorded and indexed for search, so you can ask any question about any button or form field without having to add additional code to identify it as important or worthy of recording.

Getting started with search

Virtually anything about a user session is indexed, making search one of FullStory’s most powerful features. FullStory records all the granular data that exists on the periphery of a session (for example: browser, IP location, time of visit, referrer URL, UTM parameters, etc.) and allows you to search for any combination of those attributes. We also record everything that renders in the browser and events therein, such as clicks, page navigations, field changes, typed text, and more.

To begin asking questions of your data, simply start typing in the search omnibox at the top of the page.

Pro Tip: Use the keyboard shortcut `ctrl+/` to jump directly to the search box.

Once you click in the search field, you'll be presented with a quick launch menu of various things you can search for. You'll also see some tips that you can scroll through to get more search ideas.

Pro Tip: You can hide these tips by clicking the gray 'Hide Tips' text. You can get them back later by clicking 'Show Tips'.

Try typing anything and you'll instantly be given suggestions that match your typed characters. For example, if you're looking to find a user named Joe Schmo, start typing `J o` . We'll intelligently surface the top search hits for various fields that contain 'jo' and then you can click on the one that matches your intent.

Key features of OmniSearch

Scoped queries let you get precisely the result you want. If you are looking for "Rage Clicks" you may want to be more specific, such as looking for frustrated users in your checkout flow. Use the ellipsis to add a scope to your query. In this example, we've constrained our search to only those Rage Clicks that occurred on the Cart page:

URL search allows you to narrow down the sessions where a user visited a specific URL. Using an event filter allows you to specify different components of the URL such as host, path, query, and fragment. You also have the option to adjust the criteria from “is” to “starts with” if you want to broaden your search.

Here’s an example URL with each component specified:

URL:https://www.fullstory.com/path/example?query=123#section-fragment

host:https://www.fullstory.com

path: /path/example

query: query=123

fragment: section-fragment

Referrer URL is also available as an additional criteria to add a scope to your query. For example, you may be interested in sessions where your users arrived on a product page from a search. Each of these additional options allows you to search for and discover sessions that are most relevant to what you’re interested in.

Date & Time constraints let you narrow down your custom search to a particular period of time, such as only results from last week, or the day you introduced a new feature. You can also add time constraints to the custom date fields using the format MM/DD/YYYY HH:MM.

User count shows you the percentage of users who match your search out of the total number of visitors to your site. This number will show at the top of the search query and will update each time you modify your search.

CSS selectors

One of FullStory’s most powerful features is its ability to automatically index every resource that loads in the browser, making those elements searchable based on their CSS selector.

Every element on your page has a CSS selector (either an object type, class or ID) that identifies that object in the Document Object Model (or “DOM”). If you're unsure what a CSS selector is or how to find it, the best way is to use our Inspect tool.

Using Segments to Save a Search

Save a segment

Once you've zeroed in on your desired sessions, save your search by using the 'Save segment...' button.

You'll get a pop up menu that asks you to enter a name for your segment.

Once you have saved a segment, you will then have access to the segment options bar. This menu bar will allow you to rename a segment, duplicate a segment so you don't have to start from scratch, or delete an old segment. You can also add the selected segment to your e-mail digest or .

Your Segments and Team Segments

Your segments will be saved to the left-hand toolbar in the FullStory window. Some convenient segments have already been created for you. Your custom segments will be added to the My Segments section. You can also view all custom searches created by your team under Team Segments. Use the "Find Segment" filter at the bottom of the segments list to quickly find you or your teammates saved searches.

Yes! You can visit the New this week segment in your FullStory account or use the First seen query to build custom segments of new visitors.

Search for New Visitors with First Seen

One important fact about FullStory is that it coalesces all of a user’s sessions from all time. (Yep, every user session from the time you install FullStory to the moment you’re reading this sentence.) That means the users may have already visited your site, potentially days or months, before they actually signed up for your product or began a subscription with you.

If you're looking to find users who are truly landing on your site for the first time, use a First seenquery:

data retention settings

In fact, if you've ever clicked the New this week segment in FullStory (this is a pre-made segment that all FullStory accounts have in the left-hand navigation), then you've already seen the First seen query in action.

The criteria that powers that segment is: First seen > last > 7days.

One quick caveat

FullStory will automatically delete older sessions based on your, that is, the number of months of history you choose to keep in your account. When FullStory does this, any "user tip data" such as First Seenis preserved, even if the original session in which the user was seen had been deleted. For example, if someone first visited your site 6 six months ago but your data retention settings are 3 months of history, FullStory will report the first visit of the user as 6 months prior even though the session associated with that visit had been deleted.

The only exception to this rule is if, when FullStory deletes old sessions, allthe sessions for a particular a user are deleted, all of the "user tip data" for that user will also be deleted. This happens if someone e.g. visits your site once and never comes back. For example, let's say you retain 3 months of history. A customer visits on January 1 but doesn't return to your site. Around April 1, the sessions for that customer will be deleted, including the First seen value of January 1 for that customer. If the same customer returnsto the site, say, on May 1, FullStory will now report their First seenvalue as "May 1".

Hopefully you never come across a scenario this complex! But if you do, the above explanation should come in handy.

Recipe:

How can I understand what my customer is asking in this support ticket and reduce the number of e-mail communications?

When your customers write in to support, you don't always have the context needed to troubleshoot their issue or you may not fully understand their question. A FullStory session adds clarity, allowing you to view your customer's problem session to get a better understanding of the issue instead of creating a frustrating e-mail exchange for your customer due to lack of understanding.

Ingredients:

Search

FS.identify

FullStory Console

FS.getCurrentSessionURL or Support Integration

Method:

1) Find the FullStory session URL where the issue occurred.*

2) View the session to understand your customer's meaning more clearly. Look for clues to answer these questions.

What were their intentions?

What actions were they trying to take?

Where in the app did they encounter an issue?

What did they try before reaching out to support?

Did they encounter a known bug, or is this a training issue?

Were any console errors present during their session?

*3 Ways to Find the session URL

Option 1

Search for the session in FullStory with a date and time range and identifying user details. In this example, we use their e-mail address, but for you this might be a Name, UID, or custom identifying variable.

FS.getCurrentSessionURL()

Option 2

Using one of our Support integrations, retrieve the session directly from the support application. Here is an example of our Zendesk integration:

Option 3

Using, have a session link directly embedded in your support ticket:

Similar recipes you can cook up in FullStory:

Do our help docs address this issue?

What browser was my customer using when they encountered this error?

Have any other customers had this error on this page?

The burning question, of course, is whether people clicking on our ad are converting, or performing the action you wanted them to take on your site. This is where the incredible specificity of FullStory’s data collection really comes into play.

Whatever your conversion goal, it's easy to track, and unlike GA and other analytics tools, you don't have to set a goal or add a conversion-tracking script to your HTML ahead of time. You can even decide on a conversion goal and retroactively track it using the wealth of data collected by FullStory!

Keep reading for more info on how you can dive into understanding conversions using FullStory on any plan. But if you're interested in some advancedconversion funnel analysis, we'd love you to check outFullStory's dedicated Conversions product, available on the Enterprise plan.

Learn more about it in our Introduction to Conversions !

Building your conversion search

Think about your conversion action. What does the user actually do to fulfill this goal? What action do they take on your site? And how can you turn that into a FullStory search?

If your conversion action is to fill out a form, click a button, or otherwise interact with a certain element of your site, use the "Clicked" Event Filter.You can choose to search for click events based on either the text shown in the element or the CSS selector for that element. In our example we are looking for any user who clicked an element with the text "Purchase."

For the next step in our conversion funnel, we’re going to search on Visited URL > is, and enter

https://fruitshoppe.firebaseapp.com/#/confirm.

This is a page on our demo site that’s loaded every time a user successfully completes an order, so we can infer that anyone who’s visited this page has completed our conversion goal. Our resulting segment of converting users looks like this:

As you may have read in the FS.identify() and FS.setUserVars() articles, you have the ability to pass custom data into FullStory via the JavaScipt API. This article will go into depth about how you can use the power of FullStory OmniSearch to find specific events and sessions within FullStory.

Not only is FullStory search useful in searching for the most recent custom field data, but you can also search for historical custom field events. There's a bit of nuance to getting it right, so let's take a deep dive:

Custom Fields and the User Profile

When you send custom fields to FullStory, the data will show up in the User Profile:

The values for the fields correspond to the most recent event that set that custom field. We call this data the "user tip" because this is the tipor most recentof the data for this user.

In the example above for Ben McCormack, "Reeses" was the most recent event for the "Favorite Snack" field. The call to set this may have looked like:

FS.setUserVars({"favoriteSnack_str": "Reeses"})

Keep in mind that it may take a few minutes for the user tip data to be indexed and show up in the user profile in FullStory.

Searching Custom Fields in the User's Profile

When you do a search for a custom field in FullStory from within OmniSearch, you'll be searching for data that matches the User Profile.

Notice how the Favorite Snack custom field becomes part of the User Filter section of the search results:

This data corresponds to the User Profile that we looked at in the previous section of this article.

User Filters and Event Filters

When you do a search in FullStory, you'll notice User Filters and Event Filters.

User Filters

As explained earlier, the criteria in the User Filters section correspond to the data in the User Profile as it exists now, what we call the "user tip data". This part of the search always corresponds to the latest state of the data. User Filters are not affected by the time constraints (e.g. "Past month") in the top left because User Filters only looks at the current state of the user profile data, not what it may have looked like in the past. (It is possible to search for user profile data in the past, which we'll explore further below).

Event Filters

Event Filters provide a way to search for data related to the events that happened during a FullStory session. These events include visited pages, clicked elements, Rage Clicks, etc. Unlike User Filters, the criteria in Event Filters are affected by the time constraints in the upper left. So for example, if your time box is Yesterday, you'll only see events that happened yesterday.

User Filters with Event Filters

Following the example in the screenshot above, we're saying:

Show me all users who have a "Favorite Snack" value of "Reeses" right now....

....who clicked an element with the text "Purchase" within the past month

The User Filter is not constrained by timeit's always currentbut the Event Filter, is constrained by time.

Searching for Past Custom Field Data

Using Event Filters, you can "scope" the search to look for past custom field data. Here's an example:

In the above example, note that we're using an Event Filter to look for "Any Activity". We clicked the ellipses (...) to reveal the scope of the search, which allows us to search for the value of a custom field at some time in the past. This is because, when we're in the Event Filters section, we're searching for the actual events when the custom fields were set, not the current tip of user profile, as is the case with User Filters.

In the above screenshot, note how we're searching for when "Order Item" had the value "Cherries". Contrast this to the screenshot at the very top of the page, where you can see how the latest valuethe one stored in the User Profileis currently Mangcados. By using event search to search for data in the past, we're able to go beyond just the user tip.

Custom Vars and FS.log

One limitation to keep in mind when searching for custom field data in the Event Filters is that the FullStory UI when watching a session doesn't currently tell you when a particular custom field value was recorded. You can trust that the event did in fact happen within the session, but it may be difficult to tell exactly when it happened when watching the session. That being said, if you call FS.log() at the same time and with the same data as FS.setUserVars(), you'll be able to see the data in the FullStory console during playback. Here's an example:

function setUserVarsAndLog(data){

FS.setUserVars(data);

FS.log(data);

}

setUserVarsAndLog({"favoriteFood_str": "Bananas"})

Running the above code would show up like this within the FullStory console:

Going Beyond the User Profile

You can unlock many potential use cases for custom fields when you go beyond the User Profile data and begin using custom field data for search as well. Here are a few custom field ideas that, if implemented, would unlock new search opportunities:

Note when a user saw an error message. You would then be able to search for sessions when a particular error message was seen.

Note when a particular product feature was utilized. This would let you construct segments based on product usage.

Note when a customer has a particular attribute. For example, if you wanted to record account state, you could search for events where "Account State" was "In Trial".

With the power of custom fields and OmniSearch, you can take full control of what becomes searchable within FullStory.

The Signed-up segment works hand in hand with our FS.identify call.

FullStory considers "anonymous" users to be those that don't have a unique user ID assigned via FS.identify, and "signed-up" users to be those who do have a UID.

Note:It is possible to pass user information to FullStory, such as displayName or email address, and still have the user be anonymous. They will not be considered "signed-up" until the user ID has been assigned. This unique User ID is what we use to coalesce sessions for a single user across multiple browsers and devices.

When FullStory is deployed on your site, it's possible that your script is deployed successfully, but that recording is being blocked by FullStory's servers. When this happens, you'll get a numeric reason_code as to why it was blocked.

To test this, load the page in question with Chrome's Network developer tools open. If you search for fullstory, you should see a request to page. If recording is successful, you'll get an HTTP status code of 200 in return. If recording is blocked, you'll get a 202 status code in return. Click on the name of the request and then choose the Response tab to see the reason_code.

How do I delete a user?

Here are the reasons the script may be blocked:

reason_code

Reason

Additional details

-1

Unspecified

1

Account does not exist

Install the recording script again to make sure you have the correct org.

2

Account disabled

The account has been disabled. Contact us to learn more.

3

Over quota

You've exceeded your session quota. See What happens if I hit my quota before the end of the billing cycle?

4

Domain Filter

You've blocked this particular domain. See Can I disable recording for a specific domain?

5

IP Filter

You've blocked this particular IP address. See Can I block unwanted sessions by IP address or User-Agent or bot?

6

User Agent

You've blocked this particular User Agent. See Can I block unwanted sessions by IP address or User-Agent or bot?

7

Geography

You've blocked this particular geolocation. See Can I block or allow session recordings based on geography?

8

Traffic Ramping

If you have a large quota, we gradually ramp up your traffic level as you get started. Contact us is you believe this is affecting you.

9

Invalid URL

10

Opt Out Cookie

The user has globally opted out from being recorded.

11

Invalid Recording Script

The recording script on your site is outdated. Re-install the recording script from your account settings page.

12

User actively being deleted

You've deleted this user from FullStory, and FullStory will block recording while the user is being deleted. See

First, please make sure you have followed the instructions to to install the FullStory app in your Salesforce instance. Also make sure you have the appropriate permissions to edit page layouts in Salesforce Classic.

Configure the FullStory app

You'll need to set your FullStory API key in Salesforce so that the widget can fetch the user sessions from the appropriate FullStory account.

Login to FullStory and copy your API key from Settings.

From the homepage of the Salesforce Classic UI, select the "FullStory Settings" tab. If you're unable to see it in the homepage, click on the + icon at the top of the page and look for "FullStory Settings".

FS.identify

In the "API Settings" tab paste your FullStory API key in the text field and click "Save API Key." You also have the option to configure the number of FullStory sessions shown for each record with the "Sessions Per Record" field below. Please note, the more sessions you opt to show, the taller the FullStory component will be.

Click on the "Object Settings" tab. Here you can configure the set of objects for which FullStory sessions can be fetched and displayed, as well as how sessions will be fetched.

The FullStory app comes with configuration for the Case, Contact, and Lead objects. To add support for another object, click "Add." In the Object column, select the object for which you want to install the widget. In the example below, you will see we have added the Person object. In the Field column, select the field whose values FullStory should use for filtering sessions. You can use either an Email field or an External ID field that contains the FullStory user ID (this user ID must be the same user ID that is passed into the FullStory API call).

Also note that only objects containing an Email or External ID type field will appear in the object dropdown. When you have made the appropriate selections, click "Save Changes."

Create a Visualforce Page for the FullStory Component

The FullStory app includes a Visualforce page for Contact, Lead, and Case objects. If you want to see FullStory sessions on any other objects, you will need to create a Visualforce page first. Click "Setup" at the top of the page and search for Visualforce Pages with the help of the Quick Find box.

Click on Visualforce Pages and then click the New button to create a new Visualforce Page. Enter the required fields and paste the following code in the Visualforce Markup field:

<apex:page standardController="OBJECT_NAME" extensions="fullstory.FS_SessionsCtrl">

<apex:includeLightning />

<div id="lightning"></div>

<script>

var recordID = "{!$CurrentPage.parameters.id}";

$Lightning.use("fullstory:FS_Sessions", function() {

$Lightning.createComponent("fullstory:FullStorySessions",

{"recordId":recordID},

"lightning",

function(cmp, status, error){

});

});

</script>

</apex:page>

Replace OBJECT_NAME with the API name of the object that you’re installing this on.

For example:

Add the Visualforce Page to Layouts

Click Edit Layout in the object to which you’d like to see FullStory sessions.

In the layout panel, select Visualforce Pages. If you’re trying to add the widget to one of Contact, Case or Lead, you should be able to see a Visualforce page called “FullStory Sessions”. If not, you should see the Visualforce page created in the previous section. Drag and drop the Visualforce Page onto your layout and click "Save".

You should now see FullStory sessions in the configured page. You can click on one of the session links to watch the session in FullStory.

First, please make sure you have followed the instructions to to install the FullStory app in your Salesforce instance.

Create a Custom Domain

A custom domain in Salesforce (called "My Domain") is required before you can use Lightning Components in Lightning pages. If already have a custom domain set up, skip to the next section, "Provide API Key".

Click on the gear icon at the top right of your Salesforce Lightning page.

Click on Setup from the dropdown. A new tab will open.

FS.identify

Navigate to Settings > Company Settings on the left hand side nav bar and click on My Domain.

Here, you’ll be able to see if you’ve set up a custom domain. If you haven’t please go through the instructions provided on that page to create a custom domain.

Once successfully set up, you'll see this success image.

Configure the FullStory app

You'll need to set your FullStory API key in Salesforce so that the widget can fetch the user sessions from the appropriate FullStory account.

Login to FullStory and copy your API key from Settings.

In the Salesforce Lightning UI, click on the app launcher and navigate to All Items > FullStory Settings.

In the "API Settings" tab paste your FullStory API key in the text field and click "Save API Key." You also have the option to configure the number of FullStory sessions shown for each record with the "Sessions Per Record" field below. Please note, the more sessions you opt to show, the taller the FullStory component will be.

Click on the "Object Settings" tab. Here you can configure the set of objects for which FullStory sessions can be fetched and displayed, as well as how sessions will be fetched.

The FullStory app comes with configuration for the Case, Contact, and Lead objects. To add support for another object, click "Add." In the Object column, select the object for which you want to install the widget. In the example below, you will see we have added the Person object. In the Field column, select the field whose values FullStory should use for filtering sessions. You can use either an Email field or an External ID field that contains the FullStory user ID (this user ID must be the same user ID that is passed into the FullStory API call).

Also note that only objects containing an Email or External ID type field will appear in the object dropdown. When you have made the appropriate selections, click "Save Changes."

Add the FullStory Lightning Component to your Page(s)

The FullStory widget can be added to any of the following pages: Contacts, Leads, and Cases.

Once in your preferred page (Contacts, Leads or Cases), click on the settings gear and select

Edit Page.

The Lightning Components sidebar will appear. Drag and drop the “FullStory: Record Use Only” component into your page. Ignore the components named "Do Not Use."

Click on “Save”

Now, whenever you have a record with matching Email or External ID (whichever was configured), you will have a list of sessions for that user. Simply click the session link to be taken into FullStory to watch the session.

FullStory allows users to share noteworthy sessions directly to a channel in Slack, for easy sharing with your team.

To enable and set up the integration:

Login to FullStory

Navigate to Settings > Integrations & API Keys

Click the Add button next to Slack.

A box will open on the right side of your browser prompting you to authorize Slack. Click Authorize and enter your Slack workspace domain on the following screen.

Once you've given permission for FullStory to post to Slack, you'll be able to choose a channel where FullStory sessions will be shared, as well as enable and disable the integration.

You may turn on Auto-Slack New Notesif you wish all shared sessions to be sent to Slack by default, or turn it off to pick and choose sessions to share from the FullStory Notes timeline.

If you have configured the Slack integration to not send all notes, there are two ways for you to manually push sessions of your choosing:

Sharing from Notes:

When viewing a session, click the green Note button to bring up the sharing dialogue. Type your comment and press Share to publish your note and a link to the session to your team's Notes tab.

Click on the Notes tab under the OmniSearch box to view your team's shares. Within each note, you'll see Send to:Slack

Click Slack and the note will instantly be shared!

Sharing from inside a session

Click "Notefrom the playback bar to type a note

Once you've saved your message, find the green note in the right-hand actions timeline

Click the Send to: Slack Trello link to share your note out to the correct tool

FullStory email support is available Monday through Friday, 8:00 AM to 8:00 PM Eastern Time. We're closed on the following US holidays:

New Year's Day - January 1

Martin Luther King Jr. Day - Third Monday in January

Memorial Day - Last Monday in May

US Independence Day - July 4

Labor Day - First Monday in September

Thanksgiving - Fourth Thursday in November

Christmas Eve - December 24

Christmas - December 25

When a holiday falls on Saturday, we will be closed on the preceding Friday. When a holiday falls on Sunday, we'll be closed on the following Monday.

Get help from FullStory

Do you often search for a subset of users with whom you need to interact or analyze? With Export User CSV you can download these searches from the FullStory app in one click. Once you have the list, you'll be able to easily e-mail a group of users who took an action or pivot to your heart's content.

What

Export User CSVallows you to download the list of users from your active segment or search as a CSV (comma-separated values) file, which can then be imported into spreadsheet applications, email services, and more. The list will be limited to the most recent 10,000 users (e.g. 10,000 rows) matching your search.

How

While viewing a saved segment or a new search (or the Everyone view, if you like), you'll see an option to export the results just above the session list, just click Export as CSV:

FS.setUserVars

Export Contents

Created

The time and date the User was created expressed in UTC

UID

If using FS.identify, user's unique ID will be listed

Name

The name of the User as it is displayed by FullStory

Email

The email address of the User

LastPage

The last page the User visited

NumSessions

The total number of sessions recorded by the User

LastSessionTime

The time and date of the User's last session expressed in UTC

LastSessionSec

The length of the User's last session

LastSessionNumPages

The number of pages visited in the User's last session

LastSessionNumEvents

The number of events recorded in the User's last session

PageLatLong

The latitude and longitude recorded in the User's last session

LastBrowser

The browser used in the User's last session

LastDevice

The device used in the User's last session

LastOperatingSystem

The operation system used in the User's last session

TotalSec

The total length of time of the User's recorded sessions

AvgSessionSec

The average length of time of the User's recorded sessions

NumEvents

The total number of events for the User's recorded sessions

{{customUserVars}}

If applicable, your custom user variables will be added

Please note: Any aggregate data values (e.g. NumSessions) apply to all sessions for that particular user, not just the matching sessions within the specified segment.

But there's more!

Export User CSV will also export any custom variables you have. They will be named exactly as they are defined in the call to, meaning they will typically have type suffixes (e.g. myValue_str, myValue_int, etc).

FullStory playback should capture user interactions with videos that are a part of your site, with a few exceptions. FullStory does not capture the video itself.

If you have an embedded video hosted by YouTube, Wistia, or similar services you may notice that user interaction is not captured and seen at time of playback. This is due to the content being housed in a cross-domain iframe. If you don't have control over the iframe contents in order to insert the FullStory script, you won't be able to watch user interactions with the video during your playback.

Note: FullStory session replay will never show the actual video playing regardless of whether or not the video is self-hosted or hosted by a third party.

Read more on recording iframes here.

Yes! Event Funnels are one of several different kinds of Searc hie s.

How do I create an Event Funnel Searchie?

To create an Event Funnel Searchie, you must first start a search containing the events you consider important for a given outcome. FullStory will create a Searchie with a funnel when your segment contains two or more event queries. Then FullStory will show you the percentage of your users who have been in this funnel during the specified time frame.

Scroll down below the user list fo find your funnel:

Introduction to Conversions

And here is the search that produced this funnel:

Interacting with the Event Funnel Searchie

If you're curious about why your customers are falling out of the funnel at certain steps, start by clicking on one of the bars in your Searchie to instantly alter your search to the first step.

Clicking on the bar titled "Event 1 + Event 2," for example, will automatically show you customers who completed those two steps, with no reference to Event 3. This Searchie results in any customer sessions that clicked the text Add to Cart and Visted URL (path) "/checkout".

Next, you can compare how many customers added to their carts, but didn't complete their purchases by clicking Checkout. To see which customers were affected, simply drag Event 3 to the area just below the event filters which begins with the wordExclude. This search will now show you all the users who performed Event 1 and Event 2, but failed to perform Event 3.

This will capture all customers that added to their carts, went to the checkout page, but didn't complete checkout. Of course, this technique is up to you to alter to suit your application! You'll narrow down the search to exactly where in the buying process customers are dropping off.

Now, by watching a handful of sessions, you can see for yourself where customers get tripped up or lose interest and leave your funnel.

Are you interested in more conversion funnel insights?

FullStory's dedicated Conversions product, available on the Enterprise plan, will analyze your funnel to provide proactive, actionable insights you can use to help improve your conversion rate.

Learn more about it in our !

Understand user roles, learn about integrations, and update customizations to make sure your FullStory account runs smoothly.

Table of Contents

1. Get up-and-running

2. Take steps to protect your users' privacy

3. You've got sessions - now what?

4. Set your FullStory account up for success

Feeling comfortable with FullStory fundamentals and ready to power up your account setup?

Here's a short list of recommended to-do's to complete before you go exploring:

Invite teammates, enable guest roles, or both!

Block bots or unwanted traffic

Review available integrations

Pass custom user data to your FullStory account

Invite teammates, enable guest roles, or both!

FullStory sessions spark instant empathy and have an uncanny way of breaking down silos when shared. So, we recommend inviting a crew to navigate FullStory with you.

If you'reflyin' solo, skip this part and move onto the next.

If you work with others, take a moment to consider, "Who else would benefit from being able to search across sessions? Or, should everyone at my organization be able to view a session evenif they'll never log in?"

Review the user roles that are available: Standard, Admin, and Guest.

To invite a Standard or an Admin user (someone who will be able to log into FullStory and search across sessions), click to Settings > Team Settings and click "Invite teammate..."

While you're under Team Settingsconsider whether you'd like to enable Guest roles. This setting is recommended if you know you'd like to share links to sessions in group chat or project management tools where lots of folks might have access to click the link.

the specs

Block bots or unwanted traffic

It's a big, wild universe out there, and some of the traffic that could land on your site might not be real customer traffic at all.

Because your FullStory recording quota is based on sessions and because your analytics in FullStory include all sessions that match your search criteria, it's important to make sure that you exclude traffic from bots or unwanted IP addresses to get the best results.

Click over to Settings > Recording & Exclusionsand scroll down to look for modules to add Blocked IPs and Blocked User-Agents.

Add an individual IP address or User-Agent string to block all traffic from that bot or crawler. Read more about finding the right IP or user-agent string to block in, "Can I block unwanted sessions by IP address or User-Agent or bot?"

Review available integrations

Connect the critical systems, and plug the power of FullStory into your existing workflows.

Using Slack? Turn on integrations to send sessions to channels.

Managing bugs in Jira tickets? Enable the integration to make reporting bugs a cinch.

Supporting customers with a help desk? Flip the switch to send FullStory sessions to your incoming tickets, so you can see exactly what a customer saw before they contacted support.

With FullStory's ever-expanding list of integrations, you're bound to find something that will work for you. Navigate to Settings > Integrations & API Keys, and make it so.

Pass custom user data to your FullStory account

Search and session replay is powerful on its own, but it's super-charged when you start syncing over custom data points that matter to you about yourunique customer experience.

FullStory provides a mechanism to pass in user-specific variables through the API, using FS.identify and FS.setUserVars.

Once you start passing over identifiers and custom user vars, you'll be able to just start typingand search for all users with a specific custom variable data point.

Job title? Customer lifetime value? Favorite snack? If you've got the data for a customer, you can send it over with a session.

Read all (and/or send them to a helpful web developer or engineer on your team) to get started with custom data.

User roles rolled out? Check.Bots blocked? Check.Bugs reported? Integrations activated?Custom data coming through? Check, check, and check.

All systems are go! Now, go explore in FullStory.

Yes! If you would like to change the name of your FullStory account, you can do so by navigating to Settings > Profileand changing the Name field.

Umbrella

Note: this is also possible inside inside of accounts. However, when making changes to account names under Umbrella management, make sure you are logged in to the account that you would like to change the name of.

The privacy of your customer data is of utmost importance to FullStory and is a shared responsibility. FullStory ensures that your customer data is securely stored and accessible only to you. In addition, we provide you several tools to exclude sensitive customer information at scale throughout your site or app in perpetuity as it grows and changes. When data is excluded, it is never recorded and never leaves the user’s browser.

What follows are recommended best practices to ensure your company uses FullStory in compliance with our Acceptable Use Policy and with a privacy-first stance toward your end users.

There are two primary methods of excluding data from FullStory recording:

Code-first with .fs-block [Recommended]

Privacy Settings

In addition to our primary means of excluding certain data from FullStory recording, here are additional resources you may find valuable as you protect your end users' data.

Record only with user consent

Quick exclusion via Inspect Mode

What do we exclude by default?

Additional Details

Technically, how do exclusions really work?

Code-first [recommended]

As a best practice solution to excluding data from recording, FullStory provides a simple CSS class name .fs-block that can be appended to any class in your element library ensuring as your site grows and changes, the correct data is always excluded moving forward. Elements containing the .fs-block class will be excluded from FullStory recordings.

Add the .fs-block class name to any element you want to exclude.

<input class="ccnum fs-block">

Now, in FullStory playback, this element would appear like this:

deleting sessions from FullStory

This means FullStory ignored the inner elements that appeared in this element at the time of recording and that data was never collected and never sent to FullStory. For a precise list of exactly which HTML attributes are excluded, see “ A few details about Excluded Elements ” below.

These exclusions include any child elements, so you can do things like this to block all data gathered by a group of form fields:

<form class="fs-block" id="payment">

<input class="ccnum">

<!-- etc -->

</form>

Privacy settings

While deploying .fs-block directly into your element libraries is preferable, we also provide an in-app approach to data exclusion.

Within Settings you’ll notice an area called Privacy. You can add CSS selectors to the Excluded Elements list to block any data from those HTML elements from ever being captured. Essentially FullStory dynamically blocks data whenever someone visits a page containing a blocked element in much the same way .fs-block is treated when FullStory encounters it on an element.

Click Add Element to create a new exclusion. Input the CSS selector and optionally leave yourself a note to remember why this block rule is important.

Your note will show up in the exclusions list:

Supported formats:

#idselectors

.classselectors

parent>child

tagname

tagname[attribute]

tagname[attribute=foo]

tagname[attribute*=value]

tagname[attribute^=value]

tagname[attribute$=value]

tagname[attribute-=value]

You’ll also notice the “Record with user consent” checkbox. When used together with the FS.consent() API (discussed further below), this setting allows you to record this element only after a user has given explicit consent (these are known as “consent-required elements”).

Respect the consent of your users with FS.consent

Is there a subset of data that you wish to share with FullStory, but only upon receiving consent from the end user? If so, we give you the power to respect the consent of users when determining what data should be sent to FullStory.

FS.consent()

Quick exclusion via inspect mode

If you ever see something that should have been excluded, quick remediation is a top priority. It may not be feasible to make a code change to your site or add the element to your exclusion list quickly. In that case, admins have the ability to use Inspect Mode to select the element in the playback and click Exclude to add the selected element to your Exclusion list in Settings.

If you ever have a need to remove a session or all sessions in a FullStory segment, please follow our instructions here.

Important privacy note on Inspect Mode exclusions

FullStory targets elements for exclusion using their CSS selectors. If the elements you’ve selected do not have a static identifier such as a unique `id` attribute, any changes to your site could change these CSS selectors and cause them to no longer match your Exclusions list. Changes to your site could expose the data you’re trying to exclude. We strongly recommend using code-first approach after quickly excluding via Inspect Mode.

Important note

Element exclusions are not retroactive. If you are viewing this article after you started recording, there are several options available for, if necessary.

Default exclusions

We pre-populate the exclusions list with industry standard HTML. You'll want to double check how your company has coded these sensitive fields. If your input fields have different CSS naming conventions, you'll need to add them to the exclusions list.

If you're using the industry standards, we'll block the following default exclusions:

Passwords with input[type=password]

All credit card data with [autocomplete^=cc-]

Name

Credit card number

Expiration date

Security code

Card type

Hidden inputs with input[type=hidden]

You can find the exclusions list by clicking on Settings > Privacy.

Additional details about excluded content

When you encounter a field that’s been excluded while viewing a recording, you’ll see a gray box with cross-hatches over the field indicating it’s blocked, like in the image above.

Only the inner contents and some attributes (value, checked, src, data, alt) of excluded elements will be excluded. Any HTML attributesexcept those listed aboveof the excluded elements will still be recorded (though they won't be visible in the FullStory UI during playback). Take for example the following:

<div class="fs-block" data-secret="abracadabra" value=”abra”>Your secret is abracadabra</div>

In this example, the text Your secret is abracadabra will not be recorded. However, the text <div class="fs-block" data-secret="abracadabra"> will be recorded.

If you are storing sensitive data within HTML element attributes, you'll need to exclude the parent of the element to be excluded. (Note that there is not a way in pure CSS to specify the parent node of a selector).

How does excluding elements work? What are the technical details?

FullStory records the user interface (UI). The only method FullStory uses for recording the UI is by tracking the DOM structure and any changes to it. This means the recording script sends changes to the DOM structure to FullStory's servers, along with raw input events and metadata.

Element exclusion, therefore, operates at the DOM level. This means:

Excluded elements never touch FullStory's servers.

All excluded elements are processed locally in the user's browser. When changes to the DOM structure are sent to FullStory's servers, excluded elements are left out.

Relatedly, some raw input events (e.g., key and click events) are also redacted when they relate to an excluded element.

When you run a search in FullStory, we want to deliver your search results back to you as fast as possible. For commonly/recently used searches in your organization, FullStory will return cached data immediately while fetching updated data in the background.

You'll notice timestamps on the top left corner of your FullStory data visualizations as seen below to indicate age of data, and you can refresh to pull new data for any visualization that is at least 5 minutes old.

[email protected]

The data you are viewing is 5 minutes old. This view is seen without hovering over the element.

Hover view of the above. You can choose to “Refresh Data” as soon as data is 5 minutes old.

A request is in process behind the scenes to get new fresh data for this visualization.

There is new data available if you want it! A request happened in the background to get new data, and there was some new data to share with you.

Hover view of the above.

If you have any questions or feedback about the timestamped data you have available to you in FullStory, please let us know at (ideally with a screenshot of the timestamp in question).

Learn how to use FullStory to solve problems, find answers, and optimize your customer's digital experience.

Hosted by our FullStory Huggers

*Not a FullStory customer? Reach out to request a product demo and get info about our plans.

Intro to FullStory

1-hour Training Webinar

Ideal for all new FullStory users! By the end of this webinar you will know how to:

Demystify UX with Omnisearch

Create meaningful Segments

Understand Searchie analytics

Navigate Session Replay

Use heatmaps

Find console errors with FullStory DevTools

Can't join us live? Watch arecording of a previous session

Register Now

Privacy, Custom Data, & Integrations

30-min Training Webinar

Ideal for users who desire more context in their FullStory data. This webinar will introduce you to:

Privacy and data exclusion settings

Identifying users within FullStory

Segmenting users by custom attributes

Sending custom event data to FullStory

Popular integrations such as Google Analytics, Slack, and Zendesk

Register Now

Ask a Hugger: Office Hours

1:1 Session (30-min)

Have a specific strategic question? Set-up some 1:1 time with a FullStory Hugger

Register Now

Intro to FullStory Conversions

30-min Training Webinar

Learn how to use FullStory Conversions to find the UX bugs which have the largest negative impact on your users.

*Note: FullStory Conversions is currently only available on our Enterprise plan.

Can't join us live? Watch arecording of a previous session

Register Now

Intro to Dev Tools

30-min Training Webinar

Learn how to use FullStory's Dev Tools to understand how page performance impacts your customer experience

Register Now

FullStory for Customer Support Roles

30-min Training Webinar

Best practices and strategies for Customer Support teams using FullStory

Register Now

When considering the Rights of Access and Data Portability for GDPR, it can be difficult to know what data to supply your users. We've made it easy to provide your users (and you!) any data you have collected on them that has been processed by FullStory.

It is important to note that FullStory is acting both as a Data Controller and as a Data Processor within the realm of GDPR compliance.

FullStory is a controller with respect to our visitors and customers interacting with any domain within our control (e.g. www.fullstory.com, app.fullstory.com, help.fullstory.com, blog.fullstory.com, etc.). Sessions that FullStory records of these domains into our own account fall under FullStory as Data Controller. If you would like to request your own personal data from FullStory, please contact us at [email protected]

FullStory is a processor with respect to the end users whose data FullStory receives: our customers’ users. Sessions that are recorded and stored in your FullStory account fall under FullStory as Data Processor.

Accessible Data Format and Content

To retrieve your end-users data (FullStory as Processor), two data downloads are available:

User Events:User Events download contains data in the form of recorded event data for a particular user. The data included in User Events export are the indexed events that you can search and view in FullStory. This includes things like user identification details, page duration data, clicked elements, typed text, browser and device details. This does not include actual sessions that can be played back as sessions are inferred data. See below for a full list of User Event export contents.

User Pages: The User Pages file contains a series of all the pages that the user has visited. For every page, there are two kinds of JSON objects that are present delimited by a new line. One is the page meta data and the other is the page object itself. The pairs of JSON objects are separated by a new line character. For example:

{ page-meta-data }

{ raw-page-object }

{ page-meta-data }

{ raw-page-object }

Accessing the User Data Files in FullStory UI

To access these files for a user, search and locate the user in the FullStory UI.

Click on the user display name to open their user card.

At the bottom of that user card are buttons for downloading the files:

suspicious activity detection

Accessing Data Files with the API

You can also use our API to retrieve user files. However, the API is limited to download identified users only.

Endpoints

Action

Method

URL

User events

GET

https://export.fullstory.com/api/v1/export/userEvents?uid=USER_ID

User pages

GET

https://export.fullstory.com/api/v1/export/userPages?uid=USER_ID

Examples

$ curl -O -J -H "Authorization: Basic YOUR_API_KEY" https://export.fullstory.com/api/v1/export/userPages?uid=USER_ID

(A file named UserPagesExport.json.gz)

$ curl -O -J -H "Authorization: Basic YOUR_API_KEY" https://export.fullstory.com/api/v1/export/userEvents?uid=USER_ID

(A file named DataExport.json)

User Data Export Contents

USER/SESSION FIELDS

Name

Export Field Name

Description

User Id

UserId

A unique identifier for a user cookie on a given device/browser. This ID may be reset if the User clears their cookies, switches devices, changes browsers, etc.

User App Key

UserAppKey

The user identifier that was passed to FullStory from your system using FS.identify.

Individual Id

IndvId

A unique identifier for the Individual that combines all Users with the same User App Key. For example, if you’ve identified user 123 whenever they visit your site, their Individual will include all of their Sessions across devices, browsers, etc.

Session Id

SessionId

The identifier for a particular session, within the context of a single user. Use Session Id and User Id together as a compound key to uniquely identify sessions across all export data.

User Email Address

UserEmail

The email address that was set via FS.identify or FS.setUserVars.

User Display Name

UserDisplayName

The display name that was set via FS.identify or FS.setUserVars.

IP Address

PageIp

The IP address captured at the start of the session.

Custom User Variables

(custom var name)

If you're passing any user variables into FullStory, we'll include them in the export. Each additional variable will appear as a separate field in the export file, where the field name is the variable name as provided to the FS.setUserVars function. Note that, if loading export bundles into Redshift or BigQuery with hauser, the custom variable fields are amalgamated into a single JSON document under a field named “CustomVars” prior to import into the export staging table.

PAGE FIELDS

A “page” tracks each instance when a user loaded a page with a particular URL or navigated to a different URL within a single-page application. There may be many pages with the same User Id and URL if the user left and revisited the same page, either during the course of several sessions, or even during a single session.

Name

Export Field Name

Description

Page Id

PageId

The identifier for a particular page, within the context of a single session. Use Page Id, Session Id, and User Id together as a compound key to uniquely identify pages across all export data.

Page URL

PageUrl

The full URL of the page on which the given event occurred.

Page Duration

PageDuration

The total time this User spent on this page during this session (milliseconds). This is not a running total; every event for a given page will show the same total duration.

Active Page Duration

PageActiveDuration

The active time (mouse movement, text entry, clicks, etc.) this User spent on this page during this session (milliseconds). This is not a running total; every event for a given page will show the same total duration.

Page Referrer URL

PageRefererUrl

The page from which the user reached this page. The referrer may be empty if the user manually entered the page URL, or if the referrer has been scrubbed, etc.

EVENT FIELDS

Name

Export Field Name

Description

Event Time

EventStart

The absolute time when the event occurred, in UTC, represented as a dateTime from the XML Schema Specification, e.g. 2018-01-04T20:07:11.191Z.

Event Type

EventType

The type of event that was recorded. Typical types are:

“abandon”: A form was abandoned. Learn more about form abandonment.

“change”: The text in a text entry field was changed. The Event Target Text field will contain the new text value.

“click”: An element on the page has been clicked. The Event Target Text field will contain text of the clicked element, if applicable.

“navigate”: a URL change, either to a completely new page or a new hash fragment.

“thrash”: The user moved the mouse cursor erratically or in circles. Learn more about thrashed cursors.

Event Target Text

EventTargetText

Where applicable, this contains the text of the event target and its child elements. For example, if the user clicked a button that says “Pay now”, the event target text would be “Pay now”. Long text may be truncated in some cases for performance reasons.

Event Target Selector

EventTargetSelectorTok

Where applicable, this contains the CSS selector for the event target. This will be a fully qualified descendant selector, starting from the HTML element, and including all CSS selectors of elements that appear in the DOM when walking from the HTML element through its children to the event target. Most non-alphanumeric characters within a selector will be encoded, e.g. “.my\%2Dclass” rather than “.my-class”.

BEHAVIOR HEURISTICS

For some events, one of a series of modifier fields will be set to provide additional information regarding user behavior.

Name

Export Field Name

Description

Rage Clicks

EventModFrustrated

Your customer clicked one or more elements on the page many times in rapid succession, potentially because they were frustrated. For each of the click events in this series of clicks, the numeric value of this field is a running total of the number of clicks that have occurred. It will be zero for click events that were not part of a series of rage clicks. Learn more about rage clicks.

Dead Clicks

EventModDead

Your customer clicked something, but nothing happened. Will be 1 for dead clicks, zero for non-dead clicks.

Error Clicks

EventModError

Your customer clicked something and a console error was generated, either by an actual error occurring, or by logging an error to the console. Will be 1 for error clicks, zero for non-error clicks.

Suspicious Actions

EventModSuspicious

Your customer entered text or navigated to a URL that was suspicious. When set to zero, nothing was suspicious. When 1, it indicates a possible SQL injection attack. When 2, it indicates a possible cross site scripting attack. Learn more about .

CONSOLE STATISTICS

Name

Export Field Name

Description

Console Infos/Logs

PageNumInfos

The number of times the JavaScript function console.log() was called, plus the number of times console.info() was called on the page. This is a running total for the page, and will steadily increase until the user navigates to a new page.

Console Warnings

PageNumWarnings

The number of times console.warn() was called on the page. This is a running total for the page.

Console Errors

PageNumErrors

The number of times console.error() was called, plus the number of JavaScript errors that occurred on the page. This is a running total for the page.

ENVIRONMENT FIELDS

Name

Export Field Name

Description

Latitude/

Longitude

PageLatLong

The latitude/longitude corresponding to this session. These values are derived using IP geolocation, which is only capable of pinpointing a user’s general area, often just at the city level, not their exact location.

User Agent

PageAgent

The full user agent string for the system on which this session was recorded.

Browser

PageBrowser

The browser that was used for this session, as derived from the User Agent. Current possible values: Chrome, Firefox, Internet Explorer, Microsoft Edge, Safari, Opera, Mobile App, Yandex, Robot, Unknown. New values may be added to this list at a later date.

Device

PageDevice

The device type that was used for this session, as derived from the User Agent. Current possible values: Desktop, Mobile, Tablet, Robot, Unknown. New values may be added to this list at a later date.

Operating System

PageOperatingSystem

The operating system type that was used for this session, as derived from the User Agent. Current possible values: Chrome OS, OS X, iOS, Windows, Windows Phone, Linux, Robot, Unknown. New values may be added to this list at a later date.

If you’re like us, the California Consumer Privacy Act (“CCPA”) has been top of mind lately. The CCPA (which goes into effect on January 1, 2020) sets up new requirements around user data, including how it’s collected, shared, and used, impacting organizations that “do business” in California.

As with the GDPR for Europe, we created a resource to help you understand how the CCPA impacts your use of FullStory. Our CCPA and FullStory guide will help you address the following topics:

What is the CCPAand how does it apply to your business?

What is “Personal Information” according to the CCPA?

How does the CCPA affect your use of FullStory?

How do you handle deletion requests?

How will you know if you’re compliant with the CCPA?

And a lot more.

We want FullStory customers to feel confident they have the resources and tools they need to comply with privacy laws. This guide will help bring clarity around how you should address CCPA as 2020 draws near.

Get started: Go read about CCPA and FullStory.

Looking for a CCPA Addendum?

You can view and sign the FullStory CCPA Addendum online-- FullStoryCCPA Addendum.

Once you land on that page, you'll need to authenticate your access using an emailed verification code. You will have the chance to read the document prior to signing.

Didn’t find what you needed in either our supported or manual integrations? Take advantage of our JavaScript and REST APIs to create any integration that you need!

Add and Configure FullStory

You know how to get the FullStory snippet running on your site, but do you want to expose configuration for the snippet at some higher layer? Have a look at the first few lines of your recording snippet, which should be similar to the following:

window['_fs_debug'] = false;

window['_fs_host'] = 'fullstory.com';

window['_fs_org'] = 'ABC123';

window['_fs_namespace'] = 'FS';

The variables set in these lines control the behavior of the recording snippet:

_fs_debug - Toggles FullStory debug mode. Set this to true if you want to see detailed console logs, and lots of them.

_fs_host - For successful recording, please do not change this value; it should always be fullstory.com.

_fs_org - The ID of the org or account into which data should be recorded.

_fs_namespace - Used to change the namespace for the FullStory API, to prevent namespace conflicts.

If you are building a tool that needs to deploy the snippet in a multi-tenant environment, you can collect values for the above variables and use them to generate customized snippets for each tenant.

When keeping copies of the recording snippet in a source code or other repository, please be aware that the snippet does change from time to time, typically when we add new features. Older versions of the snippet will continue to record successfully, but newer features will not be available unless the snippet is updated.

Connect FullStory on the Client

The FullStory Browser API provides functions that you can use to integrate FullStory into other platforms that drive your business.

Get a link to the currently recording session

You can use FS.getCurrentSessionURL to grab a link to the current session being recorded. It's a great way to connect FullStory to support tools, but the possibilities are endless.

// This is an example script - don't forget to change it!

// Session URL is available once the _fs_ready event occurs, hence the callback.

window['_fs_ready'] = function() {

var sessionUrl = FS.getCurrentSessionURL();

var sessionUrlAtCurrentTime = FS.getCurrentSessionURL(true);

// TODO: Save the session link to play it again later.

};

Send custom event data FullStory

You can use Custom events to send all kinds of data specific to your site and your users' behavior to FullStory. These events can drive any manner of session filters and segments that you design. FS.event is the browser API function you can use to create custom events. For example, you may want to search for sessionswhere users added specific products to their online shopping cart. You can do this by instrumenting the Cart button click with a custom event.

FS.event('Product Added', {

cart_id_str: '130983678493',

product_id_str: '798ith22928347',

sku_str: 'L-100',

category_str: 'Clothing',

name_str: 'Button Front Cardigan',

brand_str: 'Bright & Bold',

variant_str: 'Blue',

price_real: 58.99,

quantity_real: 1,

coupon_str: '25OFF',

position_int: 3,

url_str: 'https://www.example.com/product/path',

image_url_str: 'https://www.example.com/product/path.jpg'

});

Add user profile data to FullStory

You can use FS.identify and FS.setCustomVars to build rich profiles of your users in FullStory and search for sessions that match that profile data.

FS.setUserVars({

displayName : 'Daniel Falko',

email : '[email protected]',

pricingPlan_str : 'free',

popupHelp_bool : true,

totalSpent_real : 14.50

});

Connect FullStory on the Server

Use the FullStory REST API to build server-to-server integrations. In the below example, you can use the /sessions call to get a list of sessions for a given email.

#!/usr/bin/python

# TODO: Obtain API key and user email to lookup.

headers = {'Authorization':'Basic {}'.format(api_key)}

response = requests.get('https://www.fullstory.com/api/v1/sessions?email='+user_email, headers=headers)

json_data = json.loads(response.text)

for session in json_data:

# TODO: Do something with the session links.

If you're using FullStory and HelpScout Docs, you can add FullStory to Docs to see exactly how users are interacting with your documentation. We'll walk through how to set it up and some common searches you might use within FullStory.

(And if you haven't already seen it, check out our FullStory <> HelpScout integration ).

Set up

To install FullStory in Docs within HelpScout, do the following:

Within HelpScout, go to Manage > Docs

Select the Docs site you wish to update

Click Custom Code on the left sidebar

In the "Insert <head> Code" section, paste your FullStory recording snippet, like so.

That's it! Once you save the configuration, FullStory will load on all new page loads, and you'll be able to see visits from users to your help site.

Note: as long as your help site has the same TLD-1 domain as your main site (e.g. help.example.com and app.example.com), visits to your help site and main site will appear in the same session.

Useful searches for HelpScout documentation

To limit your search to visitors to your documentation, add an event filter for Visited URL (host) that matches that of your help site:

View visitors on your help site who have emailed support from within your documentation:

These are two questions we often hear: How can I use FullStory to measure bounce? and What can I learn from these sessions?

Marketers are all concerned withbounce: when a person visits a site but immediately leaves. It’s way less fun than it sounds, isn’t it?

Bounce can be caused by a variety of things, so it’s important to figure out both how many visitors are bouncing and why. Analytics tools like Google Analytics and Mixpanel can only show us the former, but FullStory, magically, can do both.

You can define bounce as any period of time you like. At FullStory we say visits lasting less than a half a minute. We would put this into a search segment by using User Filters > Total Active Time > is at most > 30 minutes. (That number is in seconds, but if longer periods of time can be achieved by typing, for example, 5:00 for five minutes, or 1:00:00 for an hour.)

Now that we have our bouncing visitors, we can watch some sessions to find out why they’re bouncing. FullStory lets us see all sorts of user pain points from confusing design to JavaScript errors. (And, in the case of the latter, or any bug, FullStory also lets us inspect the faulty code.)

Knowing the reasons for bounce helps us make the necessary adjustments to promote more visitor engagement, which will ultimately lead to more conversions.

If you see a session with the Device type of “Robot”, this means that FullStory identified the User-Agent string as a bot (see list below).

Contact Us

Robot traffic often comes from search engine crawlers, but your organization might also be using programmed monitoring services to ensure great uptime and catch user experience issues. You may find it useful to watch sessions from bots to understand exactly how they interact with and consume resources on your site.

Once you have a sense for how they’re behaving, you may wish to exclude those bots by IP or User-Agent.

User-Agent tokens

FullStory associates certain tokens within the User-Agent string with bots. You can automatically block these popular bots under Settings > Recording in your account, under the Block User-Agentssection:

If you feel like a popular bot is missing from this list, please click the button below to let us know!

Need to know which marketing or ad campaign channel is driving the most purchases? FullStory can help.

See how to measure campaign results (1:38)

If the links to your site from your marketing or ad campaigns include UTM parameters, FullStory will automatically pull in the UTM campaigns, sources, and mediums so you can understand how your campaigns perform across multiple channelsno special planning or preliminary tracking work required.

Here's what you'll use to get started:

The name of your campaign, as set with UTM parameters on the published link that drives traffic from your campaign to your site,

The path of your confirmation page, the URL that your site visitors see after they've completed a purchase,

Omnisearch, and

Top UTM Searchies

Omnisearch and Top UTM Searchies are included "out-of-the-box" with all FullStory plans including Free, Business, and Enterprise. Sweet!

Here's how to work through this use case:

First, identify the UTM parameters on your marketing or social media campaign link.

Remember: you can always add UTM parameters to any link yourself before sharing that link, and you should write UTM parameters to help you understand how traffic is coming to your website from a specific campaign or channel.

For example, if I wanted to know how many people are coming to the FruitShoppe from my Fall video ad campaign on Instagram then I would add the following UTM parameters to the FruitShoppe URL:

https://fruitshoppe.firebaseapp.com/?utm_campaign=fall&utm_source=instagram&utm_medium=video-ad

Then, I would make sure that the link to my Fruit Shoppe from Instagram includes those extra parameters. That way, I would know that if someone visits that URL on my site with those extra parameters appended to the link that they were sent to my website directly from that campaign and from that specific source.

Next, open FullStory Omnisearch and just start typing"utm_campaign=" and the name of your campaign.

Right away, you can see how many people had sessions on your site from that campaign.

support@fullstory

And, if you scroll down, you can look at the Top UTM Sources and Top UTM Mediums results to see which channels and types of content or ads are performing best.

Then, to understand whether this traffic actually drove conversions, go back to Omnisearch and start typing the path of the confirmation page that your shoppers visit when they complete a purchase.

Adding the additional layer of the conversion event to search will filter the sessions to only those visitors from the campaign who later converted.

Note: you can optionally use the "in this order" and "within the same session" drop-downs menus to refine results further to see only the people who converted within the same session.

Understanding why campaign traffic doesn't convert

Now that you've built a funnel to understand whether traffic from your campaigns leads to purchase confirmations, you can flip the criteria for Has | Visited URL (path) | is | (your confirmation page) from "Has" to "Has not" in order to see a list of sessions where people visited your site from your campaign and didn't complete a purchase.

Then:

Watch sessions within each segment - where do drop-offs seem to occur?

Look for signals to understand the quality and intent of the campaign traffic - do the visitors seem to be engaging with your site and product pages? Do they seem to bounce right away? Does any of the traffic appear fraudulent?

Check to make sure the user experience is optimized - did the page load quickly? Are there any errors or rendering problems?

Make note of anything that needs to be improved or that might inform tweaks to your campaign strategy.

Note: If you're working on optimizing your user experience within a campaign and want help to prioritize which issues to fix first, you may be interested in FullStory's dedicated Conversions product, available on the Enterprise plan.

Conversions will analyze your funnel to provide proactive, actionable insights you can use to help improve your conversion rate for different campaigns.

Learn more about it in our Introduction to Conversions !

For example, if you notice that traffic from Instagram converts better than traffic from Facebook, you may need to refine your audiences on Facebook or change your spending there.

Take it a step further

You can apply this same workflow to understand conversions from any marketing channel where UTM parameters apply, including email campaigns or paid search.

As long as you have UTM parameters on your set links, you can use FullStory to understand the customer experience for visitors coming from those links.

Try it for yourself! And, if you get stuck or have questions, be sure to reach out to us at: .com

What is Dev Tools?

Dev Tools unlocks the power to understand how page performancespeed and reliabilityaffects your customer experience.

Console view

Dev Tools includes:

Page Speed Metrics

Network View

Slowest Pages

Search for sessions where the Page Load time took longer than expected or open Dev Tools for any customer's session to see exactly what the Network requests looked like in their browser for any page that loaded during their session.

Dev Tools can help you answer business questions like

Which pages load the most slowly for my customers?

Do people convert at a better rate when my page loads faster?

Was the page slow for everyone or just this one person?

Which image, file, or script was causing my site to load slowly for my customer?

How many of my customers encountered slowness on this page?

Page Speed Metrics

Page speed metrics allow you to see page timing milestones for every page that loads during any session.

Available metrics include:

DOMContentLoaded

First Meaningful Paint, and

Load Time

Together, these page speed metrics can help you understand whether a page was rendering or loading slowly for any individual user. And, because page speed metrics are available as search criteria for OmniSearch and Segments, you can layer these timings onto any of your funnels or Segments to learn more about performance in the context of specific pages or groups of sessions.

Learn more about page speed metrics.

Network View

The Network view in FullStory allows you to see line-by-line network requests as they happened in the browser to load a page.

Learn more about using the Network view.

Slowest Pages

The Slowest Pages report shows you the slowest pages related to any search or segment, by First Meaningful Paint. You can find Slowest Pages for any search or segment, and this report gives you excellent signal to understand where to improve your performance and also where you might want to search to find slow sessions.

Note: You may notice that the Slowest Pages report doesn't show the full URL for each page, but rather displays part of the path as the page's name in the Page column.

This is because FullStory groups together similar pages into Page Types. FullStory identifies when pages rely on the same HTML template and categorizes those similar pages together.

For example, you may have thousands of unique URLs for different products, articles, or other unique pages, yet all of those unique URLs could adhere to a common template. FullStory recognizes patterns in pages with similar templates and aggregates those pages together as a common type. Page Types can help you quickly understand insights about similar pages, and they work seamlessly with dynamic single page applications where an app updates the URL as users navigate between different views.

FullStory uses Page Types to power other features like Page Insights, and you can read more about this concept under the topic "What is a page?" in the Page Insights Guide.

Looking for more debugging tools?

Dev Tools play really nicely alongside the FullStory Console, a feature that's included in every edition of FullStory Business.

Learn more about the .

Looking to understand whether your conversion rates are better on desktop or mobile? FullStory can help.

See how to compare funnels (1:57)

Because FullStory captures everything, you don't need to do any manual instrumentation or preliminary event tracking setup in order to understand how your conversion funnels compare across different devices.

Here's what you'll use to get started:

Omnisearch</a >

Event Funnels</a >, and

Device Breakdown</a >

All of these features come "out-of-the-box" with all FullStory plans including Free, Business, and Enterprise. Nice!

If you happen to be using FullStory's enterprise plan (or interested), we have another tool you can use to compare conversion rates!</em >

FullStory's dedicated Conversions product, available on the Enterprise plan, will analyze your funnel to provide proactive, actionable insights you can use to help improve your conversion rate.</em >

Learn more about it in our Introduction to Conversions</a >!</em >

Here's how to work through this use case:

First, on your own website, identify the steps in your own conversion flow. Look for the key calls to action, buttons, or page paths that customers interact with as they move through your key funnel.

On an eCommerce shop, the flow might look like "Add to cart" > "Checkout" > "Purchase."

On a SaaS marketing website the flow might look something like "Sign Up" > "Submit."

Take a moment to review your key conversion flow and remember the text in the links, buttons, or page paths that make up your critical conversion flow.

Ask yourself: do you care about whether users take those steps in a specific order within the same session? Or, are you interested in seeing who has ever completed those steps in any order or over any number of sessions?

You'll use this information to build your Event Funnel in FullStory.

Next, open FullStory Omnisearch and just start typing the text of your first call-to-action to filter sessions for users who have completed the first step of your conversion funnel.

You can search for the text of a button to build a conversion funnel based on "Click events" or you can search for the beginning of the page path to build a funnel based on "Page Visits."

support@fullstory

Once you have a filtered set of user sessions for people who completed the first step, go back up to Omnisearch and start typing again to layer on the next step of your conversion flow.

Repeat this process until you've built a search that contains all of the criteria for your funnel.

Scroll down and look for the Event Funnel Searchie. This report shows you the conversion rates at each step of your conversion flow.

Save your search as a segment so you can revisit the Event Funnel later.

Next, you'll want to create a copy of your conversion flow segment with the Event Funnel that includes conditions for the Device type you're interested to compare.

Scroll down and find the Device Breakdown Searchie. Hover over the type of Device type you're interested to compare and click " Add to search" to add the conditions for that Device type to your existing search.

For example, if I want to compare how my funnel performs on Mobile compared to performance on all device types, then I would click "Add to search" next to the numbers for "Mobile" in the Device Breakdown.

Save this new search as a segment that you can compare to the new Event Funnel for this segment to your previous Event Funnel.

Mission accomplished! With two new saved segments, you can quickly reference the Event Funnel reports for each segment to compare conversion rates across different device types.

Understand differences between conversion rates

Now that you can easily compare your conversion funnel on mobile vs. desktop, use your new segments and session replay to learn more about why the rates are different and get ideas for how to optimize for conversions.

Flip any criteria in your event funnel to "Has not" to generate a list of sessions where customers dropped out of the funnel or didn't complete specific steps.

Then:

Watch sessions within each segment - where do drop-offs seem to occur?

Look for signals of frustration - is there anything about the design of the site that seems confusing or frustrating to users?</em >

Check the page load times - are pages loading very slow?

Make note of areas to improve and share your findings with other people in your organization who have a stake in optimizing your conversion rates.

Take it a step further

You can apply this same workflow to build custom conversion funnels based on a number of other conditions such as browser type, UTM campaign, referrer URLs, or any other aspect of your customer experience that's captured by FullStory.

Not sure where to start? From any Event Filter, click the [...] ellipsis to expand the list of conditions options and discover what's possible.

Omnisearch makes it possible to answer so many questions without doing the legwork first, and that's the magic of funnels in FullStory.

Give it a try! And, if you get stuck or have questions, be sure to reach out to us at: .com

You can use FullStory's Abandoned Form search to easily find users who began to interact with a form element but did not complete the submit event. There is no instrumentation required, as FullStory will automatically find and treat all of the <form> elements on your site.

Use this one click search to quickly filter down to user sessions where a form abandonment occurred. Watch sessions, then dig deeper for root cause with Searchies and Page Insights.

How to search for Abandoned Forms

Type "form" in the OmniSearch bar and hit enter

ignore these forms

The default search will be for "Has abandoned any form". This will return all users with sessions in the time frame indicated where a form was abandoned.

When watching a session, check for the highlighted Abandoned Form event(s) in the events bar. Watch what happens before and after they abandon the form. Look for console errors or warnings, mouse thrashing, rage clicks, or poor UX that led to the abandonment. Click Page Insights at the top right of the screen to view click maps and view aggregate data for users who encountered this form.

Hone your search to sessions of specific abandoned forms by using the form's unique CSS selector, which can be found in the events bar.

A few notes on Abandoned Forms

Your <form> elements must have a submit event as a part of the form OR have a button keyword that we've identified as a common submit event (such as 'Checkout', 'Purchase', or 'Submit').

When a form submission fails on the client side, FullStory will be sure to mark that as form abandonment. However, if there is a server side submission error, FullStory won't treat that as an abandonment since the the submit event was caught.

FullStory marks each instance where a form is abandoned in a session, regardless of if the form is eventually completed in that session or a following session. FullStory waits until a page is no longer recording events before deciding that the form has been abandoned. This means if a browser window is closed, the user navigates away from the page, or a session ends and a new session begins due to inactivity before the form is submitted, it will count as abandonment.

What if I have false positives?

We are constantly tweaking our algorithm to improve results and remove false positives. Even so, there may be an abandoned form on your site that you don't wish to appear in your search results. You can use `fs-ignore-form-abandon` to and remove them from your results.

In FullStory, there are several ways that you can quickly segment sessions where the Device type was mobile:

Visit the pre-made "Mobile" segment

Search using the Device type query, or

Click through a Device Breakdown report

Visit the pre-made "Mobile" segment

Every FullStory account includes a set of pre-made segments in the lefthand navigation. Look for the segment labeled "Mobile" and give it a click.

How We Helped AWeber Tap Into the Mind of the Mobile User

In this segment, you'll find a list of sessions where FullStory detected that the visitor was using a browser with a User Agent string related to a browser on a mobile device.

Note: for the purposes of reporting in FullStory, "Mobile" refers to small devices that are likely smartphones. We report on mobile tablets separately with Device = Tablet.

Watch sessions to understand your customers' experiences on their mobile devices or scroll down to view insight reports specific to your customers' Mobile sessions.

Search using the Device type query

Sometimes the pre-made Mobile segment isn't specific enough. Maybe you only want to see sessions where a customers is checking out from their phone, or perhaps your interest is how many people complete a sign-up on mobile.

You can either start on the Mobile segment and just start typingwithin the Omnisearch box to narrow results to show people who take any action when the Device type was Mobile:

Note: click the ellipsis to scope any event filter to when the | Device | was | Mobile

Or, start a new search and just start typing"Device" to include the Device type query criteria in any search, segment, or funnel that you can imagine.

Tip: If you have a favorite segment with an Event Funnel that you use to watch a conversion flow, copy the segment and use the Device query to make a "Mobile" version of the same funnel. Then, compare your funnel results!

Click through a Device Breakdown report

From any search or segment (pre-made or custom) you can scroll down to view your Device Breakdown for that segment. This smart analytics chart will show you the breakdown of how many sessions for your given search or segment happen on Mobile vs. Desktop or other Device types.

From this view, you can hover over the label for "Mobile" within the chart to reveal an "Add to search" prompt. Click the prompt to quickly add the Device type = Mobile scope to all of the Event Filters in your current search or segment.

Looking for more Mobile-specific inspiration? Visit one of these helpful posts:

Compare Conversion Rates by Device Type (use case with video)

3 Rules for Improving the Mobile E-Commerce Experience (on the Foreward blog)

(on the Foreward blog)

Recipe:

Only one customer has reported this error. I need more examples to troubleshoot.

When you only have one instance of an error, it can be hard to know where to start in troubleshooting the issue. Use FullStory to find more users with the same environment or similar navigation path.

Ingredients:

Search

FullStory Console

Method:

Your support agent sends you a FullStory session link where a customer reported an error.

Click into the link and view the session details and user agent string at the top right of the page.

Create a search with the same environment filters as the error you're investigating. Options include:

Device: Desktop, Mobile, Tablet, Robot, Unknown

Browser: Chrome, IE, Microsoft Edge, Firefox, Safari, Opera, Robot, Mobile App, Yandex, Unknown

Operating System: Windows, OS X, Chrome OS, Android, iOS, Linux, Windows Phone, Robot, Unknown

Display Width: was, was not, was less than, was greater than, was at most, was at least

Display Height: was, was not, was less than, was greater than, was at most, was at least

Add an Event Scope filter to find users who took the same actions as the error you're investigating.

Similar recipes you can cook up in FullStory:

Did other users encounter the same console error?

Were other users using Safari when this error occurred?

Can I find users who encountered the same error while using Firefox?