Examples of adapting tracking settings by website

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:

1. Scenario 1: Multiple websites with different web tracking requirements
2. Scenario 2: Address ownership ambiguity and configuration clutter by separating configurations
3. Scenario 3: Allow default web tracking configuration
4. Scenario 4: Test a web tracking configuration

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:

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

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:

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:

• 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:

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:

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.

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:

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:

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:

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.

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.

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: