Pass on UTM Parameters From One Page To Another within the domain | Community
Skip to main content
UjjwalChandra
UjjwalChandra
Level 2
July 17, 2025
Question

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

  • July 17, 2025
  • 4 replies
  • 871 views

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!

4 replies

Jude_Felix
Jude_Felix
Level 2
July 17, 2025

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
    UjjwalChandraAuthor
    Level 2
    July 17, 2025

    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
    EurosIMS
    Level 3
    July 17, 2025

    @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
    Community Advisor
    pradnya_balvirCommunity Advisor
    Community Advisor
    July 17, 2025

    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
      Community Advisor and Adobe Champion
      Jennifer_DunganCommunity Advisor and Adobe Champion
      Community Advisor and Adobe Champion
      July 17, 2025

      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
        Community Advisor and Adobe Champion
        bjoern__kothCommunity Advisor and Adobe Champion
        Community Advisor and Adobe Champion
        July 19, 2025

        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.

         

        Cheers from Switzerland!
        Jennifer_Dungan
        Community Advisor and Adobe Champion
        Jennifer_DunganCommunity Advisor and Adobe Champion
        Community Advisor and Adobe Champion
        July 22, 2025

        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....

        Terms & ConditionsAccessibility statement

        Loading footer...