July 19, 2022
By Steven Shyne
As FullStory solution partners, we have done hundreds of hours worth of trainings, workshops, and working sessions within various brands that are using FullStory.
During these engagements there are some common questions that almost always crop up, the most popular question we hear is something like “Where and how do I start with FullStory?”
We love that question because it has a few answers. To read more on that check out our other blog post – about Where and How to Start with FullStory.
Another very common question we get – usually during the beginning of our projects – is, "Wait… how does FullStory work?" or something similar.
To help understand how FullStory works (in common language), we’ll explain below. If you want a more technical deep dive we suggest you check out technical documentation from FullStory here.
And a standard disclaimer: what we cover below is a simplified version of how we understand FullStory for web to work. We recommend checking with the FullStory team to gain clarification on the inner-workings of the platform, should that be desired. Also FullStory does have a separate solution for session reply and digital experience analytics for mobile apps, since apps and websites are built differently. We’ll save that for another blog post (or leave it up to the good folks at FullStory to answer).
Before the below steps can take place, you’ll need to ensure that you have the FullStory snippet installed on your website – this can either be directly hard-coded on the site or many people opt to include the script in their tag management solution (like Google Tag Manager). For more information on how to install fuel storage check out these instructional articles.
When a user lands on your website and the FullStory script is activated, it takes a snapshot of all of the elements that are presented to the user (and some additional data as well) and starts a session bundle in the FullStory servers. Then FullStory observes (aka, waits and watches).
As the user interacts with your site or app each click, tap, URL visit, and every other interaction is sent in tiny little packets to that existing session at FullStory servers. This keeps the FullStory script super tiny and virtually eliminates any risk to performance. Here’s an article if you’re interested in learning more about the impact of the FullStory script – spoiler alert: it’s just about zero.
A huge benefit of the platform is elements that are interacted with are automatically indexed, which eliminates the need to manually tag and track site components. For some clients, you may want to create some manual tags like Watched Elements, which will allow you to observe whenever something is rendered but may or may not be interacted with – think in-line messages, error validation text, version numbers, etc.
As packets of interactions arrive at FullStory, each of the events (i.e. click, tap, page visit) is “tagged” to make them indexable in concert with other users’ session information. Crucially, these indexed events are available in aggregate with other user behavior, building and making searchable a library of your customers’ interactions.
The original session is enriched with this information, which reconstructs the user's session, allowing it to be played back in pixel-perfect clarity (hold for any unmasking or exclusions put into place). Additionally, FullStory bundles a single user’s sessions together so we can understand a single user over several sessions to observe the things they did or did not do over time.
For a more technical and detailed account of how FullStory works, this article from FullStory is the perfect place to start.
If you’re using FullStory but not to it’s fullest, consider a partner like CXperts – we are in FullStory all day, every day and are efficient with our time (and yours). Drop us a line at hello@cxperts.io.
.png){kind=logo}
