How I Implemented Cross-Domain Tracking at Usermaven

As a developer at Usermaven, one of the most common feature requests we received from customers was the ability to track users seamlessly across multiple domains and websites.

Without cross-domain tracking, our analytics platform suffered from a fragmented view of customer journeys. The Usermaven tracker would assign each user a unique ID cookie, but this was restricted to the domain it was created on.

So if a user visited:

• example.com (Anon ID: 1234)
• example.org (Anon ID: 5678)

They would appear as two completely separate users in the analytics, even though it was the same person browsing multiple sites owned by the same company.

This made it impossible to understand the full picture of how users engaged across domains or create unified audience segments. It was a huge analytics blindspot.

In this post, I’ll walk you through how I designed and implemented a transparent cross-domain tracking solution to address this critical gap in our analytics platform.

Understanding the Problem Space

Before designing a solution, I needed to fully understand the technical constraints around cross-domain tracking:

• Browser cookies are restricted to the domain they are created on due to privacy reasons. There is no built-in method for cookies to be synchronized across domains.
• Subdomains present an additional challenge. The solution needed to work across subdomains like app.example.com and example.com.
• User data and privacy had to be protected. Nothing identifying about the user could be shared across domains.
• The user experience could not be impacted. Any solution had to work seamlessly in the background without interruptions.
• Required minimal implementation work. The tracking had to work automatically once added to the websites.

With these requirements in mind, I explored different approaches to connect the user identifiers.

Designing a Seamless Tracking Solution

I went through several iterations before landing on the ideal approach. Here were some of the options I considered:

Iframes - Loading one domain inside an iframe on another to sync cookies. This posed security issues and would be detected by browsers.

Redirect Chains - Redirecting users through multiple domains to link accounts. Too much redirection would frustrate users.

Query Parameters - Passing the user ID via URL parameters. Emerged as the best option.

Passing the user ID through query parameters gave me a way to link accounts that:

• Worked seamlessly in the background without interruption
• Required no extra implementation after initial setup
• Was secure - only passing an anonymous ID without personal data

Here is how it worked:

When a user clicked a link to move from Domain A to Domain B, the tracker would append a URL parameter ?um_id=1234 containing the user’s anonymous ID to the link.

For example:

example.com/page —> example.org/page?um_id=1234

When the new domain loaded, the tracker would check the URL parameters for the um_id and extract the ID value. It would set this as the user identifier to continue the analytics session seamlessly across domains.

This allowed linking a user’s journey while keeping all personal information isolated within each domain.

Building the Tracking Logic

With the approach decided, I got to work implementing the logic in JavaScript that would power the cross-domain tracking.

The core logic consisted of two key parts:

1. Appending ID to Outbound Links

Whenever a user clicked on a link to an external domain, the tracker would intercept the click event and append the ?um_id=1234 parameter to the link URL.

This involved adding an event listener to identify outbound clicks and use the existing getUserId() method to retrieve the current user’s analytics ID:

// Listen for link clicks
document.addEventListener('click', event => {

  // Identify link element
  const link = findClosestLink(event.target); 
  
  if (isExternalDomain(link)) {
  
    // Get current user analytics ID 
    const userId = getUserId();
  
    // Append to href as parameter
    link.setAttribute('href', `${link.href}?um_id=${userId}`);
    
  }
});

2. Reading ID Parameter on Page Load

Next, I added logic to check for the um_id URL parameter when each page loaded, and sync the passed ID:

// On page load
const url = new URL(window.location);

// Check for um_id param
const userId = url.searchParams.get('um_id'); 

if (userId) {

  // Set as user ID
  syncUser(userId);
}

This handled transferring the user ID on the new page to continue tracking the user seamlessly.

You can view the full cross-domain tracking logic here in the Usermaven JavaScript tracker.

Measuring the Impact

Launching cross-domain tracking dramatically increased the data visibility for our customers.

Other impacts included:

• Full user journeys across domains revealed new conversion funnels they never knew existed.
• Audiences could now be seamlessly targeted across domains through unified segments.
• Attribution models became significantly more accurate with the connected data.
• On-site personalization improved with a complete view of each user.

Our support and sales teams also noticed an uptick in positive feedback after rolling out cross-domain tracking to customers, which was fulfilling to see.

Results and Learnings

Delivering this feature was a collaborative effort between our dev, product, and customer success teams.

Building cross-domain tracking not only leveled up our analytics capabilities but also gave me insights into how to approach complex tracking challenges:

• Start by thoroughly understanding the problem space - don’t make assumptions.
• Design solutions focused on seamless user experience.
• Leverage browser mechanisms like query params before trying complex custom approaches.
• Collaborate closely across teams and gather regular customer feedback.

I’m proud of the solution we shipped - but it’s just one step in our journey to unlock more value through analytics. If you’re facing any product analytics challenges, I want to hear from you!