Page definition allows you to define your pages/screens by setting up matching rules for URLs to:
Group similar pages under a single name. (e.g. Product page)
Define and save properties based on URL data (e.g. Product name, product category)
Create clean and consistent Page/Screen names
Tag pages/screens based on Fragments
Without any dev dependency, with simple and intuitive UI, immediate changes and rule testing capabilities.
Why should you define your pages/screens?
Cleaner & More Actionable Data: Reduce URL clutter by storing dynamic values (e.g., product ID, user ID) as properties instead of separate pages.
Standardized Reporting: Group similar pages (e.g., Product Page, Category Page) under a common name for clearer analytics.
Enhanced Filtering & Segmentation: Use saved properties like product name or category to refine searches and uncover specific insights.
Seamless Cross-Platform Tracking: Maintain consistency between web and mobile analytics with structured, unified page nameSmarter Alerts & Insights – Grouped pages enable more accurate anomaly detection and performance monitoring.
Smarter Alerts & Insights – Grouped pages enable more accurate anomaly detection and performance monitoring.
💡Tip: We highly recommend that you always define your pages if you have Dynamic path parameters or fragments on your URLs.
✏️Note: If screen names have not been defined, UXCam will display the URL path as ‘screen name.
How to use Page Definition for different use cases
1. Grouping Similar Content (Dynamic IDs in URLs)
If your URLs contain dynamic path parameters like user IDs or product names, each variant will be treated as a separate page in reports, cluttering your analysis. With page definition, you can group them under a single page name for clearer insights.
For example, on Spotify, each artist has a unique ID in the URL:
/artist/5K79FLRUCSysQnVESLcTdb
/artist/1HY2Jd0NmPuamShAr6KMms
Even though the artist ID changes, these are all versions of the same Artist Page, and should not be considered separate pages.
To group URLs that include dynamic path parameters under a single page, follow these steps:
Choose a URL that follows the structure of the pages you want to group.
Select the Dynamic Part
Identify the changing section (e.g. artist ID: 1HY2Jd0NmPuamShAr6KMms).
Decide whether to name it and save it as a property (e.g. {artist-Id} so you can filter later) or ignore it (replace it with a wildcard * )
Define the Page Name (e.g. Artist Page)
Review & Test the Rule
Confirm the pattern and test it with different URL variations.
2. Tagging Fragments as distinct pages
If your URLs contain fragments (such as in SPAs), you may want to track them as distinct pages.
For example, if your checkout process is contained within a single page but different steps load using fragments (e.g. #/shipping, #/payment), tagging each one as a separate screen/page can provide clearer insights into user behavior.
To track these fragments as individual pages, follow these steps:
Enter the URL that represents the page structure you want to define.
Select the checkbox to ensure the Fragment is extracted from the URL
Define the Page Name
Confirm the pattern and test it with different URL variations.
3. Renaming Pages for Cleaner Reports
If you want to replace long URLs with short, customized page names for clearer reporting, follow these steps:
1. Enter a URL that follows the structure of the page you want to define.
2. Define a clear page name that aligns with your naming conventions.
In the example below, you can see https://www.spotify.com/join/ was renamed -> Join page
If your URLs contain fragments, and dynamic path parameters, and you also want a clean page name, you can solve them all at once using Page Definition.
Follow these steps:
Enter a URL that follows the structure of the page you want to define.
Select my URL contains fragments
Select the dynamic part (e.g. {RestaurantName} and optionally save it as a property.
Define a meaningful name for your screen/page (e.g. “Restaurant Choose items”).
Review and test the rule to ensure it applies correctly.
When creating Rules, you can assign the same Page/Screen name to multiple rules, these will be processed and displayed by UXCam as a single screen.
This can also be useful in case your URLs change but you want to keep your data consistent.
E.g. if you used to have domain.com/products/product-name defined as Products Page and now you have domain.com/category/products/product-name you can name it as Products Page and archive your previous rule.
Managing Rule Conflicts: Understanding Rule Hierarchy
As Page definition relies on regex-based rules, conflicting rules might occur when a single URL matches more than one pattern. To ensure predictable behavior, we use rules hierarchy to define evaluation order and determine which rule ultimately “wins” and defines the outcome.
For example, consider two URL matching rules:
Rule A: category/{product-name}/{product-detail}
Rule B: category/sub-category/{product-name}
A URL, like category/sub-category/widget may match both rules. Without an evaluation hierarchy, it would be unclear which categorization should be applied. This ambiguity is why conflicts must be managed with a well-defined order.
The importance of rules hierarchy
To resolve these conflicts, the rules are applied in order; top-to-bottom. This means that when multiple patterns match a URL, the first rule that applies takes precedence and determines the URL's categorization under a certain Page/Screen name. Establishing a hierarchy based on the specificity of each rule is crucial:
Specific rules: These target very precise paths (e.g., category/sub-category/{product-name}) and should be evaluated first.
General rules: These cover broader patterns (e.g., category/{product-name}/{product-detail}) and come later in the order.
You might not have any conflicting rules, a good way to review this is by Testing URLs.
Using Rule Testing
The rule-testing functionality lets you test a URL against all existing patterns.
We recommend that you use it before creating new rules, by testing the URL for which you want to define the new rule against all existing rules. This process helps in several ways:
Identify Overlaps: you can see which rules a given URL matches. If a URL is matched by multiple rules, it indicates a potential conflict.
Assess Specificity: If there are multiple rules that match the URL, you can evaluate whether the new rule you want to create is more or less specific than the ones already in place.
Optimize Order: Based on the test results, you can reorder the rules (drag and drop) so that the most specific rule is evaluated first.
For instance, if testing reveals that category/sub-category/widget matches both patterns, you should ensure that the more specific pattern (category/sub-category/{product-name}) is positioned higher than the more general one.
Archiving Rules & Change Log
Archiving Rules
If a rule is no longer needed, you can archive it. This ensures that new incoming data (URLs) will no longer be checked against the archived rule. However, archived rules do not affect previously recorded sessions—existing data will remain unchanged, and sessions categorized under the archived rule will still be accessible.
Important Notes on Archiving Rules
Archived rules remain visible for reference, so you can track how a Page/Screen name was previously categorized.
Archived rules are permanently deleted after 60 days—they cannot be restored.
Archiving does not affect past data—existing sessions will still reflect the previously applied rule.
Accidentally archived a rule? You'll need to manually recreate it.
Tracked Changes in the Change Log:
The change log provides a detailed history of modifications made to Page Definition rules. This helps maintain transparency and ensures that teams can track changes effectively.
Tracked Changes in the Change Log:
Rules Created
Who created the rule (email)
Date of creation
Pattern created and the assigned name
Rules updated
Who updated the rule (email)
Date of update
Specific changes made
Rules Archived
Who archived the rule (email)
Date of archival
Pattern and name of the archived rule
The change log stores up to 100 history changes, sorted by date, allowing teams to track updates over time.
How many rules can I create?
You can create up to 100 rules. Archiving rules will free up space to create more.
A Defined page can have up to 5 unique properties.
Who has access to the page definition feature?
Everyone in your organization with app manager or org manager access can create, edit, or archive rules. But we recommend that you plan this properly and keep it under a single owner.