Examples of adapting tracking settings by website

AI-generated summary

Genesys Cloud provides sophisticated web tracking capabilities through Digital User Tracking and Messenger integration, allowing organizations to manage multiple websites with distinct tracking requirements. The system supports customized visitor data collection across different environments through separate Messenger configurations, each with independent tracking parameters. Key configuration options include IP address exclusions, URL query parameter filtering, URL fragment tracking, and user search term monitoring. These settings can be tailored for different scenarios, such as public-facing websites, development environments, and testing platforms, ensuring appropriate data collection while maintaining privacy and security requirements. Organizations can implement specific tracking specifications for different websites, such as: - Excluding internal marketing team visits - Managing sensitive query parameters - Controlling URL fragment tracking - Monitoring product-specific IDs - Customizing search term tracking The solution resolves common challenges including: - Clear ownership boundaries for Business Administrators - Protected sensitive information - Accurate customer journey tracking - Proper marketing team visibility - Environment-specific customization Implementation involves version control and testing in dedicated environments before production deployment, ensuring optimal tracking while maintaining data privacy and security standards. The system supports migration from legacy chat systems and enables efficient management of web tracking settings across multiple websites and environments.

Feature deprecation: Genesys will no longer support ACD Web Chat v2, which is available to customers via all its corresponding Chat Widget versions. This is further to the deprecation of ACD Web Chat v1, which was announced earlier. As a result, Predictive Engagement will also end support for these legacy web chat versions. For more information, see Deprecation: . All existing customers are encouraged to migrate to Web Messaging and Messenger.

PrerequisitesClick to expand

Web tracking settings give you flexibility to define how visitor data is collected and interpreted across the different websites you manage. Depending on your business needs, each website may require unique tracking behavior. For more information about web tracking settings, see Configure web tracking.

This article provides four practical scenarios that illustrate how to adapt and organize your web tracking configurations effectively:

Use these scenarios as examples to help you organize web tracking settings in a way that keeps data clean, configurations maintainable, and customer journeys accurate across all your websites.

Scenario 1: Multiple websites with different web tracking requirements

A software company manages the websites of two different companies:

Website A is an e-commerce site selling multiple products.
Website B is an insurance company that hosts a single page application. The application allows users to register, log in to the website with their accounts, and manage their policies.

Both the websites share similar URL properties:

Website A	Website B
https://website-a.com/home?q=running+shoes https://website-a.com/product?id=123 https://website-a.com/product?id=456 https://website-a.com/about#ourteam	https://website-b.com/#/account?id=123 https://website-b.com/#/account?id=456 https://website-b.com/#/reset-password?q=1234

Website A

Website B

https://website-a.com/home?q=running+shoes

https://website-a.com/product?id=123

https://website-a.com/product?id=456

https://website-a.com/about#ourteam

https://website-b.com/#/account?id=123

https://website-b.com/#/account?id=456

https://website-b.com/#/reset-password?q=1234

Despite sharing the same URL properties, the two websites require completely different web tracking needs.

Tracking requirements for website A	Tracking requirements for website B
The organization wants to exclude visits from the internal marketing team to capture exclusively real customer activity. The organization wants to track product searches entered by visitors in this website, which are stored in the query parameter q. URL fragments in website A can be excluded from tracking as they just scroll to a page section. The query parameter id is used to identify individual product pages, which should be tracked to capture engagement with specific products.	Visits from website A’s marketing team should remain tracked, as they aren’t affiliated to the insurance company running website B and would represent legitimate users. The organization does not want to track the query parameter q in website B to comply with privacy policies as it contains temporary and sensitive data. URL fragments are used for page routing in a single-page application, meaning the organization must track these navigation as separate page views. The query parameter id identifies user accounts, hence, it should be excluded from tracking for security reasons.

Tracking requirements for website A

Tracking requirements for website B

The organization wants to exclude visits from the internal marketing team to capture exclusively real customer activity.
The organization wants to track product searches entered by visitors in this website, which are stored in the query parameter q.
URL fragments in website A can be excluded from tracking as they just scroll to a page section.
The query parameter id is used to identify individual product pages, which should be tracked to capture engagement with specific products.

Visits from website A’s marketing team should remain tracked, as they aren’t affiliated to the insurance company running website B and would represent legitimate users.
The organization does not want to track the query parameter q in website B to comply with privacy policies as it contains temporary and sensitive data.
URL fragments are used for page routing in a single-page application, meaning the organization must track these navigation as separate page views.
The query parameter id identifies user accounts, hence, it should be excluded from tracking for security reasons.

