Write rules for URL grouping

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:

Key concepts

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.

Use greedy wildcards in v2 rules

• Description: In v2 host and path patterns, greedy wildcards can appear at the beginning, middle, or end. They can match zero or more characters within a token, span multiple tokens, and continue matching literal text that follows. In query-parameter value patterns, greedy wildcards must remain at the end. The three greedy wildcards render their matches differently:

  • <**> preserves the matched text.

  • <w**> preserves matched text that passes the word-like checks.

  • <??> replaces the matched range with <??>.

• Use case: When literal text follows a greedy wildcard, the wildcard matches the longest possible string that still allows the remaining pattern text to match.

• Example: /<??>.png

  • /a.png → /<??>.png

  • /.png → /<??>.png

A pattern can combine capturing and placeholder greedy wildcards.

• Pattern: /<**>/images/<??>.png

• Input: /a/images/b/images/c.png

• Output: /a/images/b/images/<??>.png

<**> takes the longest match that still allows /images/ and the rest of the pattern to match. <??> replaces the final variable text with the placeholder.

<?> Single placeholder wildcard

• Description: Matches variable text within one host or path token and replaces the matched text with <?> 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 zero or more characters and replaces the matched text with <??> in the normalized URL. The wildcard can match within a token, span multiple tokens, and continue matching literal text that follows the wildcard.

• Use case: Use <??> to combine URLs with variable text into one normalized URL.

• Example: /<??>.png

  • /a.png → /<??>.png

  • /.png → /<??>.png

A pattern can combine capturing and placeholder greedy wildcards. For example, /a/images/b/images/c.png → /a/images/b/images/<??>.png.

<**> takes the longest match that still allows /images/ and the rest of the pattern to match. <??> replaces the final variable text with the placeholder.

<*> Single-token capturing wildcard

• Description: Matches variable text within one host or path token and preserves the matched text 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 capturing wildcard

• Description: Matches zero or more characters and preserves the matched text in the normalized URL. The wildcard can match within a token, span multiple tokens, and continue matching literal text that follows the wildcard.

• Use case: Use <**> to match variable text and retain that text in the normalized URL.

• Example: /<**>.png

  • /image.png → /image.png

  • /images/image.png → /images/image.png

  • /images/icons/user.png → /images/icons/user.png

<w*> Single-token word capturing wildcard

• Description: Matches word-like variable text within one host or path token and preserves the matched text in the normalized URL.

  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 → /products/product1

  • /products/12345 → Not matched

<w**> Greedy word capturing wildcard

• Description: Matches zero or more characters that pass the same word-like checks as <w*> and preserves the matched text in the normalized URL. The wildcard can match within a token, span multiple tokens, and continue matching literal text that follows the wildcard.

• Use case: Use <w**> to match and retain variable text while excluding high-cardinality values that do not pass the word-like checks.

• Example: /<w**>/remoteEntry.js

  • /app/remoteEntry.js

  • /app/shell/remoteEntry.js

  • Does not match: /remoteEntry.js

Separate multiple greedy wildcards

Separate multiple greedy wildcards in a host or path pattern with literal text or a host or path separator. The separator defines a distinct matching region for each greedy wildcard.

A non-greedy wildcard such as <*> does not provide meaningful separation between two greedy wildcards.

Validation and preview safeguards

V2 URL grouping enforces the following validation limits:

Disabled rules do not count toward the 500-pattern limit, but their patterns must still be valid. Splunk RUM might reject a pattern within these limits if its combination of wildcards and literal text is too complex to evaluate safely. Simplify the pattern or divide it into multiple rules if this occurs. If a processing safety limit is reached while generating a preview, the preview is incomplete and displays a warning.

Syntax validation

Match a file at varying path depths

Use a greedy wildcard before a fixed file name when the file can appear at different path depths.

Because <w**> preserves the matched path, each URL can produce a different normalized URL.

To combine all variable prefixes into one normalized URL, use the path pattern /<??>/remoteEntry.js. These paths all normalize to /<??>/remoteEntry.js:

Use cases

The following examples illustrate URL grouping strategies.

Group API versions while retaining the function

Use <?> to replace the API version and <*> to preserve the function. This combines different API versions of the same function while keeping different functions in separate groups.

Example URLs	Pattern	Result
/api/v1/downloadimage /api/v2/downloadimage /api/v2/uploadimage	/api/<?>/<*>	/api/v1/downloadimage → /api/<?>/downloadimage /api/v2/downloadimage → /api/<?>/downloadimage /api/v2/uploadimage → /api/<?>/uploadimage

Group URLs by domain

Use <?> to group together URLs with the same domain.

Example URLs	Pattern	Result
sub3nds9.example.com subfd89fs.example.com sub6f8sd.example.com	<?>.example.com	Groups URLs of multiple sub-domains.

Group all URLs under a common path prefix

Use <??> to replace everything after a common path prefix. This combines all matching URLs into one normalized URL, regardless of API version or function.

Example URLs	Pattern	Result
/api/v1/downloadimage → /api/<??> /api/v2/downloadimage/api/<?> → /api/<??>	/api/<??>	All URLs normalize to /api/<??>.

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

1. Review the default rules first: select Settings > RUM URL grouping.

2. Deactivate any default rules that create URL groups you don't want.

3. First add a domain rule, then you can add a path rule.

v2 rules

1. Navigate to the RUM URL Grouping page.

2. Select Edit > New rule.

3. On the Create grouping rule popup:

   1. Select the priority (order) of the new rule.

   2. Select the URL token for which you want to write a rule.

   3. Select the application(s) you want to monitor. If you don't select an application, the new rule will apply to all applications.

   4. Write the patterns by which you want to group the URLs. The pattern consists of 3 components:

      1. Host pattern (required)

      2. Path pattern

      3. URL parameters (key-value pairs)

4. Select Add.

5. Select Apply.

View URL groups