Pass on UTM Parameters From One Page To Another within the domain

[UjjwalChandra]

Hello Community,
Do we have any solution in Adobe Analytics or Launch where we can pass on the UTM paramters from one page to anaother without losing the data e.g.;
Page A: www.example01.com?utm_source=newsletter&utm_medium=email&utm_campaign=campaign01
Page B: https://www.example02.com

Want to pass the UTMs in Page A to Page B when someone clicks on PageB (which is a link within my Landing Page A)
Thanks!

[Jude_Felix]

Hey @UjjwalChandra 

If you want the UTM parameters to persist across all pages a user visits during the session:

1. On the landing page (Page A):

   • Use Launch to detect and store the utm_source, utm_medium, etc. in localStorage or a first-party cookie.

2. On subsequent pages:

   • Use Launch to read those values and:

     • Send them with Adobe Analytics tracking calls.

     • Optionally append them back to URLs (e.g., for link tracking or if needed in outbound links).

   This approach does not work for cross-domain. 

[UjjwalChandra]

Thanks @Jude_Felix ,
Is there any documentation for the above solution you provided. We do not want to do it for all pages it is just a one-of request from a regional team.

[EurosIMS]

@UjjwalChandra When you say you want them passed, what do you mean? Do you want the UTMs added back to the URL on page B load, passed as v0/another eVar on page B, or if page A loads with a utm query string do you want those added to the href of the link to page B the user could click on, on page A? 

[pradnya_balvir]

Hi @UjjwalChandra ,

Yes, this is a common use case in multi-page/multi-domain tracking.

Adobe Launch do not automatically persist UTM parameters across pages or domains, but you can implement a solution using Adobe Launch (Tags) to carry forward UTM parameters from Page A to Page B.

Pass UTM Parameters Using Adobe Launch (Client-side JavaScript)

Step 1: Create a Data Element for UTM Parameters

In Adobe Launch:

• Go to Data Elements.
• Create a new one (e.g., query string - utm_source, utm_medium, etc.)
• Use the built-in type: Query String Parameter.

•  

Step 2: Create a Rule to Modify the Link to Page B

Rule Name: Append UTM Params to Outgoing Link to Page B

Event:

Click on links (use a CSS selector or delegate all a clicks).

Condition:

Check if the link URL contains example02.com.

Action:

JavaScript code that appends UTM parameters to the href of the link before navigation.

Example code for action:

// Collect UTM params from the current page
var urlParams = new URLSearchParams(window.location.search);
var utmParams = ['utm_source', 'utm_medium', 'utm_campaign'];

var paramString = utmParams
.map(p => urlParams.get(p) ? `${p}=${encodeURIComponent(urlParams.get(p))}` : '')
.filter(Boolean)
.join('&');

if (paramString && event.target.href.includes('example02.com')) {
var link = event.target;
var baseUrl = link.href.split('?')[0]; // remove existing params if needed
link.href = baseUrl + '?' + paramString;
}

Or

If you don’t want to expose UTMs in the URL, store them in:

• sessionStorage/localStorage
• or first-party cookie via Adobe Launch
• Then read them on Page B via Launch Data Elements and use them in analytics calls or to dynamically modify links.

Thanks.

Pradnya

[Jennifer_Dungan]

Regardless of same domain or cross domain, so long as a user is properly identified as the same person on subsequent pages, if you are tracking your UTMs in a Visit or higher expiry dimension, you shouldn't need to do anything to maintain the values... and forcibly re-tracking this data on subsequent pages is NOT in your best interest.

Tracking Code is the main way for tracking this, it has a default expiry of 1 week, I will also add eVar1 with a Visit expiry into my example)

Visit 1

• Page 1 (www.domain.com/?utm_source=x&utm_medium=y&utm_campaign=z)
  • Tracking Code explicitly set to "x:y:z"
  • Tracking Code Instance is triggered
  • eVar1 is explicitly set to "x:y:z"
  • eVar1 Instance is triggered
• Page 2 (www.domain.com/somepage/)
  • Tracking Code persists the value of "x:y:z"
  • Tracking Code Instance is NOT triggered
  • eVar1 persists the value of "x:y:z"
  • eVar1 Instance is NOT triggered
• Page 3 (Moved to another domain on the same tracking suite, with the same ECID - www.hubdomain.com/) (Note, this 100% works, as we have this in our implementation)
  • Tracking Code persists the value of "x:y:z"
  • Tracking Code Instance is NOT triggered
  • eVar1 persists the value of "x:y:z"
  • eVar1 Instance is NOT triggered

Visit 2

• Page 1 (www.domain.com/)
  • Tracking Code persists the value of "x:y:z"
  • Tracking Code Instance is NOT triggered
  • eVar1 is not set (value has expired)
  • eVar1 Instance is NOT triggered

The reason it's important to distinguish the Instance from the persisted value is that looking at the Instance will tell you the explicit entries using that campaign code, versus looking at the pages, and eventual conversions that are tied to that campaign based on the persistence.

Forcing every page to retrack (i.e. reset the value) on every page is actual going to break standard behaviours.

And while yes, technically you could use segment logic to look at non-repeating instances, you will actually break the available Instance metrics that you have available to you.

Now, if you are doing cross domain for sites tracked on different suites... that of course changes things... 

[bjoern__koth]

as long as the domains are different, you won't be able to store anything neither in a local/sessionStorage, nor a cookie. As @Jennifer_Dungan mentioned, this might really not be what you want.

however, if you are using the Visitor ID service, it might be worthwhile looking at this feature: https://experienceleague.adobe.com/en/docs/id-service/using/id-service-api/methods/appendvisitorid

or with web sdk

https://experienceleague.adobe.com/en/docs/experience-platform/web-sdk/commands/appendidentitytourl

In general, this will add user identity information to urls of a different domain when opened.
https://experienceleague.adobe.com/en/docs/experience-platform/web-sdk/commands/appendidentitytourl

This might be extended with UTM query params.

[Jennifer_Dungan]

But again, if the two domains are on the same tracking suite, and the same user is identified, there is no need to pass and set the UTMs on the second domain... Adobe will remember those value in the Visit, or 1 week, or 30 Days, etc attribution for that user natively... without inflating the "instance" values....