Find click events on filters that required horizontal scrolling to be viewed
New
We have some pages where like this one were there are many filters that depending your browser window may required you to scroll horizontally to the right in order to see the rest. I’m trying to find out two things:
- Are the filters that customers use the most within the first 5-7?
- What percentage of customers use filters that are beyond those first 5 or 7?
The super tricky part is that filters are different depending the categories, the number of filters vary, but I could narrow down the search to only the top category. Meaning URL’s that only start at the second tier level /c/**
0
Comments
11 comments
Boy, this is a tricky one. Thanks for sharing it, @DataSeed99. Unfortunately, scroll maps show you vertical scrolls only and setting up watched elements would be really challenging in a scenario like this one with such a large number of dynamic filters for each category. You may be able to configure a custom event that fires when users scroll horizontally; however, I haven’t seen this done personally.
If I were you, I’d approach this by watching sessions for a handful of your most highly trafficked category pages and thinking of that as your sample size. Look for sessions where users don’t scroll to use as a proxy for how the issue affects your larger user base.
Wish I had better news to share here!
thank you @megan I wonder if it is possible then to know which filters are the most interacted with.
Since they have different names I wonder if it is possible to use a wildcard to get their position. An example would be something like this below. Where the name after the second underscore is different. Is it possible to do something like looking for click event on:
td#AttributeCategoryList_ctl00_*
td#AttributeCategoryList_ctl01_*
td#AttributeCategoryList_ctl02_*
and so on? I tried to do this in events but it tells me the selector is not valid.
@DataSeed99 CSS selector syntax doesn’t support wildcards; however, there are certain ways to match attributes in a wildcard-like fashion. This options here under next to “ID starts with” might be worth a shot! Another thought, perhaps you could create a metric that shows you clicks on each page grouped by text to see the actual text terms being selected most often for a given category page. This way is a bit more scrappy, but could again give you a general sense of click patterns.
thanks @megan I’ll check the ID starts with option. I thought about doing the dimensionality card to show which filter contents were clicked the most, it gives me another data point to look at
@megan so I found a good way to tell which filters are the most interacted. I created a named element for each filter using the format “starts with” ID, we roughly have up to 20 filters so it wasn’t too bad and then on a dimensionality card I can get the css element and click the hide CSS selectors so that’s gives me a nice representation of which filters 1-20 are getting the most clicks. From here I could be more granular and target specific URL’s or levels since I also have pages named based on the taxonomy level.
That gets me this dimensionality card
Now, the only thing I’m not 100% sure is if I should do Click or Changed event? If I do click they may click the scrolling vertical bar inside the filter but not actually select a value. If I do change, does FS count every time the changed event fires when the user changes or clicks to select a value inside the filter or does FS only counts the first changed event regardless if they interacted with the other filters.
Looks great, @DataSeed99! This is such a creative solution, and I’m so glad the ID syntax worked out. I just confirmed with the team that change events should generate every time the user selects a new value.
There’s only one exception. Let’s say, for example, that a user enters the word “help” into an input. Instead of generating four change events for “h,” “he,” “hel,” and “help,” FullStory will aggregate those into one event for “help.” This doesn’t apply to your use case here, but I thought you might find it interesting to know for the future 😊
thanks @megan the insights about the change event and how FS aggregates those events is definitely good to know. So I wonder...what’s best to use in my case? a click or change event...sounds like in my case either event would achieve the same result, but when I changed the event the numbers also change...in some cases drastically.
I’m interested in knowing which filter (not so much the value) and in which position people interact with.
@DataSeed99 I agree that both should get you similar results here. If you’re seeing drastically different numbers, that might be something worth digging into with our Support team! There could be some intricacies based on site or metric setup that I don’t have visibility into at the moment. If you’d like, I can convert this post into a Support ticket for you so the team can follow up and you don’t have to repeat the context!
Thanks @megan yes that would be super helpful if you don’t mind creating the support ticket because I do see a big difference between using click or change events
My theory is that whenever you load the page the filters “change” because filter values are different depending the page. Watching the recordings I can see the filters change event but sometimes customer don’t actually use the filters, but technically speaking the filters had changed. Seems like using click instead of change would be more accurate to represent actual customer interactions.
I would love to know if your team can confirm my theory 😁
No problem at all! I just created the ticket, so Support will be in touch soon via email to help make sure we sort this out 😊
Please sign in to leave a comment.