The organization tries to translate those unique web tracking requirements for both website A and website B in the legacy Web Tracking settings in Menu > Orchestration > Predictive Engagement Settings, resulting in the following tracking behaviors:

Field name	Value	Result for website A	Result for website B
Exclude IP Addresses	203.0.113.10– Marketing team	The marketing team is successfully filtered out of website A.	The marketing team does not appear as a user in website B when they require support in canceling their insurance policy.
Exclude URL Query Parameters	id	The product pages from website A, which should be tracked are excluded from web tracking.	Sensitive data from website B is excluded from web tracking.
Track URL Fragments	No	Any URL information after # is ignored. Any navigation within the same webpage in website A is successfully excluded from web tracking.	Any URL information after # is ignored. This also excludes the page navigations, which should be tracked in website B.
Track Site Searches	q	Any term searched in website A is successfully tracked as a user search.	Any search query id related to password resets in website B appears as a user search, breaching company policy.

To overcome the limitations of the centralized web tracking settings under Predictive Engagement, the organization decides to edit the two Messenger configurations – deployed respectively to website A and website B and define distinct web tracking settings for both of them, directly from Messenger. Their respective web tracking settings are configured as follows:

Field name	Messenger Configuration for Website A	Messenger Configuration for Website B
Exclude IP Addresses	203.0.113.10 – Marketing team	None
Exclude URL Query Parameter	None	id, q
Track URL Fragments	No	Yes
Track Site Searches	q	None

By implementing the preceding web tracking settings, the organization now:

Excludes the marketing team successfully from being tracked in website A while they appear as regular visitors in website B.
Captures information relevant to their business needs in their URLs from website A while website B has successfully excluded any sensitive data stored in the URL, while capturing relevant navigation data.

Scenario 2: Address ownership ambiguity and configuration clutter by separating configurations

An organization has multiple Business Administrators, each responsible for managing web tracking across different websites. In Predictive Engagement, the presence of multiple user entries in the web tracking settings blurs ownership boundaries and reduces the clarity of each field. As a result, Business Administrators struggle to determine which website each setting applies to or whether it still applies at all. Outdated values often remain in the configuration to avoid the risk of inadvertently affecting multiple deployments.

The organization’s web tracking settings under Predictive Engagement contain multiple user contributions, configured in the following way:

Field name	Value
Exclude IP Addresses	203.0.113.10 – Marketing team 175.210.177.40 – Personal 237.26.85.152 – Home 105.192.67.205 – Dev 250.93.249.84 – Tom’s team 143.220.228.79 – Test
Exclude URL Query Parameter	id, token, filter, p
Track URL Fragments	No
Track User Searches	q, term

By configuring their distinct web tracking settings in their respective Messenger configurations instead, Business Administrators can clearly separate ownership and responsibilities. Each administrator can maintain their own tracking configuration, deployed on the specific website they manage without impacting the tracking behavior configured by their peers, as shown as follows:

Field name	Messenger configuration A	Messenger configuration B	Messenger configuration C	Outdated data
Exclude IP Addresses	203.0.113.10 – Marketing team	250.93.249.84 – Tom’s team 175.210.177.40 – Personal 237.26.85.152 – Home	105.192.67.205 – Dev	143.220.228.79 – Test
Exclude URL Query Parameter	id, token	filter, id	None	p
Track URL Fragments	No	Yes	No	None
Track User Searches	q	q	term	None

Scenario 3: Allow default web tracking configuration

A company manages a main public-facing website and owns different web domains that are dedicated to internal development and testing. The engineering team uses the development environment to maintain and improve the company’s website. Once their code is complete, they’re added to the testing environment before the changes can be safely published publicly. While their main website is dedicated to customer use, processing sensitive user data, their internal web domains should not experience any tracking limitations to ensure that sufficient event data is collected for testing needs.

Tracking requirements for public website	Tracking requirements for the development and testing environment
Exclude web visits from internal employees who frequently review the website’s content and behavior. The website uses the query parameters id and token in URLs to store sensitive data that shouldn’t be tracked. The website doesn’t use URL fragments. Track user searches to identify customers’ interests.	Track all user traffic to ensure that the website reflects the intended behavior during tests. The values stored in query parameters in internal environments aren’t linked to real customers, and are limited to internal data only. They do not need to be excluded. Those environments contain a copy of the public website, meaning they don’t use URL fragments either. Unless the engineering team is actively working on the search feature of the website, they don’t have any specific requirements to track keywords entered in the search bar.

Tracking requirements for public website

Tracking requirements for the development and testing environment

