Write rules for URL grouping
Write rules to group URLs based on criteria that matches your business specifications, and organize data to match your business needs. Group URLs by path, domain, and parameters.
Splunk RUM automatically groups URLs together that capture errors and metrics such as page load and route change duration, JavaScript errors, backend errors, and Web vitals. This topic explains how to write rules to group URLs based on your own criteria so that you can organize your data in a way that maximizes its meaningfulness to you.
There are two versions of this feature:
| v1 features | v2 features |
|---|---|
|
Generates page-level metrics ( To migrate your rules to v2, see Migrate to v2. |
|
Key concepts
| Term | Definition |
|---|---|
|
Components of a URL |
For Splunk RUM, the components of a URL are:
For example, in the URL
Fragments introduced by a |
|
Domain |
The domain consists of a top-level domain and any prefixed subdomains. Host tokens are separated by a dot ( |
|
Hash token ( |
Single-page applications often use a hash token ( |
|
Path |
Path components are separated by a forward slash symbol ( |
|
Pattern |
The pattern is the most important component of a rule. The pattern defines the common portion in the path or domain that is shared by all URLs that match the rule. Patterns also consist of tokens, like the domain and path in the URL. A wildcard in the pattern matches actual tokens in the URL’s path or domain. You can apply a wildcard to a pattern to match one or more tokens. |
| Parameter |
Also called query parameter. In addition to host and path, v2 rules can require specific query parameters to be present with values matching a pattern. All six wildcards (<?>, <??>, <*>, <**>, <w*>, <w**>) are supported in the value pattern, and unlike host or path segments, the value pattern has no delimiter, so non-greedy wildcards (<?>, <*>, <w*>) can appear anywhere in the value and can be freely combined with literal characters inside a single value (for example, order-<?> or v<w*>-beta). Greedy wildcards (<??>, <**>, <w**>) must still sit at the end of the value pattern. |
|
Rule |
A rule defines how Splunk RUM groups URLs. |
|
Token |
A token is a string appearing in a path between two forward slashes ( |
Pattern syntax
This section describes each rule pattern, examples of URLs that match this pattern, and examples of URLs that don’t match the pattern.
-
<?>Single placeholder wildcard -
-
Description: Matches one segment and uses placeholder in the normalized URL.
-
Use case: When you want to match but normalize to a placeholder instead of the actual value.
-
Example:
/products/<?>-
/products/product1→/products/<?> -
/products/product2→/products/<?> -
/products/product2/comments→ Not matched
-
-
-
<??>Greedy placeholder wildcard -
-
Description: Matches all remaining segments and uses a placeholder in the normalized URL. Must be the last segment in the pattern.
-
Use case: When you want to match any deep path structure but normalize to placeholder.
-
Example:
/products/<??>-
/products/product1→/products/<??> -
/products/product2→/products/<??> -
/products/product2/comments→/products/<??>
-
-
-
<*>Single segment capturing wildcard -
-
Description: Matches one segment and uses the actual captured value in the normalized URL.
-
Use case: When you need to capture and show the actual value in both normalized URL and group names.
-
Example:
/products/<*>-
/products/product1→/products/product1 -
/products/product2→/products/product2 -
/products/product2/comments→ Not matched
-
-
-
<**>Greedy segment capturing wildcard -
-
Description: Matches all remaining segments and uses actual captured values in the normalized URL. Must be the last segment in the pattern.
-
Use case: When you need to capture and show everything after a certain point.
-
Example:
/<**>-
/products/product1→/products/product1 -
/products/product2→/products/product2 -
/products/product2/comments→/products/product2/comments
-
-
-
<w*>Single word capturing wildcard -
-
Description: Matches segments that look like natural words or human-readable identifiers (product names, slugs, titles).
Matches:
maroon-5,7-eleven,iphone-14-pro,best-practices-2024,module-1-lesson-4,getting-started-guide.Does not match: UUIDs (
550e8400-e29b-41d4-a716-446655440000), pure digit strings (12345), long encoded tokens (aGVsbG93b3JsZGV4YW1wbGU...), segments longer than 100 characters, user IDs with low letter-to-symbol ratio.Supports enhanced pattern matching: Recognizes sophisticated patterns like
-
Hyphenated phrases:
5-reasons-to-use-ai,maroon-5,7-eleven -
Module identifiers:
module-1-lesson-4,chapter-2-section-3 -
Product names:
iphone-14-pro,windows-11-home -
Article titles:
best-practices-2024,getting-started-guide
-
-
Use case: When you want to only match and capture on sentence-like strings. In other words you want to prevent creating groups for high cardinality elements like UUIDs, user ids, timestamps, encoded binary data, and so on; when you want to group real route names without inflating metric cardinality from IDs, hashes, or timestamps that would otherwise appear in the URL.
-
Example:
/products/<w*>-
/products/product1→ Not matched -
/products/my-product→/products/my-product -
/products/my-product/comments→ Not matched
-
-
-
<w**>Greedy word capturing wildcard -
-
Description: Matches all remaining sentence-like segments and uses actual captured values. Must be the last segment in the pattern.
<w**>applies the same sentence-like check to each of the remaining segments independently. The overall match succeeds only if every remaining segment is sentence-like.Supports enhanced pattern matching: Recognizes sophisticated multi-segment patterns like:
-
Learning paths:
course-1/module-2/lesson-3-advanced -
Product hierarchies:
electronics/phones/iphone-14-pro/accessories -
Content structures:
tutorials/web-development/react-best-practices -
Versioned content:
docs/api-v2/authentication-guide
-
-
Use case: Similar to the single word capturing wildcard, use this greedy word capturing wildcard as one of the last rules to "match everything else". This wildcard is safer than
<**>because it doesn't cause your metric cardinality to go very high. -
Example:
/<w**>-
/products/product1→ Not matched -
/products/my-product→/products/my-product -
/products/my-product/comments→/products/my-product/comments
-
-
Invalid syntax
The following syntax is invalid:
|
Invalid syntax |
v1 rule |
v2 rule |
|---|---|---|
|
|
Host patterns cannot start or end with a "." character. |
Same as v1. |
|
|
The |
In a host pattern, greedy wildcards (<**>, <??>, <w**>) must be at the end of the first segment, not in a later segment. A valid alternative is <??>.C or <??>.example.com. (In a path pattern the reverse holds: the greedy wildcard must be in the last segment.) |
|
|
Don’t mix the |
This is valid syntax in v2 rules. |
|
|
This pattern is invalid because the wildcard needs to be between two |
This is valid syntax in v2 rules. |
|
|
This pattern is invalid because the Valid alternative: |
Invalid (same as v1). In v2, a greedy wildcard ( Valid alternatives: |
|
|
A pattern for a path must start with a forward slash ( |
Path patterns may start with |
|
|
The |
Same as v1. |
|
|
The |
This is valid syntax in v2 rules. |
Use cases
The following examples illustrate URL grouping strategies.
- Group URLs by product ID
-
If you want to monitor many product URLs as a single group, such as
/products/product1,/products/product2, and so on, use the<?>wildcard. This creates one shared metric instead of multiple metrics with high cardinality. On the other hand, if you want to monitor each product URL individually and you anticipate low cardinality, use<w*>, not<*>.Example URLs
Pattern
Result
/products/product1/products/product2/products/<?>Groups URLs of multiple products. - Group URLs by domain
-
Use
<?>to group together URLs with the same domain.Example URLs
Pattern
Result
sub3nds9.example.comsubfd89fs.example.comsub6f8sd.example.com<?>.example.comGroups URLs of multiple subdomains.
- Group URLs by string
-
If you want to measure performance across v1 and v2 APIs for any function, use
<??>to wildcard the remainder of an API URL.Example URLs
Pattern
Result
/api/v1/downloadimage/api/v2/downloadimage/api/<?>api/v2/downloadimage/api/<??>Groups URLs by API function.
- Group URLs by a pattern of multiple tokens
-
Use a combination of wildcards to group together URLs by a pattern of multiple tokens.
Pattern
Matches
Doesn't match
/<?>/v2/<??>/api/v2/users/api/v2/profiles/edit/app/v2/dashboard/123/api/v3/users/app/dashboard/v2/charts/app/v2
Create a new rule
Before you create a new rule, learn about your URLs. Identify the components and tokens. Figure out what kind of results you want to see. Review the pattern syntax and examples to better understand how to formulate rules that work for your data.
Host and path rules are combined to create the URL Name in the UI. Spans are retained for 8 days in Splunk RUM. For more, see Data retention in Splunk Observability Cloud.
- v1 rules
-
-
Review the default rules first: select .
-
Deactivate any default rules that create URL groups you don't want.
-
First add a domain rule, then you can add a path rule.
-
- v2 rules
-
-
Select .
-
On the Create grouping rule popup:
-
Select the priority (order) of the new rule.
-
Select the URL token for which you want to write a rule.
-
Select the application(s) you want to monitor. If you don't select an application, the new rule will apply to all applications.
-
Write the patterns by which you want to group the URLs. The pattern consists of 3 components:
-
Host pattern (required)
-
Path pattern
-
URL parameters (key-value pairs)
-
-
-
Select Add.
-
Select Apply.
View URL groups
You can view a list of all the pages grouped by your rules and the key metrics per group in your RUM applications. Select the application name from the Real User Monitoring Overview page, then select either the Pages tab for browser applications, or select the Network Requests tab for mobile applications. Additionally, view or drill down on key metrics or sessions for your URL groups in Tag Spotlight by selecting View in Tag Spotlight. To learn more about RUM metrics, see Metrics.
Manage rules
Use an updated URL grouping system in Splunk Real User Monitoring.
Splunk RUM automatically groups URLs together based on default rules that capture errors and metrics such as page load and route change duration, JavaScript errors, backend errors, and web vitals.
Migrate to v2
Splunk RUM URL grouping v2 includes a unified rule structure system, richer wildcard matching, and query parameter grouping to better manage URL groups in Splunk RUM. In the new version, only one URL group is created after matching to a single rule. The previous logic created multiple groups based on all matching rules. Additionally, groups are created by evaluating all relevant parts of the URL (host, path, and query parameter matching), eliminating the need to coordinate separate host and path logic.
Select Start migration on the RUM URL Grouping page to begin migrating your existing rules to the new grouping system. Follow the guided workflow to review the impact to existing rules and dependencies that require manual updates. Most rules are matched exactly, resulting in no changed behavior. Additionally, review the list of dashboards and detectors where the impacted URL groups are used and confirm changes.
You can cancel the migration at any time before selecting Save with no impact to the URL grouping behavior. Your old URL grouping rules will also be saved. Metrics will populate for the new rules once they become active.
Edit a rule
Follow these steps to edit an existing rule:
data that has already been ingested.
-
Select the three dot symbol, then Edit.
-
Make your changes, then select Update.
Deactivate or reactivate a rule
Follow these steps to deactivate or reactivate an existing rule. When you deactivate a rule, Splunk RUM stops processing incoming data according to this rule. If you choose to deactivate a rule and then activate it again in the future, the rule is not applied to data that was already ingested by Splunk RUM.
-
Select the three dot symbol, then Edit
- Select the three dot symbol, then Edit.
-
Select Activate or Deactivate.
Delete a rule
Follow these steps to delete a rule:
-
Select the three dot symbol, then select .