This article explains how URL syntax is used for creating rules in Page tagging. It includes examples and guidance on how to edit Page tagging rules. For an overview of Page tagging, see Page tagging.
To learn more about the fundamentals of tagging, visit the Pendo Academy for related video tutorials.
URL syntax
Pendo follows standard web URL syntax rules for tagging Pages. A URL has several parts. The main parts of a URL are the communication protocol, the subdomain, the domain or hostname, and the path. For example, the following URL, https://www.example.com/category/user/profile.html, is constructed as follows:
| URL syntax | Description |
https:// |
The communication protocol or scheme that the browser must use to access a website. |
www. |
The subdomain. This groups different parts of a website that share a domain. This doesn't have to be www.. It could, for example, be app., as in https://app.example.com. |
example.com |
The domain name. This consists of two parts: the second-level domain ( Pendo defaults to hiding your domain with a wildcard ( |
/category/user/profile.html |
The path to the resource on the web server. Everything after the domain is the path. This identifies certain content or folders in the domain. In this example:
In most cases, the path is case-sensitive, and so we recommend that you capture case syntax for tagged Pages in Pendo. |
URLs can be more or less complicated than this. See the examples below.
Fragment example
A fragment is an internal page reference, sometimes called a named anchor, referring to a section within a webpage. A fragment usually appears at the end of a URL and begins with a hashtag (#) followed by an identifier. For example, the following URL, https://www.example.com#someHeader, includes the following parts:
https://is the communication protocol.www.is the subdomain.example.comis the domain.#someHeaderis the fragment.
Path fragment example
A path fragment is an internal page reference that's used as routing for the web framework technology of the website. A path fragment usually appears at the end of a URL and begins with a hashtag (#) followed by an identifier. For example, the following URL, https://www.example.com#products/widgets/12345, includes the following parts:
https://is the communication protocol.www.is the subdomain.example.comis the domain.#products/widgets/12345is the path fragment.
Query parameter example
Query parameters define specific content or actions based on the data passed at the end of the URL. Query parameters usually appear at the end of a URL and begin with a question mark (?) followed by a query parameter. For example, the following URL, https://www.example.com?products=widgets, includes the following parts:
https://is the communication protocol.www.is the subdomain.example.comis the domain.?products=widgetsis the query parameter, which is a key-value pair.
If you have more than one query parameter in the string that follows the question mark (?), key-value pairs are typically separated by an ampersand (&). For example: ?products=widgets&source=browser-search.
Path fragment query parameter example
You can have a combination of paths, fragments, and query parameters at the end of a URL. For example, the following URL, https://www.example.com/#products/widgets?item=12345 , includes the following parts:
https://is the communication protocol.www.is the subdomain.example.comis the domain.#products=widgetsis a path fragment used for web framework routing.?item=12345is a path fragment query parameter, which is a key-value pair.
Tagging rules in the Visual Design Studio
You can tag Pages in the Visual Design Studio using either the Rule Builder or Custom URL option. Both methods let you define how Pendo identifies and groups similar URLs, but they offer different interfaces.
- Rule Builder provides a dropdown-style interface for applying statements to parts of a URL. When you select a statement, Pendo automatically generates the corresponding syntax.
- Custom URL lets you manually enter a rule using the same syntax directly. This gives you full control and is helpful when applying more advanced patterns.
The following sections explain how both options work and include examples. For more information about these two options, see Page tagging.
Rule builder statements and their syntax
The table below shows the statements you can select in the rule builder, the equivalent syntax Pendo generates, and what each one means.
- The Statement column shows the matching condition available to select in the rule builder. These are user-friendly labels that describe how the rule behaves.
- The Syntax column shows the underlying pattern that the rule builder generates when you select a statement. This is also what you enter manually in the Custom URL field if you're creating rules outside of the rule builder.
For example, if you select a statement like tracking_id=<anything> in the rule builder, Pendo creates a rule that matches URLs like https://app.example.com/dashboard?tracking_id=abc123. This means Pendo tags any Page where the tracking_id query parameter is present, regardless of its value.
| Statement | Syntax | Description |
<Ignore> |
/*/ |
Ignores everything inside of two forward slashes when matching the URL. |
<Ignore after> |
** |
Ignores everything in the URL after a double star, unless you add rules. Rules that follow the ** are respected. For example, //*/**/path would match www.example.com/some/long/path. |
<Parameter> |
/*parameter*/ |
Treats the portion between the slashes as a Page parameter, so the exact values are ignored for matching but still stored and available in Page details, segments, and reports. |
<Contains> |
~contains: |
Includes a specific string that follows. |
search_params=_value |
?parameter= value |
When a parameter matches the specified value. |
search_params=<anything> |
?parameter |
When a parameter matches any value. |
Custom URL syntax examples
If you choose Custom URL in the Visual Design Studio, you can enter the full rule syntax directly instead of selecting statements. This option is useful for more advanced or flexible tagging needs.
The examples below show valid rule formats you can use when manually defining a Page rule. For more guidance, see the Supported URLs section in this article.
Subdomain example
| Syntax | Description | Don't match |
//~contains:pendo.io/** |
https://app.pendo.io AND https://support.pendo.io |
https://mindtheproduct.com |
Query parameters example
| Syntax | Description | Don't match |
//www.pendo.io/features?language=english |
https://www.pendo.io/features?language=english | https://www.pendo.io/features?language=french |
//www.pendo.io/features?language |
https://www.pendo.io/features?language=english AND https://www.pendo.io/features?language=french |
|
//www.pendo.io/features?language=~contains:english |
https://www.pendo.io/features?language=english-ireland AND https://www.pendo.io/features?language=australia-english |
https://www.pendo.io/features?language=french-canada |
Overlapping tagging rules
User interactions with your application are captured as raw events and sent to Pendo through the Pendo Web SDK. Pendo processes these events and matches them against the rules you create for tagging Pages. Only events that you've defined in your tagging rule for a Page are pulled into the analytics for that Page. When you segment or filter based on a named Page in Pendo, you're searching every raw event and only pulling in events that match the rules that you've defined for that Page. This has implications for how overlapping rules impact your analytics.
A Pendo Page can be made up of several rules, as well as rules that include wildcards to capture multiple URLs. This allows you to refine the search of raw events to define what counts toward a Page view, such as variations of the same URL. It also allows you to create a Page that represents views of an entire application or area of your application, which can be helpful for segments, reports, and guide targeting. For example, you might want to capture all the individual contact profiles under a single Page in Pendo called "All contacts".
You can capture both a group of URLs in a single Page and individual URLs belonging to that group in other individual Pages. This gives you flexibility in your analytics to see the data that's most useful to you. If an event satisfies the criteria defined by the tagging rules for more than one tagged Page, it's pulled into the metrics for each of those Pages.
For example, as well as a single Page that captures a group of URLs called "All contacts" in Pendo, you might want to capture the individual contact profiles as separate Pages in Pendo. Overlapping or duplicate tagging rules between the "All contacts" Page and the individual contact profile Pages don't compete with each other. Rather, Pages that have overlapping or duplicate tagging rules count the same event against each relevant Page with a matching tag.
| Example URLs | Tagging rules | Page | Page views |
https://www.example.com/contacts |
//*/contacts | Contacts landing page | 10 |
|
|
//*/contacts/SteveRogers | Steve Rogers | 2 |
|
|
//*/contacts/TonyStark | Tony Stark | 3 |
https://www.example.com/contacts/ jenniferwalters |
//*/contacts/JenniferWalters | Jennifer Walter | 1 |
https://www.example.com/contacts/ thorodinson |
//*/contacts/ThorOdinson | Thor Odinson | 4 |
https://www.example.com/contacts/ natasharomanoff |
//*/contacts/NatashaRomanoff | Natasha Romanoff | 2 |
| All of the above |
//*/contacts //*contacts/* |
All contacts | 22 |
Parameterized URLs
Pendo allows you to parameterize a URL. Parameters in Pendo Pages are specific query parameters or path variables that help you identify and track different variations of a URL or page within your application. These parameters help you gain a deeper understanding of user interactions with dynamic content or pages that share a common structure but differ in specific attributes.
This functions similarly to a wildcard *, except that it nests the different values under the Page you created and is useful for creating Page rules across a countable variety of URLs with a single entry.
For example, if you have the following three URLs that carry similar content or that you'd like to view together:
https://www.pendo.io/features/foo/
https://www.pendo.io/features/bar/
https://www.pendo.io/features/ipsum/
You could use the following Page rule to capture all three:
//*/features/*parameter*/
These appear inside your subscription under your Page rule, showing each parameter value and its number of Page views.
You can also store a single query parameter as a Page parameter using the same syntax described earlier, for example: //*/?first=*parameter*.
Note: If you're using a Page rule with a parameter, you can't include multiple instances of parameters within the same rule. Doing so prevents the Top Parameters data from displaying correctly. For example:
- Correct usage:
//*/page/*parameter* - Incorrect usage:
//*/*parameter*/*parameter*
If your Page tag has multiple rules, keep these considerations in mind:
- Rule order matters. Pendo evaluates rules in order and stops at the first match.
- Place parameterized rules first. If a rule includes a parameter, list it first in your include list so the parameter is captured when a URL matches multiple rules.
- Parameters are shared across the Page tag. You can include parameters in multiple rules, but Pendo tracks a single list of parameters for each Page tag. Make sure you structure your rules to avoid data discrepancies.
Parameter values aren't case-sensitive, and only the top 100 parameters are displayed when viewing an individual Page tag in the Pendo UI. To view more Page parameters in the Pendo UI, create a Data Explorer report and group by Page parameter. You can also use the API described in Analyze Page parameters with the API.
Analyze Page parameters in reports and segments
When a Page rule includes parameters, Pendo automatically captures these values as custom event properties. This means you can use Page parameter values outside of the Page details view, including in segments and Data Explorer.
Page parameters appear in the Event breakdown table for the Page and can also be used as filters or grouping options in reports. This allows you to analyze behavior across dynamic or personalized Page variations without tagging each version separately.
For example, if your Page rule is defined as //*/portfolio/*parameter*/, you can filter or group report data by individual portfolio IDs to compare engagement across pages like /portfolio/12345 and /portfolio/67890.
Note: Only parameters collected through Page rules appear as event properties. If a parameter isn’t captured in your Page tagging rule, it won’t display as an option in the segment builder or report filters.
URLs with UTM parameters
UTMs are tags added to the end of a URL to provide context on the source of the link. For example, a link embedded in an email might look like this: www.example.com?utm_source=email. In this case, utm_source tells you the visitor came from an email link.
As of May 1, 2025, Pendo automatically captures UTM parameters as session properties for all subscriptions using web SDK version 2.272.0 or later. These values are available in reporting tools like web analytics without any tagging required.
However, you might still want to tag UTM-specific Pages if you need to:
- Track activity for individual UTM values outside of web analytics (for example, in funnels or paths).
- View top UTM parameter values for a specific Page.
- Capture other marketing parameters not using standard UTM names.
Session properties are available to all subscriptions as of May 1, 2025.
If you decide to tag UTM parameters as Pages, we recommend one of the following approaches:
- Tag each URL individually. Create one Page for every UTM parameter value you care about.
- Use parameterized URLs. Create a single Page definition that captures all UTM values using Pendo's parameter functionality.
Option 1. Create a Page for each UTM parameter value
If you have a limited number of UTM parameter values or are only interested in a select few, you can tag each value as an individual Page in Pendo. Because each UTM parameter value has its own page in Pendo, you can view usage analytics for each UTM source individually. You can also explore each value throughout the Pendo UI, including in Data Explorer, funnel, and path reports.
For example, to view activity for the three utm_source values below, you can create one Page in Pendo for each parameter value.
| URL | Page tagging rule |
https://www.pendo.io?utm_source=email |
//*/?utm_source=email |
https://www.pendo.io?utm_source=blog_post |
//*/?utm_source=blog_post |
https://www.pendo.io?utm_source=referral |
//*/?utm_source=referral |
Option 2. Create a Page that captures multiple UTM parameter values
If there are many possible values for the UTM parameter, you can use Pendo’s parameter functionality to create one rule that captures all possible values in a single Page in Pendo.
For example, you can use a single rule with a parameter to create a Page that would allow you to view activity for all three utm_source values below. These values appear under your Top Parameters for that Page, aong with the number of views for each value on the Parameters table.
| URL | Page tagging rule |
https://www.pendo.io?utm_source=email |
//*/?utm_source=*parameter* |
https://www.pendo.io?utm_source=blog_post | |
https://www.pendo.io?utm_source=referral |
Supported URLS
The table that follows lists supported standard URL syntax and examples.
| Syntax | Description | Example |
| Standard URL | The full address of a webpage. | https://www.pendo.io/features/platform/index.html |
Wildcards (*) |
The symbol used to match any number of characters in the URL. You can use multiple wildcards. |
|
Ignore After (**) |
Ignore everything after a double wildcard. | https://www.pendo.io/features/platform/index.html/users/** |
Fragment (#) |
Internal page reference. |
Note: You can use wildcards ( |
Path fragment (# or #!) |
Internal page routing. |
Note: You can use a wildcard (*) in path fragments (#). For example, the URL |
Contains (~contains:) |
Include a specific string. | https://www.pendo.io/features/platform/index.html/users /~contains:dashboard |
Query parameter existence (?) |
Query whether a parameter exists. | https://pendo.io?mobile |
Query parameter value (?and =) |
Query the value of a parameter. | https://pendo.io?language=english |
Multiple query parameters (?, &, and =) |
Query the existence and value of multiple parameters. | https://pendo.io?mobile&language=english |
Pendo understands the difference between https://domain.com/#page1 and https://domain.com/#page2. The Page rule, https://*, will match with both URLs. If your URLs are structured this way and you'd like to have a Page rule that only corresponds with https://domain.com, review the Location API documentation.
Unsupported URLs
The table that follows lists URL syntax that isn't supported and includes examples.
| Syntax | Description |
Page Parameters (sections after an ; but before a ? or #) |
Pendo skips dynamically set page parameters in the URL. |
Any form of NOT within page rules |
Pendo doesn't support NOTin the URL syntax. |
Contains (~contains:) after a query (?) for query parameter names |
Pendo doesn't support For example, |
* only acts as a wildcard when matching the entirety of a string between two slashes |
For example, https://www.pendo.io/features will be matched by https://*/* but not by //*.pendo.io/features or //www.pendo.io/f*s. |
* doesn't work after a ?
|
Wildcards are treated literally. |
The order of query parameters is ignored after a ?
|
For example, https://www.pendo.io?first=one&second=two and https://www.pendo.io?second=two&first=one will both be matched by the page rule //www.pendo.io?first=one&second=two. |
URL normalization
We use normalization to convert URLs into a format that ensures consistent and reliable rule matching. Specifically, we implement some special rules for %20 and + for spaces. This ensures that you don't need to create separate rules for every way a space is communicated in the URL. We also normalize # into #!for path fragments. This is for differentiating between fragments and path fragments.
The table below presents examples of how original URLs are normalized, along with the rules that match these.
| Original URL | Normalized URL | Matching rules |
| https://www.example.com/foo%20bar | https://www.example.com/ foo+bar | //*/foo%20bar |
| https://www.example.com/foo+bar | https://www.example.com/ foo%20bar |
|
| https://www.example.com/?query=foo%20bar | https://www.example.com/?query=foo+bar |
|
| https://www.example.com/#path/to/page/ | https://www.example.com/ #!/path/to/page | //*#!/path/to/page |
| https://www.example.com/#documents/123/widgets/ | https://www.example.com/ #!/documents/123/widgets | //*/#!/documents/*/widgets |