Some of our widgets come with a URL filters parameter. This setting allows you to define the set of pages where you want to show (or hide) a specific widget. Here are some common recipes:

The widget appears when the page URL is exactly https://example.com

The widget appears when the page URL is either https://example.com/page1 or https://example.com/page2

The widget appears on all pages except when the page URL is exactly https://example.com/page1

The widget appear on all pages except when the page URL is either https://example.com/page1 or https://example.com/page2

If your app is available on multiple domains and/or environments, use relative paths instead of full URLs. With the example above, the widget will appear at mydomain1.com/page1 and also at mydomain2.com/page1.

Use wildcard URLs to target a broader set of pages. With the example above, the widget appears when the page URL starts with https://example.com/path/. For example, it will appear at https://example.com/path/page1 and https://example.com/path/page2 and https://example.com/path/page3.

A common way to trigger the prompt in your workflows is to add a specific query string to the current page URL. For example, with the above configuration, the widget appears only when the current page has a ?show-widget=true query string in its URL. Add that query string to the page URL in your code to trigger the widget.

You can combine all the previous examples to create a more complex set of rules with both negative and positive filters. For example, here the widget shows only when the page URL starts with https://example.com/path/, except if it has a ?nobanner=true query string in its URL.

When a positive and negative filter are in conflict, the negative filter wins. The example above instructs the widget to only show at https://example.com/path/page1 except when the page URL starts with https://example.com/path/. In this case, the widget will simply show nowhere.