In Chameleon, you can control exactly where your Experiences should display. They can be set to show in a specific Environment, or on a particular page within your web app (depending on the URL, or whether a specific element exists -or doesn't exist- on the page).

Configuring the exact page to display an Experience is useful for cases where the URL doesn't change between different pages, such as with some SPAs.


Quick access


Environments control

The easiest way to make sure you deliver Experiences to the right users is to group up your active domains into Environments. This way, whenever you create an Experience you will be able to pick the set of domains and subdomains that the Experience should be published to.

To access and manage your Environments, go to the Domains tab under Settings, in your Dashboard.


Note: with the Startup plan you have access to 2 Environments, on the Growth plan you can add 4, while on the Enterprise plan you can create unlimited Environments. Contact us to discuss your plan.


URL matching

When creating a new Experience, you can further define the page where it should show up. To do this, access the URL Rules setting in the Display Rules section of the Builder and click "Add condition" to define your matching conditions.

🪄 The art of displaying your Experience in the correct place of your app requires a healthy mix of the right URL matching conditions and user segmentation.

When it comes to matching URLs, you have flexible options to ensure you will always find a combination that allows you to target the right page or pages.

There are three major ways of working available for your to succeed:

  • Using multiple URL conditions.

  • Using different URL matching types.

  • Using wildcards, variables, or regular expressions.

Using multiple URL conditions

Explore the full potential of URL matching by combining multiple conditions, each with a specific match type.

Click the "Add condition" button to start adding URL rules. This will add a new blank condition, that you can configure with your desired URL and matching type. You can add as many conditions as you want, each configured differently to make sure the right users see the right Experiences.

After adding multiple conditions, you can determine if they should match based on all conditions existing simultaneously, or any condition existing -- essentially switching between a and/or logic.

Using different matching types

The URL matching type indicates under what conditions the criteria you add will be tested against the current URL. The existing matching types are:

  • URL contains text: Experience will show on all pages whose URL contains the input string.

  • URL is exactly: Experience will only show on pages whose URL matches the input string exactly.

  • URL matches regex: Experience will show on pages whose URL matches the regular expression defined in the input field.

  • URL does not contain: Experience will show on pages whose URL does not contain any of the input string.

  • URL is not exactly: Experience will show on all pages whose URL does not match the input string exactly.

🪄 When to use 'contains' vs. 'exactly'

If you'd like to show an Experience anywhere in your product (e.g. a notice whenever the user next logs in) you should use the URL contains text type. For example: 

  • /settings  will match www.yourdomain.com/settings  AND www.yourdomain.com/settings/admin) 

  • www.my-product.com  will match www.my-product.com/index.html  and www.my-product.com/team/invite  but NOT staging.my-product.com 

Also in cases where your URLs are user or account-specific, but you'd like the Experience to show to all users or accounts, you should use contains type. For example:

  • A page in your app is www.yourdomain.com/settings/user123  then you can use /settings as the input to match for all users

  • If your subdomains are customer specific, e.g. customer.yourdomain.com/admin  then you can match it with yourdomain.com/admin  


Note: If you're using the 'contains' match but for the positioning of the Experience you're using 'snap to element' then please uncheck 'HTML Hierarchy' to ensure that element still matches across different pages. Learn more about element selection here.


Using wildcards or variables to match dynamic URLs

Use these to match dynamic URLs (that contain parts that change per user, e.g. a user ID or customer name) more precisely.  


For example, to show an Experience on www.yourdomain.com/settings/user123/admin  but NOT on www.yourdomain.com/settings/user123/team you can either:

  • Use a wildcard (*) with 'URL contains text' to replace the part that is dynamic / changing; this will ignore that part and match the page regardless of what is contained.
    In the above example you could use: 'URL contains text' = www.yourdomain.com/settings/*/admin 

🤝 Use a wildcard only when you're matching URLs to determine which page to have an Experience show up on, out of multiple pages.

  • Use a user variable e.g. {{user_id}}  with 'URL contains text' or 'URL is exactly' to replace the dynamic part; this will fill the dynamic part with the specific value for that user/account.
    In the above example, you could use: 'URL contains text' = www.yourdomain.com/settings/{{user_id}}/admin 

🤝 Use the user variable in the URLs that you're using to redirect.

To do this successfully, you will have to include this data as part of installing Chameleon.

👉 Learn more about how to send and use user variables

Using regular expressions for complex matching

A regular expression (regex) is a codified way of creating a pattern for a string. 

You can use the 'URL matches regex' type to create a general matching condition that follows some rules. Some examples of this include:

  • [a-z]: to represent any character between a-z

  • \d: to represent any digit

  • a+: to represent one or more a's

  • $: to end the string and prevent any subsequent text matching
    (e.g. to show on yourdomain.com but not yourdomain.com/index, use the URL input: yourdomain.com$)

To use a regex, select the URL matches regex and type in the expression into the input field. The full input will be treated as a regular expression.

🎓 Understand how regex works

🎓 Explore a reference guide on regex expressions


Leveraging element rules

You can tell Chameleon to check if a given element exists on your page and display or skip a Step based on this condition.

This can be particularly useful for cases where the page content changes but the URL does not, enabling a user to interact with your page before displaying the next Step or skipping a Step when something's missing.

You can access this option by opening the Element Rules panel in the Display Rules section in the Builder. Here, you will be prompted to select your conditional element -- the one you'll use to determine if the Step will be shown. If you have an element already selected, you can adjust it or select another one on your page.

Then, you can either require this element to be present or not present on the page. You can also define a timer that:

  • When requiring the element to be present: the timer serves as a time box, representing the period for which you want Chameleon to look for your conditional element.

  • When requiring the element to be not present: the timer will serve as a buffer, and Chameleon will only start looking for the indicated element after the timer has finished.

Based on the configured conditions being met or failed, you can determine whether you want the Step to be skipped.

👉 Learn more about selecting the right elements


Testing your display rules

Getting the URL and specific element right is important, and there are a few ways to assess whether your inputs and selections will work as you want them to. 

The green/red dot indicators next to the input fields show whether the current page matches the condition you set. 

You will also get notifications in the Builder's right-side top bar about any URL or element rules you set.

Finally, to confirm everything is working as you want, you should switch to Preview mode to test if the Experience shows on the current page. 


What's next?

Did this answer your question?