Who can use this feature?
- Admins and Architects can create and manage pages.
- Available on all plans.
Page Definitions
Fullstory supports defining and naming page groups directly within most areas of the application. Using a simple pattern syntax, users can control how specific page groupings are and provide them with names that are easy to understand and read for anyone using Fullstory in their organization. No code is necessary to take advantage of this feature.
All users will be able to use page names in Fullstory, but only Administrators and Architects are allowed to define and name pages. With the proper permissions, visit Settings > Data Management > Pages.
Managing Existing Pages
Note: Mobile App pages must be created via the Mobile App Pages API.
When managing pages, users can search and filter existing pages. Filters support several categories of page definitions that are important to understand.
- Active - a list of currently active page definitions of all types.
- User Defined - a list of all active page definitions created by an end user.
- Learned - Learned pages are created by Fullstory to help you get started. They suggest definitions by analyzing, comparing, and contrasting pages automatically as users visit your application.
- Archived - a list of pages that are no longer active and won’t be visible to users elsewhere in the application. All page definitions can be archived, including learned pages and user defined pages.
The search box supports searches for both page names and URLs. If you have a particular page that you’d like to create a definition for and want to check if there is already an existing rule, simply paste that URL into the search box and check for a match.
Defining New Pages
To define a new page grouping, simply click the Create Page button at the top of Pages to start.
The name field is used to apply a label to a page definition. This label will be used elsewhere in the app to search and create charts. While there is no strictly enforced naming convention, a consistent approach will help make the label more useful.
Note: If you're using the FS.setVars API to define page names, the pageName
value sent via the API will take precedence over any page names you manually define in Fullstory.
The description field is a place to articulate exactly what a page definition is. It is used only within the page management screen for admins and architects.
All pages can only fit a single definition and will notify the user if there is a conflict.
Query Parameters
To use query parameters in a page definition, select “+ Query Parameter” in Data Studio. From there, you can define the key-value pair for the data you wish to track. If you wish to track a group of pages, you can use * as in the value field.
Syntax
URL rules are how Fullstory understands how to group your pages under a definition. It is a simple syntax that defines a pattern. Any URL that matches that pattern will be included under that label when creating charts and running searches. Rules are mutually exclusive and URLs cannot be matches under more than one rule. Definitions can have more than one rule, and in the case a URL could match to multiple rules, the most specific one will take precedent.
- Use * (wildcard) to match any single token at a position.
- Use ** to match all paths that start with a common prefix.
- Use [] to match groups of tokens at particular positions.
Notes: Combining wildcards with other characters within a token of the URL is not a supported function.
Note: A token is each portion of a pattern or URL. So in the case of a pattern like example.com/foo/bar
, the tokens would be example
, com
, foo
, and bar
.
A single wildcard will match part of a URL path only at that part. For example, if the page you’d like to group is:
https://exampleapp.com/books/business
where “books” is a product category and “business” is a subcategory, you could create a subcategory grouping with this rule :
https://exampleapp.com/books/*
This rule would not group any subpages such as
https://exampleapp.com/books/business/booktitle.
A double wildcard will match any paths that start with the non-wildcard prefix. For instance, if in the example above you wanted to catch all individual book pages you could use a double wildcard this way:
https://exampleapp.com/books/**
And finally, if there are specific values you’d like to target, you can use brackets. Continuing with our example above, perhaps there are several book categories that are related such as business, real estate, and economics. To categorize these all under the same rule, use brackets:
https://exampleapp.com/books/[business, realestate, economics]/*
Frequently Asked Questions
What if the URLs on my site use hash (#) paths?
Hash paths are sometimes used in URLs, particularly on single-page applications, as browsers don’t consider the path fragment after the hash as a separate page. The structure of these URLs look something like like this, https://mywebsite.com/#/login/foo
, where the hash is the first URL path following the website domain.
By default, Fullstory does not take these hash paths into consideration when creating page definitions via our machine-learning algorithm nor will they work properly when manually defining pages.
That said, there's a flag we can enable on our end to take these hath paths into consideration and properly categorize those pages, allowing you to create new page definitions that match the URL patterns on your site and for our machine-learning algorithm to auto-create these page definitions as well.
One thing to note, if you're utilizing anchor links across any of the domains you're capturing in Fullstory, enabling this flag would mean that all hash fragments would be considered a page view across all domains. Anchor links are actually the reason we don't have this flag enabled for customers by default since we found that most customers would not want these to be counted as a new page view.
If you'd like to us to enable this flag for your account, please have an Admin user reach out to our Support team to make that request.