A note on element attributes
Admins and Architects are the only team seats that have permissions to add new element attributes. If you are a Standard user, you'll need assistance from one of these team seats in your Settings > Team Settings view.
Jump to section:
- When to Use Element Attributes for Indexing
- How Element Attributes work in FullStory
- Allow List
- Block List
- Configure pattern rule lists for attributes
- Searching using data-attributes
When to Use Element Attributes for Indexing
You might want to use FullStory's Element Attributes feature if:
- Your site is built on React, and you have no stable class names to use in search
- Your site uses FullStory Private by Default obscuring the text on all buttons
- You've implemented FullStory's Babel React Plugin to automatically decorate selectors on your website with useful attributes
- Your engineering team already uses data-* and aria-* attributes for a testing framework
One of the most powerful experiences in FullStory is searching for click events on selectors, such as everyone who clicked on CSS selector
btn-primary cta-add-to-cart". If your site is built on React and the class names instead look like
RSzhz6gmPB1iAe-9l8gXJ" and are constantly changing, you lose this search functionality.
However, if your CSS selectors also are styled with some useful data-attributes, like
aria-label="search", or whatever your engineering team decides to add - you can get access to FullStory's powerful search functionality again!
How Element Attributes work in FullStory
The Element Attribute feature allows you to take advantage of more stable attributes on your selectors, even while the class names constantly change. You can select key Element Attributes to index so that you can search for future sessions where users interacted with those elements with the element attribute in question.
We added a general list (shown in grey text) of attributes already indexed in search, such as
aria-labelledby, and you can add your own attributes that are important to your site.
We recommend that you define attributes that do not contain solely unique values (like a UUID). In the future Element Attributes will be used for more advanced Page Analytics and attributes with unique values can lead to confusingly low numbers for aggregate click counts.
You should add attributes that are actually useful and meaningful - e.g.
data-src may decorate every product on your product detail page, but if the output is a random string that isn't useful, then
data-src isn't a good attribute to add for indexing.
The attributes that we have allow listed by default are listed here.
We block certain very common attributes (shown in the table below) from being added since attributes are meant to identify important and unique elements around the site.
So you've added key Element Attributes to FullStory for Indexing - great! But maybe your autocomplete results are full of results you don't care about, and your Page Insights results could be more accurate.
We give you the power to help fine-tune FullStory's autocomplete results and page aggregation heuristics by allowlisting and blocklisting pattern rules for specific Element Attributes.
When you edit or create a new Element Attribute list item, click "Add Rule" to input the specific patterns you'd like to include or exclude. You can use wildcard * to specify a greater range of patterns.
Once you've added a few data-attributes, and new sessions have rolled in containing the elements you'd like to search for, you can start building some segments. When searching in FullStory you'll want to toggle the "Any activity" drop down and select "Clicked"
You will then have the option to search the clicked event by "CSS selector"
Begin by searching for engagement on a specific element (w/o using class selectors)
Searching for engagement on a specific element, containing specific text
Note - click the ellipses (...) to add specific text to your search.
Searching for engagement categories, across multiple elements