LogRocket Cross-Domain Tracking

Configure LogRocket to maintain session continuity across multiple domains and subdomains.

Cross-Domain Tracking Overview

LogRocket supports cross-domain tracking to maintain session continuity when users navigate between different domains (e.g., marketing-site.com → app.example.com). Without cross-domain tracking, each domain creates a new session, breaking the user journey and making it difficult to understand full user context.

When You Need Cross-Domain Tracking

Scenarios requiring cross-domain tracking:

Marketing site on one domain, application on another (e.g., example.com → app.example.com)
Checkout flow on different domain (e.g., shop.com → checkout.shop.com)
Documentation site separate from product (e.g., docs.example.com → app.example.com)
White-label or partner sites that redirect to main application
Multiple subdomains with separate applications (admin.example.com, dashboard.example.com)

When cross-domain tracking is NOT needed:

All pages on same root domain and subdomain
Single-page applications without domain transitions
Completely separate products that should have separate sessions

Enabling Cross-Domain Tracking

Enable cross-domain tracking during LogRocket initialization on all domains that should share sessions.

Configuration:

LogRocket.init('your-app/project-name', {
  crossDomainTracking: true
});

This tells LogRocket to:

Append session ID as URL parameter when navigating to allowed domains
Read session ID from URL parameter on new domain and continue existing session
Maintain session state across domain boundaries

Configuring Allowed Domains

For security and privacy, specify which domains can share session IDs.

Via LogRocket Dashboard:

Navigate to Settings → Privacy → Cross-Domain Tracking
Add all domains that should share sessions:
- example.com
- app.example.com
- checkout.example.com
- docs.example.com
Save configuration

Via Code (Legacy Method):

// Not recommended - use dashboard configuration instead
LogRocket.init('your-app/project-name', {
  crossDomainTracking: true,
  shouldParseXHRBlob: true
});

Implementation Steps

1. Initialize on All Domains

Ensure LogRocket is initialized with the same app ID and cross-domain tracking enabled on all domains.

Domain A (marketing-site.com):

import LogRocket from 'logrocket';

LogRocket.init('your-app/project-name', {
  crossDomainTracking: true
});

Domain B (app.example.com):

import LogRocket from 'logrocket';

LogRocket.init('your-app/project-name', {
  crossDomainTracking: true
});

2. Configure Allowed Domains

Add all domains to allowed list in LogRocket dashboard (Settings → Privacy → Cross-Domain Tracking):

marketing-site.com
app.example.com

3. Verify Session ID Parameter

When navigating from one domain to another, LogRocket automatically appends lr-session-id parameter:

Before: https://app.example.com/dashboard
After:  https://app.example.com/dashboard?lr-session-id=abc123xyz

4. Test Session Continuity

Start session on Domain A (e.g., marketing-site.com)
Note the session URL: LogRocket.sessionURL
Navigate to Domain B (e.g., app.example.com)
Verify session URL remains the same
Check session replay shows activity on both domains

Advanced Configuration

Preserving URL Parameters

Ensure session ID parameter doesn't interfere with existing URL parameters or analytics.

Clean URL Parameter After Session Resume:

LogRocket.init('your-app/project-name', {
  crossDomainTracking: true
});

// After LogRocket initializes, clean URL if desired
window.addEventListener('load', () => {
  const url = new URL(window.location);
  if (url.searchParams.has('lr-session-id')) {
    url.searchParams.delete('lr-session-id');
    window.history.replaceState({}, document.title, url.toString());
  }
});

Handling SPAs with Client-Side Routing

For single-page applications that use client-side routing across domains:

// React Router example
import { useEffect } from 'react';
import { useLocation } from 'react-router-dom';
import LogRocket from 'logrocket';

function App() {
  const location = useLocation();

  useEffect(() => {
    // LogRocket automatically tracks route changes
    // No additional code needed for cross-domain tracking
  }, [location]);

  return <AppContent />;
}

Iframe Cross-Domain Tracking

LogRocket can track sessions across iframes on different domains.

Parent Page:

LogRocket.init('your-app/project-name', {
  crossDomainTracking: true,
  dom: {
    recordCrossOriginIframes: true
  }
});

Iframe (different domain):

LogRocket.init('your-app/project-name', {
  crossDomainTracking: true
});

Note: Both parent and iframe must have LogRocket initialized with the same app ID.

Subdomain Tracking

Subdomains on the same root domain (e.g., app.example.com and admin.example.com) can share sessions without explicit cross-domain configuration if cookies are set at the root domain level.

Automatic Subdomain Sharing:

// LogRocket automatically shares sessions across subdomains
// if they're on the same root domain

LogRocket.init('your-app/project-name');
// Works across: app.example.com, admin.example.com, dashboard.example.com

Force Explicit Subdomain Control:

// If you need explicit control over which subdomains share sessions
LogRocket.init('your-app/project-name', {
  crossDomainTracking: true
});

// Then configure allowed domains in dashboard:
// - app.example.com
// - admin.example.com

Troubleshooting Cross-Domain Tracking

Sessions Breaking Across Domains

Symptom: New session starts when navigating to different domain.

Solutions:

Verify cross-domain tracking is enabled on both domains:

// Check on both domains
console.log('Cross-domain enabled:', LogRocket.crossDomainTracking);

Check allowed domains list:
- Go to LogRocket dashboard → Settings → Privacy → Cross-Domain Tracking
- Ensure both domains are listed
- Domain format should match exactly (with or without www)
Verify session ID parameter is being passed:
- Check URL when navigating: should see ?lr-session-id=abc123
- If missing, cross-domain tracking may not be enabled
Check for URL parameter stripping:
- Some frameworks or redirects may strip URL parameters
- Ensure lr-session-id parameter is preserved during navigation

Session ID Parameter Not Appearing

Symptom: URL parameter lr-session-id is not appended when navigating.

Solutions:

Initialize LogRocket before navigation:
- LogRocket must be initialized before user clicks link
- Check initialization order in application lifecycle
Verify link is to allowed domain:
- Session ID is only appended to domains in allowed list
- Check dashboard configuration

Test with direct link navigation:

// Test manual navigation
window.location.href = 'https://app.example.com/dashboard';
// URL should become: https://app.example.com/dashboard?lr-session-id=abc123

Session ID Parameter Stripped

Symptom: Session ID parameter is appended but then removed before LogRocket can read it.

Solutions:

Check for redirects that strip parameters:
- Server-side redirects may remove query parameters
- Ensure redirects preserve all URL parameters
Verify LogRocket initializes before parameter cleanup:
- If you have code that cleans URL parameters, ensure it runs after LogRocket reads the session ID
Check URL rewriting rules:
- .htaccess, nginx, or other rewrite rules may strip parameters
- Update rules to preserve lr-session-id

Privacy/Security Concerns with Session ID in URL

Symptom: Session IDs visible in browser history or analytics tools.

Solutions:

Clean URL after session resume:

// After LogRocket initializes and reads session ID
setTimeout(() => {
  const url = new URL(window.location);
  if (url.searchParams.has('lr-session-id')) {
    url.searchParams.delete('lr-session-id');
    window.history.replaceState({}, '', url.toString());
  }
}, 1000); // Wait for LogRocket to read parameter

Filter session IDs from analytics:

// Google Analytics example
gtag('config', 'GA_MEASUREMENT_ID', {
  page_path: window.location.pathname + window.location.search.replace(/lr-session-id=[^&]+&?/, '')
});

Best Practices

Do:

Initialize LogRocket on all domains that should share sessions
Configure allowed domains in LogRocket dashboard
Test cross-domain navigation in all environments
Document which domains share sessions and why
Clean session ID from URL after initialization if desired

Don't:

Enable cross-domain tracking without configuring allowed domains
Share session IDs across untrusted domains
Strip URL parameters before LogRocket reads them
Forget to test domain transitions during QA

Validation Checklist

LogRocket initialized with crossDomainTracking: true on all domains
All domains added to allowed domains list in dashboard
Test navigation from Domain A to Domain B shows same session URL
Verify session replay captures activity on both domains
Check session ID parameter is appended to cross-domain links
Confirm URL parameters don't break existing functionality
Test in production-like environment (staging with actual domains)

Example: Multi-Domain E-commerce

Scenario: Marketing site on shop.com, checkout on checkout.shop.com

Implementation:

Initialize on marketing site (shop.com):

LogRocket.init('shop/production', {
  crossDomainTracking: true
});

Initialize on checkout site (checkout.shop.com):

LogRocket.init('shop/production', {
  crossDomainTracking: true
});

Configure allowed domains (LogRocket dashboard):
- shop.com
- checkout.shop.com
Test flow:
- User browses products on shop.com
- Clicks "Checkout" → redirects to checkout.shop.com?lr-session-id=abc123
- Same session continues on checkout domain
- Session replay shows full journey from browsing to purchase

Result: Single session captures entire user journey across both domains, making it easy to debug checkout abandonment or understand full conversion funnel.

Additional Resources:

返回顶部