Add platform-level UTM capture support for authenticated MFE users

Problem

Today, UTM parameters are typically captured when unauthenticated users enter the platform through login or registration flows because Django receives the initial request.

However, when an already-authenticated learner lands directly on an MFE page via a marketing campaign URL, the page is rendered entirely client-side and Django never sees the initial page load. As a result, UTM parameters may be visible in the browser URL but are not automatically transmitted to backend services.

For authenticated users, this attribution information is currently lost unless each MFE implements its own custom solution.

Current Workarounds

Current approaches typically involve one or more of the following:

• Implementing UTM capture independently in every MFE
• Relying solely on third-party analytics solutions
• Propagating UTM parameters through internal navigation

These approaches duplicate logic across repositories and require ongoing maintenance whenever new MFEs are introduced.

Proposal

Add generic UTM capture support to frontend-platform so that all MFEs using the framework can benefit automatically.

1. Capture UTM parameters during initialization

Introduce a small utility that:

• Reads standard UTM parameters from the current URL
• Captures:
  • utm_source
  • utm_medium
  • utm_campaign
  • utm_term
  • utm_content
• Persists them in a configurable cookie

The utility would be invoked from initialize() so capture occurs before authentication setup and outbound API requests.

2. Attach captured UTM data to authenticated requests

Add an interceptor to the authenticated HTTP client that:

• Reads the stored UTM payload
• Includes it in outbound authenticated requests through a dedicated header (for example, X-Openedx-Utm-Params)

This also provides a fallback path for environments where cookie-based transport may be restricted.

3. Cleanup on logout

Remove the stored UTM data during logout to avoid attribution data persisting across sessions on shared devices.

Benefits

• No per-MFE implementation required
• Works across existing and future MFEs built on frontend-platform
• Provides a consistent mechanism for transporting attribution data
• Reduces duplication across repositories
• Fully additive and inactive when no UTM parameters are present

Questions for Discussion

• Is UTM capture considered an appropriate responsibility for frontend-platform?
• Is a cookie + request-header approach acceptable, or is there a preferred platform-level mechanism?
• Is initialize() the right integration point for capturing campaign parameters?
• Are there privacy, security, or configurability concerns that should be addressed before adopting this capability?

Additional Context

This issue is based on an RFC proposing a platform-wide solution for preserving UTM attribution for authenticated learners landing directly on MFE pages from external campaigns.

The frontend-platform changes described here are intended to provide the generic capture and transport layer, while backend persistence and attribution modeling would remain separate concerns.

Start by tracing initialize(), the authenticated HTTP client, and logout in frontend-platform to identify the integration points for capture, transport, and cleanup. Review the RFC context and existing configuration patterns before deciding how the cookie and request header should work. Done means authenticated MFE requests consistently carry captured UTM data and logout removes it, with no behavior change when no UTM parameters are present.