Exclude web visits from internal employees who frequently review the website’s content and behavior.
The website uses the query parameters id and token in URLs to store sensitive data that shouldn’t be tracked.
The website doesn’t use URL fragments.
Track user searches to identify customers’ interests.

Track all user traffic to ensure that the website reflects the intended behavior during tests.
The values stored in query parameters in internal environments aren’t linked to real customers, and are limited to internal data only. They do not need to be excluded.
Those environments contain a copy of the public website, meaning they don’t use URL fragments either.
Unless the engineering team is actively working on the search feature of the website, they don’t have any specific requirements to track keywords entered in the search bar.

The company uses three different Messenger configurations for their public-facing website, their development, and testing environments to manage their three stages of development. If all three of their web tracking settings were configured to the centralized legacy settings under Predictive Engagement, the company might have to compromise:

The amount of data tracked for their internal environments, reducing the engineering team’s visibility to complete development tasks and testing, while avoiding capturing sensitive user data from the public-facing website.
Capturing unfiltered data to accommodate development and testing needs by leaving web tracking settings by default, which leads to collecting sensitive user data in the public-facing website, breaching privacy compliance.

Knowing the risks, the company chose to separate their web tracking configuration as illustrated as follows, by specifying specific values in the public-facing website’s Messenger configuration to align tracking behavior with their business needs and data compliance. Both the Messenger configurations dedicated to development and testing are also configured to Messenger-Specific web tracking settings, using the default tracking values, that is, no user is ignored and all URL query parameters are tracked. This ensures all navigation data is collected:

Field name	Messenger Configuration – Public	Messenger Configuration – Dev	Messenger Configuration – Testing
Exclude IP Addresses	203.0.113.10 – Marketing team 250.93.249.84 – Dev team 175.210.177.40 – Company	None	None
Exclude URL Query Parameter	id, token	None	None
Track URL Fragments	No	No	No
Track User Searches	q	None	None

Scenario 4: Test a web tracking configuration

An administrator user is in charge of web tracking implementation for their company. They want to exclude internal employees’ IP addresses and sensitive user data from being tracked in their public-facing website, while recording keywords searched by web visitors. Before applying them to their public-facing website in production, they must ensure that their Messenger-Specific web tracking settings are defined appropriately. They edit their Messenger configuration to specify the internal employees IP addresses, the query parameters storing unwanted data, and the query parameter used to store terms searched by users. A new Messenger configuration version is created as follows:

Field name	Messenger configuration A – version 1	Messenger configuration A – version 2
Exclude IP Addresses	None	203.0.113.10 – Marketing team 250.93.249.84 – Dev team 175.210.177.40 – Company
Exclude URL Query Parameter	None	id, token
Track URL Fragments	No	No
Track User Searches	None	q

In a Messenger Deployment created for testing purposes, named Test Env, the administrator selects the latest Messenger configuration version they created, containing the new web tracking settings. Meanwhile, their previous Messenger configuration version, which contains default Messenger-Specific web tracking settings, is still the version in production:

Messenger deployment Name	Messenger configuration selected
Production	Messenger configuration A – version 1
Test Env	Messenger configuration A – version 2

The administrator simulates a web visitor’s journey by navigating in their testing environment where those new settings apply. The administrator realizes they’re losing a considerable amount of data by leaving URL fragment tracking disabled by default. Their navigation is only partially tracked. Several pages they visited during their test are missing in the customer journey view. The administrator creates a new Messenger configuration version with URL fragment tracking enabled.

Field name	Messenger configuration A – version 1	Messenger configuration A – version 2	Messenger configuration A – version 3
Exclude IP Addresses	None	203.0.113.10 – Marketing team 250.93.249.84 – Dev team 175.210.177.40 – Company	203.0.113.10 – Marketing team 250.93.249.84 – Dev team 175.210.177.40 – Company
Exclude URL Query Parameter	None	id, token	id, token
Track URL Fragments	No	No	Yes
Track User Searches	None	q	q

Once again, the latest web tracking configuration must be tested before being deployed to production. The administrator edits their Test Env Messenger deployment to assign the latest Messenger configuration version that includes URL fragment tracking.

Messenger Deployment Name	Messenger configuration selected
Production	Messenger Configuration A – version 1
Test Env	Messenger Configuration A – version 3

The new configuration tracks all webpages as expected, aligning with the business requirements. The administrator can now safely deploy the latest Messenger configuration version to production to apply those web tracking settings to their public-facing website:

Messenger deployment Name	Messenger configuration selected
Production	Messenger Configuration A – version 3
Test Env	Messenger Configuration A – version 3

[NEXT] Was this article helpful?

Get user feedback about articles.