Live website testing with Maze allows your team to run usability tests to understand how users are interacting with your live websites.
In this article:
- Before you start
- Who can use this feature
- Install the Maze tracking code on your website
- How to create a live website test in Maze
- FAQs
- Results & Reports
- Security and performance
Before you start
- For security reasons, your team can only test websites in which your unique code snippet is installed. You won’t be able to test websites where your code snippet isn’t installed. Learn how to install the Maze code on your website
- In-page events/interactions (e.g. clicking a toggle) aren’t captured as steps in the path. The URL must change between different screens for the test to be meaningful. Why do I see a “We didn’t detect any clicks on this page” when creating a path?
- The test experience must take place on a single tab. At the moment, the ability to test websites that open a new tab or window (even if those locations also have the snippet installed) isn’t supported.
- Native mobile app testing isn’t currently supported. Learn how you can test on mobile devices
- There are currently some limitations around displaying results data for website testing. Learn more
Who can use this feature?
Live website testing is available for users on all plans.
Install the Maze tracking code on your website
To enable usability testing on your live website, you’ll need to install a unique code snippet that enables this feature to run on your website.
You’ll also be prompted to follow these steps from your draft maze if you haven’t added the code to your URL’s domain yet when creating a live website testing block.
Learn how to install the Maze tracking code on your website
How to create a live website test in Maze
To create a live website test:
- Add a live website testing block to your maze
- Enter the starting URL
- Set the device type
- Define paths
- Screenshot anonymization options
- Enable session recordings
- Define conditional logic
- Add more blocks (if needed) and publish your maze
- Hiring participants from the maze panel
Add a live website testing block
- Open a draft maze.
- Click Add block, then select Live website test.
- Enter the task title and an optional description. Learn best practices for writing task prompts
Supported languages
You can test websites in any region and language. However, at the moment, the task interface for website testing blocks will only display in English.
Enter the starting URL
Paste the URL of your website and click Set up. Wait a few moments until we verify that the Maze tracking code is correctly installed on the website.
Please note:
- The URL you paste will be the starting page/screen of your test.
- The URL must include a valid scheme (e.g.
https://). - A small floating window will open with a preview of your website. Please don’t close this window; this is an important step for Maze to detect whether the snippet is working correctly on your website.
Set the device type
Select the Device type to determine the resolution at which your live website should be opened.
- Desktop: Your website window will open at a desktop resolution (1024px). Participants on smaller screens, such as mobile devices, won’t be able to open the maze at all—in those cases, they’ll see a “This page needs a larger screen” error.
- Mobile: Your website window will open on a mobile resolution (420px). Participants on a desktop will still be able to open the maze; the live website window will simply open on a mobile resolution.
Learn more about the minimum and maximum window sizes for website tests
Define paths (optional)
Paths are the baseline for measuring the success of a mission. If you set a path, Maze will automatically categorize each test as Direct Success, Indirect Success, or Mission Unfinished.
You don’t have to pre-define paths when setting up a website test.
Without defining a path, it’s not possible for Maze to establish whether each participant’s path was successful. As a result, paths will appear in the results as Uncategorized. Why are some paths marked as “Uncategorized”?
Please note that in-page events/interactions (e.g. clicking a toggle) aren’t captured as steps in the path. The URL must change between different screens for the test to be meaningful. Why do I see a “We didn’t detect any clicks on this page” when creating a path?
To set up a path on your website test:
- In your draft maze, add a website block.
- To start creating your paths, click Create path. A floating window will open with a preview of your website. Avoid opening the task window in a new tab and/or in full screen, as it may exceed the maximum window dimension and trigger a “Window size too large” error. Learn more about device resolution in website tests
- Click through the website to define the path you expect the participants to take to complete the task. At the moment, each page change or parameter change counts as a screen in the path. Learn more about paths
- To add more paths, click + Add new path.
- Once you’re done, click Save and close to save the paths and go back to the draft maze.
Screenshot anonymization
When testing on a live website, you may be collecting personally identifiable information (PII) from your participants. For example, if you ask users to log in to their account as part of your test, the screenshots on your Results dashboard may include anything they’ve entered when logging in, as well as any data on their personal area.
Maze allows you to mask the content of the screenshots in your results in two ways: at the block level, or globally using HTML attributes.
At the block level
When creating a website test, you’ll need to select how text should be displayed in the screenshots on your results page.
- Strict: Hides all text, both in the UI and anything entered in an input box. The results page will show only the visual elements.
- Balanced: Hides anything entered in input boxes, as well as numbers and email addresses. Generally, this is the option we’d generally recommend, as it allows you to protect your participants’ sensitive data while still being able to see the UI.
- Relaxed: Shows all text, both in the UI and anything entered in an input box.
Please be mindful that, if you enable Clips, the recording will show all information on the screen. Clips recordings aren’t anonymized.
Masking/unmasking content by default
You can also add an extra layer of security and mask/reveal certain content globally, regardless of the chosen setting in Maze.
To do so, add one of the following attributes to the relevant HTML blocks:
data-maze-mask="True"
data-maze-unmask="True"
Adding these attributes will either mask or unmask the content of an HTML element in the maze results. These attributes override the anonymization settings set at the block level. For example:
- If you add
data-maze-mask="True"as an attribute to an HTML element, the content is always hidden (i.e. strict anonymization) in the results, even with the anonymization setting of the block set to “Relaxed”. - The
data-maze-unmask="True"attribute will always reveal the content in the HTML element (i.e. relaxed anonymization), even with the anonymization setting of the block set to “Strict”.
Enable session recordings
Toggle Clips to collect video and screen recordings of usability tasks in Maze. When enabled, this setting applies to all missions. Learn more about enabling Clips
Define conditional logic (optional)
Because paths are optional in website tests, it's not possible to define conditions based on mission outcomes.
In website tests, it's only possible to use ALWAYS conditions to direct participants to the next block or a specific block.
Add more blocks (if needed) and publish your maze
You can add multiple live website tests per maze. To add more tasks, simply create a new Live Website Testing block and repeat the steps above.
Once everything is ready, preview the maze and send it live to start testing.
Results & Reports
As participants complete your live maze, you’ll start seeing insights in the Results dashboard.
Learn more about your live website test results
Maze reports make it easy to analyze, share, and present your results data. Reports are automatically generated for every live maze tested with at least one participant.
See how reporting looks like for website testing blocks
Current limitations when viewing live website test results
- Due to technical limitations, heatmap screens won’t always capture the live website page in perfect detail.
- Overlays and modals aren’t captured in heatmaps; only the base page/screen.
FAQs
My website is password-protected / behind a login wall. Can I still run a website test?
Yes. You can run usability tests on websites where logging in or entering a password is required.
As long as the tracking code is correctly installed, you just need to guarantee that your participants have the required credentials to access your website.
Can I test Single Page Applications (SPAs)?
Single Page Applications (SPAs) load a single page and dynamically update it as the user interacts with the app. These applications don’t reload the page when the URL is modified in the browser. As a result, the Maze code snippet can’t detect a new URL to register a new step in the testing path. Therefore, it isn’t possible to track single-page events that don’t change the URL.
That said, we do support query parameters in website URLs. This means that any parameter changes are registered as a new step in the success path of the website test. How are URL query parameters handled in live website testing?
Security and performance FAQs
Will the Maze script slow down my website?
The Maze script is designed to have a very minimal impact on the performance of your website. It shouldn’t take more than a few milliseconds to load, and this shouldn’t be noticeable at all to your website users.
Asynchronous loading
The Maze script loads asynchronously. Your website will continue to load while the Maze script is being executed.
This means that, even if the script fails to load (which is unlikely), your website will still continue to render as expected without the script.
Dynamic loading
The Maze tracking code you install on your website is used to dynamically run a loader that powers the testing on your website. The tracking code is less than 1kb.
The dynamic loader is less than 10kb and only runs in specific circumstances:
- The loader only runs if the API has a valid response;
- The API keys are only valid for each domain you configure;
- The code for either live website testing or the in-product prompt is only triggered if the destination site is opened in a new tab. If this first check is passed, we send a post message to the tab that opened the site, and attach an event listener to wait for the response. The rest of the live website testing code is only triggered if we get the proper response in the first minute. Otherwise, it’ll have no further impact.
If either of the conditions above are not met, the script isn’t loaded at all.
Content Delivery Network (CDN)
The dynamic loader is served by a Content Delivery Network (CDN).
A CDN is a distributed network of servers that delivers content based on a user’s geographic location. It does this by storing copies of the content on servers located in different places around the world. When someone visits a website using a CDN, the content is delivered to their device from the server closest to them, reducing the distance it needs to travel and making it load faster.
Using a CDN allows us to serve the loader faster, more reliably, securely, and with reduced data usage.
Session-based caching
The script uses session-based caching. The script is loaded only once, even when the user navigates through multiple pages.
Content Security Policy (CSP) directives
A Content Security Policy (CSP) is a security feature that helps protect websites from security threats and vulnerabilities. It does this by specifying the type of content (e.g. scripts, images, videos) that can be loaded on a website, and from which sources they can be loaded. This helps mitigate certain types of malicious attacks, such as cross-site scripting (XSS), clickjacking, and data injection attacks.
If you have a CSP implemented, you’ll need to add a directive that allows files to be loaded from Maze to allow the Maze script to work on your website.
Default: If using a default CSP, we recommend adding the Maze domain as a trusted source in the default-src rules:
default-src https://*.maze.co/
Stricter: If your organization requires stricter restrictions, we recommend the settings below:
script-src https://*.maze.co/ font-src https://*.maze.co/ style-src https://*.maze.co/ connect-src https://*.maze.co/ img-src https://*.maze.co/ frame-src https://*.maze.co/
Strictest: If your CSP requires additional granularity, the following are the minimum rules required for the Maze script to work. Please note that this list is subject to change as this feature evolves. In that case, you’ll need to update your CSP directives so that the snippet can continue to work.
script-src https://snippet.maze.co/ font-src https://snippet.maze.co/ style-src https://snippet.maze.co/ img-src https://snippet.maze.co/ connect-src https://api.maze.co/ https://prompts.maze.co/ frame-src https://t.maze.co/
What measures are in place to guarantee the security of the script?
Change control
Any changes to the script are subject to Maze’s change control policy.
Access to code changes is restricted to authorized employees only. All changes must go through code review and testing before deployment.
Hosting
The script is hosted as part of our general platform infrastructure, with access restricted to authorized employees.
To learn more about the steps Maze takes to keep your data safe, please check out maze.co/security and compliance.maze.co.
Is the script open-source?
The Maze tracking script is closed-source. By keeping the source code closed, Maze controls how the script is developed and distributed.
What data does Maze collect from my testers?
You can learn more in our Privacy Policy.
Is there any tracking in place for general website visitors?
If an in-product prompt or live website test isn’t targeting your website visitors, no information or data will be collected from those users.
What should I consider regarding Privacy Policy requirements when engaging with a website test or a prompt?
You’re responsible for the policies that govern your website and domain—i.e. traffic and journeys directly to your webpages.
Maze’s policies apply when participants interact directly with our endpoints—i.e. when they open a test directly on t.maze.co.
Therefore:
- Website tests: The journey begins at Maze (t.maze.co), and at this point, Maze’s Privacy Policy and Terms of Service are applicable. Once users are redirected to your website as part of the test, your own policies come into effect.
- In-product prompts: For in-product prompts, the journey begins on your website, where your own respective policies apply. If the user is redirected to a Maze test at t.maze.co, or interacts with the Maze widget, then Maze’s policies become applicable.
What measures are in place to protect participants’ privacy when testing live websites?
Website testing happens on your actual live website. Interactions happen in the “real world”; Maze doesn’t create a dummy/test/staging environment for you.
You should therefore be mindful that you may be collecting personally-identifying information (PII) from your participants. For example, if you ask users to log in to their account as part of your test, the screenshots on your Results dashboard may include anything they’ve entered when logging in, as well as any data on their personal area.
To protect the privacy of your participants, Maze offers built-in screenshot anonymization options. Please be mindful that, if you enable Clips, the recording will show all information on the screen—Clips recordings aren’t anonymized.
Additionally, you can set up your own staging environment, and/or give users test credentials to avoid having them reveal their personal data.
Still need help?
If you have any questions or concerns, please let our Support team know — we'll be happy to help!