This article is to clarify the functionality of feature tagging, help determine the quality of an automatic selection, and provide some information on how to test custom selectors. Please note that this article is assuming some technical knowledge and is not a suggested approach for all users. If you have any questions around the contents of this article or are unsure how to advance, please contact your Pendo Customer Success Manager or Pendo Tech Success.
Pre-requisites: CSS Selectors and Chrome DevTools
Pendo’s feature selection uses a subset of CSS selectors as a means of identifying the components of your application. Before getting started here, we recommend familiarizing yourself both with general CSS selector knowledge as well as what we specifically permit for features. Here are some resources to get started:
- W3 Schools CSS Selectors Reference
- Mozilla’s Introduction to CSS Selectors
- CSS Diner: A Game to Practice CSS Selectors
- What Does Pendo Support for Custom CSS for Feature Tagging?
How Do Feature Selections Work?
Feature tags work by selecting user activity data using CSS selectors. This works just as they do when selecting elements directly from a webpage. These events are captured as hierarchical representations of each page element that an event is logged against. Due to the way in which we collect and store activity, this does limit the selectors we can utilize. Each of these selectors are referred to as ‘Feature Rules’.
Each rule for a feature will process against the total data we’ve received and surface each event that the rule applies to. This means a general selector (such as ‘any "Submit" button’) will return a greater set of results than a very specific selector (such as ‘the "Submit" button on an exact modal’). Because Pendo collects data in the form of hierarchical representations of page elements, the level of specificity of your feature rules can make a significant impact on the total count that surfaces in the Pendo application. You can read more about this further down in the section "Determining the Quality of a Feature Rule".
You can also achieve selection combinations by leveraging multiple rules. Multiple feature rules will not show duplicate results. As each rule is processed within the context of a single feature, the total count will skip any event that has already been included by another rule. Determining how many feature rules you will need to accurately capture activity against a particular feature will be entirely dependent on the implementation of your application and the goal you have for the feature you’re tagging.
Determining the Quality of a Feature Rule
Depending on the implementation of your application or how a user selects a feature when tagging, an automatic feature rule may be selected that doesn’t ideally capture the data the way you intended. A simple and common example is a span contained in a button or anchor tag:
You can see from this example there is an anchor element (indicated by
<a...) who’s child is a span (indicated by
<span\>) that contains the text ‘Generic Page’. The highlighting in the image reveals how feature clicks will be tracked at it’s lowest level: A click in the blue space will be tracked against the
span while a click in the green space will be tracked against the
anchor. If we tag this element in-app, depending on where we click, we’ll get one of two selectors:
The anchor, Rule A:
The span, Rule B:
Which selector is the better choice? Keep in mind that we track from the most specific element of our click and up. Here is a simple diagram we’ll use to show the core difference between the two:
Looking at Rule A (against the anchor), we can see two click events against it: Click 1 and Click 2. For this rule, both of these click events will be captured by our rule. This is because a click against the span will track from this element and up. Any rule that targets our anchor tag should capture every click of anything within it.
Looking at Rule B (against the span), we can see another two click events: Click 3 and Click 4. For this rule, only Click 4 is captured. This is because the click against the anchor will only collect the anchor and what is above it while our rule is pointing very specifically to the element below it.
Our best tagging selection for this element would be against the anchor, Rule A.
Testing A Feature Rule
Sizzlelibrary for reading and selecting elements from a webpage. While Sizzle can be great for testing, it will cover more selectors that we allow for features. Please familiarize yourself with our article on supported feature CSS selectors: ‘What CSS selectors are supported for feature tagging?’
To begin testing your a rule, navigate directly to the page (outside of the Designer) where your feature lives and open the Chrome DevTools. Enter the following into the console:
There will be a dropdown with your results from your selector once you run the command:
Hovering over any of these results will highlight the item inside your application:
You can also double click the result to reveal the element in the ‘Elements’ pane. Using this information in combination with the highlighting should tell you how effective your rule is.
Dynamically Rendered Frameworks
Dynamically generated attributes such as classes and ID’s are very common in frameworks such as React.js, EXT.js, or Ember. Pendo has created some automatic exclusions so that our Suggested Match will try to avoid these, however, you may find that you need to customize in order to capture all data or get a tooltip to show every time.
Some examples of dynamically generated attributes would look like:
The numbers here are randomly generated on each page load, so you’ll need to make sure that you choose something different OR wildcard the match.
Wildcard the Suggested Match
After you have used the in-app designer to tag a feature, toggle over to "Custom CSS".
Let's use an example. Say your suggested match had been `.nav_bar__2RnO8`. Pendo supports `^` which means “the attribute begins with” which is a great option when tagging with React.js classes. The format for `.nav_bar__2RnO8` would be:
Tip: You should see a red box around the element to indicate that you have used the right syntax to grab the appropriate element.
“class” in the above example is the attribute because of the `.`, whereas this same syntax works for other attributes such as id (depicted as `#`) or `href`.
Rules Pendo Supports
[attribute^=“what it begins with”]
[attribute$=“what it ends with”]
[attribute*=“what it contains”]
Note: You may want to ask your developers if you are using a custom attribute that would be a better match. Pendo does not capture custom attributes by default, but you can add them in the settings, which will make the Suggested Match more accurate and require less customization. Please read more about Custom Attributes here.